[Nouveau] [Fwd: [PATCH] Fix null dereference oopses for nv40 cards] kernel 3.13.0-rc8
Seems to work OK thanks.
Bob
On Tue, 2014-01-14 at 15:15 +1000, Ben Skeggs wrote:
> On Tue, Jan 14, 2014 at 3:07 PM, Ben Skeggs wrote:
> > On Tue, Jan 14, 2014 at 1:22 PM, Bob Gleitsmann
> > 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?
> Thinko in first attempt, new one attached.
>
> >
> > Ben.
> >
> >>
> >> Sorry about that.
> >>
> >> Bob
> >> Forwarded Message
> >> From: Bob Gleitsmann
> >> 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 2014 01:45:36 -0500
> >>
> >> The problem affects nv40 cards during booting. It comes from there being
> >> two places where subdev arrays are maintained. A commit was recently
> >> added to make the two equal. However, the struct nouveau_device version
> >> ends up being referenced before it is initialized. The problem arises
> >> during the creation of the INSTMEM and THERM subdevs. '
> >>
> >> Signed off by: Bob Gleitsmann rjgleits at bellsouth.net
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
> >> b/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
> >> index b10a143..0f494ca 100644
> >> --- a/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
> >> +++ b/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
> >> @@ -23,6 +23,7 @@
> >> */
> >>
> >> #include
> >> +#include
> >>
> >> #include "nv04.h"
> >>
> >> @@ -38,6 +39,7 @@ nv40_instmem_ctor(struct nouveau_object *parent, struct
> >> nouveau_object *engine,
> >>
> >> ret = nouveau_instmem_create(parent, engine, oclass, );
> >> *pobject = nv_object(priv);
> >> + device->subdev[NVDEV_SUBDEV_INSTMEM] = *pobject;
> >> if (ret)
> >> return ret;
> >>
> >> diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
> >> b/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
> >> index 002e51b..59b25be 100644
> >> --- a/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
> >> +++ b/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
> >> @@ -187,9 +187,11 @@ nv40_therm_ctor(struct nouveau_object *parent,
> >> {
> >> struct nv40_therm_priv *priv;
> >> int ret;
> >> + struct nouveau_device *device = nv_device(parent);
> >>
> >> ret = nouveau_therm_create(parent, engine, oclass, );
> >> *pobject = nv_object(priv);
> >> + device->subdev[NVDEV_SUBDEV_THERM] = *pobject;
> >> if (ret)
> >> return ret;
> >>
> >>
> >>
> >>
> >> ___
> >> Nouveau mailing list
> >> Nouveau at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/nouveau
[Fwd: [PATCH] Fix null dereference oopses for nv40 cards] kernel 3.13.0-rc8
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 <rjgle...@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 2014 01:45:36 -0500
The problem affects nv40 cards during booting. It comes from there being
two places where subdev arrays are maintained. A commit was recently
added to make the two equal. However, the struct nouveau_device version
ends up being referenced before it is initialized. The problem arises
during the creation of the INSTMEM and THERM subdevs. '
Signed off by: Bob Gleitsmann rjgleits at bellsouth.net
diff --git a/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
b/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
index b10a143..0f494ca 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include "nv04.h"
@@ -38,6 +39,7 @@ nv40_instmem_ctor(struct nouveau_object *parent, struct
nouveau_object *engine,
ret = nouveau_instmem_create(parent, engine, oclass, );
*pobject = nv_object(priv);
+ device->subdev[NVDEV_SUBDEV_INSTMEM] = *pobject;
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
b/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
index 002e51b..59b25be 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
@@ -187,9 +187,11 @@ nv40_therm_ctor(struct nouveau_object *parent,
{
struct nv40_therm_priv *priv;
int ret;
+ struct nouveau_device *device = nv_device(parent);
ret = nouveau_therm_create(parent, engine, oclass, );
*pobject = nv_object(priv);
+ device->subdev[NVDEV_SUBDEV_THERM] = *pobject;
if (ret)
return ret;
[PATCH] Fix null dereference oopses for nv40 cards
The problem affects nv40 cards during booting. It comes from there being
two places where subdev arrays are maintained. A commit was recently
added to make the two equal. However, the struct nouveau_device version
ends up being referenced before it is initialized. The problem arises
during the creation of the INSTMEM and THERM subdevs. '
Signed off by: Bob Gleitsmann rjgleits at bellsouth.net
diff --git a/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
b/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
index b10a143..0f494ca 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/instmem/nv40.c
@@ -23,6 +23,7 @@
*/
#include
+#include
#include "nv04.h"
@@ -38,6 +39,7 @@ nv40_instmem_ctor(struct nouveau_object *parent, struct
nouveau_object *engine,
ret = nouveau_instmem_create(parent, engine, oclass, );
*pobject = nv_object(priv);
+ device->subdev[NVDEV_SUBDEV_INSTMEM] = *pobject;
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
b/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
index 002e51b..59b25be 100644
--- a/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
+++ b/drivers/gpu/drm/nouveau/core/subdev/therm/nv40.c
@@ -187,9 +187,11 @@ nv40_therm_ctor(struct nouveau_object *parent,
{
struct nv40_therm_priv *priv;
int ret;
+ struct nouveau_device *device = nv_device(parent);
ret = nouveau_therm_create(parent, engine, oclass, );
*pobject = nv_object(priv);
+ device->subdev[NVDEV_SUBDEV_THERM] = *pobject;
if (ret)
return ret;
[Fwd: [Patch] drm/nouveau: nouveau/nouveau_abi16.c does not return offset of allocated notifier]
I think this may have been overlooked, but it does make a difference. BTW, the comments in the code state that the fence has to be at zero offset in the page. In the course of investigating this problem I found that this is not the case, at least for the 6800 Ultra. I have it located at f80 and it works correctly. Or seems to. Best Wishes, Bob -- next part -- An embedded message was scrubbed... From: Bob Gleitsmann <rjgle...@bellsouth.net> Subject: [Patch] drm/nouveau: nouveau/nouveau_abi16.c does not return offset of allocated notifier Date: Sat, 14 Sep 2013 01:40:23 -0400 Size: 4806 URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20131106/e78765f2/attachment.mht>
[Patch] drm/nouveau: nouveau/nouveau_abi16.c does not return offset of allocated notifier
Hi, The following patch fixes problems retrieving query results. I have tested it on nv40 - 6800 Ultra. Best Wishes, Bob --- a/drivers/gpu/drm/nouveau/nouveau_abi16.c +++ b/drivers/gpu/drm/nouveau/nouveau_abi16.c @@ -445,6 +445,7 @@ nouveau_abi16_ioctl_notifierobj_alloc(ABI16_IOCTL_ARGS) sizeof(args), object); if (ret) goto done; + info-offset = ntfy-node-offset; done: if (ret) ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Problems caused by commit 6803ed69994a14824081adbf1b58fd21a9966215 to 2.6.38-rc5
Good day, night, or whatever, The above mentioned commit which changed the flags passed to nouveau_gem_new to domain creates a problem in nouveau_notifier_init_channel (in nouveau_notifier.c) when it calls nouveau_bo_pin with the domain flags. That function seems to want TTM_PL_FLAGs. If this problem is not fixed, notifier allocation during channel allocation goes awry the kernel thinks that the gpu is locked up and switches to software fbcon, and X is gone. The solution is obvious. However, I am not clear on what the original purpose of the patch was nor why the TTM placement flags and the NOUVEAU placement flags are reversed for GART and VRAM. I'm not saying there isn't a good reason, I just don't know what it is. The choices are: 1. Revert the patch 2. Add code to nouveau_notifier_init_channel to pass the TTM_PL_FLAGS to nouveau_bo_pin. 3. Change nouveau_bo_pin so that it accepts the nouveau domain flags, and fix every place that nouveau_bo_pin is called (not all that many) to give it the flags it will then expect. 4. None of the above Maybe this is only a problem with earlier cards. I have a 6800 Ultra. It's hard to believe that no one else noticed it for a month as it's pretty difficult to ignore. Best Wishes, Bob Gleitsmann
Problems caused by commit 6803ed69994a14824081adbf1b58fd21a9966215 to 2.6.38-rc5
Good day, night, or whatever, The above mentioned commit which changed the flags passed to nouveau_gem_new to domain creates a problem in nouveau_notifier_init_channel (in nouveau_notifier.c) when it calls nouveau_bo_pin with the domain flags. That function seems to want TTM_PL_FLAGs. If this problem is not fixed, notifier allocation during channel allocation goes awry the kernel thinks that the gpu is locked up and switches to software fbcon, and X is gone. The solution is obvious. However, I am not clear on what the original purpose of the patch was nor why the TTM placement flags and the NOUVEAU placement flags are reversed for GART and VRAM. I'm not saying there isn't a good reason, I just don't know what it is. The choices are: 1. Revert the patch 2. Add code to nouveau_notifier_init_channel to pass the TTM_PL_FLAGS to nouveau_bo_pin. 3. Change nouveau_bo_pin so that it accepts the nouveau domain flags, and fix every place that nouveau_bo_pin is called (not all that many) to give it the flags it will then expect. 4. None of the above Maybe this is only a problem with earlier cards. I have a 6800 Ultra. It's hard to believe that no one else noticed it for a month as it's pretty difficult to ignore. Best Wishes, Bob Gleitsmann ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
