[Hardy] ACPI Embedded Controller (EC) stops boot when kernel boot 'quiet' option is enabled or AC power is connected

[Vladimir Meremyanin]

Installed Gutsy, then changed repositories to Hardy's ones, and now have 3 kernels:

linux-image-2.6.22-14-generic - from gutsy, boots fine, X can't find nvidia drivers (since they are for new kernels), but it's ok.

Now the troubles:
linux-image-2.6.24-7-386 (2.6.24-7.12) - hangs, in different places, but with a lots of acpi-related errors
linux-image-2.6.24-7-generic (2.6.24-7.12) - completely hangs with 2 lines on screen:

ACPI: EC: acpi_ec_wait timeout, status=32, expect_event=1
ACPI: EC: read timeout, command=128

only holding the power button works after these messages.

Both kernels work fine in recovery mode! the only inconvenience is the need to select 'boot normally' :)

[Vladimir Meremyanin (v-stiff)]

upgraded to 2.6.24-8-generic, and got same troubles.

[Vladimir Meremyanin (v-stiff)]

Removed battery and unplugged power cord for a few seconds, and 2.6.24-8-generic started without any problems!

I think it should handle somehow 'wrong' (or what it was) acpi states, since vista loaded fine without battery removal.

[Vladimir Meremyanin (v-stiff)]

Problem still works in 2.6.24-10. Is anyone reading this reports?

[sandfly (sjpenn)]

I have a similar booting issue with dell xps m1210.

7.1 worked fine however, 8.04 only boots in recovery mode, video drivers are jacked.

any help will be appreciated.

sandfly

[Thomas McKay (tom-mckay1)]

I can confirm this problem on my sony vaio VGN-C240E laptop.

[Thomas McKay (tom-mckay1)]

also, i can confirm that i was able to boot by removing the battery and unplugging for several seconds.
it would appear the issue is centred on the battery/battery bay.

[Vladimir Meremyanin (v-stiff)]

no improvements in 2.6.24-11 and 2.6.24-12. Things even got worse, now I have no sound.

[Alexey Starikovskiy (astarikovskiy)]

Please check if this _debug_ patch improves situation...

[marco-peroverde (marco-peroverde)]

I can confirm that problem for my fe41z.
After upgrading from 7.10 to Alpha 5 my system wasn't bootable anymore. Rec. mode worked.
Live CD from Alpha 6 couldn't boot. And the Beta LiveCD has now exactly the problem which is described above.

I can't check the debug patch, because I need that PC for work ;)

[bitzer (bitzer)]

Same problem after installing Hardy Heron Beta on my Vaio VGN-C1S/H. No problems with Gutsy.

[marco-peroverde (marco-peroverde)]

I just did some tests with the live cd.

If I try to boot with that beta cd and AC is plugged in and the battery is in the bay I can not boot.
I get the errormessage described in the first post.
If I try to boot with that beta cd and AC is plugged out and the notebook is running on battery booting is possible.
Once the progessbar is displayed I can replug AC and Ubuntu is still booting.

[Vladimir Meremyanin (v-stiff)]

I've finally compiled kernel with patch, and it works!

Thanks Alexey!

[Thomas McKay (tom-mckay1)]

I am sorry, but I cannot test the patch either.
If somebody has a laptop with this problem they do NOT depend on, please test it out so we can get this patch packaged.
I look forward to my next kernel update...

[Vladimir Meremyanin (v-stiff)]

What do you mean 'NOT depend on'? you never reboot it?

All you need to compile kernel is waste couple hours of CPU time, and some of yours: https://help.ubuntu.com/community/Kernel/Compile

once it's installed you need one reboot to test it and if it fails boot your previous kernel.

[marco-peroverde (marco-peroverde)]

'Not depend on' means not daring to install 8.04 on a productive system...

[Thomas McKay (tom-mckay1)]

Okay Vlad, you twisted my arm. I compiled the kernel with the patch and have installed it... I'm about to reboot. I'll report back here with my results, you can be assured of that.

cheers.

[Thomas McKay (tom-mckay1)]

I can confirm without a doubt that this patch has solved this bug.

