Bug 83331

Please attach your xorg log and dmesg output after the panel has gone out of sync.

Created attachment 148501 [details]
Kernel and system log

Created attachment 148511 [details]
X log

Logs after
xset dpms force standby       (screen goes black)
touching the mouse            (screen starts flickering)
xrandr --output eDP --off     (screen goes black)
xrandr --output eDP --auto    (screen becomes readable after a few seconds delay)

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.

Is your kernel log any different when you experience the long delays?  There is a 5 second time out for certain display related atombios settings, but when that happens you'll get a message in the kernel about that.  If you don't see anything in the kernel logs, you'll probably have to add some debugging messages to see where the delay is happening.

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

Created attachment 150591 [details]
Kernel boot log with printk timings

Interesting part goes from 2.35 to 7.77

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)?