>> 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
> 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
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