18 seconds ACPI delay while booting due to DSDT FSJ AMILO Xi 1554

Attached is the bootchart

Same problem for me, Laptop is again an FJS Amilo, this time the Xi1526, more or less the same, but with Nvidia Graphics.

I reported the problem in the ubuntuusers.de forum twice, but noone could really help.

When booting with acpi=off the timeout ist only about 9 seconds, but i didn't manage to find out something else.

Attached: my bootchart.

I have the same problem on my Notebook (FJS Amilo Xi 1546, Core 2 Duo T5500, 1 GB RAM, 17", ATI Mobility Radeon X1800).

After this line is shown there happens absolutely nothing for 18:
[ 17.279676] ACPI: EC: GPE=0x19, ports=0x66, 0x62

I have testet kernel 2.6.18.2 (32-bit) and kernel 2.6.22.14.
The behavior was always the same.

After showing the following line the system hangs for 18 seconds without any activity:
[ 35.259166] ACPI: EC: GPE=0x19, ports=0x66, 0x62

Same problem.
Fujitsu Siemens Amilo XI1526 intel core 2 duo t5500 nvidia fx 5600

attached bootchart

dmesg

maybe a bit off-topic, but i am thinking about buying an amilo xi 1554, too, so i wonder wether the ati graphics driver works well with all 3d stuff?

cheers, kurt

the problem is the DSDT:

line 4191: Sleep (0x2710) //--> 10 seconds
line 4211: Sleep (0x1F40) //--> 8 seconds
                                                  --> = 18 seconds total

ok, this is a DSDT for Amilo Xi1526.

..bye bye 18 seconds delay... :-)

@bassl: can this also be used for my FSJ AMILO Xi 1554 notebook?
If not, what are the steps to create my own fixed *.dsl file for the Xi1554?
And how do I apply the *.dsl file to my system?
Thanks in advance!

sudo apt-get install iasl #install iasl compiler
cat /proc/acpi/dsdt > dsdt.dat #extract your current dsdt to a file
iasl -d dsdt.dat #disassemble the dsdt,this will create a file dsdt.dsl
iasl -tc dsdt.dsl #recompile the dsdt and check possible error/warning

if you see some error/warning, edit dsdt.dsl with any text editor
search on google and http://www.cpqlinux.com/acpi-howto.html#fix_broken_dsdt your error/warnig and fix it.

for the 18sec delay:
open in a text editor your dsdt.dsl and search the function called "Sleep" in the section "Device (EC0)":
Sleep (0x2710) change the value to (0x3E8)
Sleep (0x1F40) change the value to (0x3E8)

recompile dsdt again.

install with initramfs:
sudo cp dsdt.aml /etc/initramfs-tools/DSDT.aml
sudo mkinitramfs -o /boot/initrd.img-`uname -r`
reboot

good luck

Thanks for the instructions. Everything went fine, and now my boot time is 16 sec shorter.
That's absolutely great. This is even better news than the release of hardy.
Thanks a lot, you made my day!

Also thanks from my side. That helped a lot!

The same problem is reported on https://bugs.launchpad.net/ubuntu/+source/linux/+bug/263140.

The solution reported by bassl works great for me.

Thanks bassl, that fix also worked for me (on 64bit Jaunty 2.6.28-14-generic kernel).

Anyone having a fujitsu siemens Amilo Pi 1536 and fixed their DSDT? Or know how to fix the warning "not all control paths return a value (nvif)"?

Anyone know how to apply the fix bassl described to Fedora?

Loading custom DSDT from Karmic will be impossible without recompiling the kernel. The patch that gives the functionality is dropped. Anybody with ideas about a fix?

Why Vista has no problems with that if it is in fact bad dsdt from the manufacturer?
Can/Will the problem be solved in the kernel?

This is strange. I have a different kernel version installed than the one shipped with Jaunty (installed kernel 2.6.29.1 and 2.6.30.8 from kernel.ubuntu.com/~kernel-ppa/mainline) and those are not reducing the boot lag with this change. The stock kernel however, reduces my boot from 18 seconds delay to a mere 2 seconds delay. I wonder why the Ubuntu kernel shipped with Jaunty picks it up and the others don't. Guess I have to stick to the stock kernel for now. Really wished I could load a different kernel.

