Bug 5727 - method execution failures on Toshiba Satellite
Summary: method execution failures on Toshiba Satellite
Status: CLOSED INVALID
Alias: None
Product: ACPI
Classification: Unclassified
Component: ACPICA-Core (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Robert Moore
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-12-11 09:34 UTC by Jesse Barnes
Modified: 2006-09-28 13:19 UTC (History)
0 users

See Also:
Kernel Version: 2.6.15-rc5
Subsystem:
Regression: ---
Bisected commit-id:


Attachments
acpidump output (132.90 KB, text/plain)
2005-12-14 20:40 UTC, Jesse Barnes
Details

Description Jesse Barnes 2005-12-11 09:34:13 UTC
Most recent kernel where this bug did not occur: I think it's always occurred. 
Distribution: Fedora Devel (rawhide) 
Hardware Environment: Toshiba Satellite M45 
 
Problem Description: 
I regularly get odd looking, ACPI related messages in my system log.  I'm 
running Fedora Devel, so my kernel fairly closely matches Linus' tree.  Here's 
a snippet of some of the error messages I'm getting out of a 2.6.15-rc5ish FC 
devel kernel: 
 
    ACPI-0258: *** Error: Thread 9BD cannot release Mutex [MUT1] acquired by 
thread 845 
    ACPI-0508: *** Error: Method execution failed [\_SB_.RDEC] (Node 
df6ca4b4), AE_AML_NOT_OWNER 
    ACPI-0508: *** Error: Method execution failed [\_SB_.LID0._LID] (Node 
df6e04e0), AE_AML_NOT_OWNER 
    ACPI-0258: *** Error: Thread 9BD cannot release Mutex [MUT1] acquired by 
thread 9B1 
    ACPI-0508: *** Error: Method execution failed [\_SB_.RDEC] (Node 
df6ca4b4), AE_AML_NOT_OWNER 
    ACPI-0508: *** Error: Method execution failed [\_SB_.LID0._LID] (Node 
df6e04e0), AE_AML_NOT_OWNER 
    ACPI-0258: *** Error: Thread 9BD cannot release Mutex [MUT1] acquired by 
thread 845 
    ACPI-0508: *** Error: Method execution failed [\_SB_.RDEC] (Node 
df6ca4b4), AE_AML_NOT_OWNER 
    ACPI-0508: *** Error: Method execution failed [\_SB_.LID0._LID] (Node 
df6e04e0), AE_AML_NOT_OWNER 
    ACPI-0258: *** Error: Thread 9BD cannot release Mutex [MUT1] acquired by 
thread 9B1 
    ACPI-0508: *** Error: Method execution failed [\_SB_.RDEC] (Node 
df6ca4b4), AE_AML_NOT_OWNER 
    ACPI-0508: *** Error: Method execution failed [\_SB_.LID0._LID] (Node 
df6e04e0), AE_AML_NOT_OWNER 
    ACPI-0258: *** Error: Thread 9 cannot release Mutex [MUT1] acquired by 
thread 9BD 
    ACPI-0508: *** Error: Method execution failed [\_SB_.RDEC] (Node 
df6ca4b4), AE_AML_NOT_OWNER 
    ACPI-0508: *** Error: Method execution failed [\_SB_.PCI0.LPCB.EC0_._Q13] 
(Node df6c72fc), AE_AML_NOT_OWNER 
    ACPI-0258: *** Error: Thread 9BD cannot release Mutex [MUT1] acquired by 
thread 845 
    ACPI-0508: *** Error: Method execution failed [\_SB_.RDEC] (Node 
df6ca4b4), AE_AML_NOT_OWNER 
    ACPI-0508: *** Error: Method execution failed [\_SB_.LID0._LID] (Node 
df6e04e0), AE_AML_NOT_OWNER 
    ACPI-0258: *** Error: Thread 9BD cannot release Mutex [MUT1] acquired by 
thread 845 
    ACPI-0508: *** Error: Method execution failed [\_SB_.RDEC] (Node 
df6ca4b4), AE_AML_NOT_OWNER 
    ACPI-0508: *** Error: Method execution failed [\_SB_.LID0._LID] (Node 
df6e04e0), AE_AML_NOT_OWNER 
ipw2200: Unknown notification: subtype=40,flags=0xa0,size=40 
    ACPI-0240: *** Error: Cannot release Mutex [MUT1], not acquired 
    ACPI-0508: *** Error: Method execution failed [\_SB_.RDEC] (Node 
df6ca4b4), AE_AML_MUTEX_NOT_ACQUIRED 
    ACPI-0508: *** Error: Method execution failed [\_SB_.BAT1._BST] (Node 
df6e05bc), AE_AML_MUTEX_NOT_ACQUIRED 
    ACPI-0258: *** Error: Thread 9BD cannot release Mutex [MUT1] acquired by 
thread 9B1 
    ACPI-0508: *** Error: Method execution failed [\_SB_.RDEC] (Node 
df6ca4b4), AE_AML_NOT_OWNER 
    ACPI-0508: *** Error: Method execution failed [\_SB_.LID0._LID] (Node 
df6e04e0), AE_AML_NOT_OWNER 
    ACPI-0258: *** Error: Thread 9BD cannot release Mutex [MUT1] acquired by 
thread 9B1 
    ACPI-0508: *** Error: Method execution failed [\_SB_.RDEC] (Node 
df6ca4b4), AE_AML_NOT_OWNER 
    ACPI-0508: *** Error: Method execution failed [\_SB_.LID0._LID] (Node 
df6e04e0), AE_AML_NOT_OWNER
Comment 1 Robert Moore 2005-12-12 12:52:39 UTC
Please post the acpidump for this machine, thanks.
Comment 2 Jesse Barnes 2005-12-14 20:40:15 UTC
Created attachment 6830 [details]
acpidump output
Comment 3 Robert Moore 2005-12-16 14:44:02 UTC
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)
        }
Comment 4 Jesse Barnes 2005-12-16 16:35:54 UTC
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. 

Note You need to log in before you can comment on or make changes to this bug.