However, I forgot to include my wireless drivers when compiling my kernel :(

[Vladimir Meremyanin (v-stiff)]

It's not so painful as it seems, is it?

> However, I forgot to include my wireless drivers when compiling my kernel :(

This is strange, because kernel should be exactly in the same configuration as in binary package (unless you changed config in some way, I didn't touch anything, just applied patch, and wireless works)

[Thomas McKay (tom-mckay1)]

well i do have wireless... just 802.1x, and i need WPA2 enterprise support.

anyways, I have compiled kernels before, I just didn't expect to have the free time to do this, or the free time to fix something if i borked it.

Thanks a lot for the patch though, but I'm going to continue booting in recovery mode until this issue is solved at the repository level. It may be a hassle, especially for livecd users, however for me it is a small inconvenience.

[Luca Cavalli (luca-cavalli)]

Tested the proposed patch on my brother's laptop and now he can boot without recovery mode, so another positive feedback.

[Vladimir Meremyanin (v-stiff)]

2.6.24-15.17 Consistently hangs with power cable attached, and boots when battery only (without battery removal).

[Leann Ogasawara (leannogasawara)]

Hi Everyone,

Just a few things to note here. First the upstream git commit id and description which seems to have resulted in the issue you are seeing is as follows:

commit c04209a7948b95e8c52084e8595e74e9428653d3
Author: Alexey Starikovskiy <email address hidden>
Date: Tue Jan 1 14:12:55 2008 -0500

    ACPI: EC: Enable boot EC before bus_scan

    Some _STA methods called during bus_scan() might require EC region handler,
    which might be enabled later in the scan.
    Enable it explicitly before scan to avoid errors.

    Reference: http://bugzilla.kernel.org/show_bug.cgi?id=9627

    Signed-off-by: Alexey Starikovskiy <email address hidden>
    Signed-off-by: Len Brown <email address hidden>

So it seems fixes for another upstream bug resulted in what you are seeing. I also noticed the following in the dmesg output from Vladimir:

[ 0.000000] ACPI: BIOS bug: multiple APIC/MADT found, using 0
[ 0.000000] ACPI: If "acpi_apic_instance=2" works better, notify <email address hidden>

Just curious if you tried acpi_apic_instance=2 without the patch applied and if it helps the situation.

Unfortunately the kernel is currently frozen for Hardy as we're approximately 2 weeks away from the final release. Obviously reverting this patch will cause issues for others :( I'll ping the Ubuntu kernel team to try and see what can be done but it may be the case that this won't get resolved until the Intrepid Ibex 8.10 kernel opens for development.

It would also be helpful if someone who has this issue could first test the current upstream kernel to verify the issue still exists upstream. See https://wiki.ubuntu.com/KernelTeam/GitKernelBuild for help with building the upstream kernel. If the issue still exists, if you could post a comment to the upstream bugzilla report (http://bugzilla.kernel.org/show_bug.cgi?id=9627) noting the regression the patch has caused and you've verified that removing the code (ie ifdef'ed it out) resolves the issue.

I apologize that this was overlooked until now. Apparently this report wasn't assigned to the right package (ie the Ubuntu kernel source package 'linux') and was being overlooked. It was recently reassigned to the appropriate 'linux' package. Just for future reference, https://wiki.ubuntu.com/Bugs/FindRightPackage can help with this. Thanks.

[TJ (tj)]

I've just spotted this bug report on the kernel-team mailing list thanks to Leann. I've been running a Vaio vGN-FE41Z since April 2007. I started with 32-bit builds but moved to x86_64 and have not tried 32-bit again since.

I've been testing/using Hardy alongside Gutsy all the way through the development process and not experienced this issue. The laptop is usually on mains power when it boots.

Interestingly, I did rewrite the ACPI DSDT to fix an issue with the battery-technology reported as non-rechargeable but that was ages ago and I can't see it being affected by this:

http://ubuntuforums.org/showthread.php?t=475801

I'll do some systematic tests tomorrow with 64-bit and 32-bit Hardy builds.

[TJ (tj)]

This only affects the x86 i386 build. I'm investigating further.

[marco-peroverde (marco-peroverde)]

Just to have it said. I tried a few days ago to get rid of the problem by upgrading the notebooks bios to the latest version.
Didn't work ;)

[TJ (tj)]

What we expect to see is:

[ 28.070535] ACPI: EC: Look up EC in DSDT
[ 28.077294] ACPI: Interpreter enabled
[ 28.077357] ACPI: (supports S0 S3 S4 S5)
[ 28.077612] ACPI: Using IOAPIC for interrupt routing
[ 28.078065] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 28.105273] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
[ 28.105338] ACPI: EC: driver started in interrupt mode

But i386, when on external power, reports:

[ 18.127035] ACPI: EC: Look up EC in DSDT
[ 18.136591] ACPI: Interpreter enabled
[ 18.136594] ACPI: (supports S0 S3 S4 S5)
[ 18.136604] ACPI: Using IOAPIC for interrupt routing
[ 18.136844] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 18.634304] ACPI: EC: acpi_ec_wait timeout, status = 0, expect_event = 1
[ 18.634362] ACPI: EC: read timeout, command = 128
[ 18.634415] ACPI Exception (evregion-0420): AE_TIME, Returned by Handler for [EmbeddedControl] [20070126]
[ 18.634419] ACPI Exception (dswexec-0462): AE_TIME, While resolving operands for [OpcodeName unavailable] [20070126]
[ 18.634423] ACPI Error (psparse-0537): Method parse/execution failed [\_SB_.PCI0.LPCB.EC__._REG] (Node f7c4bd20), AE_TIME
[ 19.142018] ACPI: EC: missing confirmations, switch off interrupt mode.
[ 19.154286] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
[ 19.154288] ACPI: EC: driver started in poll mode

The key part is:

[ 18.634419] ACPI Exception (dswexec-0462): AE_TIME, While resolving operands for [OpcodeName unavailable] [20070126]

The ACPI EC._REG method is:

Method (_REG, 2, NotSerialized)
{
    If (LEqual (Arg0, 0x03))
    {
        Store (Arg1, ECON)
        Store (BATP, BNUM)
        Store (RSCL, B0SC)
        Store (RPWR, PWRS)
        Notify (BAT0, 0x81)
        PNOT ()
        If (LEqual (PRCP, One))
        {
            Notify (DOCK, Zero)
        }

        If (LEqual (WKSR, 0x02))
        {
            Notify (DOCK, One)
        }
    }
}

If the early-enabling of the EC is the reason, it looks to me as if one or more of the STORE() operations is failing because the target hasn't been declared in the ACPI name-space yet.

The call-chain looks to be:

drivers/acpi/ec.c::acpi_ec_transaction_unlocked()
 drivers/acpi/ec.c::acpi_ec_wait()

-- drivers/acpi/ec.c::acpi_ec_transaction_unlocked() --

for (; rdata_len > 0; --rdata_len) {
 result = acpi_ec_wait(ec, ACPI_EC_EVENT_OBF_1, force_poll);
 if (result) {
  pr_err(PREFIX "read timeout, command = %d\n", command);
  goto end;

--

-- acpi_ec_wait() --

if (likely(test_bit(EC_FLAGS_GPE_MODE, &ec->flags)) && ...

...
 if (acpi_ec_check_status(ec, event)) {
...
 } else {
  /* missing GPEs, switch back to poll mode */
  if (printk_ratelimit())
   pr_info(PREFIX "missing confirmations, "
    "switch off interrupt mode.\n");
  clear_bit(EC_FLAGS_GPE_MODE, &ec->flags);
 }

I'll do an ACPI debug test on this and see where it is going wrong.

[TJ (tj)]

On external power, I've just installed the 2008-04-10 Hardy i386 LiveCD.

The LiveCD hangs during boot with the messages:

ACPI: EC: acpi_ec_wait timeout, status=32, expect_event=1
ACPI: EC: read timeout, command=128

However, the *installed* system boots fine:

[ 13.169576] ACPI: EC: Look up EC in DSDT
[ 13.178074] ACPI: Interpreter enabled
[ 13.178137] ACPI: (supports S0 S3 S4 S5)
[ 13.178392] ACPI: Using IOAPIC for interrupt routing
[ 13.180182] ACPI: EC: non-query interrupt received, switching to interrupt mode
[ 13.205184] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
[ 13.205249] ACPI: EC: driver started in interrupt mode

~$ uname -a
Linux hardy-i386 2.6.24-15-generic #1 SMP Tue Apr 8 00:33:51 UTC 2008 i686 GNU/Linux

Can I get some clarifications on the various reports?

1. Is anyone having problems with the *installed* i386?
2. What dates are the daily LiveCDs that *do* hang?
3. Have you tried the amd64 (64-bit) LiveCD?

This looks to me rather like something missing from the initrd of the CD.

Currently the workaround appears to be to *disconnect* external power whilst the i386 LiveCD is booting and reconnect it once the loading splash screen appears.

[TJ (tj)]

For some reason I can no longer reproduce the issue with the 2008-04-10 LiveCD, and I can't figure out why. I've tried removing the battery and doing a cold start, with and without external power, restarting from Gutsy session.

Report back if you're still seeing this issue with the most recent LiveCD (now 2008-04-11)

http://cdimage.ubuntu.com/daily-live/current/

[slash2314 (slash2314)]

I had the same problem with a sony vaio VGN-N320E. I am able to boot when I remove the quiet kernel option in grub. I am just using the ro and splash options.

[TJ (tj)]

slash2314, thank-you!

In all my testing I usually remove "quiet splash" to watch the boot messages which explains why I was unable to reproduce it. I also found this does indeed affect x86_64 as well. Because I run development kernels I never have the "quiet" option enabled - hence my not being affected.

I've rewritten the bug title since it appears to affect more machines.

So, the revised work-around is to remove the "quiet" option from the kernel command line. If you're using an installed system, do this in /boot/grub/menu.lst and maybe change the default koptions.

For the LiveCD, press "F6" when the menu appears, press "End" to get to the end of the command line, and then use back-space to delete the "quiet" option. Press Enter to continue to boot.

[marco-peroverde (marco-peroverde)]

Yebb booting unquiet works with the LiveCD. Even with the Beta release.

[TJ (tj)]

Right, I know what is causing this now. We have a complex interaction of three things:

1. Early EC initialisation introduced by commit c04209a7948b95e8c52084e8595e74e9428653d3
2. Timing (especially on multiprocessor / multitasking systems)
3. Possible 'problem' with ACPI DSDT embedded controller logic

When the EC is initialised before the rest of the ACPI namespace, any references in the EC _REG() method to other node names will fail since they're not yet known. In the case of the PCs being affected by this bug, there is a Notify(BAT0, 0x81) or similar. BAT0 is not yet known but the notify causes a general purpose event (GPE) to be fired which goes unhandled and times out.

When boot option "quiet" is enabled there are very few kernel messages being logged so everything executes faster. When "quiet" is removed, or debugging of any kind is enabled, the additional time taken to log messages gives enough breathing space for the ACPI namespace to be scanned and the other objects created before the timeout occurs.

The _REG(RegionSpace, 1) control method is used to notify AML that an operation region is available. It is not clear from the ACPI specification whether _REG() is allowed to Notify() other nodes. If the namespace is fully scanned it shouldn't be an issue, but when the EC is started early via an ECDT or by virtue of the commit here (intended to provide the ECDT equivalent for BIOSes without it), then it can cause a failure.

I edited the EC's _REG() method and disabled the Notify(BAT0...) call and then installed the revised DSDT in an initrd image. I kept the original initrd with a different name and added an additional boot entry into the GRUB menu. I then tested both initrd images. The one containing the modified DSDT with Notify() disabled starts correctly. The original DSDT causes it to fail.

$ sudo acpidump -b -t DSDT -o DSDT.aml
$ iasl -d DSDT.aml
$ gedit DSDT.dsl

Device (EC)
...

 Method (_REG, 2, NotSerialized)
 {
  If (LEqual (Arg0, 0x03))
  {
   Store (Arg1, ECON)
   Store (BATP, BNUM)
   Store (RSCL, B0SC)
   Store (RPWR, PWRS)
   /* Notify (BAT0, 0x81) not allowed for early-init ECs */
   PNOT ()
   If (LEqual (PRCP, One))
   {
    Notify (DOCK, Zero)
   }

   If (LEqual (WKSR, 0x02))
   {
    Notify (DOCK, One)
   }
  }
 }

I rebuilt the DSDT:

$ iasl DSDT.dsl
$ sudo cp DSDT.aml /etc/initramfs-tools/
$ sudo mv /boot/initrd.img-2.6.24-16-generic /boot/initrd.img-2.6.24-16-generic-ec-bug
$ sudo update-initramfs -u ALL
$ sudo mv /boot/initrd.img-2.6.24-16-generic /boot/initrd.img-2.6.24-16-generic-ec-fix

Now edit /boot/grub/menu.lst, edit the initrd name and add another menu option:

title Ubuntu Hardy 64-bit, kernel 2.6.24-16-generic EC fix
root (hd0,4)
kernel /vmlinuz-2.6.24-16-generic root=UUID=bb2c3a14-1588-4fb9-8411-71f114b568b4 ro quiet
initrd /initrd.img-2.6.24-16-generic-ec-fix
quiet

title Ubuntu Hardy 64-bit, kernel 2.6.24-16-generic EC bug
root (hd0,4)
kernel /vmlinuz-2.6.24-16-generic root=UUID=bb2c3a14-1588-4fb9-8411-71f114b568b4 ro quiet
initrd /initrd.img-2.6.24-16-generic-ec-bug
quiet

------

I have a large collection of DSDTs from across the Vaio range as part of my SNC research. I ran an ana...

[Thomas McKay (tom-mckay1)]

Thank you so much for the suggestion!
From now on i'll boot loudly and proudly!

On Sat, Apr 12, 2008 at 12:33 AM, TJ <email address hidden> wrote:

> ** Bug watch added: Linux Kernel Bug Tracker #10444
> http://bugzilla.kernel.org/show_bug.cgi?id=10444
>
> ** Also affects: linux via
> http://bugzilla.kernel.org/show_bug.cgi?id=10444
> Importance: Unknown
> Status: Unknown
>
> --
> [Hardy] ACPI Embedded Controller (EC) stops boot when kernel boot 'quiet'
> option is enabled
> https://bugs.launchpad.net/bugs/191137
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Tom McKay

[slash2314 (slash2314)]

In the kernel bug report TJ submitted to bugzilla it stated that the latest working kernel was 2.6.22, but for me the bug is not present in 2.6.23.

[Václav Šmilauer (eudoxos)]

On vaio VGN-N21, editing the DSDT alone doesn't fix the freeze; unquiet boot works just fine.

[TJ (tj)]

Václav, your result is interesting, thank you. I didn't have time to endlessly repeat the reboot tests when I did the DSDT patch so it is possible that it was in some way coincidental that the kernel didn't crash those times.

Since doing that patch and having time to think about things more I'm leaning towards the idea that the power management hardware is generating the unhandled event when it sees the AC adapter is connected - not the EC._REG() method because of early init. If this 'new' theory is correct, then when the EC GPE events are enabled early the hardware can start interrupting. The problem is, as soon as I add even minimal debug messages to try and trace the code-path the bug goes away - the same as when removing the "quiet" kernel boot option!

[Vladimir Meremyanin (v-stiff)]

I've encountered lock when boot on battery only.

On Sun, Apr 13, 2008 at 8:56 PM, TJ <email address hidden> wrote:

> Václav, your result is interesting, thank you. I didn't have time to
> endlessly repeat the reboot tests when I did the DSDT patch so it is
> possible that it was in some way coincidental that the kernel didn't
> crash those times.
>
> Since doing that patch and having time to think about things more I'm
> leaning towards the idea that the power management hardware is
> generating the unhandled event when it sees the AC adapter is connected
> - not the EC._REG() method because of early init. If this 'new' theory
> is correct, then when the EC GPE events are enabled early the hardware
> can start interrupting. The problem is, as soon as I add even minimal
> debug messages to try and trace the code-path the bug goes away - the
> same as when removing the "quiet" kernel boot option!
>
> --
> [Hardy] ACPI Embedded Controller (EC) stops boot when kernel boot 'quiet'
> option is enabled
> https://bugs.launchpad.net/bugs/191137
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[TJ (tj)]

With "quiet" still enabled, try adding this boot option:

ec_intr=1

It should force the GPE to use interrupt mode.

Also, a long shot, but try:

acpi_os_name="Windows 2006"

since the Vaios often have Vista-specific functionality in the ACPI BIOS.

[TJ (tj)]

The additional debug messages were enough to pinpoint the root-cause of the issue and I had a proof-of-concept patch succeed in fixing the issue last thing yesterday.

Today I worked through the commit logs from mainline and located the two commits that fix the issue in later kernels. I built and tested the kernel with those commit patches applied and couldn't provoke the bug.
Then, reviewing the comments on this bug, I realised that Stefan had referred to the same two commits on 9th July but, because there was no explicit link to a test kernel in his comment, I'd somehow overlooked it and not tried them.

I've currently got my PPA building kernel packages with the patches applied so that others can test the kernel easily. If/when the builds are complete please test the kernel package by adding my PPA to your apt sources:

$ sudo su
$ echo "deb http://ppa.launchpad.net/intuitivenipple/ubuntu hardy main" > /etc/apt/sources.list.d/intuitivenipple-ppa.list
$ apt-get update
$ exit

Update Manager should now discover the package and offer it for installation.

In case the PPA builds fail (kernel-builds are still a dark art!) I'm also building all binary packages. Once built they will be found at http://tjworld.net/ubuntu/bugs/lp191137/

For reference, the fix (if it solves everyone else's problems too) is to cherry-pick the commits:

b3b233c7d948a5f55185fb5a1b248157b948a1e5 Thu Jan 10 20:50:12 2008 -0500 ACPI: EC: Some hardware requires burst mode to operate properly
3e71a87d03055de0b8c8e42aba758ee6494af083 Thu Jan 10 20:49:14 2008 -0500 ACPI: EC: Do the byte access with a fast path

I was trying to figure out why they didn't get into the ubuntu-hardy tree since according to the logs there were several pulls from upstream after the commit date.

Please report your experiences with this test kernel package.

[Hao Zhe XU (haozhe.xu3)]

I tried the new kernel smb4 but wireless becomes weired, it detects some WIFI network which I never seen before, all previous working WIFI networks are not detected.

[Stefan Bader (smb)]

I had that patches included in smb6 at http://people.ubuntu.com/~smb/bug191137/.

@Hao, please could you try either that one or the one fomr TJ's PPA. Thanks.

[wvengen (wvengen)]

Just booted smb6 successfully with power cord attached :)
  [ 14.058061] ACPI: bus type pci registered
  [ 14.058143] PCI: Using configuration type 1
  [ 14.059446] ACPI: EC: acpi_ec_ecdt_probe() created boot_ec
  [ 14.059505] ACPI: EC: Look up EC in DSDT
  [ 14.065305] ACPI: EC: no EC._INI
  [ 14.067351] ACPI: Interpreter enabled
  [ 14.067407] ACPI: (supports S0 S3 S4 S5)
  [ 14.067424] ACPI: Using IOAPIC for interrupt routing
  [ 14.067554] ACPI: EC: acpi_boot_ec_enable()
  [ 14.068018] ACPI: EC: non-query interrupt received, switching to interrupt mode
  [ 14.076076] ACPI: EC: acpi_boot_ec_enable() successful
  [ 14.076132] ACPI: after acpi_boot_ec_enable() call
  [ 14.096516] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
  [ 14.096520] ACPI: EC: driver started in interrupt mode
I can't find TJ's kernels yet, however (neither ppa nor tjworld)

[Stefan Bader (smb)]

Ok, for completeness there is a 19.35smb1 kernel which incorporates the latest Hardy release with only those two upstream changes (without any debugging code). If you are happy with that I will try to get this into the next release. Time is tight, however...

[TJ (tj)]

The PPA builds failed (I somehow managed to mess up the ABI checks in
the upload package!) and my local builds for some reason didn't
auto-upload to my server after the builds completed.

It looks as if Stefan has it covered with his packages however so I'll
leave it to him since there's an SRU for this now.

[Stefan Bader (smb)]

SRU justification:

Impact: On several Sony laptop models the changes introduced by upstream
commit c04209a7948b95e8c52084e8595e74e9428653d3 to enable the EC handler
during scan will cause those machines to hang on boot.

Fix: There was a work-around to remove the quiet option on boot but that very much depended on timing and probably won't always work. There have been two upstream patches identified to solve the issue. Patches commited to Hardy as bdbcd262d8a378984716e3bc3bdbfd70841303ab and 40e55e8f3bb152df0e883dad572d263647f3c056.

Testcase: Boot a Hardy kernel on one of the affected laptops with the
quiet option active (default) and it will hang. With the fixes this
does not happen.

[Hao Zhe XU (haozhe.xu3)]

I have to confirm something:
1 do I try 34smb6 or 35smb1?
2 do I just double click the deb file and follow the instruction? Last time I did in this way but wireless does not work any more.
3 Is it possible to reverse back to previous kernel after I installed this patched kernel?
Thanks!

[Hao Zhe XU (haozhe.xu3)]

I mentioned the problem with smb4 before, I have a photo of it.

[marco-peroverde (marco-peroverde)]

I have that https://bugs.launchpad.net/ubuntu/+source/linux/+bug/191137/comments/124 Problem too
since I installed Hardy. But I think it's indipendent of this bug which is discussed here.

System hangs during boot with the messages Hao posted with this pic. Normally it's running up well
if you reboot then.

For me it's happening on a fe41z.

[Stefan Bader (smb)]

@Hao

1. Better 35smb1
2. Actually I never did it that way but by using 'dpkg --install'
3. Yes. Depending on which kernel you want download one of the linux-image packages at
http://archive.ubuntu.com/ubuntu/pool/main/l/linux/ and call the dpkg command with that.

@Weisswurst

was that with any of the debug kernels or just with the original one? If that was the stock ubuntu kernel, maybe you could try the 35smb1 kernel as well? If the problem persists there we have to look closer and decide whether this is something new or might relate to the current problem.

[marco-peroverde (marco-peroverde)]

Well this Vaio is my working machine. I can not try stuff during exams...
The problem occurs on every stock kernel since hardy. But it occures randomly.
Out of ten boots only one fails if not less. But if it fails there is a good chance that it fails again by the first reboot.
But then I don't see this message sometimes for weeks.

Thats why I never mentioned it.
I'm wondering why TJ never sees this message because he is also using a fe41z...

[marco-peroverde (marco-peroverde)]

Well, at the end of the month I could try some things. Then my exams are finished.
But I don't think, can reboot the vaio till this failure finally appears.

[Hao Zhe XU (haozhe.xu3)]

Yes that problem happens on standard kernel.

And 35smb1 does work, I only tried it once but it worked, no hangs any more.

I attached my dmesg output.

So when will the patch be formally released? At that time, do I keep using the patched 35smb1 kernel or use formally released one(do I reverse back to the standard kernel and then upgrade or the upgrade program automatically adjust my kernel with the latest standard one?)?

[Stefan Bader (smb)]

@Hao,

you could stay with that kernel. It should be more or less be the same as the upcoming security update (though that could overrule this kernel since there are chances that due to build problems the security release one might be 19.36). The fix now has been committed and should show up in the next point release (hardy-proposed). But I can't give an exact time estimate for that.

[Hao Zhe XU (haozhe.xu3)]

After installing the kernel, my update manager told me there are kernel updates, is it just the previous standard kernel? When the patch is released, do I update via update manager?
Thanks!

[Stefan Bader (smb)]

@Hao

the kernel you get offered is the 19.36 one which is the same as the 35smb1 without the fix for the booting problem. So you might want to stay with the smb1 kernel. The next kernel which should also have this fix in will be the next stable release update. To get that as soon as possible you have to enable hardy-proposed in your installation sources. You will then just use the update manager for that.

[Stefan Bader (smb)]

40e55e8f3bb152df0e883dad572d263647f3c056 + bdbcd262d8a378984716e3bc3bdbfd70841303ab in Hardy.

[Steve Langasek (vorlon)]

Accepted into -proposed, please test and give feedback here. Please see https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

[Keith Drummond (kd353)]

Hi, thanks everyone for all the work you have been putting into this!

If I want to try to upgrade to Hardy again (from Gutsy) can I just hit the upgrade button in update manager and this new kernal will be incorporated or do I have to wait until the next point release of Hardy (8.6.2??) and make a fresh install?

OR can I fresh install Hardy, add 'noacpi' to be able to turn on the computer then follow the previous post instructions, then that should in theory fix the problem when I restart the computer?

[Stefan Bader (smb)]

If you do the upgrade, make sure you have hardy-porposed enabled in your installation sources and also either wait maybe until end of next week or make sure that all the needed packages are there. The uploads are still in progress and you want to have matching LUM and LRM packages ready.

Or if you like to be on Hardy faster, you can install freshly and work around the problem (noacpi seems a bit harsh, most people just had to remove the quiet option from the grub commandline) and then go for the 35smb1 kernel I prepared. Then (if hardy-proposed is enabled) you will get updated as soon as the packages are ready.

[Thomas McKay (tom-mckay1)]

My deepest thanks go out to everybody involved in solving this showstopper
of a bug.
After enabling proposed and upgrading the kernel this bug is just a bad
dream now, a problem of the past.

THANK YOU!

[Vladimir Meremyanin (v-stiff)]

Awesome!
Works for me too, can confirm it.

Thanks guys!

On Thu, Jul 24, 2008 at 12:59, Martin Pitt <email address hidden> wrote:

> ** Tags added: verification-done
>
> ** Tags removed: verification-needed
>
> --
> [Hardy] ACPI Embedded Controller (EC) stops boot when kernel boot 'quiet'
> option is enabled or AC power is connected
> https://bugs.launchpad.net/bugs/191137
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Keith Drummond (kd353)]

THANK YOU! THANK YOU! THANK YOU!

I am confirming that the fix worked on my laptop (Sony Vaio VGN-N31S).

I made a fresh install of 8.04, deleted quiet option, booted to live session, installed Ubuntu, restarted.

After restart I hit 'esc', edited the grub command lines, booted into hardy, enabled the 'proposed' updated, then proceeded to update, then restarted.

After restart everything went perfect, not a single problem. I am here writing about it from Hardy Heron.

Did I say thank you??

Thanks again for all the effort you put into this fix.

[neffets (2-launchpad-net-neffets-de)]

Hey,

boot hanging occurs here too on non-Vaio laptop
I have a:
  HP Pavilion dv6000 (dv6500)
  CPU: AMD Turion(tm) 64 X2 Mobile Technology TL-56 (stating thats running on 800 MHz)

It hangs at BOOT when AC-power is connected.
- then I can wait for very long time,
OR: simply press two times the AC-power-button and it will proceed immediately.

attached dmesg and my DSDT
here the few lines arround the needed AC-power-button-press

...
[ 0.099536] ACPI: Core revision 20080321
[ 0.108006] ACPI: setting ELCR to 0200 (from 0ca0)
[ 0.112007] CPU0: AMD Turion(tm) 64 X2 Mobile Technology TL-56 stepping 02
[ 0.112007] Booting processor 1/1 ip 6000
[ 0.120007] Initializing CPU#1
[ 0.120007] Calibrating delay using timer specific routine.. 3600.35 BogoMIPS (lpj=7200700)
[ 0.120007] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 0.120007] CPU: L2 Cache: 512K (64 bytes/line)
[ 0.120007] CPU 1(2) -> Core 1
[ 0.120007] AMD C1E detected late. Force timer broadcast.
[ 0.199961] CPU1: AMD Turion(tm) 64 X2 Mobile Technology TL-56 stepping 02
[ 0.200012] Brought up 2 CPUs
[ 0.200012] Total of 2 processors activated (7204.70 BogoMIPS).
[ 0.200012] CPU0 attaching sched-domain:
[ 0.200012] domain 0: span 0-1
[ 0.200012] groups: 0 1
[ 0.200012] CPU1 attaching sched-domain:
[ 0.200012] domain 0: span 0-1
[ 0.200012] groups: 1 0
[ 0.200012] net_namespace: 644 bytes
[ 0.200012] Booting paravirtualized kernel on bare hardware
[ 0.200012] NET: Registered protocol family 16
[ 0.200012] EISA bus registered
[ 0.200012] ACPI: bus type pci registered
[ 0.200012] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 4
[ 0.200012] PCI: MCFG area at e0000000 reserved in E820
[ 0.200012] PCI: Using MMCONFIG for extended config space
[ 0.200179] PCI: Using configuration type 1 for base access
[ 0.200350] Setting up standard PCI resources
[ 0.204013] ACPI: EC: Look up EC in DSDT
[ 0.206659] ACPI: BIOS _OSI(Linux) query ignored via DMI
[ 0.207788] ACPI: Interpreter enabled
[ 0.207953] ACPI: (supports S0 S3 S4 S5)
[ 0.208185] ACPI: Using PIC for interrupt routing
[ 0.208185] ACPI: EC: non-query interrupt received, switching to interrupt mode

       HERE pressing shortly the AC-power-button will proceed immediately (otherwise hang for long time)

[ 0.224186] ACPI: EC: GPE = 0x10, I/O: command/status = 0x66, data = 0x62
[ 0.224186] ACPI: EC: driver started in interrupt mode
[ 0.224186] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 0.224186] PCI: Transparent bridge - 0000:00:08.0
[ 0.224498] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 0.224596] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P2P0._PRT]
[ 0.224619] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.XVR1._PRT]
[ 0.224654] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.XVR2._PRT]
[ 0.260188] ACPI: PCI Interrupt Link [LNK1] (IRQs 5 7 *10 11 14 15)
[ 0.260188] ACPI: PCI Interrupt Link [LNK2] (IRQs 5 7 10 *11 14 15)
[ 0.260894] ACPI: PCI Interrupt Link [LNK3] (IRQs 5 7 10 11 14 15) *0, disabled.
[ 0.261800] ACPI: PCI Interrupt Link [LNK4] (IRQs 5 7 10 11 ...

[neffets (2-launchpad-net-neffets-de)]

Hey,

here the DSDT.aml from my laptop "HP Pavilion dv6500"
chipset claims to be MCP67

Kernel:
* standard 2.6.24-19-386 => no problem
* self-compiled 2.6.25.6 (on 20080615) => no problem
BUT
* now kernel 2.6.26 (first release compiled on 20080716) . HANGs
(-rw-r--r-- 1 root src 49441874 2008-07-14 00:43 linux-2.6.26.tar.bz2)

[neffets (2-launchpad-net-neffets-de)]

hp pavilion dv6500
Booting with kernel options:

without ac-power it hangs too
  after ac-power-button press (or wlan-button change) it boots further
  and hangs then later

[ 25.334075] ACPI: Battery Slot [BAT0] (battery present)
[ 25.335892] ACPI: WMI: Mapper loaded
[ 25.603699] ACPI: device:25 is registered as cooling_device2
[ 25.603699] input: Video Bus as /class/input/input7
[ 25.651769] ACPI: Video Device [UVGA] (multi-head: yes rom: no post: no)
[ 25.714598] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 25.908925] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ 26.165161] ricoh-mmc: Ricoh MMC Controller disabling driver
[ 26.166967] ricoh-mmc: Copyright(c) Philip Langdale
[ 26.169028] ricoh-mmc: Ricoh MMC controller found at 0000:02:05.2 [1180:0843] (rev 12)
[ 26.169047] ricoh-mmc: Controller is now disabled.
[ 26.230659] input: PC Speaker as /class/input/input8
[ 175.522250] BUG: soft lockup - CPU#1 stuck for 140s! [swapper:0]
[ 175.522250] Modules linked in: pcspkr(+) soundcore ricoh_mmc mmc_core k8temp shpchp pci_hotplug video output wmi battery ac button evdev ext3 jbd mbcache sg sr_mod sd_mod cdrom ata_generic pata_acpi usbhid hid pata_amd ahci ssb libata ohci1394 ehci_hcd ohci_hcd ieee1394 scsi_mod forcedeth dock usbcore thermal processor fan fuse
[ 175.522250]
[ 175.522250] Pid: 0, comm: swapper Not tainted (2.6.26-20080716 #2)
[ 175.522250] EIP: 0060:[<c01176a2>] EFLAGS: 00000246 CPU: 1
[ 175.522250] EIP is at native_safe_halt+0x2/0x10

175.52... then I re-connected the ac-power chord into the laptop

[Stefan Bader (smb)]

@neffets

I thing this should go into a new bug since your problems started with a later kernel. The symptoms look similar but might be unrelated. If possible you should also try to run a vanilla upstream kernel to verify whether the problem does still exist.

[Stefan Bader (smb)]

@neffets

I think this should go into a new bug since your problems started with a later kernel. The symptoms look similar but might be unrelated. If possible you should also try to run a vanilla upstream kernel to verify whether the problem does still exist.

[Cristian T (cristroncos)]

Hey guys...I can confirm the fix works perfectly on my Sony Vaio VGN-C240E. Thanks a lot for all the work you put into this....It's really appreciated!

[Jonas Steinmann (steinmann-jonas)]

Works perfectly on my VAIO VGN-N21Z :)

[Julian Alarcon (julian-alarcon)]

@neffets

Maybe you are involve with this bug:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/204996

[neffets (2-launchpad-net-neffets-de)]

Hello,

acpi boots now without pause with the new kernels
    2.6.25.15
and
    2.6.27-rc3 (rc2 too)

[bohemier (bohemier)]

Hello everyone,

Thanks for the help, the proposed patches fixed the problem on my sony vaio vgn-n385qe

regards

[bigDs54 (big-d-rumblin)]

sorry to post here being im a bit new to the linux experience, how do i remove the quiet option? then enable 'proposed'? sorry am using sony vaio vgn-nr430 and trying to run ubuntu 8.04.1 i386, using live cd it freezes as soon as i pick either use without installing, check cd, or install. any help would be appreciated -d

[Stefan Bader (smb)]

To remove the quiet option from the live/install CDs by pressing F& (other options) and remove the quiet keyword.
Proposed is enabled from System->Administration->Software Sources. Activate the "pre-release updates" box under the updates tab.

[Martin Pitt (pitti)]

linux 2.6.24-21 copied to hardy-updates.

[Leann Ogasawara (leannogasawara)]

The above mentioned patches are already in Intrepid as well so marking from Fix Committed to Fix Released. Thanks.