[Bug 107519] New: [Regression][Bisected] Screen gets turned off until I switch to TTY, then back

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=107519

            Bug ID: 107519
           Summary: [Regression][Bisected] Screen gets turned off until I
                    switch to TTY, then back
           Product: xorg
           Version: git
          Hardware: x86-64 (AMD64)
                OS: Linux (All)
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Driver/Radeon
          Assignee: xorg-driver-ati at lists.x.org
          Reporter: Hi-Angel at yandex.ru
        QA Contact: xorg-team at lists.x.org

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 at 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 at 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]

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-driver-ati/attachments/20180807/220ed1f9/attachment.html>