[Bug 93746] Black screen when reconnecting display

[bugzilla-daemon at freedesktop.org]

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

Mario Kleiner <mario.kleiner at tuebingen.mpg.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mario.kleiner at tuebingen.mpg
                   |                            |.de

--- Comment #14 from Mario Kleiner <mario.kleiner at tuebingen.mpg.de> ---
Documenting some progress made "outside" the bug reporter.

So attached a proposed patch. And a trimmed and annotated syslog output from
some debugging with Bernd's help:


> On 15/02/16 19:34, Mario Kleiner wrote:
>> Bernd, can you apply the attached patch on top of the others and test
>> with
>> drm.debug=35 again, and ideally provide syslog output with the
>> microsecond
>> timestamps included? This adds some debug statements to see if
>> something goes
>> wrong in radeon_flip_work_func on radeon-kms.
> Sure, I tried that, but I ran into this problem:
> Feb 16 21:21:17.870174 orionis systemd-journald[618]: Missed 3 kernel
> messages
>
> The log is spammed with these messages. So I did some research and was
> pointed to the kernel parameter log_buf_leng, which I set to 16M
> (actually tried values up to 128M), but that didn't help.
>
> I'll attach the log anyway, but if you tell me how to get rid of that
> issue, I can of course give it another go.
> For journald, I set RateLimitBurst=0, which should prevent it from not
> accepting messages due to the log spam.
>
> I also did another experiment. The Dell U2415 is normally connected to
> HDMI-0.
> I connected that to DP-0 (with the Eizo disconnected) and found out,
> that now the Dell shows the same behavior as the Eizo. When disconnected
> and reconnected, the screen will be black.
> If I turn on the DP1.2 setting for the Dell, it will do so even when
> switched off, most likely because the connection is cut with DP1.2
> turned on (really really annoying behavior, that's also the reason why I
> have so many problems with the Eizo, but for that DP1.2 cannot be
> switched off).
>
> Thus, it doesn't seem like the problem is related to specific display
> hardware.
> If you'd like, I can test the HP ZR24W as well (normally connected to DVI).
>
> Best Regards,
> Bernd

Thanks, that one was useful. Can you revert the debug patch i sent you last and
instead apply the attached patch and retest? Maybe also remove the patch
"[PATCH 1/2] drm/radeon: Make vbl counter/ts queries robust against dpms
on/off. [RFC]", so your tree corresponds more closely to what is in 4.4/4.5rc.

This one is a proposed fix for the problem, also for stable 4.4.

Seems to be that when the connection gets cut while a pageflip gets queued by
the userspace driver, the radeon-kms driver does DPMS OFF as part of its
hotplug work function -- apparently only for DP displays, if i understand the
code correctly? Then when radeon_flip_work_func() executes the "wait until real
start of vblank" code introduced in Linux 4.4 to fix other regressions, that
code executes while the display engine is already disabled and the scanout is
no longer moving. That leads the wait code to go into an infinite loop - hence
the huge amount of messages in your syslog - flip_work_func hangs -> pageflip
hangs -> game over.

So the attached patch should make that new wait code robust against such
unexpected things as dpms off/on in parallel. Maybe we could manage to also get
this into 4.5-rc5, now that the other vblank fixes have landed in Linus tree.

I don't know if it is expected behavior that pageflips can be queued by
userspace while the display is disabled, or if the ddx shouldn't already
prevent that? The log suggests that the ddx got the hot(un)plug event before it
tried to page flip anyway in TearFree.

-- 
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/20160217/af418c2e/attachment.html>