As description says. There are at least 2 ways of triggering that: α. logging in from SDDM. It's not reproducible with GDM though. β. in a working system: 1. disable compositioning (specifically, I'm killing Compton) 2. call "spectacle" (KDE screenshot tool) 3. in spectacle use option "make rectangle selection" 4. after selecting a rectangle simply press escape to cancel screenshot, which will result in black screen. Upon reproducing, journalctl shows the following: > 23:24:56 constantine-N61Ja kernel: [drm] PCIE GART of 1024M enabled (table at 0x0000000000162000). > 23:24:56 constantine-N61Ja kernel: radeon 0000:02:00.0: WB enabled > 23:24:56 constantine-N61Ja kernel: radeon 0000:02:00.0: fence driver on ring 0 use gpu addr 0x0000000040000c00 and cpu addr 0x0000000032dda33a > 23:24:56 constantine-N61Ja kernel: radeon 0000:02:00.0: fence driver on ring 3 use gpu addr 0x0000000040000c0c and cpu addr 0x000000000b29f15d > 23:24:56 constantine-N61Ja kernel: radeon 0000:02:00.0: fence driver on ring 5 use gpu addr 0x0000000000072118 and cpu addr 0x000000002c2ae677 > 23:24:56 constantine-N61Ja kernel: [drm] ring test on 0 succeeded in 1 usecs > 23:24:56 constantine-N61Ja kernel: [drm] ring test on 3 succeeded in 6 usecs > 23:24:56 constantine-N61Ja kernel: [drm] ring test on 5 succeeded in 2 usecs > 23:24:56 constantine-N61Ja kernel: [drm] UVD initialized successfully. > 23:24:56 constantine-N61Ja kernel: [drm] ib test on ring 0 succeeded in 0 usecs > 23:24:56 constantine-N61Ja kernel: [drm] ib test on ring 3 succeeded in 0 usecs > 23:24:56 constantine-N61Ja kernel: [drm] ib test on ring 5 succeeded > 23:24:57 constantine-N61Ja acpid[857]: client 31033[0:0] has disconnected > 23:24:57 constantine-N61Ja acpid[857]: client connected from 31033[0:0] > 23:24:57 constantine-N61Ja acpid[857]: 1 client rule loaded # Bisected commit: commit 740f0850f1e40403c8dd727e074eae36caeb1f63 Author: Michel Dänzer <michel.daenzer@amd.com> Date: Thu Aug 2 18:49:48 2018 +0200 Store FB for each CRTC in drmmode_flipdata_rec We were only storing the FB provided by the client, but on CRTCs with TearFree enabled, we use a separate FB. This could cause drmmode_flip_handler to fail to clear drmmode_crtc->flip_pending, which could result in a hang when waiting for the pending flip to complete. We were trying to avoid that by always clearing drmmode_crtc->flip_pending when TearFree is enabled, but that wasn't reliable, because drmmode_crtc->tear_free can already be FALSE at this point when disabling TearFree. Now that we're keeping track of each CRTC's flip FB separately, drmmode_flip_handler can reliably clear flip_pending, and we no longer need the TearFree hack. (Ported from amdgpu commit 9b6782c821e0bdc53336d98f87ddde752faf7902) Reviewed-by: Alex Deucher <alexander.deucher@amd.com> # Additional info It's seen on laptop, its GPUs: 1. BeaverCreek [Radeon HD 6620G] [1002:9641] 2. Whistler [Radeon HD 6630M/6650M/6750M/7670M/7690M] [1002:6741]
Removing myself from Cc, I receive updates via the mailing lists.
Created attachment 141138 [details] [review] Use correct FB handle in radeon_do_pageflip Does this patch fix it?
(In reply to Michel Dänzer from comment #2) > Created attachment 141138 [details] [review] [review] > Use correct FB handle in radeon_do_pageflip > > Does this patch fix it? Yep, it did.
Thanks for the report and for testing the fix, which has now landed in Git master: commit 824189b3da9edc33e1a4f5c6130a043da73c1a4c Author: Michel Dänzer <michel.daenzer@amd.com> Date: Thu Aug 16 18:22:27 2018 +0200 Use correct FB handle in radeon_do_pageflip
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.