http://bugzilla.kernel.org/show_bug.cgi?id=9513
[EMAIL PROTECTED] changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |acpi-
| |[EMAIL PROTECTED]
| |et
Status|ASSIGNED |NEEDINFO
Summary|cat |cat
|/proc/acpi/thermal_zone/THRM|/proc/acpi/thermal_zone/THRM
|/temperature hangs |/temperature hangs with new
| |BIOS
------- Comment #7 from [EMAIL PROTECTED] 2007-12-27 21:49 -------
With the working BIOS, please paste the output from
more /proc/acpi/thermal_zone/THRM/* | cat
And for the failing BIOS, please do the same,
except exclude access to the problematic temperature file.
Can you attach the dmesg from the working 1102 BIOS?
I don't see anything special in the 1202 dmesg in attachment
in comment #1, but maybe the original dmesg will give some clues.
It looks like there is a bug in the AML of BIOS 1202.
They re-named CPU0 to be C000, in both the DSDT
and the SSDT, but didn't update the reference to
it from the thermal zone. (which is why iasl created
an External reference to the missing symbol)
I don't know if this causes the hang or not, but
it is certainly curious and it is in the same neck
of the woods...
$ cat DSDT.dsl.diff
5c5
< * Disassembly of DSDT.dat, Fri Dec 28 00:18:35 2007
---
> * Disassembly of DSDT.dat, Fri Dec 28 00:18:48 2007
10c10
< * Length 0x000078E1 (30945)
---
> * Length 0x00007908 (30984)
19a20,21
> External (\_PR_.CPU0)
>
22,23c24,27
< Processor (\_PR.CPU0, 0x00, 0x00000000, 0x00) {}
< Processor (\_PR.CPU1, 0x01, 0x00000000, 0x00) {}
---
> Processor (\_PR.C000, 0x00, 0x00000000, 0x00) {}
> Processor (\_PR.C001, 0x01, 0x00000000, 0x00) {}
> Processor (\_PR.C002, 0x02, 0x00000000, 0x00) {}
> Processor (\_PR.C003, 0x03, 0x00000000, 0x00) {}
2949c2953
< 0x80, // Length
---
> 0x02, // Length
$ cat SSDT.dsl.diff
5c5
< * Disassembly of SSDT.dat, Fri Dec 28 00:18:35 2007
---
> * Disassembly of SSDT.dat, Fri Dec 28 00:18:48 2007
20,21c20,21
< External (\_PR_.CPU1, DeviceObj)
< External (\_PR_.CPU0, DeviceObj)
---
> External (\_PR_.C001, DeviceObj)
> External (\_PR_.C000, DeviceObj)
23c23
< Scope (\_PR.CPU0)
---
> Scope (\_PR.C000)
91c91
< Scope (\_PR.CPU1)
---
> Scope (\_PR.C001)
While in the DSDT, there is still an access to CPU0 in _PSL:
ThermalZone (THRM)
{
Name (_AL0, Package (0x01)
{
FAN
})
Method (_INI, 0, NotSerialized)
{
}
Method (_AC0, 0, NotSerialized)
{
If (Or (PLCY, PLCY, Local7))
{
Return (KELA (TP2H))
}
Else
{
Return (KELA (TP1H))
}
}
Name (_PSL, Package (0x01)
{
\_PR.CPU0
})
The other change was the size of a system IO resource shrunk
from 0x80 to 0x02:
IO (Decode16,
0x0800, // Range Minimum
0x0800, // Range Maximum
0x01, // Alignment
0x02, // Length
I have no idea what this resource is used for.
But it would be interesting if you could correct the DSDT
and boot with a DSDT override to see if either the CPU0
or the resource size changes make the hang go away.
How to Build a custom DSDT into the kernel
------------------------------------------
Get original DSDT:
# cp /proc/acpi/dsdt DSDT
or
# acpidump > acpidump.out
$ acpixtract DSDT acpidump > DSDT.dat
Disassemble it
$ iasl -d DSDT.dat
Make your changes:
$ vi DSDT.dsl
Build it:
$ iasl -tc DSDT.dsl
Put it where the kernel build can include it:
$ cp DSDT.hex $SRC/include/
Add this to the kernel .config:
CONFIG_STANDALONE=n
CONFIG_ACPI_CUSTOM_DSDT=y
CONFIG_ACPI_CUSTOM_DSDT_FILE="DSDT.hex"
Make the kernel and off you go!
You should see in dmesg:
Table [DSDT] replaced by host OS
--
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
acpi-bugzilla mailing list
acpi-bugzilla@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
