Created attachment 38422 [details] dmesg | grep drm after the black screen If I - try to suspend my laptop, or - try to log off some user, or - try to switch to a virtual console, the screen becomes black and nothing is able to turn it on again. The system however remains alive (I'm able to connect via network). This seems like a regression, since if I use the kernel 2.6.32-3-amd64 in Debian, I'm able to suspend, while if I use 2.6.32-5-amd64 or 2.6.35-trunk I get this problem. Some more information can be found at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=587722 , but the majority of it should be not particularly useful. lspci -v says: 01:05.0 VGA compatible controller: ATI Technologies Inc RS780M/RS780MN [Radeon HD 3200 Graphics] (prog-if 00 [VGA controller]) Subsystem: Hewlett-Packard Company Device 30f1 Flags: bus master, fast devsel, latency 0, IRQ 18 Memory at c0000000 (32-bit, prefetchable) [size=256M] I/O ports at 5000 [size=256] Memory at d2400000 (32-bit, non-prefetchable) [size=64K] Memory at d2300000 (32-bit, non-prefetchable) [size=1M] Expansion ROM at <unassigned> [disabled] Capabilities: <access denied> Kernel driver in use: radeon (but notice, in case that changes anything, that this comes out while running 2.6.32-5) and the `dmesg | drm` and the Xorg.0.log (both obtained instead running 2.6.35-trunk) are attached. I guess the latter is more interesting, so it is attached in two forms: - one taken after starting the system, waiting for the gdm prompt and then switching to a virtual console - one taken after starting the system, logging an user and then logging out. Notice that the last lines (of both) are printed several seconds after the operation that causes the black screen. Instead, in the "logout" log, the lines (II) Power Button: Close and following are printed at the moment of the logout.
Created attachment 38423 [details] Xorg.0.log (several seconds) after switching to a virtual console
Created attachment 38424 [details] Xorg.0.log (several seconds) after logging out
Something goes wrong on your system, such that the radeon kernel module enables KMS but the X radeon driver thinks it's not enabled, resulting in both drivers accessing the hardware independently. This can't work properly. While this is probably some kind of system setup/configuration issue, the X driver should probably bail in this situation...
As mentioned in the original Debian bug, if I add "modprobe" in /etc/modules everything works smoothly. Either there is some misconfiguration, or udev fails to load the module in time.
(In reply to comment #4) > As mentioned in the original Debian bug, if I add "modprobe" in /etc/modules Ehm... "radeon".
Configuration issue with debian or your system.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.