Bug 83331

Summary: radeon: Laptop panel out of sync after dpms standby/suspend/off
Product: Drivers Reporter: Klaus Kusche (klaus.kusche)
Component: Video(DRI - non Intel)Assignee: drivers_video-dri
Status: NEW ---    
Severity: normal CC: alexdeucher, szg00000
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 3.15.10 Subsystem:
Regression: No Bisected commit-id:
Attachments: Kernel and system log
X log
Kernel boot log with printk timings

Description Klaus Kusche 2014-08-27 12:11:57 UTC
I've a problem on my laptop
(Dell Precision M6700 with AMD Cap Verde graphics, ChipID = 0x6825)
with the radeon driver (radeon-ucode-20140430):

Whenever the X server switches to dpms standby, suspend or off state
(it does so after 5 minutes when I'm on battery and idle)
and then back to dpms on, the internal panel is out of sync:
It is completely unreadable, flashes or shows strange moving patterns.
External displays are fine.
The problem is independent of the radeon powersave mode
(profile or dpm).

The only way to recover is either to power cycle
or to blindly type
xrandr --output eDP --off
xrandr --output eDP --auto

Switching from X to a text (framebuffer) VT does not help:
They are also corrupted.

When initializing radeon during boot, the kernel log says
radeon 0000:01:00.0: Invalid ROM contents
Could that be related?
Everything else looks fine.
When the problem happens, nothing is written to the kernel log.
Comment 1 Alex Deucher 2014-08-27 13:30:19 UTC
Please attach your xorg log and dmesg output after the panel has gone out of sync.
Comment 2 Klaus Kusche 2014-08-27 14:00:23 UTC
Created attachment 148501 [details]
Kernel and system log
Comment 3 Klaus Kusche 2014-08-27 14:00:44 UTC
Created attachment 148511 [details]
X log
Comment 4 Klaus Kusche 2014-08-27 14:03:33 UTC
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)
Comment 5 Klaus Kusche 2014-09-14 09:43:22 UTC
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.
Comment 6 Alex Deucher 2014-09-16 23:54:59 UTC
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.
Comment 7 Klaus Kusche 2014-09-17 05:56:50 UTC
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
Comment 8 Klaus Kusche 2014-09-17 05:59:24 UTC
Created attachment 150591 [details]
Kernel boot log with printk timings

Interesting part goes from 2.35 to 7.77
Comment 9 Klaus Kusche 2014-10-04 12:05:33 UTC
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)?