ACPI-0517: ****Error Method parse/execudion failed

Further Information:

when solving this bug, the one helping me with this problem in ubuntu forums (thx lithorus) suggested it's cause of this change in the kernel:

Changed by Matthew Garrett
.
* libata: Backport of ACPI handling patch.
* ide-acpi: Replaces our old IDE ACPI support code with new and shiney
stuff that should work better on some hardware.

On Mon, 2006-06-05 at 17:56 +0000, Fuctinger wrote:
> Further Information:
>
> when solving this bug, the one helping me with this problem in ubuntu
> forums (thx lithorus) suggested it's cause of this change in the kernel:
>
> Changed by Matthew Garrett
> .
> * libata: Backport of ACPI handling patch.
> * ide-acpi: Replaces our old IDE ACPI support code with new and shiney
> stuff that should work better on some hardware.

But if it worked in the install, it should work on boot. I suspect
something else is happening. Do you get a busybox prompt after this
timeout? If so, please execute this commands:

cat /proc/modules

Also, remove the "quiet usplash" options so you can see screen output
better (do this in grub's menu, using the 'e' option).

Digital photo of the output of kernel messages and output /proc/modules
is acceptable.

Thanks

Hi Ben,
>But if it worked in the install, it should work on boot. I suspect
>something else is happening.

I'm running dapper since flight 4. As said, the kernels before 2.6.15-20 worked fine for me.

Now I did some pics with the camera of my mobile phone. Sry for the rather bad quality but the things should be just readable.

Here they are: http://fucty.fu.ohost.de/acpi_errors/ .

The ACPI errors really don't seem to be the problem here. The problem is the ide, ports already in use message.

I'm assuming your root filesystem is on that controller?

Can you send me the output of "lspci -vv" and "lspci -vvn" after booting the breezy kernel?

On Kernel 2.6.15-20 (the last working):

~$ lspci -vv
0000:00:00.0 Host bridge: Intel Corporation Mobile 915GM/PM/GMS/910GML Express P rocessor to DRAM Controller (rev 03)
        Subsystem: ASUSTeK Computer Inc.: Unknown device 1882
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
        Latency: 0
        Capabilities: <available only to root>

0000:00:01.0 PCI bridge: Intel Corporation Mobile 915GM/PM Express PCI Express R oot Port (rev 03) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 0x04 (16 bytes)
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        I/O behind bridge: 0000b000-0000bfff
        Memory behind bridge: f0000000-fbefffff
        Prefetchable memory behind bridge: d0000000-deffffff
        BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-
        Capabilities: <available only to root>

0000:00:1b.0 0403: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) High De finition Audio Controller (rev 04)
        Subsystem: ASUSTeK Computer Inc.: Unknown device 10c3
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 0x04 (16 bytes)
        Interrupt: pin A routed to IRQ 169
        Region 0: Memory at dfffc000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: <available only to root>

0000:00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) P CI Express Port 1 (rev 04) (prog-if 00 [Normal decode])
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 0x04 (16 bytes)
        Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
        I/O behind bridge: 0000c000-0000cfff
        BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-
        Capabilities: <available only to root>

0000:00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Famil y) USB UHCI #1 (rev 04) (prog-if 00 [UHCI])
        Subsystem: ASUSTeK Computer Inc.: Unknown device 10e7
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step ping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort - <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 217
        Region 4: I/O ports at 9800 [size=32]

0000:00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Famil y) USB UHCI #2 (rev 04) (prog-if 00 [UHCI])
        Subsystem: ASUSTeK Computer Inc.: Unknown device 10e7...

You can find the outputs with root-previleges here: http://fucty.fu.ohost.de/lspci/ .

Kernel as said: 2.6.15-20.30. (last one working without probs)

On Tue, 2006-06-06 at 18:19 +0000, Fuctinger wrote:
> You can find the outputs with root-previleges here:
> http://fucty.fu.ohost.de/lspci/ .
>
> Kernel as said: 2.6.15-20.30. (last one working without probs)

Please attach these to the bug report (instead of pasting them in
comments).

Thanks

Try this, boot with libata.noacpi=1

You can add this option via grub's menu, using the 'e' option.

Unknown boot option 'libata.noacpi=1'.

This will cause the same like booting without acpi=off.

Yes, it will hopefully allow it to boot cleanly like with acpi=off, but without the side-affects of missing a lot of ACPI functionality elsewhere.

Did it in fact fix the problem? I realize that it will report the unknown boot option, but it should apply to the libata module when it gets loaded.

