Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1195896 > unrolled thread

[PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

Back to article view | Back to linux.kernel

Contents

  [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2015-07-30 12:40 +0200
    Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times Ilia Mirkin <imirkin@alum.mit.edu> - 2015-07-30 16:20 +0200
      Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple  times Peter Hurley <peter@hurleysoftware.com> - 2015-07-30 16:50 +0200
        Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple  times Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2015-07-30 17:00 +0200
          Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times Ilia Mirkin <imirkin@alum.mit.edu> - 2015-07-30 17:10 +0200
            Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple  times Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2015-07-30 17:20 +0200
            Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times Emil Velikov <emil.l.velikov@gmail.com> - 2015-07-30 17:30 +0200
              Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple  times Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2015-07-31 18:20 +0200
              Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times Ilia Mirkin <imirkin@alum.mit.edu> - 2015-07-31 18:40 +0200
                Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple  times Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2015-07-31 18:50 +0200
                  Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple  times Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2015-08-03 03:00 +0200
        Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple  times Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2015-07-30 17:00 +0200
      Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple  times Bryan O'Donoghue <pure.logic@nexus-software.ie> - 2015-07-30 16:50 +0200

#1195896 — [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

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.

http://tinyurl.com/orvbzf3

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/

[toc] | [next] | [standalone]

#1196073

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.
>
> http://tinyurl.com/orvbzf3
>
> 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/
--
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/

[toc] | [prev] | [next] | [standalone]

#1196097 — Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

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.
>>
>> http://tinyurl.com/orvbzf3
>>
>> 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/

[toc] | [prev] | [next] | [standalone]

#1196102 — Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

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

:(
--
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/

[toc] | [prev] | [next] | [standalone]

#1196107

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=812e8fe6ce46d733c30207ee26c788c61f546294

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1196119 — Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

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=812e8fe6ce46d733c30207ee26c788c61f546294
>
> 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 :)
--
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/

[toc] | [prev] | [next] | [standalone]

#1196126

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=812e8fe6ce46d733c30207ee26c788c61f546294
>
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
--
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/

[toc] | [prev] | [next] | [standalone]

#1197164 — Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

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=812e8fe6ce46d733c30207ee26c788c61f546294
>>>
>> 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


--
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/

[toc] | [prev] | [next] | [standalone]

#1197172

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1197179 — Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

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
--
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/

[toc] | [prev] | [next] | [standalone]

#1198470 — Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

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

--
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/

[toc] | [prev] | [next] | [standalone]

#1196104 — Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

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

--
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/

[toc] | [prev] | [next] | [standalone]

#1196100 — Re: [PATCH] drm/nouveau/gem: tolerate a buffer specified multiple times

On 30/07/15 15:12, 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.
>

Yes that's my version 2.4.60.

--
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/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web