[Nouveau] Odd text behavior on Websites and others
Online, just now noticed some websites are coming up ok, but then charac ters rapidly begin to disappear or get replaced by wrong characters. If I click on any words in this post several times, the missing characters Kr intermittently appear in the example above and disappear in this sentence. Also just noticed that same behavior occurs when I move the mouse in and out of the text pane. Very odd. Some menus are corrupted too, Evolution (mail). System was working before the updated nouveau driver. I never installed NVIDIA drivers. System Fedora 22 32-bits with GeForce GTX 745 -- Rudolf Künzli rudolf.kun...@gmail.com ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] Odd text behavior on Websites and others
Online, just now noticed some websites are coming up ok, but then characters rapidly begin to disappear or get replaced by wrong characters. If I click on any words in this post several times, the missing characters Kr intermittently appear in the example above and disappear in this sentence. Also just noticed that same behavior occurs when I move the mouse in and out of the text pane. Very odd. Some menus in applications (Evolution, LibreOffic, etc.) are corrupted too, System was working before the updated nouveau driver. System: Linux mephisto 4.1.3-201.fc22.i686 #1 SMP Wed Jul 29 20:53:52 UTC 2015 i686 i686 i386 GNU/Linux Graphic Card: GeForce GTX 745 Nouveau Driver: xorg-x11-drv-nouveau-1.0.11-2.fc22.i686 -- Rudolf Künzli rudolf.kun...@gmail.com ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 90388] [NVE4] PDISP errors on startup
https://bugs.freedesktop.org/show_bug.cgi?id=90388 Leonidas Spyropoulos artafi...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Leonidas Spyropoulos artafi...@gmail.com --- The patch proposed from Ilia works fine. I see this is released with 4.1.5 I'll consider this resolved. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] enable dri3 support without glamor causes gnome-shell regression on nv4x
On Mon, Aug 10, 2015 at 8:47 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 03-08-15 20:09, Ilia Mirkin wrote: On Mon, Aug 3, 2015 at 1:31 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 03-08-15 17:36, Ilia Mirkin wrote: On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 30-07-15 16:09, Ilia Mirkin wrote: FWIW this is a fail on nv50+ as well. See for example https://bugs.freedesktop.org/show_bug.cgi?id=91445 My suspicion is that this is due to the lack of PUSH_KICK in the *Done exa handlers -- works fine with DRI2, but DRI3 has no synchronization and so the commands never get flushed out. Easily verified by sticking PUSH_KICK's everywhere. I do not believe that that is the problem, in my case it clearly seems to be a pitch / swizzle problem rather then a synchronizarion problem, here is what my desktop with gnome shell looks like when using DRI2: https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-good.jpg And this is what it looks like when using DRI3: https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-bad.jpg The DRI2 screenshot is made with Mario's 2 patches on top of current master: http://lists.freedesktop.org/archives/nouveau/2015-July/021740.html http://lists.freedesktop.org/archives/nouveau/2015-July/021741.html And then adding Option DRI 2 to xorg.conf. His patches should have defaulted it to DRI 2 I think, so this is unnecessary. In fact you should have had to say DRI 3 to get DRI3 with his patches. -- I've also tried disabling EXA using Option AccelMethod none, but that seems to also automatically disable all DRI, leading to software rendering. I discussed this with Ben this morning and he suggested that this is likely a Mesa issue since with DRI3 mesa rather then the ddx allocs the surfaces. I've tried disabling swizzling in the mesa code by forcing nv30_miptree_create() to always take the code path for linear textures, but that leads to the exact same result as before that change. Ah yes. Very different problem indeed. I actually suspect it has to do with swizzling. Look at the white pattern of the moon -- it's all in a line. That means that it expected some locality and instead it got drawn all on a line. If it were merely a stride problem, I'd expect to see strips of the moon below and offset from one another. So... take a look at nv30_miptree_from_handle -- I wonder if it can now receive swizzled textures where it couldn't before. Ok, that does go in the direction I am expecting the problem to be, but I'm afraid I'm going to need a bit more guidance, what exactly am I looking for in that function / which knobs should I try to vary / play with to maybe fix this ? Unfortunately this is playing near (or past) the limits of my knowledge as well. My understanding is that DRI3 passes pixmaps around with dma-buf, aka bo_from_handle. DRI2 uses some other mechanism which is not that (I think it just copies stuff around). Now on nv50+, bo's have tile flags (and memtype and probably other annoyances). The tile flags indicate the specific tiling mechanism used on that bo (i.e. do you do 32x32 tiles? 32x64? etc). Take a look at the nouveau_bo_new() call in nv50_miptree.c -- note how it takes a bo config argument. This bo config can then later be retrieved using some other syscall. However on nv30 there appears to not be any such thing. The nouveau_bo_new call just passes in NULL for creating the bo, which means that there's no way to recover the are you swizzled information after-the-fact. Presumably you should create a nv04 bo config section in the union, That already exists, and indeed gets set by the nouveau_allocate_surface function from src/nv_accel_common.c from the ddx, and just pass the single swizzled bit through. I'm not sure what, if anything, is required on the kernel side for that. I don't think there's any optionality in how the swizzling is done for pre-nv50. Note that in the nv30_miptree logic, mt-swizzled implies that mt-uniform_pitch = 0, but the level pitch is set properly (again, see nv30_miptree_create). Hope this sheds some light and doesn't cause you to go in the wrong direction -- please take everything I say with a grain of salt -- I'm often a bit off on some of the details. Thanks this was helpful, I do feel we are getting somewhere, but I do need a bit more help. I've added some debug printf's to nv30_miptree.c, nv30_miptree_create and nv30_miptree_from_handle, where the latter is only used when using dri2 (e.g. in the working case). Doing a diff between a log of starting gnome-shell with dri vs dri3 results in this: --- mesa.log.dri2 2015-08-10 14:18:03.182712022 +0200 +++ mesa.log.dri3 2015-08-10 14:18:33.26338 +0200 @@ -1,8 +1,8 @@ nv30_miptree_create 512x32 uniform_pitch 0 usage 0 flags 0 -nv30_miptree_from_handle 1x1 uniform_pitch 1024 usage 0 flags 0
[Nouveau] [Bug 91598] Broken Rendering of Plasma 5 Desktop
https://bugs.freedesktop.org/show_bug.cgi?id=91598 --- Comment #2 from Ilia Mirkin imir...@alum.mit.edu --- You appear to run out of vram (fail to set_domain), and then mesa does not handle that failure particularly gracefully. -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] enable dri3 support without glamor causes gnome-shell regression on nv4x
Hi, On 11-08-15 14:21, Ilia Mirkin wrote: On Mon, Aug 10, 2015 at 8:47 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 03-08-15 20:09, Ilia Mirkin wrote: On Mon, Aug 3, 2015 at 1:31 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 03-08-15 17:36, Ilia Mirkin wrote: On Mon, Aug 3, 2015 at 9:02 AM, Hans de Goede hdego...@redhat.com wrote: Hi, On 30-07-15 16:09, Ilia Mirkin wrote: FWIW this is a fail on nv50+ as well. See for example https://bugs.freedesktop.org/show_bug.cgi?id=91445 My suspicion is that this is due to the lack of PUSH_KICK in the *Done exa handlers -- works fine with DRI2, but DRI3 has no synchronization and so the commands never get flushed out. Easily verified by sticking PUSH_KICK's everywhere. I do not believe that that is the problem, in my case it clearly seems to be a pitch / swizzle problem rather then a synchronizarion problem, here is what my desktop with gnome shell looks like when using DRI2: https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-good.jpg And this is what it looks like when using DRI3: https://fedorapeople.org/~jwrdegoede/nv46-gnome-shell-bad.jpg The DRI2 screenshot is made with Mario's 2 patches on top of current master: http://lists.freedesktop.org/archives/nouveau/2015-July/021740.html http://lists.freedesktop.org/archives/nouveau/2015-July/021741.html And then adding Option DRI 2 to xorg.conf. His patches should have defaulted it to DRI 2 I think, so this is unnecessary. In fact you should have had to say DRI 3 to get DRI3 with his patches. -- I've also tried disabling EXA using Option AccelMethod none, but that seems to also automatically disable all DRI, leading to software rendering. I discussed this with Ben this morning and he suggested that this is likely a Mesa issue since with DRI3 mesa rather then the ddx allocs the surfaces. I've tried disabling swizzling in the mesa code by forcing nv30_miptree_create() to always take the code path for linear textures, but that leads to the exact same result as before that change. Ah yes. Very different problem indeed. I actually suspect it has to do with swizzling. Look at the white pattern of the moon -- it's all in a line. That means that it expected some locality and instead it got drawn all on a line. If it were merely a stride problem, I'd expect to see strips of the moon below and offset from one another. So... take a look at nv30_miptree_from_handle -- I wonder if it can now receive swizzled textures where it couldn't before. Ok, that does go in the direction I am expecting the problem to be, but I'm afraid I'm going to need a bit more guidance, what exactly am I looking for in that function / which knobs should I try to vary / play with to maybe fix this ? Unfortunately this is playing near (or past) the limits of my knowledge as well. My understanding is that DRI3 passes pixmaps around with dma-buf, aka bo_from_handle. DRI2 uses some other mechanism which is not that (I think it just copies stuff around). Now on nv50+, bo's have tile flags (and memtype and probably other annoyances). The tile flags indicate the specific tiling mechanism used on that bo (i.e. do you do 32x32 tiles? 32x64? etc). Take a look at the nouveau_bo_new() call in nv50_miptree.c -- note how it takes a bo config argument. This bo config can then later be retrieved using some other syscall. However on nv30 there appears to not be any such thing. The nouveau_bo_new call just passes in NULL for creating the bo, which means that there's no way to recover the are you swizzled information after-the-fact. Presumably you should create a nv04 bo config section in the union, That already exists, and indeed gets set by the nouveau_allocate_surface function from src/nv_accel_common.c from the ddx, and just pass the single swizzled bit through. I'm not sure what, if anything, is required on the kernel side for that. I don't think there's any optionality in how the swizzling is done for pre-nv50. Note that in the nv30_miptree logic, mt-swizzled implies that mt-uniform_pitch = 0, but the level pitch is set properly (again, see nv30_miptree_create). Hope this sheds some light and doesn't cause you to go in the wrong direction -- please take everything I say with a grain of salt -- I'm often a bit off on some of the details. Thanks this was helpful, I do feel we are getting somewhere, but I do need a bit more help. I've added some debug printf's to nv30_miptree.c, nv30_miptree_create and nv30_miptree_from_handle, where the latter is only used when using dri2 (e.g. in the working case). Doing a diff between a log of starting gnome-shell with dri vs dri3 results in this: --- mesa.log.dri2 2015-08-10 14:18:03.182712022 +0200 +++ mesa.log.dri3 2015-08-10 14:18:33.26338 +0200 @@ -1,8 +1,8 @@ nv30_miptree_create 512x32 uniform_pitch 0 usage 0 flags 0 -nv30_miptree_from_handle 1x1 uniform_pitch 1024 usage 0 flags 0 +nv30_miptree_create 1x1 uniform_pitch 0
Re: [Nouveau] Odd text behavior on Websites and others
On Tue, Aug 11, 2015 at 10:47 AM, Rudolf Künzli rudolf.kun...@gmail.com wrote: GeForce GTX 745 is a NVIDIA card in the NV117 (GM107) Family... The update was made using DNF (Yum) in my daily update procedure using the Fedora 22 Update repository. I am not familiar with details I just can report what happens right now... OK, there's no EXA support for maxwell, so you're using glamor. Before kernel 4.1, unless you had extracted your own ctxsw firmware, you didn't have acceleration at all, that was likely the change that triggered the issue. The glamor integration in nouveau is, sadly, broken. But it's unclear whether that's the cause of your issue. You can either add Option NoAccel true to the device section in your xorg.conf, which will disable 2d acceleration and bring you back to the same state you were in before, or you can add Driver modesetting (or uninstall xf86-video-nouveau) which will use the modesetting driver which has a non-broken glamor integration. You may still get the same issues though, as they could just be generic mesa-sucks-on-maxwell issues (I don't have a Maxwell GPU, no one else has been interested in debugging/fixing issues). -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Odd text behavior on Websites and others
No, you probably want something in /etc/X11... a lot of the time it's split up into a bunch of separate files in like /etc/X11/xorg.conf.d or something. You should consult your distro documentation for how to make it happen. On Tue, Aug 11, 2015 at 11:38 AM, Rudolf Künzli rudolf.kun...@gmail.com wrote: Thanks - the only xorg.conf I found is - /usr/share/abrt/conf.d/plugins/xorg.conf Is this the file to be edited? -- Rudolf Künzli rudolf.kun...@gmail.com On Tue, 2015-08-11 at 10:56 -0400, Ilia Mirkin wrote: On Tue, Aug 11, 2015 at 10:47 AM, Rudolf Künzli rudolf.kun...@gmail.com wrote: GeForce GTX 745 is a NVIDIA card in the NV117 (GM107) Family... The update was made using DNF (Yum) in my daily update procedure using the Fedora 22 Update repository. I am not familiar with details I just can report what happens right now... OK, there's no EXA support for maxwell, so you're using glamor. Before kernel 4.1, unless you had extracted your own ctxsw firmware, you didn't have acceleration at all, that was likely the change that triggered the issue. The glamor integration in nouveau is, sadly, broken. But it's unclear whether that's the cause of your issue. You can either add Option NoAccel true to the device section in your xorg.conf, which will disable 2d acceleration and bring you back to the same state you were in before, or you can add Driver modesetting (or uninstall xf86-video-nouveau) which will use the modesetting driver which has a non-broken glamor integration. You may still get the same issues though, as they could just be generic mesa-sucks-on-maxwell issues (I don't have a Maxwell GPU, no one else has been interested in debugging/fixing issues). -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Odd text behavior on Websites and others
Thanks - the only xorg.conf I found is - /usr/share/abrt/conf.d/plugins/xorg.conf Is this the file to be edited? -- Rudolf Künzli rudolf.kun...@gmail.com On Tue, 2015-08-11 at 10:56 -0400, Ilia Mirkin wrote: On Tue, Aug 11, 2015 at 10:47 AM, Rudolf Künzli rudolf.kun...@gmail.com wrote: GeForce GTX 745 is a NVIDIA card in the NV117 (GM107) Family... The update was made using DNF (Yum) in my daily update procedure using the Fedora 22 Update repository. I am not familiar with details I just can report what happens right now... OK, there's no EXA support for maxwell, so you're using glamor. Before kernel 4.1, unless you had extracted your own ctxsw firmware, you didn't have acceleration at all, that was likely the change that triggered the issue. The glamor integration in nouveau is, sadly, broken. But it's unclear whether that's the cause of your issue. You can either add Option NoAccel true to the device section in your xorg.conf, which will disable 2d acceleration and bring you back to the same state you were in before, or you can add Driver modesetting (or uninstall xf86-video-nouveau) which will use the modesetting driver which has a non-broken glamor integration. You may still get the same issues though, as they could just be generic mesa-sucks-on-maxwell issues (I don't have a Maxwell GPU, no one else has been interested in debugging/fixing issues). -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Odd text behavior on Websites and others
I checked for all kind of conf files in /etc/... I can't figure out where the configuration file is placed. I found some for keyboard configuration... The Fedora 22 Installation Guide and the Release Notes don't reveal the necessary informations. I feel lost a little bit... I look further -- Rudolf Künzli rudolf.kun...@gmail.com On Tue, 2015-08-11 at 11:42 -0400, Ilia Mirkin wrote: No, you probably want something in /etc/X11... a lot of the time it's split up into a bunch of separate files in like /etc/X11/xorg.conf.d or something. You should consult your distro documentation for how to make it happen. On Tue, Aug 11, 2015 at 11:38 AM, Rudolf Künzli rudolf.kun...@gmail.com wrote: Thanks - the only xorg.conf I found is - /usr/share/abrt/conf.d/plugins/xorg.conf Is this the file to be edited? -- Rudolf Künzli rudolf.kun...@gmail.com On Tue, 2015-08-11 at 10:56 -0400, Ilia Mirkin wrote: On Tue, Aug 11, 2015 at 10:47 AM, Rudolf Künzli rudolf.kun...@gmail.com wrote: GeForce GTX 745 is a NVIDIA card in the NV117 (GM107) Family... The update was made using DNF (Yum) in my daily update procedure using the Fedora 22 Update repository. I am not familiar with details I just can report what happens right now... OK, there's no EXA support for maxwell, so you're using glamor. Before kernel 4.1, unless you had extracted your own ctxsw firmware, you didn't have acceleration at all, that was likely the change that triggered the issue. The glamor integration in nouveau is, sadly, broken. But it's unclear whether that's the cause of your issue. You can either add Option NoAccel true to the device section in your xorg.conf, which will disable 2d acceleration and bring you back to the same state you were in before, or you can add Driver modesetting (or uninstall xf86-video-nouveau) which will use the modesetting driver which has a non-broken glamor integration. You may still get the same issues though, as they could just be generic mesa-sucks-on-maxwell issues (I don't have a Maxwell GPU, no one else has been interested in debugging/fixing issues). -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Odd text behavior on Websites and others
I don't have a file /etc/X11/xorg.conf but a folder /etc/X11/xorg.conf.d [rudolf@mephisto xorg.conf.d]$ ls -la /etc/X11/xorg.conf.d total 12 drwxr-xr-x. 2 root root 4096 Aug 4 08:25 . drwxr-xr-x. 6 root root 4096 May 27 11:40 .. -rw-r--r--. 1 root root 265 Apr 21 17:06 00-keyboard.conf Then a folder /usr/share/X11/xorg.conf.d with serveral config files but I don't see which one to be edited... [rudolf@mephisto xorg.conf.d]$ ls -la /usr/share/X11/xorg.conf.d total 32 drwxr-xr-x. 2 root root 4096 Jul 31 18:33 . drwxr-xr-x. 7 root root 4096 May 27 11:40 .. -rw-r--r--. 1 root root 1099 Jul 15 10:20 10-evdev.conf -rw-r--r--. 1 root root 1350 Jul 15 10:20 10-quirks.conf -rw-r--r--. 1 root root 2827 May 1 08:23 50-synaptics.conf -rw-r--r--. 1 root root 115 May 15 14:49 50-vmmouse.conf -rw-r--r--. 1 root root 1385 Mar 20 00:31 50-wacom.conf -rw-r--r--. 1 root root 789 Jul 13 00:54 90-libinput.conf Any other place to look for. find didn't help... I guess I'll have to run x config as root to get a xorg.conf which I can edit later... -- Rudolf Künzli rudolf.kun...@gmail.com On Tue, 2015-08-11 at 11:42 -0400, Ilia Mirkin wrote: No, you probably want something in /etc/X11... a lot of the time it's split up into a bunch of separate files in like /etc/X11/xorg.conf.d or something. You should consult your distro documentation for how to make it happen. On Tue, Aug 11, 2015 at 11:38 AM, Rudolf Künzli rudolf.kun...@gmail.com wrote: Thanks - the only xorg.conf I found is - /usr/share/abrt/conf.d/plugins/xorg.conf Is this the file to be edited? -- Rudolf Künzli rudolf.kun...@gmail.com On Tue, 2015-08-11 at 10:56 -0400, Ilia Mirkin wrote: On Tue, Aug 11, 2015 at 10:47 AM, Rudolf Künzli rudolf.kun...@gmail.com wrote: GeForce GTX 745 is a NVIDIA card in the NV117 (GM107) Family... The update was made using DNF (Yum) in my daily update procedure using the Fedora 22 Update repository. I am not familiar with details I just can report what happens right now... OK, there's no EXA support for maxwell, so you're using glamor. Before kernel 4.1, unless you had extracted your own ctxsw firmware, you didn't have acceleration at all, that was likely the change that triggered the issue. The glamor integration in nouveau is, sadly, broken. But it's unclear whether that's the cause of your issue. You can either add Option NoAccel true to the device section in your xorg.conf, which will disable 2d acceleration and bring you back to the same state you were in before, or you can add Driver modesetting (or uninstall xf86-video-nouveau) which will use the modesetting driver which has a non-broken glamor integration. You may still get the same issues though, as they could just be generic mesa-sucks-on-maxwell issues (I don't have a Maxwell GPU, no one else has been interested in debugging/fixing issues). -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] Odd text behavior on Websites and others
Add a file to /etc/X11/xorg.conf.d, named anything-you-want.conf, which contains Section Device Driver modesetting EndSection Hopefully that should do it. On Tue, Aug 11, 2015 at 6:03 PM, Rudolf Künzli rudolf.kun...@gmail.com wrote: I don't have a file /etc/X11/xorg.conf but a folder /etc/X11/xorg.conf.d [rudolf@mephisto xorg.conf.d]$ ls -la /etc/X11/xorg.conf.d total 12 drwxr-xr-x. 2 root root 4096 Aug 4 08:25 . drwxr-xr-x. 6 root root 4096 May 27 11:40 .. -rw-r--r--. 1 root root 265 Apr 21 17:06 00-keyboard.conf Then a folder /usr/share/X11/xorg.conf.d with serveral config files but I don't see which one to be edited... [rudolf@mephisto xorg.conf.d]$ ls -la /usr/share/X11/xorg.conf.d total 32 drwxr-xr-x. 2 root root 4096 Jul 31 18:33 . drwxr-xr-x. 7 root root 4096 May 27 11:40 .. -rw-r--r--. 1 root root 1099 Jul 15 10:20 10-evdev.conf -rw-r--r--. 1 root root 1350 Jul 15 10:20 10-quirks.conf -rw-r--r--. 1 root root 2827 May 1 08:23 50-synaptics.conf -rw-r--r--. 1 root root 115 May 15 14:49 50-vmmouse.conf -rw-r--r--. 1 root root 1385 Mar 20 00:31 50-wacom.conf -rw-r--r--. 1 root root 789 Jul 13 00:54 90-libinput.conf Any other place to look for. find didn't help... I guess I'll have to run x config as root to get a xorg.conf which I can edit later... -- Rudolf Künzli rudolf.kun...@gmail.com On Tue, 2015-08-11 at 11:42 -0400, Ilia Mirkin wrote: No, you probably want something in /etc/X11... a lot of the time it's split up into a bunch of separate files in like /etc/X11/xorg.conf.d or something. You should consult your distro documentation for how to make it happen. On Tue, Aug 11, 2015 at 11:38 AM, Rudolf Künzli rudolf.kun...@gmail.com wrote: Thanks - the only xorg.conf I found is - /usr/share/abrt/conf.d/plugins/xorg.conf Is this the file to be edited? -- Rudolf Künzli rudolf.kun...@gmail.com On Tue, 2015-08-11 at 10:56 -0400, Ilia Mirkin wrote: On Tue, Aug 11, 2015 at 10:47 AM, Rudolf Künzli rudolf.kun...@gmail.com wrote: GeForce GTX 745 is a NVIDIA card in the NV117 (GM107) Family... The update was made using DNF (Yum) in my daily update procedure using the Fedora 22 Update repository. I am not familiar with details I just can report what happens right now... OK, there's no EXA support for maxwell, so you're using glamor. Before kernel 4.1, unless you had extracted your own ctxsw firmware, you didn't have acceleration at all, that was likely the change that triggered the issue. The glamor integration in nouveau is, sadly, broken. But it's unclear whether that's the cause of your issue. You can either add Option NoAccel true to the device section in your xorg.conf, which will disable 2d acceleration and bring you back to the same state you were in before, or you can add Driver modesetting (or uninstall xf86-video-nouveau) which will use the modesetting driver which has a non-broken glamor integration. You may still get the same issues though, as they could just be generic mesa-sucks-on-maxwell issues (I don't have a Maxwell GPU, no one else has been interested in debugging/fixing issues). -ilia ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()
Sending the revert patch to Dave after receiving his green light for this, and will investigate the issue on my side. I should be able to find a gk107 somewhere... On Wed, Aug 12, 2015 at 12:35 PM, Alexandre Courbot gnu...@gmail.com wrote: Mmm in that case it is probably best to revert that commit for the time being. It was targeting GM20B (and maybe other Maxwells too) so reverting it should not hurt anyone at the moment. I think Ben is on holidays for now, is there anyone else who can send a pull request to Dave Airlie for this? We don't want 4.2 to ship with a crash every other reboot... On Wed, Aug 12, 2015 at 10:01 AM, Eric Biggers ebigge...@gmail.com wrote: Hi, I think I've done about 10 reboots with the commit reverted and I never experienced the crash. But with 4.2.0-rc6 I get the crash on about every other reboot. Probably relevant: the computer on which the crash occurs has two GPUs (one Intel and one Nvidia). The Intel one is actually being used, whereas I presume the Nvidia one is being automatically disabled shortly after boot, perhaps when the crash occurs... Eric On Mon, Aug 10, 2015 at 11:28 PM, Alexandre Courbot gnu...@gmail.com wrote: Indeed, and I am actually surprised to see one here. I will double-check that patch. Eric, would you be able to give an estimate of the repro rate for this issue? More testing with and without the patch would be welcome, it'd be good to know whether it is actually the culprit or not. On Mon, Aug 10, 2015 at 2:28 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Alexandre, could you take a look? 0xbad* generally comes from bad mmio reads. On Aug 9, 2015 1:08 PM, Eric Biggers ebigge...@gmail.com wrote: Hi, I am testing Linux v4.2-rc5 and I am sporadically getting crashes shortly after startup in gk104_fifo_intr_runlist(). What I've found is that the 'mask' value read from offset 0x2a00 comes back as '0xbad0da00'. This causes the 'engn' variable to be assigned the value 9, which is invalid; then wake_up() is called on an uninitialized waitqueue which causes the crash. Reverting commit 1addc12648521d (drm/nouveau/fifo/gk104: kick channels when deactivating them) seemed to make the problem go away, although I can't be 100% sure because the problem is sporadic. Attached an example of the kernel log up to the crash. Eric ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [Bug 91598] Broken Rendering of Plasma 5 Desktop
https://bugs.freedesktop.org/show_bug.cgi?id=91598 --- Comment #3 from David March davidmarch...@gmail.com --- Just wanted to add that I likewise am seeing the same issue. As Andreas said the problems increase as time goes on. I do notice the corruption of menus and such seems to be cumulative. Eventually after many days in my experience sometimes the problem can cause a full crash. It makes no difference for me whether or not compositing is on or off. Here is a portion of the dmesg output: [48838.708929] nouveau E[plasmashell[1827]] fail set_domain [48838.708936] nouveau E[plasmashell[1827]] validating bo list [48838.708959] nouveau E[plasmashell[1827]] validate: -22 [48838.757948] nouveau E[plasmashell[1827]] fail set_domain [48838.757956] nouveau E[plasmashell[1827]] validating bo list [48838.757964] nouveau E[plasmashell[1827]] validate: -22 [48839.000699] nouveau E[ PFB][:01:00.0] trapped read at 0x0020529000 on channel 0xf64f [plasmashell[1827]] PGRAPH/TEXTURE/00 reason: PAGE_NOT_PRESENT [48839.054871] nouveau E[ PFB][:01:00.0] trapped read at 0x0020529000 on channel 0xf64f [plasmashell[1827]] PGRAPH/TEXTURE/00 reason: PAGE_NOT_PRESENT [48839.690129] nouveau E[ PFB][:01:00.0] trapped read at 0x0020529000 on channel 0xfb33 [X[1641]] PGRAPH/TEXTURE/00 reason: PAGE_NOT_PRESENT Hardware info: 01:00.0 VGA compatible controller: NVIDIA Corporation G84GL [Quadro FX 570] (rev a1) (prog-if 00 [VGA controller]) Subsystem: NVIDIA Corporation G84GL [Quadro FX 570] Flags: bus master, fast devsel, latency 0, IRQ 28 Memory at fc00 (32-bit, non-prefetchable) [size=16M] Memory at d000 (64-bit, prefetchable) [size=256M] Memory at fa00 (64-bit, non-prefetchable) [size=32M] I/O ports at dc80 [size=128] Expansion ROM at fde0 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [68] MSI: Enable+ Count=1/1 Maskable- 64bit+ Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel Capabilities: [128] Power Budgeting ? Capabilities: [600] Vendor Specific Information: ID=0001 Rev=1 Len=024 ? Kernel driver in use: nouveau - Software info: x11-drivers/xf86-video-nouveau-1.0.11 media-libs/mesa-10.6.3 x11-apps/mesa-progs-8.2.0 kde-plasma/plasma-desktop- (pulled from master 12:29:55 PM 08/09/2015) Linux gentoo 4.1.4-gentoo #1 SMP Tue Aug 4 15:36:28 EDT 2015 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux - -- You are receiving this mail because: You are the assignee for the bug. ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()
Hi, I think I've done about 10 reboots with the commit reverted and I never experienced the crash. But with 4.2.0-rc6 I get the crash on about every other reboot. Probably relevant: the computer on which the crash occurs has two GPUs (one Intel and one Nvidia). The Intel one is actually being used, whereas I presume the Nvidia one is being automatically disabled shortly after boot, perhaps when the crash occurs... Eric On Mon, Aug 10, 2015 at 11:28 PM, Alexandre Courbot gnu...@gmail.com wrote: Indeed, and I am actually surprised to see one here. I will double-check that patch. Eric, would you be able to give an estimate of the repro rate for this issue? More testing with and without the patch would be welcome, it'd be good to know whether it is actually the culprit or not. On Mon, Aug 10, 2015 at 2:28 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Alexandre, could you take a look? 0xbad* generally comes from bad mmio reads. On Aug 9, 2015 1:08 PM, Eric Biggers ebigge...@gmail.com wrote: Hi, I am testing Linux v4.2-rc5 and I am sporadically getting crashes shortly after startup in gk104_fifo_intr_runlist(). What I've found is that the 'mask' value read from offset 0x2a00 comes back as '0xbad0da00'. This causes the 'engn' variable to be assigned the value 9, which is invalid; then wake_up() is called on an uninitialized waitqueue which causes the crash. Reverting commit 1addc12648521d (drm/nouveau/fifo/gk104: kick channels when deactivating them) seemed to make the problem go away, although I can't be 100% sure because the problem is sporadic. Attached an example of the kernel log up to the crash. Eric ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
[Nouveau] [PATCH] Revert drm/nouveau/fifo/gk104: kick channels when deactivating them
This reverts commit 1addc1264852
This commit seems to cause crashes in gk104_fifo_intr_runlist() by
returning 0xbad0da00 when register 0x2a00 is read. Since this commit was
intended for GM20B which is not completely supported yet, let's revert
it for the time being.
Reported-by: Eric Biggers ebigge...@gmail.com
Signed-off-by: Alexandre Courbot acour...@nvidia.com
---
David, it would be great if this could be merged for 4.2 since lots of
users could potentially experience this issue. Thanks!
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c | 29 +++-
1 file changed, 8 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
index 52c22b026005..e10f9644140f 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/fifo/gk104.c
@@ -166,30 +166,14 @@ gk104_fifo_context_attach(struct nvkm_object *parent,
}
static int
-gk104_fifo_chan_kick(struct gk104_fifo_chan *chan)
-{
- struct nvkm_object *obj = (void *)chan;
- struct gk104_fifo_priv *priv = (void *)obj-engine;
-
- nv_wr32(priv, 0x002634, chan-base.chid);
- if (!nv_wait(priv, 0x002634, 0x10, 0x00)) {
- nv_error(priv, channel %d [%s] kick timeout\n,
-chan-base.chid, nvkm_client_name(chan));
- return -EBUSY;
- }
-
- return 0;
-}
-
-static int
gk104_fifo_context_detach(struct nvkm_object *parent, bool suspend,
struct nvkm_object *object)
{
struct nvkm_bar *bar = nvkm_bar(parent);
+ struct gk104_fifo_priv *priv = (void *)parent-engine;
struct gk104_fifo_base *base = (void *)parent-parent;
struct gk104_fifo_chan *chan = (void *)parent;
u32 addr;
- int ret;
switch (nv_engidx(object-engine)) {
case NVDEV_ENGINE_SW: return 0;
@@ -204,9 +188,13 @@ gk104_fifo_context_detach(struct nvkm_object *parent, bool
suspend,
return -EINVAL;
}
- ret = gk104_fifo_chan_kick(chan);
- if (ret suspend)
- return ret;
+ nv_wr32(priv, 0x002634, chan-base.chid);
+ if (!nv_wait(priv, 0x002634, 0x, chan-base.chid)) {
+ nv_error(priv, channel %d [%s] kick timeout\n,
+chan-base.chid, nvkm_client_name(chan));
+ if (suspend)
+ return -EBUSY;
+ }
if (addr) {
nv_wo32(base, addr + 0x00, 0x);
@@ -331,7 +319,6 @@ gk104_fifo_chan_fini(struct nvkm_object *object, bool
suspend)
gk104_fifo_runlist_update(priv, chan-engine);
}
- gk104_fifo_chan_kick(chan);
nv_wr32(priv, 0x80 + (chid * 8), 0x);
return nvkm_fifo_channel_fini(chan-base, suspend);
}
--
2.5.0
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()
I'm guessing that optimus is the operative difference, not the specific chip. Basically something that can be put to sleep via ACPI... On Tue, Aug 11, 2015 at 11:53 PM, Alexandre Courbot gnu...@gmail.com wrote: Sending the revert patch to Dave after receiving his green light for this, and will investigate the issue on my side. I should be able to find a gk107 somewhere... On Wed, Aug 12, 2015 at 12:35 PM, Alexandre Courbot gnu...@gmail.com wrote: Mmm in that case it is probably best to revert that commit for the time being. It was targeting GM20B (and maybe other Maxwells too) so reverting it should not hurt anyone at the moment. I think Ben is on holidays for now, is there anyone else who can send a pull request to Dave Airlie for this? We don't want 4.2 to ship with a crash every other reboot... On Wed, Aug 12, 2015 at 10:01 AM, Eric Biggers ebigge...@gmail.com wrote: Hi, I think I've done about 10 reboots with the commit reverted and I never experienced the crash. But with 4.2.0-rc6 I get the crash on about every other reboot. Probably relevant: the computer on which the crash occurs has two GPUs (one Intel and one Nvidia). The Intel one is actually being used, whereas I presume the Nvidia one is being automatically disabled shortly after boot, perhaps when the crash occurs... Eric On Mon, Aug 10, 2015 at 11:28 PM, Alexandre Courbot gnu...@gmail.com wrote: Indeed, and I am actually surprised to see one here. I will double-check that patch. Eric, would you be able to give an estimate of the repro rate for this issue? More testing with and without the patch would be welcome, it'd be good to know whether it is actually the culprit or not. On Mon, Aug 10, 2015 at 2:28 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Alexandre, could you take a look? 0xbad* generally comes from bad mmio reads. On Aug 9, 2015 1:08 PM, Eric Biggers ebigge...@gmail.com wrote: Hi, I am testing Linux v4.2-rc5 and I am sporadically getting crashes shortly after startup in gk104_fifo_intr_runlist(). What I've found is that the 'mask' value read from offset 0x2a00 comes back as '0xbad0da00'. This causes the 'engn' variable to be assigned the value 9, which is invalid; then wake_up() is called on an uninitialized waitqueue which causes the crash. Reverting commit 1addc12648521d (drm/nouveau/fifo/gk104: kick channels when deactivating them) seemed to make the problem go away, although I can't be 100% sure because the problem is sporadic. Attached an example of the kernel log up to the crash. Eric ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()
Right, that 0xbad0da00 is indicative of something being offline that should not be at that time. I have sent the revert patch. Thanks Eric for reporting this! On Wed, Aug 12, 2015 at 1:00 PM, Ilia Mirkin imir...@alum.mit.edu wrote: I'm guessing that optimus is the operative difference, not the specific chip. Basically something that can be put to sleep via ACPI... On Tue, Aug 11, 2015 at 11:53 PM, Alexandre Courbot gnu...@gmail.com wrote: Sending the revert patch to Dave after receiving his green light for this, and will investigate the issue on my side. I should be able to find a gk107 somewhere... On Wed, Aug 12, 2015 at 12:35 PM, Alexandre Courbot gnu...@gmail.com wrote: Mmm in that case it is probably best to revert that commit for the time being. It was targeting GM20B (and maybe other Maxwells too) so reverting it should not hurt anyone at the moment. I think Ben is on holidays for now, is there anyone else who can send a pull request to Dave Airlie for this? We don't want 4.2 to ship with a crash every other reboot... On Wed, Aug 12, 2015 at 10:01 AM, Eric Biggers ebigge...@gmail.com wrote: Hi, I think I've done about 10 reboots with the commit reverted and I never experienced the crash. But with 4.2.0-rc6 I get the crash on about every other reboot. Probably relevant: the computer on which the crash occurs has two GPUs (one Intel and one Nvidia). The Intel one is actually being used, whereas I presume the Nvidia one is being automatically disabled shortly after boot, perhaps when the crash occurs... Eric On Mon, Aug 10, 2015 at 11:28 PM, Alexandre Courbot gnu...@gmail.com wrote: Indeed, and I am actually surprised to see one here. I will double-check that patch. Eric, would you be able to give an estimate of the repro rate for this issue? More testing with and without the patch would be welcome, it'd be good to know whether it is actually the culprit or not. On Mon, Aug 10, 2015 at 2:28 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Alexandre, could you take a look? 0xbad* generally comes from bad mmio reads. On Aug 9, 2015 1:08 PM, Eric Biggers ebigge...@gmail.com wrote: Hi, I am testing Linux v4.2-rc5 and I am sporadically getting crashes shortly after startup in gk104_fifo_intr_runlist(). What I've found is that the 'mask' value read from offset 0x2a00 comes back as '0xbad0da00'. This causes the 'engn' variable to be assigned the value 9, which is invalid; then wake_up() is called on an uninitialized waitqueue which causes the crash. Reverting commit 1addc12648521d (drm/nouveau/fifo/gk104: kick channels when deactivating them) seemed to make the problem go away, although I can't be 100% sure because the problem is sporadic. Attached an example of the kernel log up to the crash. Eric ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
Re: [Nouveau] [REGRESSION] nouveau: Crash in gk104_fifo_intr_runlist()
Mmm in that case it is probably best to revert that commit for the time being. It was targeting GM20B (and maybe other Maxwells too) so reverting it should not hurt anyone at the moment. I think Ben is on holidays for now, is there anyone else who can send a pull request to Dave Airlie for this? We don't want 4.2 to ship with a crash every other reboot... On Wed, Aug 12, 2015 at 10:01 AM, Eric Biggers ebigge...@gmail.com wrote: Hi, I think I've done about 10 reboots with the commit reverted and I never experienced the crash. But with 4.2.0-rc6 I get the crash on about every other reboot. Probably relevant: the computer on which the crash occurs has two GPUs (one Intel and one Nvidia). The Intel one is actually being used, whereas I presume the Nvidia one is being automatically disabled shortly after boot, perhaps when the crash occurs... Eric On Mon, Aug 10, 2015 at 11:28 PM, Alexandre Courbot gnu...@gmail.com wrote: Indeed, and I am actually surprised to see one here. I will double-check that patch. Eric, would you be able to give an estimate of the repro rate for this issue? More testing with and without the patch would be welcome, it'd be good to know whether it is actually the culprit or not. On Mon, Aug 10, 2015 at 2:28 AM, Ilia Mirkin imir...@alum.mit.edu wrote: Alexandre, could you take a look? 0xbad* generally comes from bad mmio reads. On Aug 9, 2015 1:08 PM, Eric Biggers ebigge...@gmail.com wrote: Hi, I am testing Linux v4.2-rc5 and I am sporadically getting crashes shortly after startup in gk104_fifo_intr_runlist(). What I've found is that the 'mask' value read from offset 0x2a00 comes back as '0xbad0da00'. This causes the 'engn' variable to be assigned the value 9, which is invalid; then wake_up() is called on an uninitialized waitqueue which causes the crash. Reverting commit 1addc12648521d (drm/nouveau/fifo/gk104: kick channels when deactivating them) seemed to make the problem go away, although I can't be 100% sure because the problem is sporadic. Attached an example of the kernel log up to the crash. Eric ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau ___ Nouveau mailing list Nouveau@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/nouveau
