A suspend regression seems to have slipped in between kernel ~126.96.36.199 and ~188.8.131.52, approximated from the Debian distribution versions linux-image-2.6.32-3-amd64 and linux-image-2.6.32-5-amd64. The regression is still present with the latest 2.6.35 kernels. It causes the system to not properly wake up again after a suspension to RAM. The screen remains black, and Ctrl+Alt+Del doesn't work anymore either.
According to the debugging instructions in basic-pm-debugging.txt, the isolation tests were performed with s2ram -f on a 2.6.35 recovery system with only init, bash and udev running. Configuring /sys/power/pm_test to "freezer" works, whereas configuring it to "devices" already causes the problem.
# s2ram --identify
This machine can be identified by:
sys_vendor = "System manufacturer"
sys_product = "System Product Name"
sys_version = "System Version"
bios_version = "1006 "
See http://suspend.sf.net/s2ram-support.html for details
The bug happens even with the following reduced module list. The Radeon modules cannot be removed even in console mode, the others seem to be fairly standard low-level modules.
Module Size Used by
fuse 57937 1
radeon 692822 1
ttm 56623 1 radeon
drm_kms_helper 26939 1 radeon
drm 180695 3 radeon,ttm,drm_kms_helper
i2c_algo_bit 4914 1 radeon
i2c_core 22507 4 radeon,drm_kms_helper,drm,i2c_algo_bit
ext3 112373 3
jbd 44134 1 ext3
mbcache 7044 1 ext3
sd_mod 32903 5
crc_t10dif 1515 1 sd_mod
ata_generic 3411 0
ahci 20381 0
libahci 20639 5 ahci
libata 168236 3 ata_generic,ahci,libahci
scsi_mod 183302 2 sd_mod,libata
The original bug report contains reference information regarding the hardware specs and previous discussion.
The bug seems to vanish when the Debian package firmware-linux-nonfree is installed. This seems to be a Debian packaging issue so I will give more details in the distribution-specific bug report.