Ubuntu is shipping Chrome Version 44.0.2403.125 (64-bit). With this version of the browser and current tip-of-tree 86ea07ca846a I get the following error message followed by a lock-up of X.
nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[ PFIFO][0000:01:00.0] PFIFO: read fault at 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum 0x00000000)/GPC0/(unknown enum 0x0000000f) on channel 0x007f80c000 [unknown]
This patch suggests a fix for this with the kernel simply tolerating an application such as chrome requesting the same buffer more than once.
With the version of chrome given above, you can elicit this behaviour by clicking on the bookmarks drop down. This will open another window on-top of the current window. Minus the fix included here, this will lead to hard lockup of all windows on the desktop.
Chrome Version 44.0.2403.125 (64-bit) Linux 4.2.0-rc4+ 86ea07ca846a
People are suggesting running chrome with -disable-gpu however it is possible to run Chrome in it's default mode, so long as we tolerate the above behaviour.
Signed-off-by: Bryan O'Donoghue pure.logic@nexus-software.ie --- drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index af1ee51..a9694faad 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -401,9 +401,7 @@ retry: if (nvbo->reserved_by && nvbo->reserved_by == file_priv) { NV_PRINTK(error, cli, "multiple instances of buffer %d on " "validation list\n", b->handle); - drm_gem_object_unreference_unlocked(gem); - ret = -EINVAL; - break; + continue; }
ret = ttm_bo_reserve(&nvbo->bo, true, false, true, &op->ticket);
Is this happening with libdrm 2.4.60? If so, that's a known (user-side) issue and should be fixed by using any version but that one.
On Thu, Jul 30, 2015 at 6:28 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote:
Ubuntu is shipping Chrome Version 44.0.2403.125 (64-bit). With this version of the browser and current tip-of-tree 86ea07ca846a I get the following error message followed by a lock-up of X.
nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[ PFIFO][0000:01:00.0] PFIFO: read fault at 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum 0x00000000)/GPC0/(unknown enum 0x0000000f) on channel 0x007f80c000 [unknown]
This patch suggests a fix for this with the kernel simply tolerating an application such as chrome requesting the same buffer more than once.
With the version of chrome given above, you can elicit this behaviour by clicking on the bookmarks drop down. This will open another window on-top of the current window. Minus the fix included here, this will lead to hard lockup of all windows on the desktop.
Chrome Version 44.0.2403.125 (64-bit) Linux 4.2.0-rc4+ 86ea07ca846a
People are suggesting running chrome with -disable-gpu however it is possible to run Chrome in it's default mode, so long as we tolerate the above behaviour.
Signed-off-by: Bryan O'Donoghue pure.logic@nexus-software.ie
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index af1ee51..a9694faad 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -401,9 +401,7 @@ retry: if (nvbo->reserved_by && nvbo->reserved_by == file_priv) { NV_PRINTK(error, cli, "multiple instances of buffer %d on " "validation list\n", b->handle);
drm_gem_object_unreference_unlocked(gem);ret = -EINVAL;break;
continue; } ret = ttm_bo_reserve(&nvbo->bo, true, false, true, &op->ticket);-- 1.9.1
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
Is this happening with libdrm 2.4.60? If so, that's a known (user-side) issue and should be fixed by using any version but that one.
What's the freedesktop bugzilla # for reference?
Regards, Peter Hurley
On Thu, Jul 30, 2015 at 6:28 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote:
Ubuntu is shipping Chrome Version 44.0.2403.125 (64-bit). With this version of the browser and current tip-of-tree 86ea07ca846a I get the following error message followed by a lock-up of X.
nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[ PFIFO][0000:01:00.0] PFIFO: read fault at 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum 0x00000000)/GPC0/(unknown enum 0x0000000f) on channel 0x007f80c000 [unknown]
This patch suggests a fix for this with the kernel simply tolerating an application such as chrome requesting the same buffer more than once.
With the version of chrome given above, you can elicit this behaviour by clicking on the bookmarks drop down. This will open another window on-top of the current window. Minus the fix included here, this will lead to hard lockup of all windows on the desktop.
Chrome Version 44.0.2403.125 (64-bit) Linux 4.2.0-rc4+ 86ea07ca846a
People are suggesting running chrome with -disable-gpu however it is possible to run Chrome in it's default mode, so long as we tolerate the above behaviour.
Signed-off-by: Bryan O'Donoghue pure.logic@nexus-software.ie
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index af1ee51..a9694faad 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -401,9 +401,7 @@ retry: if (nvbo->reserved_by && nvbo->reserved_by == file_priv) { NV_PRINTK(error, cli, "multiple instances of buffer %d on " "validation list\n", b->handle);
drm_gem_object_unreference_unlocked(gem);ret = -EINVAL;break;
continue; } ret = ttm_bo_reserve(&nvbo->bo, true, false, true, &op->ticket);-- 1.9.1
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On Thu, Jul 30, 2015 at 10:46 AM, Peter Hurley peter@hurleysoftware.com wrote:
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
Is this happening with libdrm 2.4.60? If so, that's a known (user-side) issue and should be fixed by using any version but that one.
What's the freedesktop bugzilla # for reference?
I believe there may have been several, and also a number of reports on IRC as well since it took a few months to work out what was going on, but here's one:
https://bugs.freedesktop.org/show_bug.cgi?id=89842
I've recently filed a gentoo bug to drop the ebuild for libdrm-2.4.60 here:
https://bugs.gentoo.org/show_bug.cgi?id=556270
although it's not used by default there.
-ilia
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
Is this happening with libdrm 2.4.60? If so, that's a known (user-side) issue and should be fixed by using any version but that one.
What's the freedesktop bugzilla # for reference?
Regards, Peter Hurley
On Thu, Jul 30, 2015 at 6:28 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote:
Ubuntu is shipping Chrome Version 44.0.2403.125 (64-bit). With this version of the browser and current tip-of-tree 86ea07ca846a I get the following error message followed by a lock-up of X.
nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[ PFIFO][0000:01:00.0] PFIFO: read fault at 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum 0x00000000)/GPC0/(unknown enum 0x0000000f) on channel 0x007f80c000 [unknown]
This patch suggests a fix for this with the kernel simply tolerating an application such as chrome requesting the same buffer more than once.
With the version of chrome given above, you can elicit this behaviour by clicking on the bookmarks drop down. This will open another window on-top of the current window. Minus the fix included here, this will lead to hard lockup of all windows on the desktop.
Chrome Version 44.0.2403.125 (64-bit) Linux 4.2.0-rc4+ 86ea07ca846a
People are suggesting running chrome with -disable-gpu however it is possible to run Chrome in it's default mode, so long as we tolerate the above behaviour.
Signed-off-by: Bryan O'Donoghue pure.logic@nexus-software.ie
drivers/gpu/drm/nouveau/nouveau_gem.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c b/drivers/gpu/drm/nouveau/nouveau_gem.c index af1ee51..a9694faad 100644 --- a/drivers/gpu/drm/nouveau/nouveau_gem.c +++ b/drivers/gpu/drm/nouveau/nouveau_gem.c @@ -401,9 +401,7 @@ retry: if (nvbo->reserved_by && nvbo->reserved_by == file_priv) { NV_PRINTK(error, cli, "multiple instances of buffer %d on " "validation list\n", b->handle);
drm_gem_object_unreference_unlocked(gem);ret = -EINVAL;break;
continue; } ret = ttm_bo_reserve(&nvbo->bo, true, false, true, &op->ticket);-- 1.9.1
On 30/07/15 15:49, Peter Hurley wrote:
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
Is this happening with libdrm 2.4.60? If so, that's a known (user-side) issue and should be fixed by using any version but that one.
What's the freedesktop bugzilla # for reference?
Regards, Peter Hurley
I believe it's this one
On 30/07/15 15:52, Bryan O'Donoghue wrote:
On 30/07/15 15:49, Peter Hurley wrote:
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
Is this happening with libdrm 2.4.60? If so, that's a known (user-side) issue and should be fixed by using any version but that one.
What's the freedesktop bugzilla # for reference?
Regards, Peter Hurley
I believe it's this one
Not really a world of choice on ubuntu to fix it though...
deckard@aineko:~/Development/projectara$ apt-show-versions libdrm2 libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
:(
On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote:
On 30/07/15 15:52, Bryan O'Donoghue wrote:
On 30/07/15 15:49, Peter Hurley wrote:
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
Is this happening with libdrm 2.4.60? If so, that's a known (user-side) issue and should be fixed by using any version but that one.
What's the freedesktop bugzilla # for reference?
Regards, Peter Hurley
I believe it's this one
Not really a world of choice on ubuntu to fix it though...
deckard@aineko:~/Development/projectara$ apt-show-versions libdrm2 libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
:(
That's unfortunate. I know next to nothing about debian/ubuntu or how they do versions or how to even build packages for them. But they're big distros, presumably they have support teams of some sort, perhaps they can help you.
Assuming that switching away does resolve the issue for you, perhaps you can also recommend that they avoid shipping that version, or include this nouveau fix in it:
http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c7...
This whole libdrm thing is a bit of a cluster%@#$ unfortunately -- 2.4.60 is broken for nouveau, building even the latest released xf86-video-intel against 2.4.61+ causes it to not start ("fixed" in xf86-video-intel git), and newer mesa requires libdrm 2.4.60+.
-ilia
On 30/07/15 16:02, Ilia Mirkin wrote:
That's unfortunate. I know next to nothing about debian/ubuntu or how they do versions or how to even build packages for them. But they're big distros, presumably they have support teams of some sort, perhaps they can help you.
Assuming that switching away does resolve the issue for you, perhaps you can also recommend that they avoid shipping that version, or include this nouveau fix in it:
http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c7...
This whole libdrm thing is a bit of a cluster%@#$ unfortunately -- 2.4.60 is broken for nouveau, building even the latest released xf86-video-intel against 2.4.61+ causes it to not start ("fixed" in xf86-video-intel git), and newer mesa requires libdrm 2.4.60+.
-ilia
Matter of fact
apt-cache show libdrm2 sudo apt-get install libdrm2=2.4.56-1~ubuntu2 #sudo echo “package libdrm2” | sudo dpkg –set-selections
I'll give it a go at the end of the working day - should give enough time to recover if it all goes spectacularly wrong :)
On 30 July 2015 at 16:02, Ilia Mirkin imirkin@alum.mit.edu wrote:
On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote:
On 30/07/15 15:52, Bryan O'Donoghue wrote:
On 30/07/15 15:49, Peter Hurley wrote:
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
Is this happening with libdrm 2.4.60? If so, that's a known (user-side) issue and should be fixed by using any version but that one.
What's the freedesktop bugzilla # for reference?
Regards, Peter Hurley
I believe it's this one
Not really a world of choice on ubuntu to fix it though...
deckard@aineko:~/Development/projectara$ apt-show-versions libdrm2 libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
:(
That's unfortunate. I know next to nothing about debian/ubuntu or how they do versions or how to even build packages for them. But they're big distros, presumably they have support teams of some sort, perhaps they can help you.
Assuming that switching away does resolve the issue for you, perhaps you can also recommend that they avoid shipping that version, or include this nouveau fix in it:
http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c7...
Fwiw debian has been tracking this as #789759, and they are shipping 2.4.62 which includes the fix.
This whole libdrm thing is a bit of a cluster%@#$ unfortunately -- 2.4.60 is broken for nouveau, building even the latest released xf86-video-intel against 2.4.61+ causes it to not start ("fixed" in xf86-video-intel git), and newer mesa requires libdrm 2.4.60+.
I'm wondering if xf86-video-intel cannot, use libdrm's "features" rather than having a local copy of every drm change for the last 2 years. If bumping the requirement is not an option, then having a few build/compile time checks should do just fine.
Either way I'm glad that it wasn't me how broke that one :-P
-Emil
[ +cc Debian maintainer ]
On 07/30/2015 11:26 AM, Emil Velikov wrote:
On 30 July 2015 at 16:02, Ilia Mirkin imirkin@alum.mit.edu wrote:
On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote:
On 30/07/15 15:52, Bryan O'Donoghue wrote:
On 30/07/15 15:49, Peter Hurley wrote:
On 07/30/2015 10:12 AM, Ilia Mirkin wrote:
Is this happening with libdrm 2.4.60? If so, that's a known (user-side) issue and should be fixed by using any version but that one.
What's the freedesktop bugzilla # for reference?
Regards, Peter Hurley
I believe it's this one
Not really a world of choice on ubuntu to fix it though...
deckard@aineko:~/Development/projectara$ apt-show-versions libdrm2 libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
:(
That's unfortunate. I know next to nothing about debian/ubuntu or how they do versions or how to even build packages for them. But they're big distros, presumably they have support teams of some sort, perhaps they can help you.
Assuming that switching away does resolve the issue for you, perhaps you can also recommend that they avoid shipping that version, or include this nouveau fix in it:
http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c7...
Fwiw debian has been tracking this as #789759, and they are shipping 2.4.62 which includes the fix.
Unfortunately the LTS version of Ubuntu (trusty) was updated to 2.4.60 several days ago without this fix.
I repackaged libdrm 2.4.60 with only the bug fix above and confirm the patch above fixes the observed behavior in freedesktop bug# 89842/ debian bug# 789759.
I pushed the repackage to Launchpad PPA @ ppa:phurley/libdrm
Hopefully the Debian maintainer grabs this fix and updates the official distribution version soon.
Regards, Peter Hurley
On 30/07/15 22:45, Peter Hurley wrote:
[ +cc Debian maintainer ]
On 07/30/2015 11:26 AM, Emil Velikov wrote:
On 30 July 2015 at 16:02, Ilia Mirkin imirkin@alum.mit.edu wrote:
On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote:
On 30/07/15 15:52, Bryan O'Donoghue wrote:
On 30/07/15 15:49, Peter Hurley wrote:
On 07/30/2015 10:12 AM, Ilia Mirkin wrote: > > Is this happening with libdrm 2.4.60? If so, that's a known > (user-side) issue and should be fixed by using any version but that > one.
What's the freedesktop bugzilla # for reference?
Regards, Peter Hurley
I believe it's this one
Not really a world of choice on ubuntu to fix it though...
deckard@aineko:~/Development/projectara$ apt-show-versions libdrm2 libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
:(
That's unfortunate. I know next to nothing about debian/ubuntu or how they do versions or how to even build packages for them. But they're big distros, presumably they have support teams of some sort, perhaps they can help you.
Assuming that switching away does resolve the issue for you, perhaps you can also recommend that they avoid shipping that version, or include this nouveau fix in it:
http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c7...
Fwiw debian has been tracking this as #789759, and they are shipping 2.4.62 which includes the fix.
Unfortunately the LTS version of Ubuntu (trusty) was updated to 2.4.60 several days ago without this fix.
I repackaged libdrm 2.4.60 with only the bug fix above and confirm the patch above fixes the observed behavior in freedesktop bug# 89842/ debian bug# 789759.
I pushed the repackage to Launchpad PPA @ ppa:phurley/libdrm
Hopefully the Debian maintainer grabs this fix and updates the official distribution version soon.
Regards, Peter Hurley
Yep.
Dropping down to 2.4.56-1~ubuntu2 definitely removes the
nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[ PFIFO][0000:01:00.0] PFIFO: read fault at 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum 0x00000000)/GPC0/(unknown enum 0x0000000f) on channel 0x007f80c000 [unknown]
and hard lock-up of X. I'll update these guys with the fix
On 31/07/15 01:03, Bryan O'Donoghue wrote:
On 30/07/15 22:45, Peter Hurley wrote:
[ +cc Debian maintainer ]
On 07/30/2015 11:26 AM, Emil Velikov wrote:
On 30 July 2015 at 16:02, Ilia Mirkin imirkin@alum.mit.edu wrote:
On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote:
On 30/07/15 15:52, Bryan O'Donoghue wrote:
On 30/07/15 15:49, Peter Hurley wrote: > > On 07/30/2015 10:12 AM, Ilia Mirkin wrote: >> >> Is this happening with libdrm 2.4.60? If so, that's a known >> (user-side) issue and should be fixed by using any version but that >> one. > > > What's the freedesktop bugzilla # for reference? > > Regards, > Peter Hurley
I believe it's this one
Not really a world of choice on ubuntu to fix it though...
deckard@aineko:~/Development/projectara$ apt-show-versions libdrm2 libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
:(
That's unfortunate. I know next to nothing about debian/ubuntu or how they do versions or how to even build packages for them. But they're big distros, presumably they have support teams of some sort, perhaps they can help you.
Assuming that switching away does resolve the issue for you, perhaps you can also recommend that they avoid shipping that version, or include this nouveau fix in it:
http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c7...
Fwiw debian has been tracking this as #789759, and they are shipping 2.4.62 which includes the fix.
Unfortunately the LTS version of Ubuntu (trusty) was updated to 2.4.60 several days ago without this fix.
I repackaged libdrm 2.4.60 with only the bug fix above and confirm the patch above fixes the observed behavior in freedesktop bug# 89842/ debian bug# 789759.
I pushed the repackage to Launchpad PPA @ ppa:phurley/libdrm
Hopefully the Debian maintainer grabs this fix and updates the official distribution version soon.
Regards, Peter Hurley
Yep.
Dropping down to 2.4.56-1~ubuntu2 definitely removes the
nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[ PFIFO][0000:01:00.0] PFIFO: read fault at 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum 0x00000000)/GPC0/(unknown enum 0x0000000f) on channel 0x007f80c000 [unknown]
and hard lock-up of X. I'll update these guys with the fix
Hmm.
Interesting - I spoke way too soon on that.
Left my machine up overnight and lo and behold now that I do a dmesg I see...
nouveau E[chrome[2870]] multiple instances of buffer 16 on validation list nouveau E[chrome[2870]] multiple instances of buffer 24 on validation list nouveau E[chrome[2870]] multiple instances of buffer 167 on validation list nouveau E[chrome[2870]] multiple instances of buffer 251 on validation list nouveau E[chrome[2870]] multiple instances of buffer 248 on validation list nouveau E[chrome[2870]] multiple instances of buffer 249 on validation list nouveau E[chrome[2870]] multiple instances of buffer 230 on validation list nouveau E[chrome[2870]] multiple instances of buffer 253 on validation list nouveau E[chrome[2870]] multiple instances of buffer 255 on validation list nouveau E[chrome[2870]] multiple instances of buffer 230 on validation list nouveau E[chrome[2870]] multiple instances of buffer 257 on validation list nouveau E[chrome[2870]] multiple instances of buffer 230 on validation list
deckard@aineko:~$ dpkg -s libdrm2 Package: libdrm2 Status: install ok installed Priority: optional Section: libs Installed-Size: 106 Maintainer: Ubuntu X-SWAT ubuntu-x@lists.ubuntu.com Architecture: amd64 Multi-Arch: same Source: libdrm Version: 2.4.56-1~ubuntu2 Depends: libc6 (>= 2.17) Pre-Depends: multiarch-support Description: Userspace interface to kernel DRM services -- runtime This library implements the userspace interface to the kernel DRM services. DRM stands for "Direct Rendering Manager", which is the kernelspace portion of the "Direct Rendering Infrastructure" (DRI). The DRI is currently used on Linux to provide hardware-accelerated OpenGL drivers. . This package provides the runtime environment for libdrm. Orig-Maintainer: Debian X Strike Force debian-x@lists.debian.org
deckard@aineko:~$ uname -a Linux aineko 4.2.0-rc4+ #50 SMP Thu Jul 30 01:22:01 IST 2015 x86_64 x86_64 x86_64 GNU/Linux
Please note - this machine has the fix I proposed in the original patch applied so X is not locking up when the multiple instances message happens.
In any case to answer the original question - I don't believe switching away from 2.4.60 will resolve this issue and similarly then Ilia - do you happen to know if 2.4.56 should have the bug ? Should I now be using a version of libdrm2 which is good ???
Bryan
On 31/07/15 10:53, Bryan O'Donoghue wrote:
On 31/07/15 01:03, Bryan O'Donoghue wrote:
On 30/07/15 22:45, Peter Hurley wrote:
[ +cc Debian maintainer ]
On 07/30/2015 11:26 AM, Emil Velikov wrote:
On 30 July 2015 at 16:02, Ilia Mirkin imirkin@alum.mit.edu wrote:
On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote:
On 30/07/15 15:52, Bryan O'Donoghue wrote: > > On 30/07/15 15:49, Peter Hurley wrote: >> >> On 07/30/2015 10:12 AM, Ilia Mirkin wrote: >>> >>> Is this happening with libdrm 2.4.60? If so, that's a known >>> (user-side) issue and should be fixed by using any version but >>> that >>> one. >> >> >> What's the freedesktop bugzilla # for reference? >> >> Regards, >> Peter Hurley > > > I believe it's this one > > https://bugs.freedesktop.org/show_bug.cgi?id=89842#c19 >
Not really a world of choice on ubuntu to fix it though...
deckard@aineko:~/Development/projectara$ apt-show-versions libdrm2 libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
:(
That's unfortunate. I know next to nothing about debian/ubuntu or how they do versions or how to even build packages for them. But they're big distros, presumably they have support teams of some sort, perhaps they can help you.
Assuming that switching away does resolve the issue for you, perhaps you can also recommend that they avoid shipping that version, or include this nouveau fix in it:
http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c7...
Fwiw debian has been tracking this as #789759, and they are shipping 2.4.62 which includes the fix.
Unfortunately the LTS version of Ubuntu (trusty) was updated to 2.4.60 several days ago without this fix.
I repackaged libdrm 2.4.60 with only the bug fix above and confirm the patch above fixes the observed behavior in freedesktop bug# 89842/ debian bug# 789759.
I pushed the repackage to Launchpad PPA @ ppa:phurley/libdrm
Hopefully the Debian maintainer grabs this fix and updates the official distribution version soon.
Regards, Peter Hurley
Yep.
Dropping down to 2.4.56-1~ubuntu2 definitely removes the
nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[ PFIFO][0000:01:00.0] PFIFO: read fault at 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum 0x00000000)/GPC0/(unknown enum 0x0000000f) on channel 0x007f80c000 [unknown]
and hard lock-up of X. I'll update these guys with the fix
Hmm.
Interesting - I spoke way too soon on that.
Left my machine up overnight and lo and behold now that I do a dmesg I see...
nouveau E[chrome[2870]] multiple instances of buffer 16 on validation list nouveau E[chrome[2870]] multiple instances of buffer 24 on validation list nouveau E[chrome[2870]] multiple instances of buffer 167 on validation list nouveau E[chrome[2870]] multiple instances of buffer 251 on validation list nouveau E[chrome[2870]] multiple instances of buffer 248 on validation list nouveau E[chrome[2870]] multiple instances of buffer 249 on validation list nouveau E[chrome[2870]] multiple instances of buffer 230 on validation list nouveau E[chrome[2870]] multiple instances of buffer 253 on validation list nouveau E[chrome[2870]] multiple instances of buffer 255 on validation list nouveau E[chrome[2870]] multiple instances of buffer 230 on validation list nouveau E[chrome[2870]] multiple instances of buffer 257 on validation list nouveau E[chrome[2870]] multiple instances of buffer 230 on validation list
deckard@aineko:~$ dpkg -s libdrm2 Package: libdrm2 Status: install ok installed Priority: optional Section: libs Installed-Size: 106 Maintainer: Ubuntu X-SWAT ubuntu-x@lists.ubuntu.com Architecture: amd64 Multi-Arch: same Source: libdrm Version: 2.4.56-1~ubuntu2 Depends: libc6 (>= 2.17) Pre-Depends: multiarch-support Description: Userspace interface to kernel DRM services -- runtime This library implements the userspace interface to the kernel DRM services. DRM stands for "Direct Rendering Manager", which is the kernelspace portion of the "Direct Rendering Infrastructure" (DRI). The DRI is currently used on Linux to provide hardware-accelerated OpenGL drivers. . This package provides the runtime environment for libdrm. Orig-Maintainer: Debian X Strike Force debian-x@lists.debian.org
deckard@aineko:~$ uname -a Linux aineko 4.2.0-rc4+ #50 SMP Thu Jul 30 01:22:01 IST 2015 x86_64 x86_64 x86_64 GNU/Linux
Please note - this machine has the fix I proposed in the original patch applied so X is not locking up when the multiple instances message happens.
In any case to answer the original question - I don't believe switching away from 2.4.60 will resolve this issue
2.40.6 I mean :)
On 31/07/15 10:58, Bryan O'Donoghue wrote:
On 31/07/15 10:53, Bryan O'Donoghue wrote:
On 31/07/15 01:03, Bryan O'Donoghue wrote:
On 30/07/15 22:45, Peter Hurley wrote:
[ +cc Debian maintainer ]
On 07/30/2015 11:26 AM, Emil Velikov wrote:
On 30 July 2015 at 16:02, Ilia Mirkin imirkin@alum.mit.edu wrote:
On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote: > On 30/07/15 15:52, Bryan O'Donoghue wrote: >> >> On 30/07/15 15:49, Peter Hurley wrote: >>> >>> On 07/30/2015 10:12 AM, Ilia Mirkin wrote: >>>> >>>> Is this happening with libdrm 2.4.60? If so, that's a known >>>> (user-side) issue and should be fixed by using any version but >>>> that >>>> one. >>> >>> >>> What's the freedesktop bugzilla # for reference? >>> >>> Regards, >>> Peter Hurley >> >> >> I believe it's this one >> >> https://bugs.freedesktop.org/show_bug.cgi?id=89842#c19 >> > > Not really a world of choice on ubuntu to fix it though... > > deckard@aineko:~/Development/projectara$ apt-show-versions libdrm2 > libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate > libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate > > :(
That's unfortunate. I know next to nothing about debian/ubuntu or how they do versions or how to even build packages for them. But they're big distros, presumably they have support teams of some sort, perhaps they can help you.
Assuming that switching away does resolve the issue for you, perhaps you can also recommend that they avoid shipping that version, or include this nouveau fix in it:
http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c7...
Fwiw debian has been tracking this as #789759, and they are shipping 2.4.62 which includes the fix.
Unfortunately the LTS version of Ubuntu (trusty) was updated to 2.4.60 several days ago without this fix.
I repackaged libdrm 2.4.60 with only the bug fix above and confirm the patch above fixes the observed behavior in freedesktop bug# 89842/ debian bug# 789759.
I pushed the repackage to Launchpad PPA @ ppa:phurley/libdrm
Hopefully the Debian maintainer grabs this fix and updates the official distribution version soon.
Regards, Peter Hurley
Yep.
Dropping down to 2.4.56-1~ubuntu2 definitely removes the
nouveau E[chrome[2737]] multiple instances of buffer 33 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[chrome[2737]] multiple instances of buffer 18 on validation list nouveau E[chrome[2737]] validate_init nouveau E[chrome[2737]] validate: -22 nouveau E[ PFIFO][0000:01:00.0] PFIFO: read fault at 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum 0x00000000)/GPC0/(unknown enum 0x0000000f) on channel 0x007f80c000 [unknown]
and hard lock-up of X. I'll update these guys with the fix
Hmm.
Interesting - I spoke way too soon on that.
Left my machine up overnight and lo and behold now that I do a dmesg I see...
nouveau E[chrome[2870]] multiple instances of buffer 16 on validation list nouveau E[chrome[2870]] multiple instances of buffer 24 on validation list nouveau E[chrome[2870]] multiple instances of buffer 167 on validation list nouveau E[chrome[2870]] multiple instances of buffer 251 on validation list nouveau E[chrome[2870]] multiple instances of buffer 248 on validation list nouveau E[chrome[2870]] multiple instances of buffer 249 on validation list nouveau E[chrome[2870]] multiple instances of buffer 230 on validation list nouveau E[chrome[2870]] multiple instances of buffer 253 on validation list nouveau E[chrome[2870]] multiple instances of buffer 255 on validation list nouveau E[chrome[2870]] multiple instances of buffer 230 on validation list nouveau E[chrome[2870]] multiple instances of buffer 257 on validation list nouveau E[chrome[2870]] multiple instances of buffer 230 on validation list
deckard@aineko:~$ dpkg -s libdrm2 Package: libdrm2 Status: install ok installed Priority: optional Section: libs Installed-Size: 106 Maintainer: Ubuntu X-SWAT ubuntu-x@lists.ubuntu.com Architecture: amd64 Multi-Arch: same Source: libdrm Version: 2.4.56-1~ubuntu2 Depends: libc6 (>= 2.17) Pre-Depends: multiarch-support Description: Userspace interface to kernel DRM services -- runtime This library implements the userspace interface to the kernel DRM services. DRM stands for "Direct Rendering Manager", which is the kernelspace portion of the "Direct Rendering Infrastructure" (DRI). The DRI is currently used on Linux to provide hardware-accelerated OpenGL drivers. . This package provides the runtime environment for libdrm. Orig-Maintainer: Debian X Strike Force debian-x@lists.debian.org
deckard@aineko:~$ uname -a Linux aineko 4.2.0-rc4+ #50 SMP Thu Jul 30 01:22:01 IST 2015 x86_64 x86_64 x86_64 GNU/Linux
Please note - this machine has the fix I proposed in the original patch applied so X is not locking up when the multiple instances message happens.
In any case to answer the original question - I don't believe switching away from 2.4.60 will resolve this issue
2.40.6 I mean :)
ah no... 2.4.60 is right...
Yes so Ilia - I've switched out 2.4.60 as per your suggestion to 2.4.56 (getting the version numbers right :) ) and it's still definitely giving me the multiple instances message.
On Fri, Jul 31, 2015 at 6:27 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote:
ah no... 2.4.60 is right...
Yes so Ilia - I've switched out 2.4.60 as per your suggestion to 2.4.56 (getting the version numbers right :) ) and it's still definitely giving me the multiple instances message.
This is going to sound like a stupid question, but I'll ask anyways -- you *did* restart chrome after changing libdrm versions, right?
I was going to mention that there were a handful of fixes in libdrm, potentially since 2.4.56 (I forget the exact versions), but if 2.4.60 also fails, then that would have them.
There was a final assert() added in 2.4.62, but that was to better isolate the cause of weirdo crashes (i.e. crash when the thing going wrong happens rather than stashing bad pointers for later very confusing dereference). Not GPU crashes.
Just for your information,
nouveau E[ PFIFO][0000:01:00.0] PFIFO: read fault at 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum 0x00000000)/GPC0/(unknown enum 0x0000000f) on channel 0x007f80c000 [unknown]
means that there was VM fault from an unknown gpu unit (???) when reading some resource by the GPU. (The GPU has its own MMU.) Unfortunately this can happen for one of a million reasons, the biggest one being "unknown", but mesa definitely doesn't handle command submission failures particularly well... should probably add a "fail 1% of the time" thing to help fix that up.
Do you have a reproducible way of achieving the multiple buffer on validation list thing? What GPU do you have? (Looking for a codename, not a marketing name... lspci should have it... GFxxx or GKxxx or Gxx.)
-ilia
On 31/07/15 17:36, Ilia Mirkin wrote:
On Fri, Jul 31, 2015 at 6:27 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote:
ah no... 2.4.60 is right...
Yes so Ilia - I've switched out 2.4.60 as per your suggestion to 2.4.56 (getting the version numbers right :) ) and it's still definitely giving me the multiple instances message.
This is going to sound like a stupid question, but I'll ask anyways -- you *did* restart chrome after changing libdrm versions, right?
There are no stupid questions - just stupid answers like 'whaddya mean restart chrome'
Seriously though, I've restarted the machine each time I've tried to switch out those libraries, so it's definitely not that.
I was going to mention that there were a handful of fixes in libdrm, potentially since 2.4.56 (I forget the exact versions), but if 2.4.60 also fails, then that would have them.
There was a final assert() added in 2.4.62, but that was to better isolate the cause of weirdo crashes (i.e. crash when the thing going wrong happens rather than stashing bad pointers for later very confusing dereference). Not GPU crashes.
Just for your information,
nouveau E[ PFIFO][0000:01:00.0] PFIFO: read fault at 0x0003e21000 [PAGE_NOT_PRESENT] from (unknown enum 0x00000000)/GPC0/(unknown enum 0x0000000f) on channel 0x007f80c000 [unknown]
means that there was VM fault from an unknown gpu unit (???) when reading some resource by the GPU.
OK, I was assuming it was a side effect of the -EINVAL when we get the multiple instances message.
(The GPU has its own MMU.) Unfortunately this can happen for one of a million reasons, the biggest one being "unknown", but mesa definitely doesn't handle command submission failures particularly well... should probably add a "fail 1% of the time" thing to help fix that up.
Do you have a reproducible way of achieving the multiple buffer on validation list thing? What GPU do you have? (Looking for a codename, not a marketing name... lspci should have it... GFxxx or GKxxx or
01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 750M Mac Edition] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Apple Inc. Device 0130 Flags: bus master, fast devsel, latency 0, IRQ 45 Memory at c0000000 (32-bit, non-prefetchable) [size=16M] Memory at 80000000 (64-bit, prefetchable) [size=256M] Memory at 90000000 (64-bit, prefetchable) [size=32M] I/O ports at 1000 [size=128] Expansion ROM at c1000000 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [b4] Vendor Specific Information: Len=14 <?> Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting <?> Capabilities: [420] Advanced Error Reporting Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?> Capabilities: [900] #19 Kernel driver in use: nouveau
Macbook pro retina 2014
On 31/07/15 17:43, Bryan O'Donoghue wrote:
On 31/07/15 17:36, Ilia Mirkin wrote:
Do you have a reproducible way of achieving the multiple buffer on validation list thing?
Reliable enough. Start Chrome, then get Chrome to open a menu on top of it's own screen - for example click the top right menu bar - the thing with the three horizontal bars, scroll down to 'recent tabs' and let the mouse hover.
You'll get a menu that opens up over the main chrome screen and at that point you'll also get a 'multiple instances of buffer'
Basically drawing one window on top of another inside of the same Chrome tab.
I guess the same PID is mapping the same piece of memory twice because if I open a seperate Chrome window (which will have a seperate PID) and drag one window over the other we don't see a repeat.
If it helps
deckard@aineko:~$ dmesg | tail -n 5 [ 6900.249427] nouveau E[chrome[3176]] multiple instances of buffer 456 on validation list [ 6920.992475] nouveau E[chrome[3176]] multiple instances of buffer 458 on validation list [ 6934.277352] nouveau E[chrome[3176]] multiple instances of buffer 458 on validation list [ 6994.303600] nouveau E[chrome[3176]] multiple instances of buffer 458 on validation list [ 7067.436049] nouveau E[chrome[3176]] multiple instances of buffer 456 on validation list
deckard@aineko:~$ ps -ax | grep chrome | grep 3176 3176 pts/6 Sl+ 0:29 /opt/google/chrome/chrome --type=gpu-process --channel=3143.0.1295591 ives-passed-by-fd --v8-snapshot-passed-by-fd --supports-dual-gpus=false --gpu-driver-bug-workarounds=2,29,32,45,55,57 --disable-accelerated-video-decode --gpu-vendor-id=0x10de --gpu-device-id=0x0fe9 --gpu-driver-vendor --gpu-driver-version --v8-natives-passed-by-fd --v8-snapshot-passed-by-fd
What GPU do you have? (Looking for a codename,
not a marketing name... lspci should have it... GFxxx or GKxxx or
01:00.0 VGA compatible controller: NVIDIA Corporation GK107M [GeForce GT 750M Mac Edition] (rev a1) (prog-if 00 [VGA controller]) Subsystem: Apple Inc. Device 0130 Flags: bus master, fast devsel, latency 0, IRQ 45 Memory at c0000000 (32-bit, non-prefetchable) [size=16M] Memory at 80000000 (64-bit, prefetchable) [size=256M] Memory at 90000000 (64-bit, prefetchable) [size=32M] I/O ports at 1000 [size=128] Expansion ROM at c1000000 [disabled] [size=512K] Capabilities: [60] Power Management version 3 Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [b4] Vendor Specific Information: Len=14 <?> Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting <?> Capabilities: [420] Advanced Error Reporting Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 <?> Capabilities: [900] #19 Kernel driver in use: nouveau
Macbook pro retina 2014
On 31/07/15 19:11, Bryan O'Donoghue wrote:
On 31/07/15 17:43, Bryan O'Donoghue wrote:
On 31/07/15 17:36, Ilia Mirkin wrote:
Do you have a reproducible way of achieving the multiple buffer on validation list thing?
Ilia, Peter.
I've filed a bug for you here : https://bugs.freedesktop.org/show_bug.cgi?id=91535
I've verified that Peter's PPA library when installed fixes the race condition you guys were talking about but running the test program tests/nouveau/threaded so, this issue we're discussing here is a separate one.
Cheers, Bryan
On 30/07/15 22:45, Peter Hurley wrote:
[ +cc Debian maintainer ]
On 07/30/2015 11:26 AM, Emil Velikov wrote:
On 30 July 2015 at 16:02, Ilia Mirkin imirkin@alum.mit.edu wrote:
On Thu, Jul 30, 2015 at 10:56 AM, Bryan O'Donoghue pure.logic@nexus-software.ie wrote:
On 30/07/15 15:52, Bryan O'Donoghue wrote:
On 30/07/15 15:49, Peter Hurley wrote:
On 07/30/2015 10:12 AM, Ilia Mirkin wrote: > > Is this happening with libdrm 2.4.60? If so, that's a known > (user-side) issue and should be fixed by using any version but that > one.
What's the freedesktop bugzilla # for reference?
Regards, Peter Hurley
I believe it's this one
Not really a world of choice on ubuntu to fix it though...
deckard@aineko:~/Development/projectara$ apt-show-versions libdrm2 libdrm2:amd64/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate libdrm2:i386/trusty-updates 2.4.60-2~ubuntu14.04.1 uptodate
:(
That's unfortunate. I know next to nothing about debian/ubuntu or how they do versions or how to even build packages for them. But they're big distros, presumably they have support teams of some sort, perhaps they can help you.
Assuming that switching away does resolve the issue for you, perhaps you can also recommend that they avoid shipping that version, or include this nouveau fix in it:
http://cgit.freedesktop.org/mesa/drm/commit/?id=812e8fe6ce46d733c30207ee26c7...
Fwiw debian has been tracking this as #789759, and they are shipping 2.4.62 which includes the fix.
Unfortunately the LTS version of Ubuntu (trusty) was updated to 2.4.60 several days ago without this fix.
I repackaged libdrm 2.4.60 with only the bug fix above and confirm the patch above fixes the observed behavior in freedesktop bug# 89842/ debian bug# 789759.
I pushed the repackage to Launchpad PPA @ ppa:phurley/libdrm
Hopefully the Debian maintainer grabs this fix and updates the official distribution version soon.
Regards, Peter Hurley
Peter.
I tried your suggested fix too as uploaded and it doesn't fix it either.
I think that this is a separate bug or the fix as applied to libdrm doesn't actually fix it.
deckard@aineko:~$ dmesg | tail -n 1 nouveau E[chrome[3176]] multiple instances of buffer 413 on validation list
deckard@aineko:~$ dpkg -s libdrm2 Package: libdrm2 Status: install ok installed Priority: optional Section: libs Installed-Size: 106 Maintainer: Debian X Strike Force debian-x@lists.debian.org Architecture: amd64 Multi-Arch: same Source: libdrm Version: 2.4.60-2ppa1~trusty1
deckard@aineko:~$ uname -a Linux aineko 4.2.0-rc4+ #50 SMP Thu Jul 30 01:22:01 IST 2015 x86_64 x86_64 x86_64 GNU/Linux
dri-devel@lists.freedesktop.org
-
Bryan O'Donoghue -
Emil Velikov -
Ilia Mirkin -
Peter Hurley