Reported regressions for 4.7 as of Sunday, 2016-06-19
Am Sonntag, den 26.06.2016, 14:52 +0200 schrieb Thorsten Leemhuis: > On 24.06.2016 16:19, George Spelvin wrote: > > > > Here's a regression you might add.  > Thx, added. > Probably the same bug as https://bugzilla.kernel.org/show_bug.cgi?id=119861 and already fixed in the last -rc. Regards, Lucas > > > > I only reported it to dri-devel, > > since it's DRI-specific, but since there's been thunderous silence > > for a few weeks, I'm trying to be a squeakier wheel. > Added the nouveau developers to CC, maybe it's a bug in the drm > driver > that triggers this problem; and airlied is "Internet challenged" > right > now and Daniel on holidays, so it might be good to get more people > into > the loop anyway. > > > > > Given that I bisected it to a single, small, revertable commit, I'd > > hoped it would be easy to deal with. > > > > [BISECTED: 0955c1250e] 4.7-rc1 oops at > > drm_connector_cleanup+0x5c/0x1d0 > > > > E-mail report at > > https://marc.info/?l=dri-devel=146577898611849 > > > > Bugzilla report at > > https://bugs.freedesktop.org/show_bug.cgi?id=96532 > FWIW the important detail: Reverting > https://git.kernel.org/linus/0955c1250e (drm/crtc: take references to > connectors used in a modeset. (v2)) fixes this. > > Sincerely, your regression tracker for Linux 4.7 (http://bit.ly/28JRm > Jo) >  Thorsten > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel
Reported regressions for 4.7 as of Sunday, 2016-06-19
On 24.06.2016 16:19, George Spelvin wrote: > Here's a regression you might add. Thx, added. > I only reported it to dri-devel, > since it's DRI-specific, but since there's been thunderous silence > for a few weeks, I'm trying to be a squeakier wheel. Added the nouveau developers to CC, maybe it's a bug in the drm driver that triggers this problem; and airlied is "Internet challenged" right now and Daniel on holidays, so it might be good to get more people into the loop anyway. > Given that I bisected it to a single, small, revertable commit, I'd > hoped it would be easy to deal with. > > [BISECTED: 0955c1250e] 4.7-rc1 oops at drm_connector_cleanup+0x5c/0x1d0 > > E-mail report at > https://marc.info/?l=dri-devel=146577898611849 > > Bugzilla report at > https://bugs.freedesktop.org/show_bug.cgi?id=96532 FWIW the important detail: Reverting https://git.kernel.org/linus/0955c1250e (drm/crtc: take references to connectors used in a modeset. (v2)) fixes this. Sincerely, your regression tracker for Linux 4.7 (http://bit.ly/28JRmJo) Thorsten
[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?
On Sun, Jun 26, 2016 at 2:04 PM, Andy Lutomirski wrote: > Eeek! My desire to hack on EXA is pretty low. If there was some Well, the EXA hacking was all done a long time ago. You'd just need to add support for sticking 4 vertices into a buffer. (Maxwell killed direct vertex submit, which was incredibly convenient for the DDX.) > straightforward way I could try to figure out why GLAMOR was so slow, > maybe I could fiddle with that a bit. Upgrade mesa & pray. I think that X11 can end up being pretty glReadPixels-heavy, which in a UMA system is ~free, but much more expensive when the FB is in VRAM. Recently some changes were committed to cache the entire texture in a staging texture if someone does a lot of readpixels on it. Could help. Or could be totally unrelated. You could do an apitrace of the X server (github.com/apitrace/apitrace) and then analyze what all it's doing. > > FWIW, my i915-based laptop uses the modesetting driver and GLAMOR as > well, and it's plenty fast, so I don't think the problem is that > GLAMOR is inherently terrible at legacy X11 operations. Different workloads, I suppose. I had to use GLAMOR on a SKL while the regular ddx was still lacking support for it, and my favorite screensaver was unbearably slow on it (xlock -mode wator, in case you're curious). [And regular usage was also not great, but not to the point of frustration.] It runs plenty fast with the SNA backend though. -ilia
[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?
On Sun, Jun 26, 2016 at 1:49 PM, Andy Lutomirski wrote: > On Sun, May 29, 2016 at 12:27 PM, Andy Lutomirski wrote: >> On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin >> wrote: >>> On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote: On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin wrote: > Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2. > I just upgraded to 11.2. I'm getting errors like this in the log: [ 5383.723240] nouveau :09:00.0: fifo: read fault at 011000 engine 07 [PBDMA0] client 06 [HOST] reason 00 [PDE] on channel -1 [007f9ed000 unknown] [ 5398.722676] nouveau :09:00.0: systemd-logind[30778]: failed to idle channel 2 [systemd-logind[30778]] [ 5413.722853] nouveau :09:00.0: systemd-logind[30778]: failed to idle channel 2 [systemd-logind[30778]] and the display output in general is unreliable enough that I'm having trouble telling whether the performance is remotely reasonable. >>> >>> If you're having trouble telling, that means it's not :) The error you >>> pasted is quite odd. Was there anything in the log before those >>> messages? If there's no channel associated, that means that it's the >>> background copying between vram and sysmem? Not sure. >> >> Don't get too excited yet. In the process of upgrading mesa, I >> managed to boot 4.5 without noticing. I'll post back later today with >> actual valid test results. >> > > I replaced the monitor (turns out that my monitor had a known DP > problem), and now the screen lights up reliably. I still get Great to hear! > occasional log lines like this: > > [Jun26 09:25] nouveau :09:00.0: fifo: FB_FLUSH_TIMEOUT > [Jun26 09:30] nouveau :09:00.0: fifo: FB_FLUSH_TIMEOUT > [Jun26 09:32] nouveau :09:00.0: fifo: CHSW_ERROR 0004 > [ +0.000162] nouveau :09:00.0: fifo: CHSW_ERROR 0005 These don't sound good at all! > [Jun26 09:46] nouveau :09:00.0: disp: outp 04:0006:0f44: link > training failed > [ +0.107894] nouveau :09:00.0: disp: outp 04:0006:0f44: link > training failed These are surprising if your monitor is working. Usually it means "couldn't establish link with the monitor". Perhaps something forces it to retry and it eventually succeeds. > > but they aren't causing an obvious problem. > >>> >>> Note that with maxwell we have yet to add EXA support to >>> xf86-video-nouveau, so you're ending up with GLAMOR (and Ben and I >>> disagree on whether EXA support should be added in the first place). >>> There was also an issue that glamor was hitting with nouveau which >>> appears to have dissipated, either due to a change in nouveau or a >>> change in glamor. So you might consider upgrading to Xorg 1.18.3 (as >>> glamor is part of X). > > I do have a serious performance issue, though: when I scroll in > Firefox (default configuration), the whole system drops to ~1fps or > less and, if I scroll enough (even putting the mouse over a simple > page like start.fedoraproject.org and flicking the wheel up and down a > few times), the entire desktop will become unusable for several > seconds. I seem to have this problem under X and under Wayland. > > For better or for worse, forcing Firefox's layers acceleration on > fixes the problem and scrolling is fast. > > I have no idea whether this is an X problem, a gnome-shell problem, a > mesa problem, a kernel problem, or something else. I believe the issue is with GLAMOR, but I'm not sure - in my experience, GLAMOR is slow as molasses for actual X11 ops that aren't "take this composited image and stick it on the screen", and the fact that you are on the lowest perf level of your GPU isn't helping your cause. Turning on acceleration in firefox probably makes it use more optimized GL paths than having some X11 -> GL translation layer. If you're interested, I've a 95% (percentage made up) completed EXA backend for maxwell, but I don't have the hw, or, to be frank, the interest in completing it (as a result of NVIDIA's creation of these locked down, actively anti-open source GPUs). However you're welcome to hack on it if you like - https://github.com/imirkin/xf86-video-nouveau/commit/abf0933a236b6069f42f86ad5b0bf5bbab28e0d6 - if you ask in #nouveau on irc.freenode.net, would be happy to talk about what all needs finishing. -ilia
[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?
On Sun, Jun 26, 2016 at 10:59 AM, Ilia Mirkin wrote: > On Sun, Jun 26, 2016 at 1:49 PM, Andy Lutomirski > wrote: >> On Sun, May 29, 2016 at 12:27 PM, Andy Lutomirski wrote: >>> On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin >>> wrote: On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote: > On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin > wrote: >> Do you have mesa 11.2 or later? GM20x support was only added in mesa >> 11.2. >> > > I just upgraded to 11.2. I'm getting errors like this in the log: > > [ 5383.723240] nouveau :09:00.0: fifo: read fault at 011000 > engine 07 [PBDMA0] client 06 [HOST] reason 00 [PDE] on channel -1 > [007f9ed000 unknown] > [ 5398.722676] nouveau :09:00.0: systemd-logind[30778]: failed to > idle channel 2 [systemd-logind[30778]] > [ 5413.722853] nouveau :09:00.0: systemd-logind[30778]: failed to > idle channel 2 [systemd-logind[30778]] > > and the display output in general is unreliable enough that I'm having > trouble telling whether the performance is remotely reasonable. If you're having trouble telling, that means it's not :) The error you pasted is quite odd. Was there anything in the log before those messages? If there's no channel associated, that means that it's the background copying between vram and sysmem? Not sure. >>> >>> Don't get too excited yet. In the process of upgrading mesa, I >>> managed to boot 4.5 without noticing. I'll post back later today with >>> actual valid test results. >>> >> >> I replaced the monitor (turns out that my monitor had a known DP >> problem), and now the screen lights up reliably. I still get > > Great to hear! > >> occasional log lines like this: >> >> [Jun26 09:25] nouveau :09:00.0: fifo: FB_FLUSH_TIMEOUT >> [Jun26 09:30] nouveau :09:00.0: fifo: FB_FLUSH_TIMEOUT >> [Jun26 09:32] nouveau :09:00.0: fifo: CHSW_ERROR 0004 >> [ +0.000162] nouveau :09:00.0: fifo: CHSW_ERROR 0005 > > These don't sound good at all! > >> [Jun26 09:46] nouveau :09:00.0: disp: outp 04:0006:0f44: link >> training failed >> [ +0.107894] nouveau :09:00.0: disp: outp 04:0006:0f44: link >> training failed > > These are surprising if your monitor is working. Usually it means > "couldn't establish link with the monitor". Perhaps something forces > it to retry and it eventually succeeds. Given the timing, I'm guessing that it tries a couple of times and eventually works. Given that the monitor is a newer, "fixed" revision of a known-seriously-broken Dell monitor, it wouldn't shock me if what's actually happening is that the monitor uses buggy DP hardware and the "fixed" firmware A03 actually works by forcing several retries when link training fails (as opposed to what A00 - A02 did, which seemed to involve failing a few times and then crashing, sometimes hard enough that even the monitor power button stopped working). > >> >> but they aren't causing an obvious problem. >> Note that with maxwell we have yet to add EXA support to xf86-video-nouveau, so you're ending up with GLAMOR (and Ben and I disagree on whether EXA support should be added in the first place). There was also an issue that glamor was hitting with nouveau which appears to have dissipated, either due to a change in nouveau or a change in glamor. So you might consider upgrading to Xorg 1.18.3 (as glamor is part of X). >> >> I do have a serious performance issue, though: when I scroll in >> Firefox (default configuration), the whole system drops to ~1fps or >> less and, if I scroll enough (even putting the mouse over a simple >> page like start.fedoraproject.org and flicking the wheel up and down a >> few times), the entire desktop will become unusable for several >> seconds. I seem to have this problem under X and under Wayland. >> >> For better or for worse, forcing Firefox's layers acceleration on >> fixes the problem and scrolling is fast. >> >> I have no idea whether this is an X problem, a gnome-shell problem, a >> mesa problem, a kernel problem, or something else. > > I believe the issue is with GLAMOR, but I'm not sure - in my > experience, GLAMOR is slow as molasses for actual X11 ops that aren't > "take this composited image and stick it on the screen", and the fact > that you are on the lowest perf level of your GPU isn't helping your > cause. Turning on acceleration in firefox probably makes it use more > optimized GL paths than having some X11 -> GL translation layer. > > If you're interested, I've a 95% (percentage made up) completed EXA > backend for maxwell, but I don't have the hw, or, to be frank, the > interest in completing it (as a result of NVIDIA's creation of these > locked down, actively anti-open source GPUs). However you're welcome > to hack on it if you like - > https://github.com/imirkin/xf86-video-nouveau/commit/abf0933a236b6069f42f86ad5b0bf5bbab28e0d6 > - if you ask
[Nouveau] Should I expect nouveau on 4.6 to work on a GM206?
On Sun, May 29, 2016 at 12:27 PM, Andy Lutomirski wrote: > On Sun, May 29, 2016 at 12:22 PM, Ilia Mirkin wrote: >> On Sun, May 29, 2016 at 3:07 PM, Andy Lutomirski wrote: >>> On Sat, May 28, 2016 at 5:48 PM, Ilia Mirkin >>> wrote: Do you have mesa 11.2 or later? GM20x support was only added in mesa 11.2. >>> >>> I just upgraded to 11.2. I'm getting errors like this in the log: >>> >>> [ 5383.723240] nouveau :09:00.0: fifo: read fault at 011000 >>> engine 07 [PBDMA0] client 06 [HOST] reason 00 [PDE] on channel -1 >>> [007f9ed000 unknown] >>> [ 5398.722676] nouveau :09:00.0: systemd-logind[30778]: failed to >>> idle channel 2 [systemd-logind[30778]] >>> [ 5413.722853] nouveau :09:00.0: systemd-logind[30778]: failed to >>> idle channel 2 [systemd-logind[30778]] >>> >>> and the display output in general is unreliable enough that I'm having >>> trouble telling whether the performance is remotely reasonable. >> >> If you're having trouble telling, that means it's not :) The error you >> pasted is quite odd. Was there anything in the log before those >> messages? If there's no channel associated, that means that it's the >> background copying between vram and sysmem? Not sure. > > Don't get too excited yet. In the process of upgrading mesa, I > managed to boot 4.5 without noticing. I'll post back later today with > actual valid test results. > I replaced the monitor (turns out that my monitor had a known DP problem), and now the screen lights up reliably. I still get occasional log lines like this: [Jun26 09:25] nouveau :09:00.0: fifo: FB_FLUSH_TIMEOUT [Jun26 09:30] nouveau :09:00.0: fifo: FB_FLUSH_TIMEOUT [Jun26 09:32] nouveau :09:00.0: fifo: CHSW_ERROR 0004 [ +0.000162] nouveau :09:00.0: fifo: CHSW_ERROR 0005 [Jun26 09:46] nouveau :09:00.0: disp: outp 04:0006:0f44: link training failed [ +0.107894] nouveau :09:00.0: disp: outp 04:0006:0f44: link training failed but they aren't causing an obvious problem. >> >> Note that with maxwell we have yet to add EXA support to >> xf86-video-nouveau, so you're ending up with GLAMOR (and Ben and I >> disagree on whether EXA support should be added in the first place). >> There was also an issue that glamor was hitting with nouveau which >> appears to have dissipated, either due to a change in nouveau or a >> change in glamor. So you might consider upgrading to Xorg 1.18.3 (as >> glamor is part of X). I do have a serious performance issue, though: when I scroll in Firefox (default configuration), the whole system drops to ~1fps or less and, if I scroll enough (even putting the mouse over a simple page like start.fedoraproject.org and flicking the wheel up and down a few times), the entire desktop will become unusable for several seconds. I seem to have this problem under X and under Wayland. For better or for worse, forcing Firefox's layers acceleration on fixes the problem and scrolling is fast. I have no idea whether this is an X problem, a gnome-shell problem, a mesa problem, a kernel problem, or something else.
[Bug 96678] Awesomenauts cannot launch AMD PITCAIRN
https://bugs.freedesktop.org/show_bug.cgi?id=96678 Bug ID: 96678 Summary: Awesomenauts cannot launch AMD PITCAIRN Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: quentin at splizard.com QA Contact: dri-devel at lists.freedesktop.org Created attachment 124723 --> https://bugs.freedesktop.org/attachment.cgi?id=124723=edit Stacktrace of the crash The video game Awesomenauts crashes on startup when initialising OpenGL renderer. This is on AMD PITCAIRN (DRM 2.43.0 / 4.4.0-24-generic, LLVM 3.8.0) Using mesa found in Ubuntu 16.04 and Mesa 12.1.0-devel (git-81978c6 2016-06-25 xenial-oibaf-ppa). Crashes while trying to free an invalid pointer. The game worked fine with a previous AMD card. (not radeonsi) -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20160626/261024c3/attachment.html>
