Re: suspending to disk on FC6 not working

Pallipadi, Venkatesh
2006-09-29T21:35:43Z

>-----Original Message-----
>From: Dave Jones [mailto:davej@redhat.com]
>Sent: Friday, September 29, 2006 1:54 PM
>To: Louis Garcia
>Cc: Pallipadi, Venkatesh; Pavel Machek; linux-pm@lists.osdl.org
>Subject: Re: [linux-pm] suspending to disk on FC6 not working
>
>On Wed, Sep 27, 2006 at 02:55:29AM -0400, Louis Garcia wrote:
>
> > > > > > > > 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
> > > > > > 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.
> > >
> > > This patch might give us some more clues.
> > >
> > > --- 1/drivers/cpufreq/cpufreq.c 2006-09-24
>00:26:42.000000000 -0400
> > > +++ 2/drivers/cpufreq/cpufreq.c 2006-09-26
>22:48:49.000000000 -0400
> > > @@ -63,27 +63,36 @@ struct cpufreq_policy *cpufreq_cpu_get(u
> > > struct cpufreq_policy *data;
> > > unsigned long flags;
> > >
> > > - if (cpu >= NR_CPUS)
> > > + if (cpu >= NR_CPUS) {
> > > + printk(KERN_DEBUG "cpufreq_cpu_get failed
>(!>=NR_CPUS)\n");
> > > goto err_out;
> > > + }
> > >
> > > /* get the cpufreq driver */
> > > spin_lock_irqsave(&cpufreq_driver_lock, flags);
> > >
> > > - if (!cpufreq_driver)
> > > + if (!cpufreq_driver) {
> > > + printk(KERN_DEBUG "cpufreq_cpu_get failed (!driver)\n");
> > > goto err_out_unlock;
> > > + }
> > >
> > > - if (!try_module_get(cpufreq_driver->owner))
> > > + if (!try_module_get(cpufreq_driver->owner)) {
> > > + printk(KERN_DEBUG "cpufreq_cpu_get failed
>(!try_module_get)\n");
> > > goto err_out_unlock;
> > > -
> > > + }
> > >
> > > /* get the CPU */
> > > data = cpufreq_cpu_data[cpu];
> > >
> > > - if (!data)
> > > + if (!data) {
> > > + printk(KERN_DEBUG "cpufreq_cpu_get failed (!data)\n");
> > > goto err_out_put_module;
> > > + }
> > >
> > > - if (!kobject_get(&data->kobj))
> > > + if (!kobject_get(&data->kobj)) {
> > > + printk(KERN_DEBUG "cpufreq_cpu_get failed
>(!kobject_get)\n");
> > > goto err_out_put_module;
> > > + }
> > >
> > > spin_unlock_irqrestore(&cpufreq_driver_lock, flags);
> > > return data;
> > >
> > ...
> > PM: snapshotting memory.
> > cpufreq_cpu_get failed (!data)
> > Class driver suspend failed for cpu0
> > Could not power down device &q->lock: error -22
> > Some devices failed to power down, aborting suspend
>
>Ok, I'm not quite sure how we got into this state. Venkatesh,
>any ideas ?
>acpi-cpufreq got quite a few changes between .17 and .18, including the
>two large 'P-state coordination' change.
>
>Louis, I'm attaching two smaller changes that went into .18.
>Can you apply those with -R, and see if either of those makes
>a difference?
>
> Dave
>

cpufreq_cpu_data[] = NULL; only happens when acpi_cpufreq driver init
fails;
Looks like acpi_cpufreq driver init is failing at some point in this
case and the driver is staying loaded after that failure. That in turn
seems similar to one other bug I saw recently.

Louis, Can you check whether cpufreq is really working In you case. Boot
normally and before you try suspending, just see whether
/sys/devices/system/cpu/cpu0/cpufreq exists and if it does, cat
everything in that directory.

Thanks,
Venki