Created attachment 102848 [details] bisect report Good day, xorg segfaults with latest xf86-video-intel driver and nvidia binary blob 340.24 randr offloading. Enclosing xorg log, git bisect report and my .xinitrc.
Created attachment 102849 [details] xorg log
Created attachment 102850 [details] .xinitrc im using
After reverting commit in question, everything works for me once again (latest master).
That wasn't the bug I was expecting to see... Why do you have the low power igfx slaved to the dgpu? That prevents -nvidia from ever powering down.
Can you attach gdb and get a 'bt full'? Note that requires a second computer to ssh in and run 'gdb --pid `pidof X`'
Will do. by the way, why would I had to use ssh for this? Can't I just fire gdb from unused tty?
(In reply to comment #4) > That wasn't the bug I was expecting to see... Why do you have the low power > igfx slaved to the dgpu? That prevents -nvidia from ever powering down. I'm playing around some opengl 4.x extensions and this machine is muxless optimus laptop so I can either go for offloading or use things like bumblebee, which brings some extra complexity when I'm debugging. Also, I'm playing some videogames in my spare time so I don't mind having nvidia (I have custom runlevel that only runs on igfx for powersave).
(In reply to comment #5) > Can you attach gdb and get a 'bt full'? Note that requires a second computer > to ssh in and run 'gdb --pid `pidof X`' Hm, it seems that it's not X thats segfaulting, it's 'xrandr --auto' that is being run after 'xrandr --setprovideroutputsource "Intel" NVIDIA-0'.
(In reply to comment #8) > (In reply to comment #5) > > Can you attach gdb and get a 'bt full'? Note that requires a second computer > > to ssh in and run 'gdb --pid `pidof X`' > > Hm, it seems that it's not X thats segfaulting, it's 'xrandr --auto' that is > being run after 'xrandr --setprovideroutputsource "Intel" NVIDIA-0'. Sorry for jitter, its 'xrandr --auto' that causes X to crash, but I'm unable to catch it in time since X is dying too quickly. Will give it some thought in the evening when I have free time. Any advice would be appreciated (perhaps I should just send dump or something).
If you don't have a second machine handy, try reproducing the crash after compiling xf86-video-intel with --enable-debug=full. That will dump lots to Xorg.0.log, so please compress before attaching.
Created attachment 102979 [details] Xorg.0.log Here is the log with --enable-debug=full. This time X didn't actually crash, but rather froze showing black screen and '_' cursor. Had to reboot the laptop.
Thanks. I see that the handling of foreign scanouts is indeed broken and needs some tlc.
The fix in your case should be fairly trivial, remove the sna_crtc->transform = true and remember to unoffset the CRTC. However, handling the transformed slaved CRTC was broken. commit a45b2ea11c15f35c36330ff27cb45854a29c2e2c Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jul 17 14:40:51 2014 +0100 sna: Handle rotated slaved scanouts As per the usual handling of rotated scanouts with unsupported rotations, we stage the drawing onto a backbuffer then rotate onto the crtc later. The difference here is that we must read the contents from the master pixmap rather than our own screen pixmap. Spotted was looking at slaved scanouts mistakenly setting the CRTC transformed flag. Reported-by: Tomas Pruzina <pruzinat@gmail.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81383 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
(In reply to comment #13) > The fix in your case should be fairly trivial, remove the > sna_crtc->transform = true and remember to unoffset the CRTC. However, > handling the transformed slaved CRTC was broken. > > > commit a45b2ea11c15f35c36330ff27cb45854a29c2e2c > Author: Chris Wilson <chris@chris-wilson.co.uk> > Date: Thu Jul 17 14:40:51 2014 +0100 > > sna: Handle rotated slaved scanouts > > As per the usual handling of rotated scanouts with unsupported > rotations, we stage the drawing onto a backbuffer then rotate onto the > crtc later. The difference here is that we must read the contents from > the master pixmap rather than our own screen pixmap. > > Spotted was looking at slaved scanouts mistakenly setting the CRTC > transformed flag. > > Reported-by: Tomas Pruzina <pruzinat@gmail.com> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=81383 > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Thanks, I'll test it for a bit and report back if anything is unstable.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.