*** Please type your report below this line ***
After upgrading my Debian Squeeze system (using aptitude)
this week, my system lost the ability to resume after a
suspend-to-RAM.

Previous behavior: system powers back up, screen powers on
(black background), video BIOS text is displayed, a second or
two passes, X desktop reappears.

New behavior: system powers back up, screen powers on (black
but with an odd rolling flicker in mid-screen for a moment), no
BIOS text or anything else is displayed, screen remains black,
X desktop never reappears, and the system is stuck.  Attempting
to switch virtual terminals has no effect - screen remains black.
Only remedy is to power off and on again.

The problem affects both KDE and Gnome desktop environments.
It can be reproduced by using the laptop's BIOS suspend
hotkey (function-F1) or by closing the lid (if the desktop
power management package is configured to suspend-to-RAM
when this happens).

Please try a newer kernel (or squeeze's kernel).

Cheers,
Julien

Hi, Julien - thanks for responding so quickly!

As it happens, I was in the process of building a fresh 2.6.34 kernel
when your message arrived.  I just tried it, and the symptoms are
unchanged - screen video never comes back after the wakeup.

I'm going to attach a log from an X session which shows the
post-wakeup steps.  I didn't see anything directly useful
here - no error messages during the restore process - but it
does show that the driver seems to be going through the
restore process.

I checked my kernel/daemon logs, and they do show the
expected activity after a wakeup - specifically, that
wpa_supplicant is bringing the wireless interface back
alive, successfully registering with my access point, and
bringing up the IP interface.  This shows that the problem
isn't a total freeze of the system - normal functions are
being restored, except for screen-video output.

Log of X session, with failed restore after suspend-to-RAM,
is attached.

I've learned of an effective workaround for the problem via
another open bug (#565344), and this workaround probably points
to the source of the problem.

The workaround:  go into /etc/modprobe.d/, find the file
which has the options for the "radeon" module, and change
"modeset=1" to "modeset=0".  Reboot.  Problem fixed.

It appears that on some Radeon chipsets, having the kernel
mode-setting enabled will cause this black-screen problem after
wakeup from a suspend or hibernation.  Explicitly disabling
KMS via this option, resolves the problem.

The problem doesn't seem to be unique to particular versions
of the kernel, or even to specific versions of the Radeon driver
and module.  I've tried both custom-built kernels, and the standard
Squeeze kernel... no difference.  In one of the other bug reports
on this problem, a poster even tried switching back and forth between
Debian and Ubuntu driver installs, and the problem did not follow the
installs in any predictable way... once the problem appeared,
reverting back to a kernel and driver pair which had previously worked,
still exhibited the problem.  However, when he did a fresh install
of this software on a different system (same chipset) it worked!

The difference, apparently, is the contents of the module configuration
file... if it says "modeset=1", resume is broken, and if you say
"modeset=0", everything works.

It seems likely that the problem first occurred on my machine, when
I did a regular Debian "testing" upgrade, which picked up a deb package
of the Radeon driver that added "modeset=1" to the driver options.

When I looked back through the logs I uploaded back in July, I
noticed something curious... the driver reported that KMS was being
disabled due to some sort of incompatibility.  It appears, though,
that having "modeset=1" in the driver options was enough to cause the
problem to occur, even though kernel modesetting had been disabled
by the driver.

In any case:

(1) I have a workaround and am happy once again!

(2) It looks as if there may be some loopholes in how kernel modesetting
     is done for at least some of the Radeon chips, which causes the
     black-screen problem upon wakeup if kernel modesetting is not
     explicitly disabled.  This problem may affect the Mobility X700
     and has also been reported on the 4200... others may also be
     affected.

Hi Dave,

Dave Platt <dplatt@radagast.org> (14/02/2011):

OK. Now, what happens if you upgrade your kernel to 2.6.37-1-$arch in
sid, and enable KMS again? It would be even nicer to know how it goes
with an up-to-date X stack, meaning xserver-xorg-video-{ati,radeon}
and xserver-xorg-core from sid.

KiBi.

At a point when I'm feeling brave and have some hours to spare, I'll
try pulling in those packages from sid (plus whatever others are
needed to get them to install), re-enable KMS, and (as Lennier said
about high-speed pre-programmed evasive maneuvers) "Push this button,
and then pray very very fast" :-)

I'll letcha know if/when I manage to get these packages installed
and tested.

With the move of the Linux X stack towards a KMS-only architecture,
getting this fixed properly would certainly make sense.

tag 586485 moreinfo
thanks

Dave Platt <dplatt@radagast.org> (21/02/2011):

Thanks, I'm tagging this bug report accordingly then.

KiBi.

I upgraded my kernel and xserver-xorg-* debs to the versions
in unstable, as you suggested.

With KMS disabled, suspend and resume continue to work OK.

With KMS re-enabled, I still see the black screen after
resuming.  There is no change in behavior from the previous
versions (from the testing distribution).  Switching virtual
terminals works fine (very quickly) prior to the suspend, but
after the resume the screen remains black after switching
VTs (I was able to log in as root and capture the log file,
but only "blindly").

I'll see if I can upload the kernel and Xorg logs from a
session during which I suspended, resumed, and saw the
black screen.  The logs indicate that KMS is enabled, and
is apparently used during the initial setup of the screen
and during VT-switch.

Kernel log attached...

X server log attached...

Hi,

	Can I add some observations to this bug report.

I have what appears to be the same problem.  I've had a some difficulty
getting radeon to work with much of the problem caused by a conflict between
vesafb and radeondrmfb.   It seems grub likes to use vesafb if it gets half a
chance.  Not using GRUB_GFXPAYLOAD_LINUX is helpful.

However it all now pretty much works except if I suspend (pm-suspend).  When
resuming from suspend, the display is not restored.  It stays black and
nothing I've tried can coax it into action.  Apart from the display the system
is working normally.

If I hibernate (pm-hibernate) the display resumes properly. So having resumed
from suspend and got the black screen if I then hibernate and resume it all
recovers back to where it should be.

To me this points to some sort of initialisation issue when resuming from
suspend. My guess it's being re-initialised by the reboot after hibernating
but that doesn't happen when resuming from suspend.

I hope that's interesting.

Dick

Video: 01:05.0 VGA compatible controller: ATI Technologies Inc RS780M/RS780MN
[Radeon HD 3200 Graphics]

Package: xserver-xorg-video-radeon
Version: 1:6.14.0-1
Linux: 2.6.38-2-686

I'm sorry to report that this hoary old bug is still around, and
its impact has just become more acute.

I'm running Debian "testing" on my laptop, and the X server (or
the Radeon module for it) now seems to require that KMS be enabled
in the kernel's radeon module.  After I updated to the latest set
of changes from the testing distribution, X would no longer start
up until I re-enabled modesetting in my /etc/modprobe.d/radeon-kms.conf
file.

I can now get into X just fine, but if I do a suspend-to-RAM, I'm
in trouble.  Upon resuming, the screen is black, and stays black
until I force a reboot.

The older workaround of using user-level modesetting rather than KMS
no longer works.

I'm attaching the kernel logs, and Xorg.log from my most recent
attempt.  The kernel log shows the suspend/resume.