Tested a bit more. I have to boot a different kernel than the stock one, because my wireless just won't connect to my access point with the stock one. This really sucks. I'm gonna try the Karmic kernel, that should give me my wireless back and hopefully accept the 'patch'. Else I'm forced with the 18 seconds delay :(.

The stock kernel for 9.04 has the patch - I believe it was added by Ben Collins.
The mainline kernel has dropped the patch for some time now.
The kernel for 9.10 will be droppind the patch.
See https://bugs.launchpad.net/ubuntu/+source/linux/+bug/395239 for more info.

Two options:
1. This to be fixed in the kernel (if it's possible) - we know that vista does not have the problem.
2. Locally compiling kernel with the patch (inconvenient)

I'll try to connect with bassl or Ben Collins to check if option 1 is possible. If not, someone should mark the bug as "Won't fix" and make a PPA with the patched kernel. But I won't have the time to do it until the end of next week.

With the stock kernel from Jaunty, I meant the current kernel in the repo (currently 2.6.28.15-38). It does not have this patch, I had to add it myself as per Bassl in comment #10. No other kernel picks it up, so there must be something in 2.6.28 that's not in newer kernels.
Is there anything I can test or check or whatever to make this working properly for me?

The method described by Bassl in comment 10 works only if the kernel can use custom DSDT. The kernel for 9.04 was patched to do it (this functionality is not supported in the mainline kernel). Newer kernels are generally not patched according to bug 395239. You must find the patch that is needed (I haven't searched for it), patch a kernel source, compile it, install it and then use the method proposed by Bassl.

The problem is that our computers are shipped with buggy DSDT and we must change it manually. We can do it only if the kernel we are using supports custom DSDT. But even if the kernel supports changing the DSDT the USER must change it.

Generally that is a problem that can not be solved in the kernel in a way that works without the user creating the new DSDT. But why there is no delay on Vista?

Windows XP doesn't show this delay either, and an older kernel doesn't seem to be affected by this, as I've stated in the duplicate bug.

OK, It would be better to find where the delay was introduced before contacting the developers (as it's something very old I doubt that it would be that easy to fix, so speed doesn't really matter). Can to tell me the version of a kernel for which you think custom DSDT are not needed, so I can check and confirm. I hope you can cut the list down to less than five - I don't want to spend a day rebooting ;) On Friday I will have the time to check, and I will be very happy if you can check it also.

Upstream has decided that modifiying the DSDT is too risky in general to be something enabled in commonly shipped kernels, as it is possible to write DSDTs which damage your hardware. It is therefore unlikely we will resurect this DSDT patch for Karmic or later.

The upstream approach is to detect the bad machines and to work round the bad entries in the DSDT at DSDT execute time. In this case that might include detecting and 'adjusting' the sleeps which are faulty as we execute them. In order to achieve this we would need to ensure we have correctly identified these sleeps. At the URL below is a kernel (kernels will be there shortly) with a debug patch applied which atttempts to detect these sleeps and eliminate them (note this is specific to the sleeps for this machine):

    http://people.canonical.com/~apw/lp100110-karmic/

Could those of you who are affected try the kernel below and report whether it helps or not. In either case please include dmesg output from the boot with this kernel. Thanks!

Thank you, You will have my report by 10 pm GMT.

Ok, there was a flaw in the apw1 kernels, so make sure you test the apw2 kernels which are the only ones now at the URL above. Sorry about that.

It's working for me.

I'm uploading the dmesg file.

At line 218-220 this time there is no 18 seconds delay.
Thank you.

Working fine for me too, no more 18 seconds delay. This is a big improvement. I especially like this part, where it used to hang for 18 seconds (line 229):

[ 0.168507] ACPI: BIOS _OSI(Linux) query ignored
[ 0.169429] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 0.176115] APW: ACPI delay of major proportions 10000 ms
[ 0.176165] APW: ACPI zapping delay to 1000 ms
[ 1.176079] APW: ACPI delay of major proportions 8000 ms
[ 1.176126] APW: ACPI zapping delay to 1000 ms
[ 2.176061] ACPI: Interpreter enabled
[ 2.176114] ACPI: (supports S0 S3 S4 S5)

It's also nice that wireless works flawlessly too, without the need of backported modules, like I needed with 2.6.28.

Just noticed that on the second reboot some messages were printed to screen before usplash.
Well it's the debug messages and probably that's normal but on the web page for 9.10beta was stated that we must report such issues.

[ 0.320116] APW: ACPI delay of major proportions 10000 ms
[ 0.320162] APW: ACPI zapping delay to 1000 ms
[ 1.320075] APW: ACPI delay of major proportions 8000 ms
[ 1.320088] APW: ACPI zapping delay to 1000 ms

I checked the kernel from the SuSE system (the one I mentioned in the duplicate bug) and it's version 2.6.16.60-0.21-default. That's the one that I'm sure has no boot delay. However, it was booted from CD in a live environment I think and it might not have all the ACPI in it like a full install would have. I don't have the hard drive space, nor the physical disc to install and test with that kernel. Maybe one of the kernel devs can get his/her hands on the kernel configuration. The kernel belongs to SuSE Enterprise Dekstop 10.

If the current 'fix' is used instead, would it matter much if the delay could be brought back to a minimum, like maybe 250 ms or lower? I find 1000 ms still quite a long wait considering how long systems that don't have this faulty DSDT wait (the don't at all or very short).

