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
Looks like the slave pixmap didn't have a GPU bo associated with it. Hmm.
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.
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 on attachment 107318 [details] xorg.log with --enable-debug=full Wrong mime type, it's xz compressed.
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.
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.
Created attachment 107362 [details] debug xorg log after e50e1bb3fd2fd20cce580841b20a3e47c7111ee9
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).
(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.
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.