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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
