Bug 5727
Summary: | method execution failures on Toshiba Satellite | ||
---|---|---|---|
Product: | ACPI | Reporter: | Jesse Barnes (jbarnes) |
Component: | ACPICA-Core | Assignee: | Robert Moore (Robert.Moore) |
Status: | CLOSED INVALID | ||
Severity: | normal | ||
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.15-rc5 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | acpidump output |
Description
Jesse Barnes
2005-12-11 09:34:13 UTC
Please post the acpidump for this machine, thanks. Created attachment 6830 [details]
acpidump output
There appears to be a bug in the BIOS ASL Code where a timeout could happen on an Acquire, but the code does not check for this and just blindly releases the mutex even if it was not acquired, causing the exception. The problem is that the 0x0FFF timeout should probably be 0xFFFF which is WAIT_FOREVER (looks like a typo). You could fix this and override the DSDT. Note, there are two cases of this in the ASL, one is shown below. Also, you might try setting the global acpi_serialized flag to disallow method reentrancy. The BIOS vendor should be notified of this problem. This is not a bug in ACPICA or any ACPI related code. Method (RDEC, 1, NotSerialized) { Acquire (\_SB.PCI0.LPCB.EC0.MUT1, 0x0FFF) If (BCMD) { Sleep (0x02) } Store (Arg0, BINX) Store (0x01, BCMD) Sleep (0x01) If (BCMD) { Sleep (0x02) } Store (BDAT, Local0) Release (\_SB.PCI0.LPCB.EC0.MUT1) Return (Local0) } Thanks, I'll see if Toshiba has an update for my model. I'm not too keen on overwriting my DSDT though, so if they don't have one I'll just live with the warnings I guess. |