Hi, I noticed in the following changeset, the cpufreq_driver->resume call semantics looked a little odd: http://linux.bkbits.net:8080/linux-2.6/gnupatch@41d25ff3DyITFVz4Jm34PpluFPlt-g Since acpi_cpufreq_resume and speedstep_resume appear to return 0 upon success, it seems like the attached patch is what the desired behavior would be. Otherwise, cpufreq_resume() always prints an error and exits early if using a cpufreq_driver that supports resume. -- Andres Salomon