| Summary: | Reverse Prime with intel/amdgpu causes segfault in glamor_block_handler when enabling monitor | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | xorg | Reporter: | EoD <EoD> | ||||||
| Component: | Driver/AMDgpu | Assignee: | xf86-video-ati maintainers <xorg-driver-ati> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Xorg Project Team <xorg-team> | ||||||
| Severity: | normal | ||||||||
| Priority: | medium | ||||||||
| Version: | git | ||||||||
| Hardware: | Other | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| i915 platform: | i915 features: | ||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 103618 | ||||||||
| Attachments: |
|
||||||||
|
Description
EoD
2017-11-07 19:05:30 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. 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 Created attachment 135291 [details]
GDBs Backtrace with -O0
Created attachment 135295 [details] [review] Use the correct ScrnInfoPtr in redisplay_dirty Does this xf86-video-amdgpu patch fix it? (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. (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. (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". (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. 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.