* Re: Resume problems on Fujitsu-Siemens AMILO M7440G -- SATA
From: Michael Schierl @ 2006-03-21 15:37 UTC (permalink / raw)
To: Mark Lord; +Cc: Shaohua Li, linux-acpi, linux-ide
In-Reply-To: <441F04D6.4070404@rtr.ca>
Mark Lord wrote:
>> I copy all stuff need into tmpfs to ensure that it can restore the video
>> without hard disk access.
>
> OOhh.. clever, wish I'd thought of that,
One should not forget to disable swap first :)
> as all of my (now solved) suspend/resume issues
> were *all* libata related.
So I guess it is a good idea to get SATA working first, isn't it?
>> What to do, what to test?
>
> Randy Dunlop's libata-acpi patch might work for you.
> http://www.xenotime.net/linux/SATA/
I tried the 2.6.16-rc4 patches on 2.6.16 (one hunk did not apply in
libata.h, but I think I was able to fix it manually). Before suspend it
works well, after suspend it does not work. Seems that the timeout is
longer with the patch, though. I tried it several times; once it seemed
to have worked, but it was not reproducible (and it did not work any
longer after the next suspend), so I guess it could be just that I only
tried files already in cache. (Or alternatively, the patch has a success
rate of maybe 5%...)
"Just for fun" i tried the 2.6.15 patches on 2.6.15, but it did not even
boot.
BTW: It is an Intel AHCI controller.
Any other ideas/patches?
Michael
^ permalink raw reply
* FW: linux kernel ACPI thermal trip_points
From: Karasyov, Konstantin A @ 2006-03-21 9:48 UTC (permalink / raw)
To: adsmith; +Cc: linux-acpi
Hello, Abraham.
It is possible, that the trip points are being reset by BIOS on thermal
events. To make sure, please, send the output of acpidump and dmesg
commands. 'acpidump' available in pmtools here:
http://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/utils/
You can use linux-acpi@vger.kernel.org mailing list or open a new entry
in bugzilla.kernel.org under ACPI/Power-Thermal component.
Regards.
Konstantin.
-----Original Message-----
From: adsmith@math.duke.edu [mailto:adsmith@math.duke.edu]
Sent: Saturday, March 18, 2006 7:03 AM
To: Grover, Andrew; paul.s.diefenbaugh@intel.co
Cc: Abraham David Smith
Subject: linux kernel ACPI thermal trip_points
I have a question about the acpi thermal_zone driver as it appears in
the 2.6.15 kernel series.
Naturally, I've already search the web and various forums before
emailing the driver authors,
On my laptop (a Sharp Actius PC-UM32W), the following occurs:
The default trip_points are
hedwig THRM # cat trip_points
critical (S5): 95 C
passive: 85 C: tc1=1 tc2=5 tsp=30 devices=0xcf6c2448
active[0]: 70 C: devices=0xcf6c3708
active[1]: 63 C: devices=0xcf6c3948
active[2]: 55 C: devices=0xcf6c3b88
Then, I reset them as follows
hedwig THRM # echo -n "75:0:30:45:40:35" > trip_points
hedwig THRM # cat trip_points
critical (S5): 75 C
passive: 30 C: tc1=1 tc2=5 tsp=30 devices=0xcf6c2448
active[0]: 45 C: devices=0xcf6c3708
active[1]: 40 C: devices=0xcf6c3948
active[2]: 35 C: devices=0xcf6c3b88
However, the new trip points are ignored, and once the temp rises or
falls across one of the *original* trip points, they are then shown as
at first:
hedwig THRM # cat trip_points
critical (S5): 95 C
passive: 85 C: tc1=1 tc2=5 tsp=30 devices=0xcf6c2448
active[0]: 70 C: devices=0xcf6c3708
active[1]: 63 C: devices=0xcf6c3948
active[2]: 55 C: devices=0xcf6c3b88
(The only relevant daemon running is acpid-1.0.4, and it is merely
printing behaviour to the system logs.)
Do you have any suggestions as to how to override this behavior or
otherwise force lower trip-points?
Thanks,
Abe Smith
--
# Abraham David Smith, <adsmith@math.duke.edu> #
# http://fds.duke.edu/db/aas/math/grad/adsmith #
# Please enable PGP or GnuPG for email privacy! #
# Mathematics Graduate Student, Duke University #
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-21 9:11 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>With _TMP faked in the kernel and one whole zone ignored, this
>is what I
>get:
>
>Zone to ignore | Result
>---------------------------------------------------------------
>---------
>THM0 OK (10 cycles)
>THM2 "kernel panic! attempted to kill init"
I guess, if you fake DSDT by completely removing THM2
you won't see this.
>THM6 Hangs (4th cycle)
Is it still hang at SMPI?
>THM7 OK (8 cycles)
>
>So THM6 seems healthy, but THM0 and THM7 (and maybe THM2) interact
>badly. If I unload THM2, THM6, and THM7, then it's okay (previous
>experiments with faking _TMP but with only THM0 loaded). But unloading
>THM6 is not enough.
Please try to remove THM2 judge if it is JUST the
problem of THM0 && THM7.
>
>The kernel panic for the don't-load-THM2 kernel is very strange. I had
>another kernel panic while doing another set of tests, which I also
>couldn't explain. The only difference between the no-THM0 and the
>no-THM2 kernels is:
Could you just printk device->pnp? it could be null point (due to
you hack?)
>
>diff -r b7ad6c906aba -r 213308f0ec31 drivers/acpi/thermal.c
>--- a/drivers/acpi/thermal.c Tue Mar 21 02:23:30 2006 -0500
>+++ b/drivers/acpi/thermal.c Tue Mar 21 02:36:42 2006 -0500
>@@ -1324,7 +1324,7 @@ static int acpi_thermal_add(struct acpi_
>
> if (!device)
> return_VALUE(-EINVAL);
>- if (strcmp("THM2", device->pnp.bus_id) == 0) {
>+ if (strcmp("THM0", device->pnp.bus_id) == 0) {
> printk(KERN_INFO PREFIX "thermal_add: ignoring %s\n",
> device->pnp.bus_id);
> return_VALUE(-EINVAL);
>
>
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-21 8:47 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B417262@pdsmsx403>
With _TMP faked in the kernel and one whole zone ignored, this is what I
get:
Zone to ignore | Result
------------------------------------------------------------------------
THM0 OK (10 cycles)
THM2 "kernel panic! attempted to kill init"
THM6 Hangs (4th cycle)
THM7 OK (8 cycles)
So THM6 seems healthy, but THM0 and THM7 (and maybe THM2) interact
badly. If I unload THM2, THM6, and THM7, then it's okay (previous
experiments with faking _TMP but with only THM0 loaded). But unloading
THM6 is not enough.
The kernel panic for the don't-load-THM2 kernel is very strange. I had
another kernel panic while doing another set of tests, which I also
couldn't explain. The only difference between the no-THM0 and the
no-THM2 kernels is:
diff -r b7ad6c906aba -r 213308f0ec31 drivers/acpi/thermal.c
--- a/drivers/acpi/thermal.c Tue Mar 21 02:23:30 2006 -0500
+++ b/drivers/acpi/thermal.c Tue Mar 21 02:36:42 2006 -0500
@@ -1324,7 +1324,7 @@ static int acpi_thermal_add(struct acpi_
if (!device)
return_VALUE(-EINVAL);
- if (strcmp("THM2", device->pnp.bus_id) == 0) {
+ if (strcmp("THM0", device->pnp.bus_id) == 0) {
printk(KERN_INFO PREFIX "thermal_add: ignoring %s\n",
device->pnp.bus_id);
return_VALUE(-EINVAL);
-Sanjoy
`A society of sheep must in time beget a government of wolves.'
- Bertrand de Jouvenal
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-21 7:27 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F840B417262@pdsmsx403>
> From pervious experience, we know _THM0._TMP causes problem. If you
> fake _TMP for all THM, what could happen?
It still hangs on the second sleep. I faked them in the kernel instead
of the DSDT, by faking them in acpi_evaluate_integer() like so:
diff -r ac486e270597 -r 959c4fa10a36 drivers/acpi/utils.c
--- a/drivers/acpi/utils.c Sat Mar 18 08:35:34 2006 -0500
+++ b/drivers/acpi/utils.c Mon Mar 20 20:52:01 2006 -0500
@@ -270,7 +270,15 @@ acpi_evaluate_integer(acpi_handle handle
memset(element, 0, sizeof(union acpi_object));
buffer.length = sizeof(union acpi_object);
buffer.pointer = element;
- status = acpi_evaluate_object(handle, pathname, arguments, &buffer);
+ if (strcmp(pathname, "_TMP") != 0)
+ status = acpi_evaluate_object(handle, pathname, arguments, &buffer);
+ else {
+ printk(KERN_INFO PREFIX "acpi_evaluate_integer: Faking _TMP\n");
+ status = AE_OK;
+ element->type = ACPI_TYPE_INTEGER;
+ element->integer.value = 3000; /* 27 C, in deciKelvins */
+ }
+
if (ACPI_FAILURE(status)) {
acpi_util_eval_error(handle, pathname, status);
return_ACPI_STATUS(status);
Each thermal zone loaded with produced printk's like "Faking _TMP", etc,
so the patch was working. It shouldn't change the result if instead I
make all the _TMP methods in the DSDT return 0xBB8 (or whatever the
magic number was).
So my plan, which I'm trying now, is to keep _TMP faked for all zones,
and take away one zone at a time until the hang goes away. If I take
away all of THM[267], then it won't hang (since THM0 by itself hangs but
THM0 without _TMP does not hang). But I hope that an earlier
combination in the search will not hang.
-Sanjoy
`A society of sheep must in time beget a government of wolves.'
- Bertrand de Jouvenal
^ permalink raw reply
* Suspend Medion Akoya LS
From: L. A. Linden Levy @ 2006-03-21 5:59 UTC (permalink / raw)
To: linux-acpi; +Cc: lindenle
[-- Attachment #1: Type: text/plain, Size: 952 bytes --]
Hi when I use suspend my machine wont wake up unless i hit the power
button but then it shuts down. It is like the keyboard is not
registering when it is suspended. Can anyone help me make this work?
kernel 2.6.15
P.S. I can provide more info if necessary, thanks!!
--
---------------------------------------------
Loren A. Linden Levy
481 Loomis, Department of Physics
University of Illinois at Urbana-Champaign
1110 W. Green St., Urbana, IL 61801-3080
Tel: 217-244-7995 Fax: 217-333-1215
Email: lindenle@uiuc.edu
url: http://w3.physics.uiuc.edu/~lindenle/
_____________________________________________
---------------------------------------------
This email has been cryptographically signed.
Search for "lindenle" at pgp.mit.edu
to obtain my public key which can be used
to verify the authenticity of this message.
_____________________________________________
---------------------------------------------
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-21 1:38 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>> I think you need to continue to find out which THMs, which methods
>> cause s3 hang when THM0._TMP disabled.
>
>So far I've found that if (with no THM0 loaded) I load exactly one of
>THM2, THM6, or THM7, then there's no hang. Now I am looking for which
>combinations of the THM[0267] zones cause the problem.
Hmm, I guess you don't need to try each combination of THM[0267].
>From pervious experience, we know _THM0._TMP causes problem.
If you fake _TMP for all THM, what could happen?
If you verified _TMP cause issue by fake them in DSDT, probably,
we need to continue dig Method : UPDT.
Method (UPDT, 0, NotSerialized)
{
If (IGNR)
{
Decrement (IGNR)
}
Else
{
If (H8DR)
{
If (Acquire (I2CM, 0x0064)) {}
Else
{
Store (I2RB (Zero, 0x01, 0x04),
Local7)
If (Local7)
{
Fatal (0x01, 0x80000003, Local7)
}
Else
{
Store (HBS0, TMP0)
Store (HBS2, TMP2)
Store (HBS6, TMP6)
Store (HBS7, TMP7)
}
Release (I2CM)
}
}
}
}
Thanks,
Luming
^ permalink raw reply
* Re: Resume problems on Fujitsu-Siemens AMILO M7440G -- SATA
From: Mark Lord @ 2006-03-20 19:39 UTC (permalink / raw)
To: Michael Schierl; +Cc: Shaohua Li, linux-acpi, linux-ide
In-Reply-To: <441EF7B8.4040901@gmx.de>
Michael Schierl wrote:
..
> Okay, I got video working on vanilla 2.6.16 by using "vbetool post" and
> "vbetool vbestate restore" directly after "echo mem >/sys/power/state".
>
> I copy all stuff need into tmpfs to ensure that it can restore the video
> without hard disk access.
OOhh.. clever, wish I'd thought of that,
as all of my (now solved) suspend/resume issues
were *all* libata related.
> when accessing hard disks first time after resume, I get (wrote it by
> hand so maybe this is not 100% correct)
>
> ata1: handling error / timeout
> ata1: port reset p_ is 400000 is 0 pis 400000 cmd 8007
> tf 80 ss 113 se 405000
> ata1: status = 0x50 {DriveReady SeekComplete}
> sda: current: senseKey 0x0 ASC 0x0 ASCQ 0x0
>
> Sometimes there is "cmd 6" instead of "cmd 8007".
>
> What to do, what to test?
Randy Dunlop's libata-acpi patch might work for you.
http://www.xenotime.net/linux/SATA/
Cheers
^ permalink raw reply
* Re: Resume problems on Fujitsu-Siemens AMILO M7440G -- SATA
From: Michael Schierl @ 2006-03-20 18:43 UTC (permalink / raw)
To: Shaohua Li; +Cc: linux-acpi, linux-ide
In-Reply-To: <1141349791.19013.1.camel@sli10-desk.sh.intel.com>
[added linux-ide to CC]
Shaohua Li schrieb:
> If the video is dark, please try the boot options listed in
> documentation/power/video.txt.
Okay, I got video working on vanilla 2.6.16 by using "vbetool post" and
"vbetool vbestate restore" directly after "echo mem >/sys/power/state".
I copy all stuff need into tmpfs to ensure that it can restore the video
without hard disk access.
when accessing hard disks first time after resume, I get (wrote it by
hand so maybe this is not 100% correct)
ata1: handling error / timeout
ata1: port reset p_ is 400000 is 0 pis 400000 cmd 8007
tf 80 ss 113 se 405000
ata1: status = 0x50 {DriveReady SeekComplete}
sda: current: senseKey 0x0 ASC 0x0 ASCQ 0x0
Sometimes there is "cmd 6" instead of "cmd 8007".
What to do, what to test?
I don't have any way of getting information out of my machine after
resume except on display (hard disks do not work after resume, the
notebook does not have a serial port and network does not work after
resume either) and by flashing keyboard LEDs, so transcribing huge dmesg
output would be a pain...
Please CC me since I am not on the list(s). Thank you.
Michael
^ permalink raw reply
* Re: Powers off after suspen to mem
From: Stefan Seyfried @ 2006-03-20 6:55 UTC (permalink / raw)
To: linux-acpi
In-Reply-To: <F7DC2337C7631D4386A2DF6E8FB22B30065E13EC@hdsmsx401.amr.corp.intel.com>
On Mon, Mar 13, 2006 at 10:50:01PM -0500, Brown, Len wrote:
> rmmod button
> before the suspend.
ok.
> or resume by opening the lid instead of pressing the power button.
This won't help on toshibas (for example) that always generate a
button/power event on resume, no matter how you do it.
=> best solution is to let userspace ignore button event directly
after resume (like e.g. powersaved does)
--
Stefan Seyfried
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-20 6:39 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F84041AC26C@pdsmsx403>
> I think you need to continue to find out which THMs, which methods
> cause s3 hang when THM0._TMP disabled.
So far I've found that if (with no THM0 loaded) I load exactly one of
THM2, THM6, or THM7, then there's no hang. Now I am looking for which
combinations of the THM[0267] zones cause the problem.
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-19 14:33 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F84041AC26C@pdsmsx403>
> Maybe I need to make a summary here for this issue:
> 1. The s3 hang is in While-loop in SMPI that looks like
> waiting BIOS response.
Right.
> 2. If THM2, THM6, THM7 disabled, disabling THM0._TMP
> fix the s3 hang.
Right. And many ways of disabling THM0._TMP fix the hang:
1. making acpi_evaluate_integer() not evaluate _TMP methods.
2. the short-term fix using acpi_in_suspend
3. taking out \_SB.PCI0.ISA0.EC0.UPDT () line from _TMP method.
> I think you need to continue to find out which THMs, which methods
> cause s3 hang when THM0._TMP disabled. I assume the problem is:
> THM0._TMP && THMx._XXX && THMy._YYY..
I agree, and am testing the other thermal methods one at a time. I
suspect that THMx.AC0 will be involved, but we'll see.
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
^ permalink raw reply
* Re: 2.6.16-rc6-mm2 uninitialized online_policy_cpus.bits[0]
From: Venkatesh Pallipadi @ 2006-03-19 6:13 UTC (permalink / raw)
To: Andrew Morton
Cc: Con Kolivas, linux-kernel, Venkatesh Pallipadi, Len Brown,
linux-acpi
In-Reply-To: <20060318173512.313a3453.akpm@osdl.org>
On Sat, Mar 18, 2006 at 05:35:12PM -0800, Andrew Morton wrote:
> Con Kolivas <kernel@kolivas.org> wrote:
> >
> > Wonder if this is related to rc6's oops?
> > gcc 4.0.3
> >
> > CC [M] arch/i386/kernel/cpu/cpufreq/speedstep-centrino.o
> > arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c: In function
> > 'centrino_target':
> > include/linux/bitmap.h:170: warning: 'online_policy_cpus.bits[0]' is used
> > uninitialized in this function
> > CC [M] arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.o
> > arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c: In function
> > 'acpi_cpufreq_target':
> > include/linux/bitmap.h:170: warning: 'online_policy_cpus.bits[0]' is used
> > uninitialized in this function
>
> Well conceivably. That warning is a consequence of my quick hack to make
> the ACPI tree compile on uniprocessor.
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm2/broken-out/git-acpi-up-fix.patch
>
> My patch is, as the compiler points out, wrong.
>
> I've sent that patch two or three times to the APCI maintainers, to the
> ACPI mailing list and to the author of the original buggy patch. The
> response thus far has been dead silence.
>
> IOW, despite my efforts, the ACPI tree has been in a non-compiling state on
> uniprocessor since February 11.
>
> This is pathetic. People are trying to get things done here and ACPI is
> getting in the way.
Oops. Sorry. It is me who dropped the ball here. I somehow assumed that
your original patch fixed the issue and didn't look at the actual code.
Here is the patch against mm.
Thanks,
Venki
Fix the UP build breakage in acpi-cpufreq and speedstep-centrino due to
previous p-state software coordination patch.
Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
diff -purN linux-2.6.15/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c linux-2.6.15-new/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
--- linux-2.6.15/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 2006-03-18 19:41:25.000000000 -0800
+++ linux-2.6.15-new/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 2006-03-18 19:48:10.000000000 -0800
@@ -225,9 +225,11 @@ acpi_cpufreq_target (
freqs.old = data->freq_table[cur_state].frequency;
freqs.new = data->freq_table[next_state].frequency;
-#ifdef CONFIG_SMP
+#ifdef CONFIG_HOTPLUG_CPU
/* cpufreq holds the hotplug lock, so we are safe from here on */
cpus_and(online_policy_cpus, cpu_online_map, policy->cpus);
+#else
+ online_policy_cpus = policy->cpus;
#endif
for_each_cpu_mask(j, online_policy_cpus) {
diff -purN linux-2.6.15/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c linux-2.6.15-new/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
--- linux-2.6.15/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 2006-03-18 19:41:25.000000000 -0800
+++ linux-2.6.15-new/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 2006-03-18 19:47:46.000000000 -0800
@@ -652,9 +652,11 @@ static int centrino_target (struct cpufr
return -EINVAL;
}
-#ifdef CONFIG_SMP
+#ifdef CONFIG_HOTPLUG_CPU
/* cpufreq holds the hotplug lock, so we are safe from here on */
cpus_and(online_policy_cpus, cpu_online_map, policy->cpus);
+#else
+ online_policy_cpus = policy->cpus;
#endif
saved_mask = current->cpus_allowed;
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-19 4:12 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>> Do you load processor driver?
>
>It's loads at boot. When thermal loads, it pulls in processor:
>
>$ lsmod | grep thermal
>thermal 17224 0
>processor 30080 1 thermal
>
Maybe I need to make a summary here for this issue:
1. The s3 hang is in While-loop in SMPI that looks like
waiting BIOS response.
2. If THM2, THM6, THM7 disabled, disabling THM0._TMP
fix the s3 hang.
I think you need to continue to find out which THMs, which methods
cause s3 hang when THM0._TMP disabled.
I assume the problem is:
THM0._TMP && THMx._XXX && THMy._YYY..
Thanks,
Luming
^ permalink raw reply
* Re: 2.6.16-rc6-mm2 uninitialized online_policy_cpus.bits[0]
From: Con Kolivas @ 2006-03-19 2:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Venkatesh Pallipadi, Len Brown, linux-acpi
In-Reply-To: <20060318173512.313a3453.akpm@osdl.org>
On Sunday 19 March 2006 12:35, Andrew Morton wrote:
> Con Kolivas <kernel@kolivas.org> wrote:
> > Wonder if this is related to rc6's oops?
> > gcc 4.0.3
> >
> > CC [M] arch/i386/kernel/cpu/cpufreq/speedstep-centrino.o
> > arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c: In function
> > 'centrino_target':
> > include/linux/bitmap.h:170: warning: 'online_policy_cpus.bits[0]' is
> > used uninitialized in this function
> > CC [M] arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.o
> > arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c: In function
> > 'acpi_cpufreq_target':
> > include/linux/bitmap.h:170: warning: 'online_policy_cpus.bits[0]' is
> > used uninitialized in this function
>
> Well conceivably. That warning is a consequence of my quick hack to make
> the ACPI tree compile on uniprocessor.
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.
>6.16-rc6-mm2/broken-out/git-acpi-up-fix.patch
>
> My patch is, as the compiler points out, wrong.
>
> I've sent that patch two or three times to the APCI maintainers, to the
> ACPI mailing list and to the author of the original buggy patch. The
> response thus far has been dead silence.
Well this will end up being the wrong place to do it but I needed it to work
now so this patch fixes it for me. Dunno what else it will break. Works on
a couple of configs fine.
Cheers,
Con
---
Hacky workaround for cpu_online_map not being defined
arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c | 2 --
arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c | 2 --
kernel/sched.c | 4 ++++
3 files changed, 4 insertions(+), 4 deletions(-)
Index: linux-2.6.16-rc6-mm2/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c
===================================================================
--- linux-2.6.16-rc6-mm2.orig/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 2006-03-19 11:15:05.000000000 +1100
+++ linux-2.6.16-rc6-mm2/arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c 2006-03-19 12:45:56.000000000 +1100
@@ -225,10 +225,8 @@ acpi_cpufreq_target (
freqs.old = data->freq_table[cur_state].frequency;
freqs.new = data->freq_table[next_state].frequency;
-#ifdef CONFIG_SMP
/* cpufreq holds the hotplug lock, so we are safe from here on */
cpus_and(online_policy_cpus, cpu_online_map, policy->cpus);
-#endif
for_each_cpu_mask(j, online_policy_cpus) {
freqs.cpu = j;
Index: linux-2.6.16-rc6-mm2/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c
===================================================================
--- linux-2.6.16-rc6-mm2.orig/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 2006-03-19 11:15:05.000000000 +1100
+++ linux-2.6.16-rc6-mm2/arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c 2006-03-19 12:45:42.000000000 +1100
@@ -652,10 +652,8 @@ static int centrino_target (struct cpufr
return -EINVAL;
}
-#ifdef CONFIG_SMP
/* cpufreq holds the hotplug lock, so we are safe from here on */
cpus_and(online_policy_cpus, cpu_online_map, policy->cpus);
-#endif
saved_mask = current->cpus_allowed;
first_cpu = 1;
Index: linux-2.6.16-rc6-mm2/kernel/sched.c
===================================================================
--- linux-2.6.16-rc6-mm2.orig/kernel/sched.c 2006-03-19 13:25:25.000000000 +1100
+++ linux-2.6.16-rc6-mm2/kernel/sched.c 2006-03-19 13:25:36.000000000 +1100
@@ -6366,6 +6366,10 @@ void __init sched_init_smp(void)
init_sched_domain_sysctl();
}
#else
+/* bitmap of online cpus */
+cpumask_t cpu_online_map __read_mostly;
+EXPORT_SYMBOL(cpu_online_map);
+
void __init sched_init_smp(void)
{
}
^ permalink raw reply
* Re: 2.6.16-rc6-mm2 uninitialized online_policy_cpus.bits[0]
From: Andrew Morton @ 2006-03-19 1:35 UTC (permalink / raw)
To: Con Kolivas; +Cc: linux-kernel, Venkatesh Pallipadi, Len Brown, linux-acpi
In-Reply-To: <200603191209.54946.kernel@kolivas.org>
Con Kolivas <kernel@kolivas.org> wrote:
>
> Wonder if this is related to rc6's oops?
> gcc 4.0.3
>
> CC [M] arch/i386/kernel/cpu/cpufreq/speedstep-centrino.o
> arch/i386/kernel/cpu/cpufreq/speedstep-centrino.c: In function
> 'centrino_target':
> include/linux/bitmap.h:170: warning: 'online_policy_cpus.bits[0]' is used
> uninitialized in this function
> CC [M] arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.o
> arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.c: In function
> 'acpi_cpufreq_target':
> include/linux/bitmap.h:170: warning: 'online_policy_cpus.bits[0]' is used
> uninitialized in this function
Well conceivably. That warning is a consequence of my quick hack to make
the ACPI tree compile on uniprocessor.
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.16-rc6/2.6.16-rc6-mm2/broken-out/git-acpi-up-fix.patch
My patch is, as the compiler points out, wrong.
I've sent that patch two or three times to the APCI maintainers, to the
ACPI mailing list and to the author of the original buggy patch. The
response thus far has been dead silence.
IOW, despite my efforts, the ACPI tree has been in a non-compiling state on
uniprocessor since February 11.
This is pathetic. People are trying to get things done here and ACPI is
getting in the way. But *need* to get the ACPI development tree out for
people to test else we'll never be able to take another ACPI update into
mainline.
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-18 20:12 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F84041AC26B@pdsmsx403>
> Do you load processor driver?
It's loads at boot. When thermal loads, it pulls in processor:
$ lsmod | grep thermal
thermal 17224 0
processor 30080 1 thermal
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-18 17:08 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>>> PM: Preparing system for mem sleep
>>> Stopping tasks:
>>> =======================================================|
>
>> Did you see any methods before and after this line in hang case on
>> screen? If yes, do you recall what they are?
>
>I capture across a serial console, so here are the exact msgs (I just
>ran the second sleep and got the usual hang). This is with vanilla
>2.6.16-rc5 (and vanilla DSDT):
>
>Stopping tasks:
>=========================================================|
>Execute Method: [\_SB_.LID0._PSW] (Node c1564808)
>Execute Method: [\_SB_.SLPB._PSW] (Node c1564708)
>Execute Method: [\_S3_] (Node c157a988)
>Execute Method: [\_PTS] (Node c157ab48)
>
>The screen itself is full of garbage because the first
>sleep/wake messes
>up the console. Along with a giant white square that fills most of the
>screen, I see a fuzzy, dotted version of the above messages, plus one
>more line "ACPI" and then a flashing underscore cursor after that. I
>don't know if it was trying to printk "ACPI" but then the rest of the
>message got lost, or it hung before printing it, or whether the ACPI is
>from a previous dmesg (i.e. the first sleep/wake) that didn't get
>cleared properly.
Do you load processor driver?
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-18 17:03 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F84041AC26A@pdsmsx403>
>> PM: Preparing system for mem sleep
>> Stopping tasks:
>> =======================================================|
> Did you see any methods before and after this line in hang case on
> screen? If yes, do you recall what they are?
I capture across a serial console, so here are the exact msgs (I just
ran the second sleep and got the usual hang). This is with vanilla
2.6.16-rc5 (and vanilla DSDT):
Stopping tasks: =========================================================|
Execute Method: [\_SB_.LID0._PSW] (Node c1564808)
Execute Method: [\_SB_.SLPB._PSW] (Node c1564708)
Execute Method: [\_S3_] (Node c157a988)
Execute Method: [\_PTS] (Node c157ab48)
The screen itself is full of garbage because the first sleep/wake messes
up the console. Along with a giant white square that fills most of the
screen, I see a fuzzy, dotted version of the above messages, plus one
more line "ACPI" and then a flashing underscore cursor after that. I
don't know if it was trying to printk "ACPI" but then the rest of the
message got lost, or it hung before printing it, or whether the ACPI is
from a previous dmesg (i.e. the first sleep/wake) that didn't get
cleared properly.
-Sanjoy
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-18 16:37 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>Here first are the dmesgs from suspending with a vanilla 2.6.16-rc5. I
>did only one cycle so that it didn't hang and I could edit this email
>without rebooting (but later suspends produce the same method
>calls, I'm
>90% sure):
>
># the sleep dmesgs
>PM: Preparing system for mem sleep
>Stopping tasks:
>=======================================================|
Did you see any methods before and after this line in hang case on
screen?
If yeas, do you recall what they are?
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-18 16:27 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F84041AC269@pdsmsx403>
> just return AE_OK, because we are hacking. :-)
I found that out the hard way. I first tried AE_BAD_PARAMETER but the
kernel paniced on boot, which I don't understand. So then I switched to
returning AE_OK, and it booted fine. But it hung on the *second* sleep
cycle. So the problem got worse, or the bug is slithering around and
shows up in odd places depending what we do.
>> That's in my lilo.conf so all kernels I test use those options. I
>> can send you the dmesgs from the suspends without the ugly hack (and
>> will send them from the upcoming suspends, with the ugly hack).
> Thanks, I'm waiting for that to understand if the hack is clean for
> killing unwanted AML methods call.
Here first are the dmesgs from suspending with a vanilla 2.6.16-rc5. I
did only one cycle so that it didn't hang and I could edit this email
without rebooting (but later suspends produce the same method calls, I'm
90% sure):
# the sleep dmesgs
PM: Preparing system for mem sleep
Stopping tasks: =======================================================|
Execute Method: [\_SB_.LID0._PSW] (Node c1564808)
Execute Method: [\_SB_.SLPB._PSW] (Node c1564708)
Execute Method: [\_S3_] (Node c157a988)
Execute Method: [\_PTS] (Node c157ab48)
Execute Method: [\_SI_._SST] (Node c157a8c8)
uhci_hcd 0000:00:07.2: suspend_rh
uhci_hcd 0000:00:07.2: uhci_suspend
uhci_hcd 0000:00:07.2: --> PCI D0/legacy
PM: Entering mem sleep
# and here are the wakeup dmesgs
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Back to C!
PM: Finishing wakeup.
Execute Method: [\_GPE._L0B] (Node c157a848)
PCI: Found IRQ 11 for device 0000:00:02.0
PCI: Sharing IRQ 11 with 0000:00:06.0
PCI: Sharing IRQ 11 with 0000:01:00.0
PCI: Found IRQ 11 for device 0000:00:02.1
uhci_hcd 0000:00:07.2: PCI legacy resume
PCI: Found IRQ 11 for device 0000:00:07.2
uhci_hcd 0000:00:07.2: uhci_resume
uhci_hcd 0000:00:07.2: uhci_check_and_reset_hc: legsup = 0x2000
uhci_hcd 0000:00:07.2: Performing full reset
usb usb1: root hub lost power or was reset
uhci_hcd 0000:00:07.2: suspend_rh
usb usb1: finish resume
uhci_hcd 0000:00:07.2: wakeup_rh
Restarting tasks...<7>hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
done
Execute Method: [\_SI_._SST] (Node c157a8c8)
Execute Method: [\_WAK] (Node c157aac8)
Execute Method: [\_TZ_.THM0._PSV] (Node c157be48)
Execute Method: [\_TZ_.THM0._TC1] (Node c157bdc8)
Execute Method: [\_TZ_.THM0._TC2] (Node c157bd88)
Execute Method: [\_TZ_.THM0._TSP] (Node c157bd48)
Execute Method: [\_TZ_.THM0._AC0] (Node c157bf48)
Execute Method: [\_TZ_.THM0._TMP] (Node c157bf88)
Execute Method: [\_SI_._SST] (Node c157a8c8)
Execute Method: [\_TZ_.THM2._AC0] (Node c157bb48)
Execute Method: [\_TZ_.THM2._TMP] (Node c157bb88)
Execute Method: [\_TZ_.THM6._AC0] (Node c157b908)
Execute Method: [\_TZ_.THM6._TMP] (Node c157b948)
Execute Method: [\_TZ_.THM7._AC0] (Node c157b6c8)
Execute Method: [\_TZ_.THM7._TMP] (Node c157b708)<7>uhci_hcd 0000:00:07.2: suspend_rh (auto-stop)
Execute Method: [\_SB_.LID0._PSW] (Node c1564808)
Execute Method: [\_SB_.SLPB._PSW] (Node c1564708)
# next msgs are from 'cardctl eject'
ds: ds_open(socket 0)
ds: ds_open(socket 1)
ds: ds_open(socket 2)
pccard: card ejected from slot 1
PCMCIA: socket e231c028: *** DANGER *** unable to remove socket power
ds: ds_release(socket 0)
ds: ds_release(socket 1)
# now for the dmesgs with the latest hack (returning AE_OK) for the
# first suspend cycle (which didn't hang):
Stopping tasks: ====================================================|
Execute Method: [\_SB_.LID0._PSW] (Node c1564808)
Execute Method: [\_SB_.SLPB._PSW] (Node c1564708)
Execute Method: [\_S3_] (Node c157a988)
Execute Method: [\_PTS] (Node c157ab48)
Execute Method: [\_SI_._SST] (Node c157a8c8)
uhci_hcd 0000:00:07.2: suspend_rh
uhci_hcd 0000:00:07.2: uhci_suspend
uhci_hcd 0000:00:07.2: --> PCI D0/legacy
PM: Entering mem sleep
# and the wakeup msgs
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Back to C!
PM: Finishing wakeup.
PCI: Found IRQ 11 for device 0000:00:02.0
PCI: Sharing IRQ 11 with 0000:00:06.0
PCI: Sharing IRQ 11 with 0000:01:00.0
PCI: Found IRQ 11 for device 0000:00:02.1
uhci_hcd 0000:00:07.2: PCI legacy resume
PCI: Found IRQ 11 for device 0000:00:07.2
uhci_hcd 0000:00:07.2: uhci_resume
uhci_hcd 0000:00:07.2: uhci_check_and_reset_hc: legsup = 0x2000
uhci_hcd 0000:00:07.2: Performing full reset
usb usb1: root hub lost power or was reset
uhci_hcd 0000:00:07.2: suspend_rh
usb usb1: finish resume
uhci_hcd 0000:00:07.2: wakeup_rh
Restarting tasks...<7>hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000
done
Execute Method: [\_SI_._SST] (Node c157a8c8)
Execute Method: [\_WAK] (Node c157aac8)
Execute Method: [\_TZ_.THM0._PSV] (Node c157be48)
Execute Method: [\_TZ_.THM0._TC1] (Node c157bdc8)
Execute Method: [\_TZ_.THM0._TC2] (Node c157bd88)
Execute Method: [\_TZ_.THM0._TSP] (Node c157bd48)
Execute Method: [\_TZ_.THM0._AC0] (Node c157bf48)
Execute Method: [\_SI_._SST] (Node c157a8c8)
Execute Method: [\_TZ_.THM0._TMP] (Node c157bf88)
Execute Method: [\_TZ_.THM2._AC0] (Node c157bb48)
Execute Method: [\_TZ_.THM2._TMP] (Node c157bb88)
Execute Method: [\_TZ_.PFN0._OFF] (Node c157a288)
Execute Method: [\_TZ_.PFN0._STA] (Node c157a308)
Execute Method: [\_TZ_.THM6._AC0] (Node c157b908)
Execute Method: <7>uhci_hcd 0000:00:07.2: suspend_rh (auto-stop)
[\_TZ_.THM6._TMP] (Node c157b948)
Execute Method: [\_TZ_.THM7._AC0] (Node c157b6c8)
Execute Method: [\_TZ_.THM7._TMP] (Node c157b708)
Execute Method: [\_SB_.LID0._PSW] (Node c1564808)
Execute Method: [\_SB_.SLPB._PSW] (Node c1564708)
# next msgs are from 'cardctl eject'
ds: ds_open(socket 0)
ds: ds_open(socket 1)
ds: ds_open(socket 2)
pccard: card ejected from slot 1
PCMCIA: socket e34e1828: *** DANGER *** unable to remove socket power
ds: ds_release(socket 0)
ds: ds_release(socket 1)
# I think these were after the wakeup when the fan turned on.
Execute Method: [\_SB_.PCI0.ISA0.EC0_._Q42] (Node c1572408)
Execute Method: [\_TZ_.THM2._AC0] (Node c157bb48)
Execute Method: [\_TZ_.THM2._TMP] (Node c157bb88)
Execute Method: [\_TZ_.PFN0._ON_] (Node c157a2c8)
Execute Method: [\_TZ_.PFN0._STA] (Node c157a308)
Execute Method: [\_TZ_.THM2._TMP] (Node c157bb88)
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-18 15:58 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>> Please try additional ugly hack
>> 5. in acpi_os_queue_for_execution:
>> if(acpi_in_suspend == YES)
>> do nothing.
>
>Am compiling it. If acpi_in_suspend, I've had it do
>return_ACPI_STATUS(AE_BAD_PARAMETER). Is there a better error code to
>use? I didn't want to use AE_OK, since the caller might think that
>the function will be executed eventually, and might do something silly
>like wait for it to be executed -- and produce another hang. I didn't
>know, but to be safe I wanted to return an error code.
just return AE_OK, because we are hacking. :-)
The only place that could have issue is in acpi_ev_global_lock_handler,
you can add a printk there, then you can know what happened.
>
>> Also, please add acpi_debug_layer=0x10 acpi_debug_leve=0x10 boot
>> option, then you can observe what methods were executed before
>> suspend.
>
>That's in my lilo.conf so all kernels I test use those options. I can
>send you the dmesgs from the suspends without the ugly hack (and will
>send them from the upcoming suspends, with the ugly hack).
Thanks, I'm waiting for that to understand if the hack is clean for
killing unwanted AML methods call.
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-18 15:48 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F84041AC268@pdsmsx403>
> Please try additional ugly hack
> 5. in acpi_os_queue_for_execution:
> if(acpi_in_suspend == YES)
> do nothing.
Am compiling it. If acpi_in_suspend, I've had it do
return_ACPI_STATUS(AE_BAD_PARAMETER). Is there a better error code to
use? I didn't want to use AE_OK, since the caller might think that
the function will be executed eventually, and might do something silly
like wait for it to be executed -- and produce another hang. I didn't
know, but to be safe I wanted to return an error code.
> Also, please add acpi_debug_layer=0x10 acpi_debug_leve=0x10 boot
> option, then you can observe what methods were executed before
> suspend.
That's in my lilo.conf so all kernels I test use those options. I can
send you the dmesgs from the suspends without the ugly hack (and will
send them from the upcoming suspends, with the ugly hack).
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-18 15:10 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>> Hmm, probably, you need to do :
>>
>> 4. in acpi_thermal_notify,
>> if (acpi_in_suspend == YES)
>> do nothing.
>
>I've just tested that. It suspended twice without problem, which made
>me think the problem was solved. But it hung on the third suspend!
I'm NOT surprised about that hung, because kernel thread kacpid
is a kernel worker thread that has flag PF_NOFREEZE, that means
kacpid won't be freezed. I tried to freeze kacpid, but end up with
this conclusion. From my understanding, for safety concern,
kernel worker thread should be freezed. Because, kacpid could
invoke AML methods that we are trying to avoid during suspend.
Please try additional ugly hack
5. in acpi_os_queue_for_execution:
if(acpi_in_suspend == YES)
do nothing.
Also, please add acpi_debug_layer=0x10 acpi_debug_leve=0x10
boot option, then you can observe what methods were executed
before suspend.
Thanks,
Luming
^ permalink raw reply
* Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Sanjoy Mahajan @ 2006-03-18 14:37 UTC (permalink / raw)
To: Yu, Luming
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
In-Reply-To: <3ACA40606221794F80A5670F0AF15F84041AC267@pdsmsx403>
> Hmm, probably, you need to do :
>
> 4. in acpi_thermal_notify,
> if (acpi_in_suspend == YES)
> do nothing.
I've just tested that. It suspended twice without problem, which made
me think the problem was solved. But it hung on the third suspend!
I placed all the source under revision control, since I was spending
more time moving versions of files back and forth (and fixing the
inevitable mistakes, forgetting which version was which) than I would by
figuring out how to use the SCM. So here is its generated diff between
the vanilla kernel (with config file that uses vanilla DSDT) and the
kernel that I just tested.
As you can see, the only change is the short-term fix including item 4
above. It doesn't do anything else, e.g. there's no code to load just
THM0 (which is probably why it hung).
Perhaps the other thermal zones have different problems, or maybe
there's yet another source of thermal method calls?
-Sanjoy
diff -r ac486e270597 -r 03c54e90f75d drivers/acpi/sleep/main.c
--- a/drivers/acpi/sleep/main.c Sat Mar 18 08:35:34 2006 -0500
+++ b/drivers/acpi/sleep/main.c Sat Mar 18 09:08:04 2006 -0500
@@ -19,6 +19,12 @@
#include <acpi/acpi_drivers.h>
#include "sleep.h"
+/* for functions putting machine to sleep to know that we're
+ suspending, so that they can careful about what AML methods they
+ invoke (to avoid trying untested BIOS code paths) */
+int acpi_in_suspend;
+EXPORT_SYMBOL(acpi_in_suspend);
+
u8 sleep_states[ACPI_S_STATE_COUNT];
static struct pm_ops acpi_pm_ops;
@@ -55,6 +61,8 @@ static int acpi_pm_prepare(suspend_state
printk("acpi_pm_prepare does not support %d \n", pm_state);
return -EPERM;
}
+ acpi_os_wait_events_complete(NULL);
+ acpi_in_suspend = TRUE;
return acpi_sleep_prepare(acpi_state);
}
@@ -131,6 +139,7 @@ static int acpi_pm_finish(suspend_state_
{
u32 acpi_state = acpi_suspend_states[pm_state];
+ acpi_in_suspend = FALSE;
acpi_leave_sleep_state(acpi_state);
acpi_disable_wakeup_device(acpi_state);
diff -r ac486e270597 -r 03c54e90f75d drivers/acpi/thermal.c
--- a/drivers/acpi/thermal.c Sat Mar 18 08:35:34 2006 -0500
+++ b/drivers/acpi/thermal.c Sat Mar 18 09:08:04 2006 -0500
@@ -79,6 +79,8 @@ static int tzp;
static int tzp;
module_param(tzp, int, 0);
MODULE_PARM_DESC(tzp, "Thermal zone polling frequency, in 1/10 seconds.\n");
+
+extern int acpi_in_suspend;
static int acpi_thermal_add(struct acpi_device *device);
static int acpi_thermal_remove(struct acpi_device *device, int type);
@@ -683,6 +685,8 @@ static void acpi_thermal_run(unsigned lo
static void acpi_thermal_run(unsigned long data)
{
struct acpi_thermal *tz = (struct acpi_thermal *)data;
+ if (acpi_in_suspend) /* thermal methods might cause a hang */
+ return; /* so don't do them */
if (!tz->zombie)
acpi_os_queue_for_execution(OSD_PRIORITY_GPE,
acpi_thermal_check, (void *)data);
@@ -1224,6 +1228,9 @@ static void acpi_thermal_notify(acpi_han
struct acpi_device *device = NULL;
ACPI_FUNCTION_TRACE("acpi_thermal_notify");
+
+ if (acpi_in_suspend) /* thermal methods might cause a hang */
+ return_VOID; /* so don't do them */
if (!tz)
return_VOID;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox