On Wed, 2006-09-27 at 00:26 +0200, Rafael J. Wysocki wrote: > On Wednesday, 27 September 2006 00:15, Pavel Machek wrote: > > Hi! > > > > > > > Please boot the kernel with "2" appended to the command line, so the system > > > > > goes to the 2nd runlevel (ie. without network servers and X). Then log in > > > > > as root, do "echo 8 > /proc/sys/kernel/printk" and > > > > > "echo disk > /sys/power/state". The system should suspend to disk and power > > > > > off the machine. If it doesn't do that (ie. if it returns to the shell > > > > > immediately), please do "dmesg > dmesg.log" and send the dmesg.log file > > > > > to me. > > > > > > > > The system didn't power off, it returned to the shell. I attached dmesg. > > > > > > Thanks. > > > > > > Pavel, it looks like we have a problem with the CPU suspend on this box: > > > > > > acpi acpi: freeze > > > PM: snapshotting memory. > > > Class driver suspend failed for cpu0 > > > Could not power down device &q->lock: error -22 > > > Some devices failed to power down, aborting suspend > > > acpi acpi: resuming > > > > That looks like cpufreq/acpi, no? > > > > Can we get bugzilla.kernel.org report? > > Ah, it may be the same bug as http://bugzilla.kernel.org/show_bug.cgi?id=7188 > > > Can you try without acpi processor and cpufreq? > > First, please try to remove the acpi_cpufreq module before the suspend. > > Greetings, > Rafael Yep sure is. I removed the acpi_cpufreq module and my box suspended and resumed nicely, from gnome even. This has not been working since 2.6.17. Something in cpufreq in the 2.6.18pre series broke. -Louis
