Re: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]

[Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk>]

The following tests all have acpi_evaluate_integer() hacked to return
_TMP=27C.

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

device->pnp is a struct and I couldn't figure out how to printk it, so
I just printk'ed device->pnp.bus_id (most of its other elements aren't
initialized by then anyway):

diff -r ac486e270597 -r 8b088512dd1d drivers/acpi/thermal.c
--- a/drivers/acpi/thermal.c	Sat Mar 18 08:35:34 2006 -0500
+++ b/drivers/acpi/thermal.c	Tue Mar 21 11:32:31 2006 -0500
@@ -1324,6 +1324,7 @@ static int acpi_thermal_add(struct acpi_
 
 	if (!device)
 		return_VALUE(-EINVAL);
+	printk(KERN_INFO PREFIX "pnp.bus_id=0x%x\n", (u32) device->pnp.bus_id);
 
 	tz = kmalloc(sizeof(struct acpi_thermal), GFP_KERNEL);
 	if (!tz)

It produced nothing surprising:

ACPI: pnp.bus_id=0xe3ed7830
ACPI: pnp.bus_id=0xe3ed7430
ACPI: pnp.bus_id=0xe3ed7030
ACPI: pnp.bus_id=0xe3ed8c30
ACPI: pnp.bus_id=0xe3ed4030

for THM0,2,6,7, and _TZ.

So I still don't know why getting rid of THM2 in the kernel causes the
panic.

But while I had this kernel booted, I tried a few sleep cycles, and it
hung on the second one as expected (it's just the vanilla kernel&DSDT
with acpi_evaluate_integer() hacked to return _TMP=27C).

>> THM6			Hangs (4th cycle)
> Is it still hang at SMPI?

It looked like the usual hang, but I had debug_{layer,level}=0x10.  I
increased debug_layer to 0xFFFFFFFF it to see the function traces.
However, the hang didn't occur even after 15 cycles. So I rebooted with
debug_layer=0x10 and still couldn't reproduce the hang even after 12
cycles.  But the same kernel hung yesterday after 4 cycles [I save all
the kernels tagged by their revision hash], so I don't know what to
think about THM6.

>> THM2			"kernel panic! attempted to kill init"

> I guess, if you fake DSDT by completely removing THM2 you won't see
> this.

Right, it booted fine when I removed THM2 from the DSDT instead of from
the kernel.

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

I tried the kernel with THM2 taken out of the DSDT, and it was fine (so
the total change was that plus _TMP faked in acpi_evaluate_integer()).

-Sanjoy

`A society of sheep must in time beget a government of wolves.'
   - Bertrand de Jouvenal