Bug 107519

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]