Bug 81383

Summary: [intel+nvidia randr offloading] X segfaults with latest intel drivers
Product: xorg Reporter: Tomas Pruzina <pruzinat>
Component: Driver/intelAssignee: Chris Wilson <chris>
Status: RESOLVED FIXED QA Contact: Intel GFX Bugs mailing list <intel-gfx-bugs>
Severity: blocker    
Priority: highest CC: chris, pruzinat
Version: unspecified   
Hardware: x86-64 (AMD64)   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
bisect report
none
xorg log
none
.xinitrc im using
none
Xorg.0.log none

Description Tomas Pruzina 2014-07-15 11:57:36 UTC
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.
Comment 1 Tomas Pruzina 2014-07-15 11:58:16 UTC
Created attachment 102849 [details]
xorg log
Comment 2 Tomas Pruzina 2014-07-15 11:58:57 UTC
Created attachment 102850 [details]
.xinitrc im using
Comment 3 Tomas Pruzina 2014-07-15 13:56:34 UTC
After reverting commit in question, everything works for me once again (latest master).
Comment 4 Chris Wilson 2014-07-16 06:24:44 UTC
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.
Comment 5 Chris Wilson 2014-07-16 06:26:19 UTC
Can you attach gdb and get a 'bt full'? Note that requires a second computer to ssh in and run 'gdb --pid `pidof X`'
Comment 6 Tomas Pruzina 2014-07-16 13:10:07 UTC
Will do.
by the way, why would I had to use ssh for this? Can't I just fire gdb from unused tty?
Comment 7 Tomas Pruzina 2014-07-16 13:26:34 UTC
(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).
Comment 8 Tomas Pruzina 2014-07-16 14:05:09 UTC
(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'.
Comment 9 Tomas Pruzina 2014-07-16 14:22:44 UTC
(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).
Comment 10 Chris Wilson 2014-07-17 06:29:07 UTC
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.
Comment 11 Tomas Pruzina 2014-07-17 11:30:41 UTC
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.
Comment 12 Chris Wilson 2014-07-17 12:03:52 UTC
Thanks. I see that the handling of foreign scanouts is indeed broken and needs some tlc.
Comment 13 Chris Wilson 2014-07-17 14:25:06 UTC
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>
Comment 14 Tomas Pruzina 2014-07-17 14:52:59 UTC
(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.