public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: Pavel Machek <pavel@ucw.cz>
Cc: linux-acpi@intel.com,
	Dominik Brodowski <linux@dominikbrodowski.de>,
	LKML <linux-kernel@vger.kernel.org>,
	Dave Jones <davej@codemonkey.org.uk>
Subject: Re: cpufreq problem wrt suspend/resume on Athlon64 [update]
Date: Mon, 7 Feb 2005 13:38:49 +0100	[thread overview]
Message-ID: <200502071338.49694.rjw@sisk.pl> (raw)
In-Reply-To: <200502040015.22457.rjw@sisk.pl>

Hi,

On Friday, 4 of February 2005 00:15, Rafael J. Wysocki wrote:
> On Thursday, 3 of February 2005 15:22, Pavel Machek wrote:
[-- snip --] 
> > > I'm currently thinking that the proper approach may be to add a ->suspend()
> > > routine to struct cpufreq_driver and call the driver-specific ->suspend()
> > > (if one is defined) from cpufreq_suspend().  Then, it'll be possible to do
> > > whatever-is-necessary on a per-driver basis.  Just a thought. :-)
> > 
> > Yes, that seems like right solution.
> 
> Then I'll try to do something along this line.

Previously I had made a mistake and compiled the cpufreq drivers as modules
instead of compiling them directly into the kernel.  When I compiled cpufreq
in directly, it turned out that any such patches were not necessary, as the
warning about the differences in the CPU frequency went away.  Nonetheless,
I used such a patch in testing the resume/suspend behaviour when
resuming on either AC or battery power (this patch is available at:
http://www.sisk.pl/kernel/patches/2.6.11-rc3-mm1/cpufreq-k8-suspend.patch).

The results of the testing are as follows:
1) When the cpufreq drivers are compiled directly into the kernel:
	a) the box resumes successfully if:
		i) it is on AC power during resume, or
		ii) it is started on AC power (ie bootloader starts on AC
		power) and disconnected from the AC before the kernel
		is loaded (!?)
	b) the box hangs solid as soon as the image is restored if it is
	started and the kernel is booted on battery power.
2) When the cpufreq drivers are not compiled into the kernel, the box reboots
on resume as soon as the image is restored.

The above results do not depend on whether the patch that forces the minimal
frequency of the CPU before suspend is used.

The results 1)a)ii) and 2) indicate that cpufreq is not to blame in this case,
so sorry for the noise here.

I think it is a BIOS-related issue and it seems to me that it's also related
to ACPI.  As the results 1)a)i) and 1)a)ii) are reproducible with probability
1, I'm going to investigate it a bit further, so if anyone on linux-acpi could
give me a hint on what to do next, I'd be grateful.

Greets,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
		-- Lewis Carroll "Alice's Adventures in Wonderland"

  parent reply	other threads:[~2005-02-07 12:38 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-02 13:28 cpufreq problem wrt suspend/resume on Athlon64 Rafael J. Wysocki
2005-02-02 13:31 ` Pavel Machek
2005-02-03  0:08   ` Rafael J. Wysocki
2005-02-03 10:41     ` Pavel Machek
2005-02-03 10:56       ` Dominik Brodowski
2005-02-03 10:58         ` Pavel Machek
2005-02-03 11:01           ` Dominik Brodowski
2005-02-03 11:30             ` Rafael J. Wysocki
2005-02-03 12:40               ` Dominik Brodowski
2005-02-03 13:20                 ` Rafael J. Wysocki
2005-02-03 14:22                   ` Pavel Machek
2005-02-03 23:15                     ` Rafael J. Wysocki
2005-02-03 23:34                       ` Nigel Cunningham
2005-02-03 23:52                         ` Rafael J. Wysocki
2005-02-07 12:38                       ` Rafael J. Wysocki [this message]
2005-02-03 14:20                 ` Pavel Machek
2005-02-03 21:46                   ` Rafael J. Wysocki
2005-02-03 22:00                     ` Pavel Machek
2005-02-03 23:37                       ` Rafael J. Wysocki
2005-02-03 22:01                     ` Pavel Machek

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=200502071338.49694.rjw@sisk.pl \
    --to=rjw@sisk.pl \
    --cc=davej@codemonkey.org.uk \
    --cc=linux-acpi@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@dominikbrodowski.de \
    --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