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