[Bug 83331] New: radeon: Laptop panel out of sync after dpms standby/suspend/off

[Bug 83331] New: radeon: Laptop panel out of sync after dpms standby/suspend/off

[bugzilla-daemon]

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

            Bug ID: 83331
           Summary: radeon: Laptop panel out of sync after dpms
                    standby/suspend/off
           Product: Drivers
           Version: 2.5
    Kernel Version: 3.15.10
          Hardware: All
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: Video(DRI - non Intel)
          Assignee: drivers_video-dri@kernel-bugs.osdl.org
          Reporter: klaus.kusche@computerix.info
        Regression: No

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

[bugzilla-daemon]

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

[bugzilla-daemon]

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

--- Comment #2 from Klaus Kusche <klaus.kusche@computerix.info> ---
Created attachment 148501
  --> https://bugzilla.kernel.org/attachment.cgi?id=148501&action=edit
Kernel and system log

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

[bugzilla-daemon]

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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

[bugzilla-daemon]

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

--- Comment #4 from Klaus Kusche <klaus.kusche@computerix.info> ---
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)

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

[bugzilla-daemon]

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

[bugzilla-daemon]

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

--- Comment #6 from Alex Deucher <alexdeucher@gmail.com> ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

[bugzilla-daemon]

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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

[bugzilla-daemon]

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

--- Comment #8 from Klaus Kusche <klaus.kusche@computerix.info> ---
Created attachment 150591
  --> https://bugzilla.kernel.org/attachment.cgi?id=150591&action=edit
Kernel boot log with printk timings

Interesting part goes from 2.35 to 7.77

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

[Bug 83331] radeon: Laptop panel out of sync after dpms standby/suspend/off

[bugzilla-daemon]

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

-- 
You are receiving this mail because:
You are watching the assignee of the bug.