I'll test 2.6.16 and 2.6.17 vanilla this evening and report.

@Sasquatch -- I chose the 1s delay as it matched the tested and known working subsitution as applied to the DSDT for some considerable time in previous releases.

Ah, well, I don't think it would do much harm if the wait is reduced more. I'll try with a lower value, of 100 ms and report back for my 2.6.28 kernel.

I didn't notice anything strange or not functioning properly. All it did was put the next entry on my boot 200 ms later. I don't see any harm that can be done if you change the sleep from 1000 ms to 100 ms.

@Sasquatch -- thanks for that testing ... I'll have to think about that as its a riskier change.

Ok, now to look to make a proper fix for this. I can't simply bodge all ACPI sleeps as was done in the last patch. We need to limit this munging to your broken laptops. To do that I need to know what they call themselves. So could those of you affected by this issue please add your dmidecode information to this bug and please make sure you tell me what you think your laptop is called too from a humans point of view. Thanks!

human name: Fujitsu Siemens Amilo XI 1526
System Information
 Manufacturer: FUJITSU SIEMENS
 Product Name: AMILO Xi 1526
 Version: Not Applicable
 Serial Number: 72015157
 UUID: 80DD4F76-0C65-0010-9F47-AC84E27654C6
 Wake-up Type: Power Switch
 SKU Number: Not Specified
 Family: Not Specified

Also in the attachment.

Any explanation why this is not observed on 2.6.16? I doubt that older kernels just skipped DSDT waits.

System Information
 Manufacturer: FUJITSU SIEMENS
 Product Name: AMILO Pi 1536
 Version: Not Applicable
 Serial Number: 531171D1
 UUID: 00D0E151-CD63-0010-9302-C8913D38C486
 Wake-up Type: Power Switch
 SKU Number: Not Specified
 Family: Not Specified

Aka Fujitsu-Siemens Amilo Pi1536.

Manufacturer: FUJITSU SIEMENS
Product Name: AMILO Pi 1556

I'm on Arch but the same problem. It also occurred when I was using Ubuntu

please attach the acpidump output, with the latest pmtools at http://www.lesswatts.org/projects/acpi/utilities.php

Here is my acpidump output.

@Krastanov -- most likely we didn't use the parts of the DSDT with these errant waits during innitialisation. Likely we didn't initialise the EC 'correctly' back then.