I think you misinterpreted my last post. With libata.noacpi=1 i get the same error like when booting the kernel normally, without the acpi=off option.

Sorry to say, but libata.noacpi=1 does nothing for me when booting. Booting with that option will cause still the 'mounting root file system' and then 'waiting for root file system' like already posted in the report.

I confirme this bug. I've the same laptop (Asus W3V).
This bug occurs both with live cd or install cd, for ubuntu et kubuntu 6.06.
Live cd can boot, but I cannot access to my hard-drive.
Gparted say : "cannot read the content of this filesystem".
Installation is strictly impossible.

using acpi=off at as boot option seem to solve the problem (ubuntu boot correctly and I can see my partition, but not mount them)

With the install cd, installation totally fails. Partition manager load, I can select my installation partition, but cannot format them, or sometime, I can, but partition table is broken during the process.

The same conclusion can be drawn for kubuntu.

It a critical bug !!

I confirme this bug. Installation of ubuntu or kubuntu is strictly impossible

No, it's not impossible, as noted, acpi=off works. What I need to find out is if it's only a portion of the acpi subsystem that is causing it, so we can disable that portion on this type of machine.

If you can reproduce it, please add libata.noacpi=1 to your boot command line and test that for me. Also try acpi=noirq.

acpi=noirq also doesn't work. The only option with what the kernel was able to boot is still acpi=off.

I say again : installation is impossible, even with acpi=off.
With this option, I can boot live cd correctly, partition are correctly seen, but installation fail in ubiquity, etap 5, "mounting_point"...
Sata seems totally broken in dapper with asus hardware! (see other reported bugs on asus)

Perhaps this is related ...

I'm running Dapper (2.6.15-23-386) on a Toshiba A105-S2712. The system boots successfully, but the kernel log keeps posting the subject error message every minute or so. Actually, a group of 6 messages is posted each time, where the last 3 are a repeat of the first 3. They appear to be issued from:

linux-source-2.6.15/drivers/acpi/executer/exmutex.c (line 240)
linux-source-2.6.15/drivers/acpi/parser/psparse.c (line 516)

Here are the messages:

ACPI-0240: *** Error: Cannot release Mutex [MUT1], not acquired
ACPI-0517: *** Error: Method parse/execution failed [\_SB_.RDEC] (Node df7c25c0), AE_AML_MUTEX_NOT_ACQUIRED
ACPI-0517: *** Error: Method parse/execution failed [\_TZ_.TZCL._TMP] (Node df7c97c0), AE_AML_MUTEX_NOT_ACQUIRED

I never encountered this when running Breezy (2.6.12-10-386).

Same error in my laptop: no brand, is a Intel (model 82801G (ICH7 Family), 13").
I have installed the system: if you run Live-CD, you can begin install process, when you put the partitions, you can remove the ext3 partitions, and made new ext3 partitions, the installation process can format and write the SATA partitions and install the Ubuntu Dapper 6.06 linux.

And no more, the problem in the boot is the same. Now I will go to change the menu.lst in the grub: begin with Live-CD Ubuntu-Breeze and mount the partition in sdaX for change the grub file.

In 5 minutes say the result.

All ok, with acpi=off as option of my kernel en the /boot/grub/menu.lst file, the ubuntu go well.

Thanks you.

This is fixed for the next dapper release

The new release 2.6.15-26.44 does not fix this problem. Still have to boot with acpi=off.

I have reproduced this bug on an ASUS s96j with the Intel 945PM chipset.

Using toshiba M70-122 and can confirm since 2.6.15-25 and now 2.6.15-26-44 that it does not boot. Still have to boot acpi=off

Has anyone got a solution to this yet?

I too am experiencing a similar error on a Toshiba Tecra A4 with the nvidia driver. Unable to use the X environment because it is slow and dmesg keeps displaying the error: ACPI-0240: *** Error: Cannot release Mutex [MUT1], not acquired

Must be a problem with ASUS boards. Mine's a P5LD2, and i'm getting the exact same problem. I couldn't even start the liveCD, read thru the errors and it was getting hung up on my DVD writer: "Error 0x01: CD is probably confused".

Booted with "irqpoll" as suggested by the kernel output and was able to get the livecd started and do an install.

Coincidentally, the drive that ubuntu is installed to is on the same IDE channel as the drive. This mobo has 3 channels.. 2 IDE, 2 IDE RAID, and 2 SATA.

Will try ACPI off.

Can you do this:

sudo cat /proc/acpi/dsdt > DSDT.aml

Then attach that file.

acpi=off did not help. tried acpi=off and irqpoll, also didnt work.

How do i get in far enough to attach the file? It's not even getting far enough into the boot process to give me a bash prompt.

First off, let's open a new bug report. Your problem is different than this bug report. Please do that, and provide all info requested so far (version of CD you are booting, details of your hw, etc).

Confirm that this is not fixed with the latest 2.6.15 kernels. I am still required to boot with acpi=off on my ASUS Z96J. 2.6.15-26.46 still exhibits the problem.

I can confirm on:

http://acpi.sourceforge.net/dsdt/view.php

That a lot of ASUS motherboards have a DSDT (ACPI) bug, dealing with interpreter problems.

So the bug is mainly that the hardware is broken.

Some of these motherboards have fixed DSDT's at the above URL. Others can be fixed (or use similar fixed DSDT's from similar ASUS motherboards).

DSDT file for ASUS Z96J with factory BIOS. This should be the same as the ASUS S96J as they are identical models. This is not the same as the original reporter's machine but matches two others (including mine) in this bug report.

To generate this file, I had to boot into a Kubuntu liveCD. Obviously, my laptop will not boot with the installed version of Kubuntu unless I specify ACPI=OFF, in which case I can't grab the DSDT info.

PLEASE IGNORE my addition of linux-restricted modules to the 'affects' list, that was accidental.

I can understand the DSDT problem as that is common (although I think Asus uses the Intel compiler rather than MS). What doesn't make sense to me is that a development Ubuntu kernel prior to Dapper release works and the Edgy 2.6.17 kernel works as well.

Doesn't this point to a kernel issue?

In addition Asus also manufacturers another version of the S96J - the S96F. This model lacks ATI graphics and uses ATA rather than SATA. The S96F works without the acpi=off append.

Also worth noting is that the liveCD for Kubuntu 2006-06 (original release) doesn't seem to exhibit this problem. That is, I can boot up and use that version just fine.

I tried decompiling my DSDT last night. 8 warnings, no errors. I tried fixing the warnings and booting up with a replacement DSDT but got the same problem. I may well have not fixed the warnings or deployed my DSDT file properly. Additionally, seven of the warnings were concerning ignored return values on mutex acquires. It wasn't clear to me how to fix that so I just told it to wait indefinitely.

On Fri, 2006-08-18 at 15:14 +0000, Chris Thompson wrote:
> Also worth noting is that the liveCD for Kubuntu 2006-06 (original
> release) doesn't seem to exhibit this problem. That is, I can boot up
> and use that version just fine.
>
> I tried decompiling my DSDT last night. 8 warnings, no errors. I tried
> fixing the warnings and booting up with a replacement DSDT but got the
> same problem. I may well have not fixed the warnings or deployed my
> DSDT file properly. Additionally, seven of the warnings were concerning
> ignored return values on mutex acquires. It wasn't clear to me how to
> fix that so I just told it to wait indefinitely.

If your DSDT was used, you would see something like this in dmesg:

ACPI: Looking for DSDT in initramfs... found /DSDT.aml ... successfully read 14592 bytes from /DSDT.aml
ACPI: Using customized DSDT
ACPI (tbget-0282): Table [DSDT] replaced by host OS [20060127]

Heh. I'm dropped into a ramdisk because Ubuntu cannot find my root directory, so no access to dmesg. However, I do have access to cmp so I compared DSDT.aml (in the root directory) to the extracted /proc/acpi/dsdl and found that they seem to match.

Bummer. Either the DSDT is not the problem or my fixes weren't sufficient.

I am very new to Linux but have found this bug to be the culpret to all my problems. I am running Ubuntu 2.6.15-26-686 on the ASUS S96J and have found that turning acpi=off worked to get my system up and running. Now to not have all my acpi turned off there is a patch that must be implemented as you have all mentioned. My drive is also on a dual boot with XP but GRUB seems to be letting me boot nicely with them both. My question is how do i implement the patch for the DSDT.aml file?

It's not clear that the bug is actually with acpi. It's the most likely problem but it's not _certain_. My tests at fixing the "low-hanging fruit" with the replacement DSDT.aml weren't productive. However, this was the first time I even looked at a DSDT file so I could well have not done it properly.

I installed Gentoo Linux with kernel 2.6.17-r4 and found that it installed without problem on the Z96J. The minimal install CD came with kernel 2.6.15, I believe (same as what Ubuntu uses). It is not clear to me what this implies but it at least gives hope that Ubuntu could fix or work around the problem.

I got around this problem by installing from the ubuntu livecd, then using the livecd from another distribution (for which the hard drive was recognized) to install a custom-compiled kernel (2.6.17.6 if anyone is interested).

It worked great for me. Though I will be excited when I can use a stock ubuntu kernel.

Also using unbranded intel 82801G (ICH7 Family)

Hope this helps anyone.

I can confirm that pwaller's workaround works.

Steps I took:
Install Kubuntu
Reboot, when I get to the grub screen edit, the kernel command line and add acpi=off to the line
Boot
Kubuntu starts up but freezes every 30 s or so.
Follow the guide at http://www.ubuntuforums.org/showthread.php?t=157560 for installing a new kernel. In my case, 2.6.17.7. Note that on my z96j, I got a lot of warnings showing up in my syslog about asus-acpi not being able to determine the LCD settings. In the end, I modified /usr/src/linux/drivers/acpi.c, function static int get_lcd_state(void) so that the body of the function is simply: return 0; (all other lines removed). This stops the warnings from cluttering up syslog.
Reboot
(no need to specify acpi=off)
Now, you'll find that the ipw3945 driver is now broken. Download the latest from ipw3945.sourceforge.net and follow the instructions on installing it.

And that's it! I haven't played around with the ATI binary driver yet but it'll probably be the same as the ipw3945 driver (i.e. have to install manually).

But it is good to know that whatever bug there was is fixed in later kernels.

There is an easier way to accomplish the same:

* change to edgy repositories
   * sudo nano /etc/apt/sources.list
   * change dapper to edgy in the file
* sudo apt-get update

use Synaptic to upgrade linux-686-smp, linux-image-2.6.17-xx-686, linux-restricted-2.6.17-xx-686

Reboot
* Change sources.list back to Dapper
* sudo apt-get update

Now you're using the edgy's working 17 kernel without breaking stuff (from earlier test with S96J) and staying on Dapper's stable repos as well.

Perfect, I'm writing 10 minutes later without acpi=off in the grub.

But I have the steps:
* change to edgy repositories
   * sudo nano /etc/apt/sources.list
   * change dapper to edgy in the file
* sudo apt-get update
Ok, is the same.

use Synaptic to upgrade or install the next:
linux-386 (is version 2.6.17-9)
linux-image-2.6.17-10-386 (yes, is -10 and for 386, my synaptic say that the 686 is obsolete and only upgrade no install)
linux-restricted-modules-2.6.17-10-386, this install too the
linux-restricted-modules-common

I install all, and now edit the /boot/grub/menu.lst:
sudo nano /boot/grub/menu.lst
and view that the kernel 2.6.17 have NOT the acpi=off option, and the kernel old YES have acpi=off (you can run the old kernel if all fail)

Now reboot and:
* Change sources.list back to Dapper
* sudo apt-get update

Perfect, I have installed GkrellM and I view the battery state perfectly (before without acpi was impossible detect the battery level, in a laptop that is very important)

Thanks you.

I had also the problem: "waiting for root file system...". The problem arised due to kernel upgrade. Ubuntu changed partition names from hda to hdc, so i modificated /boot/grub/menu.lst line:

kernel /boot/vmlinuz-2.6.15-26-386 root=/dev/hda7
to:
kernel /boot/vmlinuz-2.6.15-26-386 root=/dev/hdc7

and i also modificated /etc/fstab on points where hda appears i changed it to hdc.
If you have mounted partitons, leave only names of the directory in /etc/fstab like they was:
example:
/dev/hdc5 /media/hda5 vfat defaults,utf8,umask=007,gid=46 0 1

Also, i do not know what changed, but my Ubuntu partition was on hda3, and now is on hdc7.
You can verify on which partition Ubuntu is by running gparted on Ubuntu Live CD.

That's all.

Me again. The problem occured due to change of IDE cabel of the hard disk and the cd-rom.

Seems lke a candidate for 6.06.2. It doesn't affect enough hardware to warrant 'Critical' though.

The dapper-proposed approach with ABI 50 never really took off, readjusting tags and status for standard SRU workflow.

Bug is complete, but a real fix is not present at this time.

Hi,

Just curious if this is still an issue in the Hardy Heron 8.04 Alpha release? The Hardy Heron Alpha series was recently released which contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha release from http://cdimage.ubuntu.com/releases/hardy/ . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/ . Thanks.

Bug is fixed for me since the edgy kernel. Though I have not tried hardy yet. Can't test the new alpha either because I sold my old computer recently.

Thanks so much for the update. Will mark this Fix Released against the Edgy kernel (linux-source-2.6.17).