On Wed, Sep 27, 2006 at 12:15:56AM +0200, 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.
> >
> > 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
That's an interesting device name.
> > Some devices failed to power down, aborting suspend
> > acpi acpi: resuming
>
> That looks like cpufreq/acpi, no?
Looking at drivers/cpufreq/cpufreq.c:cpufreq_suspend(),
There's only two ways we can fail that function. In one way,
we'll see a printk, and the other we silently -EINVAL.
Given the log doesn't show the printk, we must be failing here..
cpu_policy = cpufreq_cpu_get(cpu);
if (!cpu_policy)
return -EINVAL;
cpufreq_cpu_get has a number of potential ways it could fail however,
and isn't very chatty about failing, so we've no real idea
what's falling apart there.
Dave
