Bug 5676 - Error: Method execution failed
Error: Method execution failed
Status: CLOSED PATCH_ALREADY_AVAILABLE
Product: ACPI
Classification: Unclassified
Component: Power-Battery
i386 Linux
: P2 normal
Assigned To: Vladimir Lebedev
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-29 13:53 UTC by Cristian Rigamonti
Modified: 2006-07-13 03:53 UTC (History)
0 users

See Also:
Kernel Version: 2.6.14
Tree: Mainline
Regression: ---


Attachments
acpidump output (71.12 KB, text/plain)
2005-11-29 13:57 UTC, Cristian Rigamonti
Details
lspci and .config (69.22 KB, text/plain)
2005-11-29 14:00 UTC, Cristian Rigamonti
Details
acpidump output, after the event (71.12 KB, text/plain)
2005-12-06 11:58 UTC, Cristian Rigamonti
Details

Description Cristian Rigamonti 2005-11-29 13:53:10 UTC
Most recent kernel where this bug did not occur: 2.6.7
Distribution: Debian unstable
Hardware Environment: Pentium 4, SiS chipset (Asus a2500h notebook)
Software Environment: bash, Icewm window manager

Problem Description: 

Icewm's battery monitor and "acpi -V" can't report the battery status. The
kernel logs the following 3 lines every time someone tries to read the battery
status:

ACPI-0508: *** Error: Method execution failed [\ECWR] (Node
c145ecc0),AE_AML_OPERAND_TYPE
ACPI-0508: *** Error: Method execution failed [\RBAT] (Node c145ec80),
AE_AML_OPERAND_TYPE
ACPI-0508: *** Error: Method execution failed [\_SB_.BAT0._BST] (Node c145da60),
AE_AML_OPERAND_TYPE

or even:

ACPI-0508: *** Error: Method execution failed [\WEIE] (Node deba7ce0),
AE_AML_OPERAND_TYPE
ACPI-0508: *** Error: Method execution failed [\ECWR] (Node deba7c80),
AE_AML_OPERAND_TYPE
ACPI-0508: *** Error: Method execution failed [\RBAT] (Node deba7c40),
AE_AML_OPERAND_TYPE
ACPI-0508: *** Error: Method execution failed [\_SB_.BAT0._BST] (Node deba6a20),
AE_AML_OPERAND_TYPE



Steps to reproduce:

