From: Dave Jones <davej@redhat.com>
To: Louis Garcia <louisg00@bellsouth.net>
Cc: linux-pm@lists.osdl.org, Pavel Machek <pavel@ucw.cz>
Subject: Re: suspending to disk on FC6 not working
Date: Fri, 29 Sep 2006 16:54:22 -0400 [thread overview]
Message-ID: <20060929205422.GA22014@redhat.com> (raw)
In-Reply-To: <1159340129.2547.3.camel@soncomputer>
[-- Attachment #1: Type: text/plain, Size: 3709 bytes --]
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
[-- Attachment #2: commit-a0cc621 --]
[-- Type: text/plain, Size: 1715 bytes --]
commit a0cc621f52a4dea10c34eeed6eb4e36b26db63dc
Author: Dave Jones <davej@redhat.com>
Date: Sun Aug 27 01:23:35 2006 -0700
[PATCH] cpufreq: acpi-cpufreq: Ignore failure from acpi_cpufreq_early_init_acpi
Ignore the return value of early_init_acpi(), as it can give false error
messages. If there is something really wrong, then register_driver will
fail cleanly with EINVAL later.
[ background: modprobe acpi-cpufreq on systems not capable of speed-scaling
started failing with 'invalid argument', where previously it would only
ever -ENODEV
I'm not 100% happy with the solution. It'd be better to handle
failure properly, but this is a low-impact change for 2.6.18
We can always revisit doing this better in .19 --davej.]
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
Signed-off-by: Dave Jones <davej@redhat.com>
Cc: Greg KH <greg@kroah.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
index efb41e8..e6ea00e 100644
--- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -567,16 +567,11 @@ static struct cpufreq_driver acpi_cpufre
static int __init
acpi_cpufreq_init (void)
{
- int result = 0;
-
dprintk("acpi_cpufreq_init\n");
- result = acpi_cpufreq_early_init_acpi();
+ acpi_cpufreq_early_init_acpi();
- if (!result)
- result = cpufreq_register_driver(&acpi_cpufreq_driver);
-
- return (result);
+ return cpufreq_register_driver(&acpi_cpufreq_driver);
}
[-- Attachment #3: commit-12e704d --]
[-- Type: text/plain, Size: 893 bytes --]
commit 12e704db809cd4101b7d3594fc9a96f30fe88a31
Author: bert hubert <bert.hubert@netherlabs.nl>
Date: Sun Jul 30 21:19:32 2006 +0200
[CPUFREQ] Propagate acpi_processor_preregister_performance return value.
Note how any error from acpi_processor_preregister_performance is ignored.
From: bert hubert <bert.hubert@netherlabs.nl>
Signed-off-by: Dave Jones <davej@redhat.com>
diff --git a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
index 567b39b..efb41e8 100644
--- a/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
+++ b/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
@@ -384,8 +384,7 @@ static int acpi_cpufreq_early_init_acpi(
}
/* Do initialization in ACPI core */
- acpi_processor_preregister_performance(acpi_perf_data);
- return 0;
+ return acpi_processor_preregister_performance(acpi_perf_data);
}
static int
[-- Attachment #4: Type: text/plain, Size: 0 bytes --]
next prev parent reply other threads:[~2006-09-29 20:54 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-24 22:55 suspending to disk on FC6 not working Louis Garcia
2006-09-25 7:16 ` Rafael J. Wysocki
2006-09-25 17:10 ` Louis Garcia
2006-09-25 18:43 ` Rafael J. Wysocki
2006-09-25 19:34 ` Louis Garcia
2006-09-25 20:15 ` Rafael J. Wysocki
2006-09-25 23:04 ` Louis Garcia
2006-09-26 10:00 ` Rafael J. Wysocki
2006-09-26 21:47 ` Louis Garcia
2006-09-26 22:01 ` Rafael J. Wysocki
2006-09-26 22:15 ` Pavel Machek
2006-09-26 22:26 ` Rafael J. Wysocki
2006-09-26 22:39 ` Louis Garcia
2006-09-26 22:45 ` Pavel Machek
2006-09-26 22:54 ` Rafael J. Wysocki
2006-09-26 22:58 ` Pavel Machek
2006-09-26 23:09 ` Louis Garcia
2006-09-26 23:12 ` Pavel Machek
2006-09-27 2:36 ` Dave Jones
2006-09-27 2:51 ` Dave Jones
2006-09-27 6:55 ` Louis Garcia
2006-09-29 20:54 ` Dave Jones [this message]
-- strict thread matches above, loose matches on Subject: below --
2006-09-29 21:35 Pallipadi, Venkatesh
2006-09-29 22:14 ` Pavel Machek
2006-09-29 22:25 ` Dave Jones
2006-09-29 22:23 Pallipadi, Venkatesh
2006-09-29 22:55 Pallipadi, Venkatesh
2006-10-01 2:49 ` Louis Garcia
2006-10-01 3:21 ` Dave Jones
2006-10-01 5:00 ` Louis Garcia
2006-10-01 5:05 ` Dave Jones
2006-10-01 5:30 ` Pavel Machek
2006-10-01 5:07 Pallipadi, Venkatesh
2006-10-01 5:22 ` Dave Jones
2006-10-01 12:28 ` Rafael J. Wysocki
2006-10-01 18:36 ` Dave Jones
2006-10-01 18:38 ` Pavel Machek
2006-10-01 18:56 ` Dave Jones
2006-10-01 5:22 ` Louis Garcia
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060929205422.GA22014@redhat.com \
--to=davej@redhat.com \
--cc=linux-pm@lists.osdl.org \
--cc=louisg00@bellsouth.net \
--cc=pavel@ucw.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox