similar to: [PATCH] Fix null dereference oopses for nv40 cards

I should have mentioned that this applies to Linus' 3.13.0-rc7 and rc8 git. Maybe it's obvious. Sorry about that. Bob -------- Forwarded Message -------- From: Bob Gleitsmann <rjgleits at bellsouth.net> To: bskeggs at redhat.com Cc: nouveau at lists.freedesktop.org, dri-devel at lists.freedesktop.org Subject: [PATCH] Fix null dereference oopses for nv40 cards Date: Mon, 13 Jan

On Tue, Jan 14, 2014 at 1:22 PM, Bob Gleitsmann <rjgleits at bellsouth.net> wrote: > I should have mentioned that this applies to Linus' 3.13.0-rc7 and rc8 > git. Maybe it's obvious. Hey Bob, Thanks for reporting this. Can you try the attached patch instead and report if it helps you? Ben. > > Sorry about that. > > Bob > -------- Forwarded Message --------

On Tue, Jan 14, 2014 at 3:07 PM, Ben Skeggs <skeggsb at gmail.com> wrote: > On Tue, Jan 14, 2014 at 1:22 PM, Bob Gleitsmann <rjgleits at bellsouth.net> wrote: >> I should have mentioned that this applies to Linus' 3.13.0-rc7 and rc8 >> git. Maybe it's obvious. > Hey Bob, > > Thanks for reporting this. Can you try the attached patch instead and >

Current uninitialized sensor detection does not work for me on nv4b and sensor returns crazy values (>190?C). It stabilises later, but it's too late - therm code shutdowns the machine... Let's just reset it on init. Signed-off-by: Marcin Slusarz <marcin.slusarz at gmail.com> --- drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c | 12 +++++++++++- 1 file changed, 11

Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu> --- drivers/gpu/drm/nouveau/core/engine/graph/nv40.h | 3 +++ drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c | 10 ++-------- 2 files changed, 5 insertions(+), 8 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nv40.h b/drivers/gpu/drm/nouveau/core/engine/graph/nv40.h index 7da35a4..ad82093 100644 ---

This is a workaround to avoid the instmem backup/restore during the suspend and resume process in nv50 instemem driver. Signed-off-by: Vince Hsu <vinceh at nvidia.com> --- drm/Kbuild | 1 + nvkm/engine/device/nve0.c | 2 +- nvkm/include/subdev/instmem.h | 1 + nvkm/subdev/instmem/gk20a.c | 70 +++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 73

On Tue, Dec 23, 2014 at 5:40 AM, Vince Hsu <vinceh at nvidia.com> wrote: > This is a workaround to avoid the instmem backup/restore during the suspend > and resume process in nv50 instemem driver. > > Signed-off-by: Vince Hsu <vinceh at nvidia.com> > --- > drm/Kbuild | 1 + > nvkm/engine/device/nve0.c | 2 +- >

From: Martin Peres <martin.peres at labri.fr> Signed-off-by: Martin Peres <martin.peres at free.fr> --- drm/Kbuild | 1 + drm/core/subdev/therm/gm107.c | 1 + nvkm/engine/device/gm100.c | 4 +- nvkm/include/subdev/therm.h | 1 + nvkm/subdev/therm/Makefile.am | 3 +- nvkm/subdev/therm/fan.c | 9 ++++- nvkm/subdev/therm/gm107.c | 93

Hello all, Two oopses were found by zhaoyao and Daniel Blueman. Patch against 2.4.23 and 2.6.0-test10 is here. It will be included in next kernel releases of course. ------------------------------- Martin Devera aka devik Linux kernel QoS/HTB maintainer http://luxik.cdi.cz/~devik/ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl

Hi, We've been experiencing repeated (every other day) oopses on hosts with high load glusterfs accesses. Co-occurrent (not immediately tho, but there is some sort of connection) are hanging nginx processes (doing the accessing), which can not be stopped, killed and also block the shutdown of the respective openvz instance. I think I remember at least one instance where this occurred without

This is with last night''s Xen snapshot (apr 24th), on kernel 2.6.12-rc3 - but the mess is so horrid that I''m not quite sure how to fix it... This oops prevents xen from starting xenU domains. Basically xend does the following: 1) mmap /proc/xen/privcmd 2) call an ioctl to populate the mmap 3) munmap the mapping created in (1) During the munmap, the dom0 kernel oopses, as

OK - this is starting to get frustrating... Are there any known issues with 2.6.9 and traffic shaping? I am using 2.6.9 with geoip 20041115, and get odd oopses. The following script oopses my box: ----------------------------------------------------- #!/bin/sh -x IFOUT=''eth1'' IFIN=''eth0'' TC=''/sbin/tc''

Hello, I have been looking at cubic texture mapping for a bit, and I have found that hw mipmap generation doesn't work at all or the textures are all messed up (normal 2d work fine). This is with linear textures. Also of note is that software mipmap generation works fine. I have done sanity checks for the miptree pitches, offsets, etc and everything seems to match up fine for both the

Bonjour. (1) Is there any other open source GPU backend in LLVM? (2) I'd like to know the current status and plan of NV40 LLVM backend. Does it work? I cloned from git://anongit.freedesktop.org/~marcheu/llvm, but it seems that a lot of code are stilling missing. I've done a search on Nouveau wiki and mailing list but what I only found is: "Marcheu is working on and off on LLVM for

On Sun, Jan 25, 2009 at 10:58 AM, Jimmy Rentz <jedynamic at bellsouth.net> wrote: > Hello, > I was playing around with the OpenGlSuperBible samples and > noticed some odd issues around textures. Yes, I know it won't > be perfect right now (and not supported)...I am just curious > if you see the same issues. > Well, I am seeing some

ThibG from irc reported an issue with transparent cursors, i noticed the ddx had a workaround, which wasn't in the kms code. ThibG (whoever you are), please test. The patch is untested. Maarten. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-nv04-import-hw-workaround-for-partially-transparent-.patch Type: text/x-patch Size: 4908 bytes Desc: not

Currently in nvXX_transfer_new a temporary as large as the surface is created. If the subrectangle is not the whole texture we would need to read back the whole texture, but we aren't. Thus, everything but the subrectangle specified is loaded as garbage. This can be seen in progs/demos/ray. This patch fixes the problem by creating a temporary that covers only the desired subrectangle. This

--- src/gallium/drivers/nv40/nv40_fragprog.c | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/src/gallium/drivers/nv40/nv40_fragprog.c b/src/gallium/drivers/nv40/nv40_fragprog.c index 1237066..209d211 100644 --- a/src/gallium/drivers/nv40/nv40_fragprog.c +++ b/src/gallium/drivers/nv40/nv40_fragprog.c @@ -843,7 +843,8 @@ nv40_fragprog_translate(struct nv40_context *nv40,

In a message to the Nouveau mailing list (http://lists.freedesktop.org/archives/nouveau/2009-January/002166.html), you said that you cloned the git tree of Stephane Marchesin's NV40 LLVM work, at git://anongit.freedesktop.org/~marcheu/llvm That code has since been lost due to an hard drive crash. If you happened to still have that git tree on your hard drive, it would be extremely appreciated

On the Radeon IRC channel (http://www.radeonhd.org/?page=archive_display&c=radeon&m=1&y=2009&d=2009-1-26), you expressed interest in Corbin Simpson's R300 LLVM work, at git://anongit.freedesktop.org/~csimpson/llvm, which was based on Stephane Marchesin's earlier NV40 work. Both these projects have since been lost due to an hard drive crash. If you happened to still have