This is the important part of the trace:
> 4e10 Store
> 4e11 \\_SB_.PCI0.LPCB.H_EC.CTMP
> locking
> field: aml_rwgas bitpos 1536 bpos 0 blen 8,flags 0x11
> read 03 000000c0 0008 [\\_SB_.PCI0.LPCB.H_EC.ECR_]
> gasio rd: 3 0xc0 1 1 851728760
> aml_bufcpy: 0x90
> unlocking
> 4e28 Local0
> 4e29 If
> 4e2b LNotEqual
> 4e2d Local0
> 4e2e 0xff
> 4e30 Return
> 4e31 Add
> 4e32 0x0aac
> 4e35 Multiply
> 4e36 Local0
> 4e37 0x0a
> acpitz0: critical temperature exceeded 144C, shutting down
What happens is that we read 8 bits from bit-position (bitpos) 1536
from the ECR field from the EC and then store it in Local0.
What we read from there is 0x90, which is 144 in decimal.
The revelant AML code looks like this:
Store (\_SB.PCI0.LPCB.H_EC.CTMP, Local0)
If (LNotEqual (Local0, 0xFF))
Return (Add (0x0AAC, Multiply (Local0, 0x0A)))
CTMP is supposed to keep the temperature in Celsius, thus it needs a
conversion to Kelvin.
So what this does is check if the value it just read is different from
0xFF and if so it converts the value to Kelvin degrees and returns them
to the upper layers as required by the ACPI spec.
Local0 * 10 + 2732 => 4172 which is 417.2K as dictated by the spec.
Then userland transforms it back to Celsius and freaks out.
The field, from your AML dump, looks like the following:
Field (ECR, ByteAcc, Lock, Preserve) {
[...]
Offset (0xC0),
CTMP, 8,
[...] }
Offset 0xC0 is the offset in bytes from the beginning of the field and
it's 192 in decimal which translates to 192 * 4 = 1536 bits.
This matches the bitpos from which the temperature was read, so the
position is correct.
Thus the bad news is that the bug is not a bitpos parsing bug...
This happens only with OpenBSD? Linux or Windows runs fine, right?
