Comment 34 for bug 191137
Revision history for this message
| TJ (tj) wrote Re: [Hardy] ACPI Embedded Controller (EC) stops boot when kernel boot 'quiet' option is enabled | #34 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
35a32c5
(Get the code!)
Right, I know what is causing this now. We have a complex interaction of three things:
1. Early EC initialisation introduced by commit c04209a7948b95e
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-
$ sudo mv /boot/initrd.
$ sudo update-initramfs -u ALL
$ sudo mv /boot/initrd.
Now edit /boot/grub/
title Ubuntu Hardy 64-bit, kernel 2.6.24-16-generic EC fix
root (hd0,4)
kernel /vmlinuz-
initrd /initrd.
quiet
title Ubuntu Hardy 64-bit, kernel 2.6.24-16-generic EC bug
root (hd0,4)
kernel /vmlinuz-
initrd /initrd.
quiet
------
I have a large collection of DSDTs from across the Vaio range as part of my SNC research. I ran an analysis script on them all to see how many have a Notify() call in the EC _REG() control method (listed as model-BIOS_
VGN-AR31S-R0200J6, VGN-AR370E-R0200J6, VGN-C140G-R0030J4, VGN-C1S, VGN-C1ZB-R0034J4, VGN-C22GH-R0080J4, VGN-C240E-R0080J4, VGN-C2S-R0080J4, VGN-C2Z-R0080J4, VGN-FE11H-R0072J3, VGN-FE11H-R0074J3, VGN-FE11M-R0172J3, VGN-FE11M-R0174J3, VGN-FE21H-R0100J3, VGN-FE21M-R0130J3, VGN-FE31M, VGN-FE31M-R0170J3, VGN-FE41E-R0190J3, VGN-FE41M-R0190J3, VGN-FE41Z-R0200J3, VGN-FE45G-R0190J3, VGN-FE550G-R0074J3, VGN-FE590P-R0072J3, VGN-FE660G-R0133J3, VGN-FE670G-R0130J3, VGN-FE690-R0172J3, VGN-FE770G-R0173J3, VGN-FE830, VGN-FE870E-R0190J3, VGN-FE880EH-
This issue could end up impacting a *lot* of users not just of Vaios but other brands too. I've seen at least 3 others mentioned in bug reports in the kernel.org bugzilla. What is worrying is that the kernel ACPI guys seem to be sticking with the early EC initialisation and telling users to create a custom DSDT.