I noticed one thing this morning when I resumed my laptop from hibernate. I wasn't able to play any audio file to produce sound coming out of my speakers. A reboot was needed to get my audio back. I had the 'fixed' kernel loaded and Audacious2 would simply hang when playing a file, mplayer showed playback for audio from command line, video had no audio and speakertest would hang at or after the first channel.
Maybe it was something else on my system that happened before I sent it to hibernate, I didn't look for a cause and simply rebooted to the 2.6.28 kernel. I'll keep an eye on it and test some in the weekend.
I'm using ALSA as sound system, don't have PulseAudio or anything else installed.

There is indeed a problem with audio and the 'fixed' kernel. I get this in my logs, and some other message spammed all across my display when going to hibernate. It's gone before I can write it down unfortunately.

Oct 9 09:00:15 Chii kernel: [ 5281.588024] hda_intel: azx_get_response timeout, switching to single_cmd mode: last cmd=0x10170500

Here is my acpidump

I have no problems with hibernation or suspend. And no messages on the screen, neither on dmesg. But that is on Amilo xi 1526. (The "fixed" kernel it the one with 1 second delay or the one with 0.1 seconds delay? I'm reporting about the one with 1s.)

acpidump of FSC Amilo Pi 1556

With 'fixed' kernel I mean the 2.6.31 for karmic that was posted here, not the Jaunty kernel we can modify with DSDT. My laptop has a Realtek HD audio card. I don't have issues going to or resuming from hibernate, the only problem I'm having is that after the second resume my audio fails. I can still use audio after the first resume, but with that one I already get those errors. I'll try to get the spam message noted.

hda - intel: spurious response 0x0 : 0x1, last cmd=0x10b...

That last cmd value changes with every entry. I get it 73 times in one second, then it stops and shows the line I mentioned above. I tried restarting a few services (alsa-utils, hal and udev) but it didn't bring back any audio. Mplayer seems to play, but it doesn't return the shell when it's done, I have to ctrl+c twice to get my terminal back.

I couldn't remove the modules either for my sound card, they were all in use. Will try with the Jaunty kernel now.

The modules are in use with the Jaunty kernel too, no shock there. However, I did notice a big difference in the amount of modules loaded between the two kernels. 2.6.31 has a few additional modules for my sound card (and probably modem too).

Modules loaded in 2.6.28:
snd_hda_intel
snd_pcm
snd
snd_page_alloc

And the modules in 2.6.31:
snd_hda_codec_realtek
snd_hda_codec_si3054
snd_hda_intel
snd_hda_codec
snd_hwdep
snd_pcm
snd
snd_page_alloc

I think the problem lies there, in the additional modules. Might be a new bug, don't know if it's reported already, or something that's due to my config (Karmic kernel on Jaunty). I will leave it be for now and submit a report if it still happens when I'm on full Karmic.

very nice, working fine me too!
now only 2 second delay without recompile the kernel.

only one thing, I tried for some month with 1s (total) sleep in a custom kernel without any problem.
maybe we can decrease again (or set to zero) the sleep.

Affects my Alienware brand notebook, which might be a re-branded Fujitsu.

Alienware Area-51 m5500i-R3

System Information
 Manufacturer: ALIENWARE
 Product Name: m5500i-R3
 Version: plicable
 Serial Number: 1234Aa782e
 UUID: 004D721C-3565-0010-881F-BD84891041C9
 Wake-up Type: Power Switch
 SKU Number: Not Specified
 Family: Not Specified

Attached is
- dmesg from the stock Karmic kernel (2.6.31-11-generic)
- dmesg from Mr. Whitcroft's kernel
- output of acpidump

Patched kernel boots with no obvious problems. I'll try hibernating and resuming a few times and see if sound still works, since I also have a Realtek HDA sound device.

Manufacturer: FUJITSU SIEMENS
Product Name: AMILO Xi 1554

My sound stops working after hibernate, but this also happens with the stock 2.6.31-11-generic kernel. I believe it's a separate bug.

That's what I thought. The new modules are the source of the problem, not the ACPI changes.

I haven't tested the new kernel and haven't updated to 9.10 yet because I can't afford to be without my machine at present, however the previous DSDT fix worked for me.

My machine is a `Rock Pegasus 665'. Its physically identical to the Alienware m5500 and some of the Fujitsus. I believe these are Uniwill 255 based machines.

Attached dmidecode and acpidump.

Thanks.

I'm seeing this too with a HP Pavilion zv5308ea. Didn't clock it but the delay when reading "Starting up" is 10s+ and the problem wasn't there in Jaunty. Attatching output of dmidecode, acpidump and bootchart.

Glad that you guys are on top of this and glad I could help with something :)

could anyone help me on how to apply this patch??

Does the bootflag use_acpi_timer_override do anything for you? Is it safe to use?

Hi all !
I'm on Fujitsu-Siemens Amilo XI 1526 and i've the same problem of delay...
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/100110/comments/10 doesn't work and i can't execute the patch...
A new solution found ?
Thanks (sorry for bad english)

Will this fix be available in upstream? In kernel mainline?

Need more informations ? Bootchart on Lucid ?
Thx

Up ?

Since windows does not have this 18 second delay at boot, I would suspect that their implementation of the AML Sleep() operator puts a cap on the amount of sleep time allowed. Perhaps ACPICA should do the same; maybe a configurable amount of maximum time?

As original submitter of this bug, I was very happy with the solution using a custom DSDT.
With the usage of custom DSDTs being turned off in the kernel, now I have 18 seconds time with every boot to think about the problem that some guys take wise decision about problems they are not affected of and don't care about the drawbacks that others may suffer :-(
I hope there will be a solution to this problem soon...

Maybe in Maverick... I hope soon too..

Stay "In Progress" ?

I can't understand that more than 3 years later this bug still exists ...

This problem should be addressed by the following upstream patch which is contained in Maverick (2.6.35):

commit 9cbfa18e8a7b34a32eddbd914a07f085962f50a8
Author: Bob Moore <email address hidden>
Date: Wed May 26 11:22:41 2010 +0800

    ACPICA: Limit maximum time for Sleep() operator

    To prevent accidental deep sleeps, limit the maximum time that
    Sleep() will sleep. Configurable, default maximum is two seconds.
    ACPICA bugzilla 854.

    http://www.acpica.org/bugzilla/show_bug.cgi?id=854

If we can confirm this, we may also try to work with Robert to submit this fix to stable.

Maybe I miss something, but with the last kernel 2.6.35.4 from kernel.org the sleep appear again.

This bug is still present in Maverick (at least on my Amilo Pi 1536 with kernel 2.6.35-22-generic). What is the current state of things with it? Is there any working workaround for Maverick?

I confirm that I also see this bug in Maverick, occuring on a macbook pro. Would anyone like to comment if I should start a new bug report, or if this one will be revisited by the developers?

It's almost impossible that this is the same bug because apple produce their own laptops.

But to check - see comment 10 and look for the very same hex values. Do not try the fix - it does not work without modified kernels.
If there are no such values the problem is different. File a new bug report but do post a link to this one here.

@ANYONE

what's happen to this bug?

We are destined to recompile the kernel everytime to get a decent boot?
(especially for me that i've upgrade my notebook with an ssd disk...)

this is a bad perspective..

This bug was nominated against a series that is no longer supported, ie karmic. The bug task representing the karmic nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Andreas Schiffer, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in the development release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. As well, please comment on which kernel version specifically you tested.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream', and comment as to why specifically you were unable to test it.

Please let us know your results. Thanks in advance.

I was asked to review this bug to see if it still exists.
(By the way I experience this strategy repeatedly: do nothing on a bug, wait if time helps, and then ask the submitter to reproduce it... Great way of handling bugs...)

This bug is more than five years old, and I became used to living with this bug... Anyway, the notebook that I experienced this bug on was broken three months ago.
So as I don't have that notebook any longer, I can't reproduce the defect anymore.
(Seems like the strategy mentioned above has worked out again :) )

Andreas Schiffer, just to be clear, I am a volunteer who did not even know your bug existed until I commented on it. Despite this, this bug report is being closed due to your last comment regarding you no longer having the hardware. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.