<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body><a class="email" href="mailto:mario.kleiner@tuebingen.mpg.de" title="Mario Kleiner <mario.kleiner@tuebingen.mpg.de>"> Mario Kleiner</a> changed <a class="bz_bug_link bz_status_NEW " title="NEW - Black screen when reconnecting display" href="https://bugs.freedesktop.org/show_bug.cgi?id=93746">bug 93746</a> <table border="1" cellspacing="0" cellpadding="8"> <tr> <th>What</th> <th>Removed</th> <th>Added</th> </tr> <tr> <td style="text-align:right;">CC</td> <td> </td> <td>mario.kleiner@tuebingen.mpg.de </td> </tr></table> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Black screen when reconnecting display" href="https://bugs.freedesktop.org/show_bug.cgi?id=93746#c14">Comment # 14</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Black screen when reconnecting display" href="https://bugs.freedesktop.org/show_bug.cgi?id=93746">bug 93746</a> from <a class="email" href="mailto:mario.kleiner@tuebingen.mpg.de" title="Mario Kleiner <mario.kleiner@tuebingen.mpg.de>"> Mario Kleiner</a> <pre>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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>