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