Bug 84653

Summary: xorg segfault when disabling and reenabling kwin compositing with dri2 gpu offloading
Product: xorg Reporter: Christoph Haag <haagch>
Component: Server/Ext/RandRAssignee: Xorg Project Team <xorg-team>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: medium    
Version: git   
Hardware: Other   
OS: Linux (All)   
Whiteboard:
i915 platform: i915 features:
Attachments:
Description Flags
full backtrace
none
xorg.log with --enable-debug=full
none
full backtrace after e50e1bb3fd2fd20cce580841b20a3e47c7111ee9
none
debug xorg log after e50e1bb3fd2fd20cce580841b20a3e47c7111ee9
none
Unredirect me! none

Description Christoph Haag 2014-10-04 08:03:24 UTC
Created attachment 107312 [details]
full backtrace

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Wimbledon XT [Radeon HD 7970M] (rev ff)

0. xrandr --setprovideroffloadsink radeon Intel
1. Start 3d program with DRI_PRIME=1 GALLIUM_HUD="fps,VRAM-usage+GTT-usage,requested-VRAM+requested-GTT,num-bytes-moved" LIBGL_DRI3_DISABLE=1 whatever
2. Press ctrl+alt+f12 hotkey to toggle kwin compositing twice
3. segfault

Happens every time.

xorg-server 1.16.1
xf86-video-intel, xf86-video-ati and mesa from recent git master
Comment 1 Chris Wilson 2014-10-04 09:26:02 UTC
Looks like the slave pixmap didn't have a GPU bo associated with it. Hmm.
Comment 2 Chris Wilson 2014-10-04 09:28:43 UTC
I'll have to go and refresh my memory on how the slaves are created and how we should be copying from them into the scanout. Iirc, they are dma-buf and so should be imported and created with a GPU bo. If you can attach the Xorg.0.log from xf86-video-intel compiled with --enable-debug=full that would fill in the missing details.
Comment 3 Christoph Haag 2014-10-04 10:14:41 UTC
Created attachment 107318 [details]
xorg.log with --enable-debug=full

(In reply to Chris Wilson from comment #2)
> Xorg.0.log from xf86-video-intel compiled with --enable-debug=full

Interesting detail: It does not happen after X startup on my LVDS output, but it happens once I disable the LVDS output and enable the HDMI output and then start the opengl program.
Comment 4 Christoph Haag 2014-10-04 10:17:14 UTC
Comment on attachment 107318 [details]
xorg.log with --enable-debug=full

Wrong mime type, it's xz compressed.
Comment 5 Chris Wilson 2014-10-05 07:17:38 UTC
Hmm, still haven't spotted why we end up with a GPU bo. I think it is because the CRTC is redirected to the slave pixmap, but that slave pixmap is never exported (and so its GPU bo is not pinned and gets removed).

The crash should be fixed with

commit e50e1bb3fd2fd20cce580841b20a3e47c7111ee9
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Sun Oct 5 08:12:52 2014 +0100

    sna: Only use copy redisplay fast path if we have a source GPU bo
    
    Odd as it may seem, but we can end up attempting to copy from a source
    CRTC pixmap that is not on the GPU. Here we need to use the heavyweight
    path to handle its composition normally.
    
    Reported-by: Christoph Haag <haagch@frickel.club>
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=84653
    Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>

but I still wonder if there is another bug at play here.
Comment 6 Christoph Haag 2014-10-05 17:05:14 UTC
Created attachment 107361 [details]
full backtrace after e50e1bb3fd2fd20cce580841b20a3e47c7111ee9

(In reply to Chris Wilson from comment #5)
> The crash should be fixed with
> 
> commit e50e1bb3fd2fd20cce580841b20a3e47c7111ee9

Unfortunately there is another crash.
Comment 7 Christoph Haag 2014-10-05 17:07:35 UTC
Created attachment 107362 [details]
debug xorg log after e50e1bb3fd2fd20cce580841b20a3e47c7111ee9
Comment 8 Chris Wilson 2014-10-06 08:25:55 UTC
Created attachment 107403 [details] [review]
Unredirect me!

It looks like a use-after-free of the redirected scanout pixmap. Notably we never receive the callback to unhook it. I think the clue is that you are driving pipe=1 (i.e. the second CRTC).
Comment 9 Christoph Haag 2014-10-06 17:45:08 UTC
(In reply to Chris Wilson from comment #8)
> Created attachment 107403 [details] [review] [review]
> Unredirect me!
> 
> It looks like a use-after-free of the redirected scanout pixmap. Notably we
> never receive the callback to unhook it. I think the clue is that you are
> driving pipe=1 (i.e. the second CRTC).

I'm using both patches and it works. No crash when using my second screen only anymore. Thanks.
Comment 10 Chris Wilson 2014-10-07 06:24:26 UTC
http://patchwork.freedesktop.org/patch/34647/

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.