Latest working kernel version:
Earliest failing kernel version:
Distribution: Debian testing
Hardware Environment: Asus A6Jc Laptop
When the system is put to suspend to ram mode, the message "suspending consoles" appears, then, the hard drive spins down. Instead of switching the pc to suspend however, the disk spins up, immediately afterwards spins down again and then the system enters suspend mode.
Everything else works as expected.
smartctl -A /dev/hda | grep Start_Stop_Count
confirms this behaviour by showing an increase of the raw value by two after one suspend-resume cycle.
I am running kernel 2.6.26-1-686 from debian testing archives currently, I experienced the same behaviour with 2.6.28-1-686 from debian kernel trunk archives.
Steps to reproduce:
Put system to suspend to ram with either s2ram or "echo mem > /sys/power/state". Watch raw value of smartctls Start_Stop_Count to verify that two start-stop-cycles occur (can also be noted acoustically on my system).
Can you please try libata drivers?
Also, please post the kernel boot log and the output of dmesg after suspend/resume.
Created attachment 20169 [details]
output of dmesg after boot
Created attachment 20170 [details]
additional dmesg output after suspend-resume cycle
the attachments above contain the kernels boot messages and the dmesg output after one suspend-resume-cycle.
Unfortunately I did not manage to successfully boot the machine using libata. I tried to recompile the kernel without IDE support but with libata for intel piix enabled, resulting in a kernel panic during boot stating that no device containing the root was found (or similar). This also appears after adjusting the root=XXX option on the kernel command line.
Do you have a howto for enabling libata on a Debian lenny system?
Please post the output "lspci -nn" too. To use libata without initrd, you need to build in libata, ata_piix, SCSI and SCSI disk support.
Created attachment 20181 [details]
lspci -nn output
I did enable libata, ata_piix, SCSI support and SCSI cdrom as well as disk support. However, the kernel did not boot successfully. I compiled the kernel from clean sources several times and checked the above options carefully, unfortunately without success.
Any chance you can grab the failing boot log? Serial console or netconsole should do.
Unfortunetly I never used serial- or netconsole before and did not find out how to set it up. Is there any quick howto available?
Yeap, in the kernel source tree,
Will you please try to use ata driver on the latest upstream kernel and see whether the issue still exists?
Will you please also attach the output of acpidump, lspci -vxxx?
Heiner, please verify if this is a duplicate of bug #8855.
i.e. please try a kernel later than 2.6.29-rc3 and see if the problem still exist.
please re-open it if the problem still exists in 2.6.32