https://bugzilla.kernel.org/show_bug.cgi?id=83331

Alex Deucher alexdeucher@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- CC| |alexdeucher@gmail.com

--- Comment #1 from Alex Deucher alexdeucher@gmail.com --- Please attach your xorg log and dmesg output after the panel has gone out of sync.

https://bugzilla.kernel.org/show_bug.cgi?id=83331

--- Comment #3 from Klaus Kusche klaus.kusche@computerix.info --- Created attachment 148511 --> https://bugzilla.kernel.org/attachment.cgi?id=148511&action=edit X log

https://bugzilla.kernel.org/show_bug.cgi?id=83331

--- Comment #5 from Klaus Kusche klaus.kusche@computerix.info --- Any news on this one?

Some more info's:

1.) Still there on 3.16.2.

2.) My workaround (disabling and re-enabling the internal output) takes ages:

~: time xrandr --output eDP --off ; time xrandr --output eDP --auto

real 0m0.516s user 0m0.003s sys 0m0.004s

real 0m7.832s user 0m0.000s sys 0m0.003s

Times are very reproducible, almost constant (+/- 5 ms only).

During these commands, the system is more or less blocked, in spite of the CPU being idle. Also, the first timing is not displayed after half a second on the external monitor as one would expect from its real time, but after 6 seconds, one second before the second timing.

What are these commands doing that long?

3.) A similar problem seems to affect switching from VGA to FB console during kernel bootup: * It takes ages (I counted more than 5 seconds on a really fast machine). * It sometimes shows the same strange white moving stripes during the switch.

https://bugzilla.kernel.org/show_bug.cgi?id=83331

--- Comment #7 from Klaus Kusche klaus.kusche@computerix.info --- 1.) The behaviour is absolutely reproducible: I *always* get almost exactly the same delays (both during boot and during internal display output off / on), I *always* get exactly the same messages, and I *always* get a non-functional internal display with strange patterns after dpms standby/suspend/off (external displays are fine).

The only random thing is that during boot the internal display sometimes is cleanly black for 5 seconds on the VGA->fbcon switch, and sometimes shows some white flashes at the beginning of this 5 second period.

2.) Internal display output off / on does not produce any kernel messages, the delay happens silently.

3.) I'll attach a kernel boot log with printk timings: Radeon, drm and fbcon init start at 2.35 and end at 7.77 (which is 60 % of the whole kernel boot time) * There is a 0.5 sec delay before the ring tests. * ... and a 1.5 sec delay before "fb mappable" * ... and a 3.0 sec delay before switching to fbcon

https://bugzilla.kernel.org/show_bug.cgi?id=83331

--- Comment #9 from Klaus Kusche klaus.kusche@computerix.info --- Anything else I can try? Any debug outputs I could add?

I think we are hunting two different problems:

1.) Why does the internal display crash after a dpms standby/suspend/off? This is extremely annoying, because it happens all the time while giving my presentations in the lecture halls, and with all the students in front of me, blindly fixing things is irritating.

Without knowing the code, I'd assume that this should be easy to find: What's the difference in code paths between "dpms on" and "xrandr off+auto"? "xrandr off+auto" obviously does something more than "dpms on"? Couldn't this be simply added to "dpms on", too? Note that just "xrandr auto" alone does not fix the crashed display, a "xrandr off" is needed first.

2.) Why do the switch from VGA to framebuffer during boot and an "xrandr off+auto" both take ages (> 5 sec)?