The problem happened twice in 3 days, out of the blue, while the computer was on
AC power. The first time I killed X, restarted it, and had the whole system
freeze (had to shutdown using hardware switch). The second time I killed X and
managed to reboot the system properly (and the problem didn't show up at reboot).
Comment 1 Cristian Rigamonti 2005-11-29 13:57:23 UTC
Created attachment 6715 [details]
acpidump output

Here is the output of acpidump, when the system is working properly (I'll
attach a dump from a "sick" system as soon as the problem shows up again)
Comment 2 Cristian Rigamonti 2005-11-29 14:00:26 UTC
Created attachment 6716 [details]
lspci and .config

Here you are the output of lspci -vv and the .config for the 2.6.14 kernel
Comment 3 Robert Moore 2005-11-30 14:50:56 UTC
Hopefully, you can find a way to consistently reproduce this problem.

There is a potentially very serious bug in the ASL code for this machine, the 
vendor should be notified:

Method (GPLV, 0, NotSerialized)
{
    Acquire (MTXE, 0xFFFF)
    Store (0x59, CMOI)
    Store (0x00, CMOP)
    Store (0x02, CAPC)
    ISMI (0x49)
    Return (CMOD)
    Release (MTXE)
}
dsdt.dsl  1570:                 Release (MTXE)
Warning  2097 -    Statement is unreachable ^

The global mutex is never released by this method.


Comment 4 Cristian Rigamonti 2005-12-06 11:58:46 UTC
Created attachment 6776 [details]
acpidump output, after the event

Here you are the output of acpidump, right after the problem happened
Comment 5 Robert Moore 2005-12-06 13:04:25 UTC
acpidump just dumps the ACPI tables for the machine, these don't change at 
runtime. We need an idea of the sequence of events that results in the failure.
Comment 6 Cristian Rigamonti 2006-01-12 12:05:18 UTC
Some more information (I hope it helps):

- The problem happens also with kernel 2.6.15-rc5

- The problem seems to happen everytime I reach an uptime of about 6 hours;
  I did some analysis on my syslog:

  20060112 problem happened at 20:38:29 (boot at 14:32:46)
  20060110 problem happened at 15:35:46 (boot at 09:24:04)
  20060109 problem happened at 15:35:32 (boot at 09:16:32)
  20060105 problem happened at 16:26:16 (boot at 10:22:02)
  20040105 problem happened at 18:27:42 (boot at 12:17:59)
Comment 7 Vladimir Lebedev 2006-06-21 15:21:01 UTC
Please try the latest stable kernel version (2.6.17.1 is available now) and
the latest mm version (2.6.17-mm1 is available now).
It will give us more information.
Comment 8 Cristian Rigamonti 2006-06-26 12:47:17 UTC
I compiled 2.6.17.1 and this time I get the following errors on the kernel log:

ACPI Warning (utdelete-0378): Large Reference Count (401) in object c145d6b4
[20060127]
ACPI Warning (utdelete-0378): Large Reference Count (401) in object c145d6b4
[20060127]
ACPI Warning (utdelete-0378): Large Reference Count (402) in object c145d6b4
[20060127]
ACPI Warning (utdelete-0378): Large Reference Count (401) in object c145d6b4
[20060127]
ACPI Warning (utdelete-0378): Large Reference Count (401) in object c145d6b4
[20060127]
ACPI Warning (utdelete-0378): Large Reference Count (402) in object c145d6b4
[20060127]

...

ACPI Warning (utdelete-0378): Large Reference Count (406) in object c145d6b4
[20060127]
ACPI Warning (utdelete-0378): Large Reference Count (407) in object c145d6b4
[20060127]
ACPI Warning (utdelete-0378): Large Reference Count (408) in object c145d6b4
[20060127]
ACPI Warning (utdelete-0378): Large Reference Count (407) in object c145d6b4
[20060127]
ACPI Warning (utdelete-0378): Large Reference Count (406) in object c145d6b4
[20060127]
ACPI Warning (utdelete-0378): Large Reference Count (407) in object c145d6b4
[20060127]

... and so on

Some observations:

- The annoying messages start to appear after about 80 times that the 
  battery status is checked (using "acpi -V" or my window manager's facility)

- I get about 40 of the above messages every time the battery status is checked

- If I don't check the battery, nothing bad happens (at least for a couple of 
  hours, I haven't (yet) done further tests)

Please let me know if I can be of any help
Comment 9 Vladimir Lebedev 2006-06-27 01:54:16 UTC

And what about 2.6.17-mm* tree (2.6.17-mm3 is available now)?
Comment 10 Cristian Rigamonti 2006-06-27 12:27:55 UTC
Great. With 2.6.17-mm3 all the errors disappeared: both the "ACPI error" I
reported in my first message and the latest "ACPI warning".

The downside of it (although I think it's unrelated :) is that with 2.6.17-mm3
the keyboard lacks any autorepeat functionality. There is no way to set it with
kbdrate; this happens both in X and in the console, and passing
"atkbd_softrepeat=1" at boot doesn't have any effect. I searched bugzilla about
it but I couldn't find any open bugs, maybe this is due to a configuration error
on my side? I used the same .config I used for 2.6.17.1...
Comment 11 Vladimir Lebedev 2006-06-27 13:51:57 UTC
I have the same problem, but I think it is not ACPI bug; some time is needed 
for investigation. Maybe next kernel mm version will resolve this new problem.
Comment 12 Vladimir Lebedev 2006-06-30 04:45:12 UTC
Try mm4, the problem is resolved - at least on my laptop.
Comment 13 Vladimir Lebedev 2006-07-11 20:11:27 UTC
Do you have any problems on latest kernel versions, or bug can be closed?
 
Thanks.
Vladimir.
Comment 14 Cristian Rigamonti 2006-07-13 02:14:06 UTC
Ok, I tested 2.6.17.4 and I got the same behaviour as with 2.6.17.1:

  ACPI Warning (utdelete-0378): Large Reference Count (401) in object c145d6b4
[20060127]

Then I tested 2.6.18-rc1 and everything was just fine, no more errors even after
8hrs+ uptime (and no more keyboard errors)

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