Kernel Bug Tracker – Bug 7188
acpi_cpufreq causes 'swsusp' to fail
Last modified: 2007-04-28 12:49:15 UTC
Most recent kernel where this bug did not occur:
Unknown ('swsusp' has not worked for me until now)
Acer Aspire 2010 laptop, Pentium M 1.5Ghz
When 'acpi_cpufreq' is loaded, issuing 'echo disk>/sys/power/state' results in
the following console message (among normal usb-related messages):
"Could not power down device `
It seems that cpufreq has some problems with driver model... Name of device is
set incorrectly, at least. Strange thing is that it seems to work here..? I'd
like to cc gregkh, but firstname.lastname@example.org is unknown by bugzilla :-(.
Am also experiencing this problem on FC6 with kernel-2.6.18
Pavel, <email@example.com> works just fine here :)
Created attachment 9110 [details]
2.6.18 kernel .config
Created attachment 9112 [details]
2.6.18 config file (after problem fix)
Current (non-problem) config; the old one had CONFIG_CPU_FREQ set.
The Clevo D610SU (known under many brands, here in CR it is Mironet 9610)
notebook (P-4/2.4G, SIS chipset, Phoenix BIOS 4.06 dated 11/29/2002) exhibits
the same behaviour. In addition, the following message occurs during boot:
acpi_processor-0742  processor_preregister_: Error while parsing _PSD
domain information. Assuming no coordination
There is no _PSD object in my DSDT.
Making the cpufreq driver modular and unloading it before the suspend attempt
fixes the problem and the machine can be suspended.
It worked in 2.6.15, not tried anything between .15 and .18.
Can you please test the 2.6.19-rc2-mm2 kernel?
On Mon, Oct 30, 2006 at 10:32:05AM -0800, firstname.lastname@example.org wrote:
> ------- Additional Comments From email@example.com 2006-10-30 10:18 -------
> Can you please test the 2.6.19-rc2-mm2 kernel?
I'm sorry, but I've come to hate patching kernels; I end up wandering
away from the main tree and being unable to just download a new kernel
and install it without major problems. :( I'll wait for the next full
kernel release and give it a shot then, and will follow up here with the
This issue has been fixed in the Linus' tree and I'm unable to reproduce it on
my test boxes any more.