>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);
>
>
-
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]
