Bug#586485: Regression: can't resume after suspend-to-RAM
Thanks, I'm tagging this bug report accordingly then. 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. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d64aea2.7000...@radagast.org
Bug#586485: Regression: can't resume after suspend-to-RAM
X server log attached... [25.733] X.Org X Server 1.9.4 Release Date: 2011-02-04 [25.733] X Protocol Version 11, Revision 0 [25.733] Build Operating System: Linux 2.6.32.29-dsa-ia32 i686 Debian [25.733] Current Operating System: Linux chembook 2.6.37-1-686 #1 SMP Tue Feb 15 18:21:50 UTC 2011 i686 [25.733] Kernel command line: BOOT_IMAGE=/vmlinuz-2.6.37-1-686 root=UUID=64aef0b8-c7fb-4d9a-a42f-4a3f18541e73 ro quiet [25.734] Build Date: 20 February 2011 05:47:22AM [25.734] xorg-server 2:1.9.4-3 (Cyril Brulebois k...@debian.org) [25.734] Current version of pixman: 0.16.4 [25.734]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [25.734] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [25.734] (==) Log file: /var/log/Xorg.0.log, Time: Tue Feb 22 22:31:08 2011 [25.785] (==) Using config file: /etc/X11/xorg.conf [25.785] (==) Using system config directory /usr/share/X11/xorg.conf.d [25.863] (==) ServerLayout Default Layout [25.863] (**) |--Screen aticonfig Screen 0 (0) [25.864] (**) | |--Monitor aticonfig Monitor 0 [25.871] (**) | |--Device ATI Graphics Adapter 0 [25.871] (**) |--Input Device Generic Keyboard [25.871] (**) |--Input Device Synaptics Touchpad [25.871] (==) Automatically adding devices [25.871] (==) Automatically enabling devices [25.969] (WW) The directory /usr/lib/X11/fonts/misc does not exist. [25.969]Entry deleted from font path. [25.969] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [25.969]Entry deleted from font path. [25.969] (WW) The directory /usr/lib/X11/fonts/cyrillic does not exist. [25.969]Entry deleted from font path. [25.969] (WW) The directory /usr/lib/X11/fonts/100dpi/ does not exist. [25.969]Entry deleted from font path. [25.969] (WW) The directory /usr/lib/X11/fonts/75dpi/ does not exist. [25.969]Entry deleted from font path. [26.031] (WW) The directory /usr/lib/X11/fonts/Type1 does not exist. [26.031]Entry deleted from font path. [26.031] (WW) The directory /usr/share/fonts/X11/CID does not exist. [26.031]Entry deleted from font path. [26.031] (WW) The directory /usr/lib/X11/fonts/CID does not exist. [26.031]Entry deleted from font path. [26.053] (WW) The directory /usr/lib/X11/fonts/100dpi does not exist. [26.053]Entry deleted from font path. [26.076] (WW) The directory /usr/lib/X11/fonts/75dpi does not exist. [26.076]Entry deleted from font path. [26.076] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [26.076]Entry deleted from font path. [26.111] (**) FontPath set to: unix/:7100, /usr/share/fonts/X11/misc, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins [26.111] (==) ModulePath set to /usr/lib/xorg/modules [26.111] (**) Extension Composite is enabled [26.111] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [26.111] (WW) AllowEmptyInput is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [26.111] (WW) Disabling Generic Keyboard [26.111] (II) Loader magic: 0x81f7140 [26.111] (II) Module ABI versions: [26.111]X.Org ANSI C Emulation: 0.4 [26.111]X.Org Video Driver: 8.0 [26.111]X.Org XInput driver : 11.0 [26.111]X.Org Server Extension : 4.0 [26.113] (--) PCI:*(0:1:0:0) 1002:5652:1043:1962 rev 0, Mem @ 0xd000/134217728, 0xfe9f/65536, I/O @ 0xc000/256, BIOS @ 0x/131072 [26.113] (II) Open ACPI successful (/var/run/acpid.socket) [26.113] (II) extmod will be loaded. This was enabled by default and also specified in the config file. [26.113] (II) dbe will be loaded. This was enabled by default and also specified in the config file. [26.114] (II) glx will be loaded. This was enabled by default and also specified in the config file. [26.114] (II) record will be loaded. This was enabled by default and also specified in the config file. [26.114] (II) dri will be loaded. This was enabled by default and also specified in the config file. [26.114] (II) dri2 will be loaded by default. [26.114] (II) LoadModule: dbe [26.183] (II) Loading /usr/lib/xorg/modules/extensions/libdbe.so [
Bug#586485: Regression: can't resume after suspend-to-RAM
On 02/21/2011 10:36 AM, Cyril Brulebois wrote:
Hi Dave,
Dave Platt dpl...@radagast.org (14/02/2011):
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.
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.
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.
--
To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d62bc40.5080...@radagast.org
Bug#586485: Regression: can't resume after suspend-to-RAM
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. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d598a1d.90...@radagast.org
Bug#586485: Regression: can't resume after suspend-to-RAM
Please try a newer kernel (or squeeze's kernel). 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. -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4c1e5eb3.4050...@radagast.org
