In a previous question (What is an ACPI GPE storm?), I asked about ACPI GPE storm. Looking closer to my kern.log file in /var/log/, I notice that in every session at some point (usually withing 20' after startup) a GPE storm is triggered. When I open kern.log immediately after startup, and wait for a storm to come up, I see that it can be triggered by anything (a copy-action, the opening of an app like Firefox or Thunderbird, etc...). This worries me, since the answer I got for my previous question confirms this can threaten stability and might be a sign of hardware malfunction. Looking for other ACPI related events in kern.log, I find the error messages below. I hope someone can give some advice:

Jun 10 16:33:20 Guy-VAIO kernel: [    0.724505] ACPI FADT declares the system doesn't support PCIe ASPM, so disable it
Jun 10 16:33:20 Guy-VAIO kernel: [    0.795205] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored
Jun 10 16:33:20 Guy-VAIO kernel: [    1.024009] ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
Jun 10 16:33:20 Guy-VAIO kernel: [   23.140259] [Firmware Bug]: ACPI(VGA) defines _DOD but not _DOS

I'm experiencing frequent (several times /d) application crashes, that seem random so not in particular apps, and less frequent (once a week or so) complete system freezes where the system becomes unresponsive to keyboard, mouse or touchpad input and the only solution is a hard reboot (press start button).

My questions:

  1. what about the Firmware Bugs in ACPI?
  2. how and where do I have to 'clear CONFIG_ACPI_PROCFS_POWER'?

Ubuntu 12.04, 64-bit, 3.2.0-25-generic Kernel, Intel® Core™ i5-2430M CPU @ 2.40GHz × 4


No, an ACPI GPE storm is not normal.

Here's a line-by-line explanation of the messages you saw, along with inline solutions which may help you:

  1. ACPI FADT declares the system doesn't support PCIe ASPM, so disable it

    • The FADT is an ACPI table containing power management info.
    • All the message means is that your computer doesn't support PCI-Express Active State Power Management, one of the ways to slightly reduce power usage when a PCI-e device isn't being actively used.
    • This shouldn't cause stability problems.
  2. [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored

    • In trying to identify the OS, the BIOS asked the kernel "Are you Linux?" and the kernel did not respond (this is normal behavior).
    • BIOSes can use this query to enable or disable functionality based on the running operating system, but they shouldn't.
    • You can try adding the boot parameter acpi_osi=Linux to make the kernel respond with "Yes", and see if this helps your GPE storm problem. (More info)
  3. ACPI: Deprecated procfs I/F for battery is loaded...

    • This is a harmless notification that the old, backwards-compatible /proc/acpi/... interface is also present, along with the new sysfs interface.
    • If you think that your manufacturer-specific kernel modules (e.g. sony-laptop, etc.) are somehow mis-handling the legacy /proc/acpi interface, you can try disabling it, but the only way to do so is to build a custom kernel with the ACPI_PROCFS_POWER option disabled.
    • Scroll down to the end for the complete description from the kernel docs.
    • Removing this may have some minor side effects, e.g. the powertop utility won't fully work.
  4. ACPI(VGA) defines _DOD but not _DOS

    • The BIOS uses the _DOD to tell ACPI if it has more than one display, and if so, how many.
    • _DOS is used to tell ACPI that the BIOS supports video switching, i.e. from one display to the other.
    • So ACPI is confused when your computer tells it it has two or more displays, but that it can't switch between them!
    • This warning appears in varied contexts -- can you try these boot options and see if stability improves: acpi=off, noapic, nolapic?

Full description of ACPI_PROCFS_POWER

Deprecated power /proc/acpi directories (ACPI_PROCFS_POWER)


For backwards compatibility, this option allows
deprecated power /proc/acpi/ directories to exist, even when
they have been replaced by functions in /sys.
The deprecated directories (and their replacements) include:
/proc/acpi/battery/* (/sys/class/power_supply/*)
/proc/acpi/ac_adapter/* (sys/class/power_supply/*)
This option has no effect on /proc/acpi/ directories
and functions, which do not yet exist in /sys
This option, together with the proc directories, will be
deleted in 2.6.39.

Say N to delete power /proc/acpi/ directories that have moved to /sys/

Type : boolean
Prompt: Deprecated power /proc/acpi directories
Defined at drivers/acpi/Kconfig:59
Depends on: ACPI [=y] && PROC_FS [=y]
-> Power management and ACPI options
-> ACPI (Advanced Configuration and Power Interface) Support (ACPI [=y])
  • 1. OK 2. entered boot parameter acpi_osi=Linux to GRUB, did a sudo update-grub and rebooted. In kern.log, the message [Firmware Bug]: ACPI: BIOS etc... is still there, and so is the GPE storm 2 min. after startup... So thanks for all your efforts but no luck so far... – Tinellus Jun 22 '12 at 16:25
  • @Tinellus, please paste the output of dmesg... – ish Jun 22 '12 at 16:26
  • Is this OK? (first line is terminal command) pastebin.ubuntu.com/1054571 If not, please give me more details... – Tinellus Jun 22 '12 at 16:50
  • 1
    @Tinellus: yes, it appears Jorge gave me the bounty prematurely. I'm still working on the full answer, as the note at the end explains. If you flag the question and use the "other" to ask the mods to refund your bounty, explaining the situation, they will -- I'm not going to ask for it! If you have any problems, just show up in the general chat room: chat.stackexchange.com/rooms/201/ask-ubuntu-general-room – ish Jun 25 '12 at 8:22
  • 1
    Tested 'nolapic', 'acpi=off' and 'noapic' consecutively: in each of these there was no GPE storm; in the first two, however there were problems with touchpad (was gone) and/or CPUs (only 1 iso 4). With the 'noapic' bootparameter everything went smoothly. I tried this one, along with 'acpi_osi=Linux' but within two minutes after startup a GPE storm was triggered. Now for about 2 hours with 'noapic' as single bootparameter without triggering a GPE storm. The kernel messages as listed in the original post are stil there, though. I consider this solved and award the bounty. Thx for your effort!! – Tinellus Jun 29 '12 at 16:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.