Bug 103613 - Reverse Prime with intel/amdgpu causes segfault in glamor_block_handler when enabling monitor
Summary: Reverse Prime with intel/amdgpu causes segfault in glamor_block_handler when ...
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/AMDgpu (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: xf86-video-ati maintainers
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 103618
  Show dependency tree / graph
 
Reported: 2017-11-07 19:05 UTC by EoD
Modified: 2017-11-15 16:59 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

Attachments
GDBs Backtrace with -O0 (2.36 KB, text/x-log)
2017-11-07 20:54 UTC, EoD 		no flags Details
Use the correct ScrnInfoPtr in redisplay_dirty (474 bytes, patch)
2017-11-08 09:33 UTC, Michel Dänzer 		no flags Details | Splinter Review
View All

Description EoD 2017-11-07 19:05:30 UTC 
I have a discrete AMD card (Tonga) using amdgpu and an iGPU (Skylake/HD530) using the intel driver.

I enabled DRI3 on both devices, but xrandr only shows the outputs/monitors of the AMD card.

When I use "xrandr --setprovideroutputsource 1 0" everything is still fine, xrandr shows now all outputs/monitors.

When I try to enable the monitor connected to the iGPU via "xrandr --output HDMI3 --auto" the x-server segfaults with the following backtrace:

#0  0x00007fdffdd2334d in glamor_block_handler () from /usr/lib64/xorg/modules/libglamoregl.so
#1  0x00007fe00d639f8b in amdgpu_glamor_flush () from /usr/lib64/xorg/modules/drivers/amdgpu_drv.so
#2  0x00007fe00d62df23 in redisplay_dirty () from /usr/lib64/xorg/modules/drivers/amdgpu_drv.so
#3  0x00007fe00d62f728 in AMDGPUBlockHandler_KMS () from /usr/lib64/xorg/modules/drivers/amdgpu_drv.so
#4  0x000000000043a27f in BlockHandler ()
#5  0x0000000000587ac3 in WaitForSomething ()

Here are further details, including the Xorg.log and the used configs: https://gist.github.com/EoD/c1c4f2b4afde2d0523e9ea8bb1567452
Comment 1 EoD 2017-11-07 19:23:12 UTC 
I also tried using modesetting instead of the other drivers and

Enabling the monitor...

- works, when I set driver=modesetting on the both cards via an xorg.conf
- works, when I set driver=modesetting on the intel card only.
- works, when I set driver=modesetting on the amd card only, but according to listproviders, both cards use modesetting.
Comment 2 EoD 2017-11-07 20:06:07 UTC 
On request from IRC, I also tried using UXA instead of SNA with the intel driver.

It does not crash anymore, but when I try to enable the 2nd monitor, I get a "xrandr: Configure crtc 6 failed" and the following output in the Xorg.log:

[  1537.831] randr: falling back to unsynchronized pixmap sharing
[  1537.831] randr: failed to set shadow slave pixmap
[  1537.831] (EE) intel(G0): failed to set mode: No space left on device
Comment 3 EoD 2017-11-07 20:54:05 UTC 
Created attachment 135291 [details]
GDBs Backtrace with -O0
Comment 4 Michel Dänzer 2017-11-08 09:33:58 UTC 
Created attachment 135295 [details] [review]
Use the correct ScrnInfoPtr in redisplay_dirty

Does this xf86-video-amdgpu patch fix it?
Comment 5 EoD 2017-11-08 10:09:37 UTC 
(In reply to Michel Dänzer from comment #4)
> Created attachment 135295 [details] [review] [review]
> Use the correct ScrnInfoPtr in redisplay_dirty
> 
> Does this xf86-video-amdgpu patch fix it?

The patch avoids the crash, but the 2ndary screen does not change. It just stays active (power LED is on) with a blank screen.
Comment 6 Michel Dänzer 2017-11-08 10:30:31 UTC 
(In reply to EoD from comment #5)
> The patch avoids the crash, but the 2ndary screen does not change. It just
> stays active (power LED is on) with a blank screen.

Does that only happen when using xf86-video-intel for the Intel GPU, or also when using modesetting? If the former, it sounds like a separate issue in xf86-video-intel.
Comment 7 EoD 2017-11-08 10:58:21 UTC 
(In reply to Michel Dänzer from comment #6)
> (In reply to EoD from comment #5)
> > The patch avoids the crash, but the 2ndary screen does not change. It just
> > stays active (power LED is on) with a blank screen.
> 
> Does that only happen when using xf86-video-intel for the Intel GPU, or also
> when using modesetting? If the former, it sounds like a separate issue in
> xf86-video-intel.

With and w/o the patch, there no problems when I use modesetting instead of xf86-video-intel.

Does this mean it's clearly an Intel issue now? Even w/o the patch?


I also asked on IRC and more or less these lines were the last ones regarding the issue:
20:55 ickle: I wasn't expecting 0  
21:21 ickle: more perplexing, we don't use screen->devPrivates 
21:22 ickle: amdgpu_glamor_flush() is flushing the wrong pScrn 
21:23 ickle: amdgpu's screen/scrn is 0xd66150/0xbfad60, the one it pasted to glamor is 0xbfc650/0xd4fa10

I think the "expecting 0" is a "expecting 0 for glamor_priv".
Comment 8 Michel Dänzer 2017-11-08 11:12:43 UTC 
(In reply to EoD from comment #7)
> With and w/o the patch, there no problems when I use modesetting instead of
> xf86-video-intel.
> 
> Does this mean it's clearly an Intel issue now? Even w/o the patch?

The crash this report is about is an xf86-video-amdgpu bug, for which I'll submit a proper fix for review soon.

The blank screen described in comment 5 sounds like a separate bug in xf86-video-intel so far.
Comment 9 Michel Dänzer 2017-11-15 16:59:23 UTC 
Thanks for the report, fixed in xf86-video-amdgpu Git master:

commit 3a4f7422913093ed9e26b73ecd7f9e773478cb1e
Author: Michel Dänzer <michel.daenzer@amd.com>
Date:   Wed Nov 8 18:44:25 2017 +0100

    Use correct ScrnInfoPtr in redisplay_dirty

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.