Hi,
There is an ACPI regression in 2.6.25-rc6, which causes the ACPI keys
to stop working on my laptop, an Asus V6VA. git bisect identified the
appended commit as guilty, and reverting it indeed fixes the problem
for me. Attached are my .config, a good dmesg and a bad one. The diff
between both dmesg reveals this interesting hunk:
@@ -121,8 +121,9 @@
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: EC: non-query interrupt received, switching to interrupt mode
+ACPI: EC: GPE storm detected, disabling EC GPE
ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
-ACPI: EC: driver started in interrupt mode
+ACPI: EC: driver started in poll mode
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci 0000:00:1f.0: Enabled ICH6/i801 SMBus device
pci 0000:00:1f.0: quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
Thanks.
commit 2c81ce4c9c37b910210f2640c28e98a0c398dc26
Author: Alexey Starikovskiy <[email protected]>
Date: Tue Mar 11 13:30:00 2008 -0400
ACPI: EC: Handle IRQ storm on Acer laptops
On some Acer systems, the HW fails to clear the GPE source,
causing an interrupt storm.
So in EC interrupt mode, we count how many interrupts we
receive when waiting. If we get more than 5, we give
up on interrupt mode and revert to polling mode.
Also, for polling mode to work on Acers, we need
to insert a delay.
Signed-off-by: Alexey Starikovskiy <[email protected]>
Signed-off-by: Len Brown <[email protected]>
diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index caf873c..2c77359 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -129,6 +129,7 @@ static struct acpi_ec {
struct mutex lock;
wait_queue_head_t wait;
struct list_head list;
+ atomic_t irq_count;
u8 handlers_installed;
} *boot_ec, *first_ec;
@@ -181,6 +182,8 @@ static int acpi_ec_wait(struct acpi_ec *ec, enum
ec_event event, int force_poll)
{
int ret = 0;
+ atomic_set(&ec->irq_count, 0);
+
if (unlikely(event == ACPI_EC_EVENT_OBF_1 &&
test_bit(EC_FLAGS_NO_OBF1_GPE, &ec->flags)))
force_poll = 1;
@@ -227,6 +230,7 @@ static int acpi_ec_wait(struct acpi_ec *ec, enum
ec_event event, int force_poll)
while (time_before(jiffies, delay)) {
if (acpi_ec_check_status(ec, event))
goto end;
+ msleep(5);
}
}
pr_err(PREFIX "acpi_ec_wait timeout,"
@@ -529,6 +533,13 @@ static u32 acpi_ec_gpe_handler(void *data)
struct acpi_ec *ec = data;
pr_debug(PREFIX "~~~> interrupt\n");
+ atomic_inc(&ec->irq_count);
+ if (atomic_read(&ec->irq_count) > 5) {
+ pr_err(PREFIX "GPE storm detected, disabling EC GPE\n");
+ acpi_disable_gpe(NULL, ec->gpe, ACPI_ISR);
+ clear_bit(EC_FLAGS_GPE_MODE, &ec->flags);
+ return ACPI_INTERRUPT_HANDLED;
+ }
clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags);
if (test_bit(EC_FLAGS_GPE_MODE, &ec->flags))
wake_up(&ec->wait);
--
Guillaume
Hi,
Please provide 'cat /proc/interrupts'.
Could you try if such patch works?
Thanks,
Alex.
Guillaume Chazarain wrote:
> Hi,
>
> There is an ACPI regression in 2.6.25-rc6, which causes the ACPI keys
> to stop working on my laptop, an Asus V6VA. git bisect identified the
> appended commit as guilty, and reverting it indeed fixes the problem
> for me. Attached are my .config, a good dmesg and a bad one. The diff
> between both dmesg reveals this interesting hunk:
>
> @@ -121,8 +121,9 @@
> ACPI: (supports S0 S1 S3 S4 S5)
> ACPI: Using IOAPIC for interrupt routing
> ACPI: EC: non-query interrupt received, switching to interrupt mode
> +ACPI: EC: GPE storm detected, disabling EC GPE
> ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
> -ACPI: EC: driver started in interrupt mode
> +ACPI: EC: driver started in poll mode
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> pci 0000:00:1f.0: Enabled ICH6/i801 SMBus device
> pci 0000:00:1f.0: quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
>
>
> Thanks.
>
>
> commit 2c81ce4c9c37b910210f2640c28e98a0c398dc26
> Author: Alexey Starikovskiy <[email protected]>
> Date: Tue Mar 11 13:30:00 2008 -0400
>
> ACPI: EC: Handle IRQ storm on Acer laptops
>
> On some Acer systems, the HW fails to clear the GPE source,
> causing an interrupt storm.
>
> So in EC interrupt mode, we count how many interrupts we
> receive when waiting. If we get more than 5, we give
> up on interrupt mode and revert to polling mode.
>
> Also, for polling mode to work on Acers, we need
> to insert a delay.
>
> Signed-off-by: Alexey Starikovskiy <[email protected]>
> Signed-off-by: Len Brown <[email protected]>
>
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index caf873c..2c77359 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -129,6 +129,7 @@ static struct acpi_ec {
> struct mutex lock;
> wait_queue_head_t wait;
> struct list_head list;
> + atomic_t irq_count;
> u8 handlers_installed;
> } *boot_ec, *first_ec;
>
> @@ -181,6 +182,8 @@ static int acpi_ec_wait(struct acpi_ec *ec, enum
> ec_event event, int force_poll)
> {
> int ret = 0;
>
> + atomic_set(&ec->irq_count, 0);
> +
> if (unlikely(event == ACPI_EC_EVENT_OBF_1 &&
> test_bit(EC_FLAGS_NO_OBF1_GPE, &ec->flags)))
> force_poll = 1;
> @@ -227,6 +230,7 @@ static int acpi_ec_wait(struct acpi_ec *ec, enum
> ec_event event, int force_poll)
> while (time_before(jiffies, delay)) {
> if (acpi_ec_check_status(ec, event))
> goto end;
> + msleep(5);
> }
> }
> pr_err(PREFIX "acpi_ec_wait timeout,"
> @@ -529,6 +533,13 @@ static u32 acpi_ec_gpe_handler(void *data)
> struct acpi_ec *ec = data;
>
> pr_debug(PREFIX "~~~> interrupt\n");
> + atomic_inc(&ec->irq_count);
> + if (atomic_read(&ec->irq_count) > 5) {
> + pr_err(PREFIX "GPE storm detected, disabling EC GPE\n");
> + acpi_disable_gpe(NULL, ec->gpe, ACPI_ISR);
> + clear_bit(EC_FLAGS_GPE_MODE, &ec->flags);
> + return ACPI_INTERRUPT_HANDLED;
> + }
> clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags);
> if (test_bit(EC_FLAGS_GPE_MODE, &ec->flags))
> wake_up(&ec->wait);
>
>
Hi Guillaume,
Please check if the patch to call _PSW methods, attached to bug #9998
helps to reduce number of ACPI interrupts if you revert the 2c81ce4c9c3
Thanks,
Alex.
Guillaume Chazarain wrote:
> Hi,
>
> There is an ACPI regression in 2.6.25-rc6, which causes the ACPI keys
> to stop working on my laptop, an Asus V6VA. git bisect identified the
> appended commit as guilty, and reverting it indeed fixes the problem
> for me. Attached are my .config, a good dmesg and a bad one. The diff
> between both dmesg reveals this interesting hunk:
>
> @@ -121,8 +121,9 @@
> ACPI: (supports S0 S1 S3 S4 S5)
> ACPI: Using IOAPIC for interrupt routing
> ACPI: EC: non-query interrupt received, switching to interrupt mode
> +ACPI: EC: GPE storm detected, disabling EC GPE
> ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
> -ACPI: EC: driver started in interrupt mode
> +ACPI: EC: driver started in poll mode
> ACPI: PCI Root Bridge [PCI0] (0000:00)
> pci 0000:00:1f.0: Enabled ICH6/i801 SMBus device
> pci 0000:00:1f.0: quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
>
>
> Thanks.
>
>
> commit 2c81ce4c9c37b910210f2640c28e98a0c398dc26
> Author: Alexey Starikovskiy <[email protected]>
> Date: Tue Mar 11 13:30:00 2008 -0400
>
> ACPI: EC: Handle IRQ storm on Acer laptops
>
> On some Acer systems, the HW fails to clear the GPE source,
> causing an interrupt storm.
>
> So in EC interrupt mode, we count how many interrupts we
> receive when waiting. If we get more than 5, we give
> up on interrupt mode and revert to polling mode.
>
> Also, for polling mode to work on Acers, we need
> to insert a delay.
>
> Signed-off-by: Alexey Starikovskiy <[email protected]>
> Signed-off-by: Len Brown <[email protected]>
>
> diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> index caf873c..2c77359 100644
> --- a/drivers/acpi/ec.c
> +++ b/drivers/acpi/ec.c
> @@ -129,6 +129,7 @@ static struct acpi_ec {
> struct mutex lock;
> wait_queue_head_t wait;
> struct list_head list;
> + atomic_t irq_count;
> u8 handlers_installed;
> } *boot_ec, *first_ec;
>
> @@ -181,6 +182,8 @@ static int acpi_ec_wait(struct acpi_ec *ec, enum
> ec_event event, int force_poll)
> {
> int ret = 0;
>
> + atomic_set(&ec->irq_count, 0);
> +
> if (unlikely(event == ACPI_EC_EVENT_OBF_1 &&
> test_bit(EC_FLAGS_NO_OBF1_GPE, &ec->flags)))
> force_poll = 1;
> @@ -227,6 +230,7 @@ static int acpi_ec_wait(struct acpi_ec *ec, enum
> ec_event event, int force_poll)
> while (time_before(jiffies, delay)) {
> if (acpi_ec_check_status(ec, event))
> goto end;
> + msleep(5);
> }
> }
> pr_err(PREFIX "acpi_ec_wait timeout,"
> @@ -529,6 +533,13 @@ static u32 acpi_ec_gpe_handler(void *data)
> struct acpi_ec *ec = data;
>
> pr_debug(PREFIX "~~~> interrupt\n");
> + atomic_inc(&ec->irq_count);
> + if (atomic_read(&ec->irq_count) > 5) {
> + pr_err(PREFIX "GPE storm detected, disabling EC GPE\n");
> + acpi_disable_gpe(NULL, ec->gpe, ACPI_ISR);
> + clear_bit(EC_FLAGS_GPE_MODE, &ec->flags);
> + return ACPI_INTERRUPT_HANDLED;
> + }
> clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags);
> if (test_bit(EC_FLAGS_GPE_MODE, &ec->flags))
> wake_up(&ec->wait);
>
>
Hi Guillaume,
Thanks for tests, it looks like call_psw_on_capable_devices.patch does not
help at all, and we should just revert the offending patch.
Sorry for the toruble,
Alex.
Guillaume Chazarain wrote:
> Hi Alexey,
>
> Thanks for your assistance. Here are the results of various tests:
>
> === vanilla:
> CPU0
> 0: 14637 IO-APIC-edge timer
> 1: 213 IO-APIC-edge i8042
> 3: 2 IO-APIC-edge
> 8: 1 IO-APIC-edge rtc
> 9: 318 IO-APIC-fasteoi acpi
> 12: 3534 IO-APIC-edge i8042
> 14: 12481 IO-APIC-edge ata_piix
> 15: 0 IO-APIC-edge ata_piix
> 16: 14609 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
> radeon@pci:0000:01:00.0
> 17: 5681 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb4, sdhc0:slot0, eth0
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 0 IO-APIC-fasteoi Intel ICH6 Modem
> 23: 4 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 22742 Local timer interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
> MIS: 0
>
> ACPI keys don't work at all
>
> === 2c81ce4c9c3 reverted:
>
> CPU0
> 0: 13379 IO-APIC-edge timer
> 1: 205 IO-APIC-edge i8042
> 3: 2 IO-APIC-edge
> 8: 1 IO-APIC-edge rtc
> 9: 3599 IO-APIC-fasteoi acpi
> 12: 3654 IO-APIC-edge i8042
> 14: 13034 IO-APIC-edge ata_piix
> 15: 0 IO-APIC-edge ata_piix
> 16: 14073 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
> radeon@pci:0000:01:00.0
> 17: 7855 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb4, eth0, sdhc0:slot0
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 0 IO-APIC-fasteoi Intel ICH6 Modem
> 23: 4 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 22153 Local timer interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
> MIS: 0
>
> ACPI keys work fine.
>
> === 2c81ce4c9c3 reverted + call_psw_on_capable_devices.patch
>
> CPU0
> 0: 12372 IO-APIC-edge timer
> 1: 195 IO-APIC-edge i8042
> 3: 2 IO-APIC-edge
> 8: 1 IO-APIC-edge rtc
> 9: 7976 IO-APIC-fasteoi acpi
> 12: 1824 IO-APIC-edge i8042
> 14: 12168 IO-APIC-edge ata_piix
> 15: 0 IO-APIC-edge ata_piix
> 16: 11829 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
> radeon@pci:0000:01:00.0
> 17: 4803 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb4, sdhc0:slot0, eth0
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 0 IO-APIC-fasteoi Intel ICH6 Modem
> 23: 58 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 21962 Local timer interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
> MIS: 0
>
> ACPI keys work fine.
>
> === dont_disable_ec_gpe_completely_at_storm.patch
>
> CPU0
> 0: 19657 IO-APIC-edge timer
> 1: 434 IO-APIC-edge i8042
> 3: 2 IO-APIC-edge
> 8: 1 IO-APIC-edge rtc
> 9: 3310 IO-APIC-fasteoi acpi
> 12: 7224 IO-APIC-edge i8042
> 14: 13055 IO-APIC-edge ata_piix
> 15: 0 IO-APIC-edge ata_piix
> 16: 18637 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
> radeon@pci:0000:01:00.0
> 17: 7281 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb4, eth0, sdhc0:slot0
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 0 IO-APIC-fasteoi Intel ICH6 Modem
> 23: 4 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 26645 Local timer interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
> MIS: 0
>
> dmesg contains:
> ACPI: EC: GPE storm detected, throttle EC GPE
> ACPI: EC: missing write data confirmation, don't expect it any longer.
>
> ACPI keys quite work but are very laggy (in the order of seconds).
>
>
> Conclusion: I never experienced acpi interrupts flood in any case, in
> vanilla the interrupt count is much lower but then there are no
> interrupts even when I press acpi keys.
> dont_disable_ec_gpe_completely_at_storm.patch does not correctly fix
> the problem for me. When 2c81ce4c9c3 is reverted,
> call_psw_on_capable_devices.patch makes no difference as it still
> works well.
>
> Thanks.
>
Hi Guilaume,
May I ask you for one more favor?
Could you please uncomment DEBUG at the beginning of drivers/acpi/ec.c
and send me dmesg (or, better, attach it to bugzilla.kernel.org #9998) with
the reverted offender patch?
Thanks,
Alex.
Guillaume Chazarain wrote:
> Hi Alexey,
>
> Thanks for your assistance. Here are the results of various tests:
>
> === vanilla:
> CPU0
> 0: 14637 IO-APIC-edge timer
> 1: 213 IO-APIC-edge i8042
> 3: 2 IO-APIC-edge
> 8: 1 IO-APIC-edge rtc
> 9: 318 IO-APIC-fasteoi acpi
> 12: 3534 IO-APIC-edge i8042
> 14: 12481 IO-APIC-edge ata_piix
> 15: 0 IO-APIC-edge ata_piix
> 16: 14609 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
> radeon@pci:0000:01:00.0
> 17: 5681 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb4, sdhc0:slot0, eth0
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 0 IO-APIC-fasteoi Intel ICH6 Modem
> 23: 4 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 22742 Local timer interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
> MIS: 0
>
> ACPI keys don't work at all
>
> === 2c81ce4c9c3 reverted:
>
> CPU0
> 0: 13379 IO-APIC-edge timer
> 1: 205 IO-APIC-edge i8042
> 3: 2 IO-APIC-edge
> 8: 1 IO-APIC-edge rtc
> 9: 3599 IO-APIC-fasteoi acpi
> 12: 3654 IO-APIC-edge i8042
> 14: 13034 IO-APIC-edge ata_piix
> 15: 0 IO-APIC-edge ata_piix
> 16: 14073 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
> radeon@pci:0000:01:00.0
> 17: 7855 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb4, eth0, sdhc0:slot0
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 0 IO-APIC-fasteoi Intel ICH6 Modem
> 23: 4 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 22153 Local timer interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
> MIS: 0
>
> ACPI keys work fine.
>
> === 2c81ce4c9c3 reverted + call_psw_on_capable_devices.patch
>
> CPU0
> 0: 12372 IO-APIC-edge timer
> 1: 195 IO-APIC-edge i8042
> 3: 2 IO-APIC-edge
> 8: 1 IO-APIC-edge rtc
> 9: 7976 IO-APIC-fasteoi acpi
> 12: 1824 IO-APIC-edge i8042
> 14: 12168 IO-APIC-edge ata_piix
> 15: 0 IO-APIC-edge ata_piix
> 16: 11829 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
> radeon@pci:0000:01:00.0
> 17: 4803 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb4, sdhc0:slot0, eth0
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 0 IO-APIC-fasteoi Intel ICH6 Modem
> 23: 58 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 21962 Local timer interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
> MIS: 0
>
> ACPI keys work fine.
>
> === dont_disable_ec_gpe_completely_at_storm.patch
>
> CPU0
> 0: 19657 IO-APIC-edge timer
> 1: 434 IO-APIC-edge i8042
> 3: 2 IO-APIC-edge
> 8: 1 IO-APIC-edge rtc
> 9: 3310 IO-APIC-fasteoi acpi
> 12: 7224 IO-APIC-edge i8042
> 14: 13055 IO-APIC-edge ata_piix
> 15: 0 IO-APIC-edge ata_piix
> 16: 18637 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
> radeon@pci:0000:01:00.0
> 17: 7281 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb4, eth0, sdhc0:slot0
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 0 IO-APIC-fasteoi Intel ICH6 Modem
> 23: 4 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 26645 Local timer interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
> MIS: 0
>
> dmesg contains:
> ACPI: EC: GPE storm detected, throttle EC GPE
> ACPI: EC: missing write data confirmation, don't expect it any longer.
>
> ACPI keys quite work but are very laggy (in the order of seconds).
>
>
> Conclusion: I never experienced acpi interrupts flood in any case, in
> vanilla the interrupt count is much lower but then there are no
> interrupts even when I press acpi keys.
> dont_disable_ec_gpe_completely_at_storm.patch does not correctly fix
> the problem for me. When 2c81ce4c9c3 is reverted,
> call_psw_on_capable_devices.patch makes no difference as it still
> works well.
>
> Thanks.
>
Tim Elliott wrote:
> I am seeing the same problem on my Lenovo 3000 v100. The function keys
> stopped working.
>
> tim@tim-len:~$ cat /proc/interrupts
> CPU0 CPU1
> 0: 164105 0 IO-APIC-edge timer
> 1: 12560 0 IO-APIC-edge i8042
> 9: 6 0 IO-APIC-fasteoi acpi
> 12: 117534 0 IO-APIC-edge i8042
> 14: 51 0 IO-APIC-edge ide0
> 16: 31 0 IO-APIC-fasteoi uhci_hcd:usb4,
> i915@pci:0000:00:02.0
> 18: 121892 0 IO-APIC-fasteoi uhci_hcd:usb3, iwl3945
> 19: 36197 0 IO-APIC-fasteoi uhci_hcd:usb2, ahci
> 20: 7931 0 IO-APIC-fasteoi eth0
> 22: 11071 0 IO-APIC-fasteoi sdhc0:slot0, HDA Intel
> 23: 5 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5
> NMI: 0 0 Non-maskable interrupts
> LOC: 11296 73879 Local timer interrupts
> RES: 23199 49164 Rescheduling interrupts
> CAL: 297 27033 function call interrupts
> TLB: 838 1286 TLB shootdowns
> TRM: 0 0 Thermal event interrupts
> THR: 0 0 Threshold APIC interrupts
> SPU: 0 0 Spurious interrupts
> ERR: 0
>
> The problem goes away when reverting 2c81ce4c9c37b910210f2640c28e98a0c398dc26
>
> Reverting the above and applying the patch in comment #38 of bug #9998
> also works (http://bugzilla.kernel.org/show_bug.cgi?id=9998).
reverting the above and patch in comment #38 of #9998 are the same thing.
I am really interested if after revert (or application of #38) you notice a
difference in interrupt count before and after applying #37 from #9998.
Thanks,
Alex.
>
> Cheers,
> Tim
>
> On 3/18/08, Alexey Starikovskiy <[email protected]> wrote:
>> Hi Guillaume,
>>
>> Please check if the patch to call _PSW methods, attached to bug #9998
>> helps to reduce number of ACPI interrupts if you revert the 2c81ce4c9c3
>>
>> Thanks,
>> Alex.
>>
>>
>> Guillaume Chazarain wrote:
>> > Hi,
>> >
>> > There is an ACPI regression in 2.6.25-rc6, which causes the ACPI keys
>> > to stop working on my laptop, an Asus V6VA. git bisect identified the
>> > appended commit as guilty, and reverting it indeed fixes the problem
>> > for me. Attached are my .config, a good dmesg and a bad one. The diff
>> > between both dmesg reveals this interesting hunk:
>> >
>> > @@ -121,8 +121,9 @@
>> > ACPI: (supports S0 S1 S3 S4 S5)
>> > ACPI: Using IOAPIC for interrupt routing
>> > ACPI: EC: non-query interrupt received, switching to interrupt mode
>> > +ACPI: EC: GPE storm detected, disabling EC GPE
>> > ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
>> > -ACPI: EC: driver started in interrupt mode
>> > +ACPI: EC: driver started in poll mode
>> > ACPI: PCI Root Bridge [PCI0] (0000:00)
>> > pci 0000:00:1f.0: Enabled ICH6/i801 SMBus device
>> > pci 0000:00:1f.0: quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
>> >
>> >
>> > Thanks.
>> >
>> >
>> > commit 2c81ce4c9c37b910210f2640c28e98a0c398dc26
>> > Author: Alexey Starikovskiy <[email protected]>
>> > Date: Tue Mar 11 13:30:00 2008 -0400
>> >
>> > ACPI: EC: Handle IRQ storm on Acer laptops
>> >
>> > On some Acer systems, the HW fails to clear the GPE source,
>> > causing an interrupt storm.
>> >
>> > So in EC interrupt mode, we count how many interrupts we
>> > receive when waiting. If we get more than 5, we give
>> > up on interrupt mode and revert to polling mode.
>> >
>> > Also, for polling mode to work on Acers, we need
>> > to insert a delay.
>> >
>> > Signed-off-by: Alexey Starikovskiy <[email protected]>
>> > Signed-off-by: Len Brown <[email protected]>
>> >
>> > diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
>> > index caf873c..2c77359 100644
>> > --- a/drivers/acpi/ec.c
>> > +++ b/drivers/acpi/ec.c
>> > @@ -129,6 +129,7 @@ static struct acpi_ec {
>> > struct mutex lock;
>> > wait_queue_head_t wait;
>> > struct list_head list;
>> > + atomic_t irq_count;
>> > u8 handlers_installed;
>> > } *boot_ec, *first_ec;
>> >
>> > @@ -181,6 +182,8 @@ static int acpi_ec_wait(struct acpi_ec *ec, enum
>> > ec_event event, int force_poll)
>> > {
>> > int ret = 0;
>> >
>> > + atomic_set(&ec->irq_count, 0);
>> > +
>> > if (unlikely(event == ACPI_EC_EVENT_OBF_1 &&
>> > test_bit(EC_FLAGS_NO_OBF1_GPE, &ec->flags)))
>> > force_poll = 1;
>> > @@ -227,6 +230,7 @@ static int acpi_ec_wait(struct acpi_ec *ec, enum
>> > ec_event event, int force_poll)
>> > while (time_before(jiffies, delay)) {
>> > if (acpi_ec_check_status(ec, event))
>> > goto end;
>> > + msleep(5);
>> > }
>> > }
>> > pr_err(PREFIX "acpi_ec_wait timeout,"
>> > @@ -529,6 +533,13 @@ static u32 acpi_ec_gpe_handler(void *data)
>> > struct acpi_ec *ec = data;
>> >
>> > pr_debug(PREFIX "~~~> interrupt\n");
>> > + atomic_inc(&ec->irq_count);
>> > + if (atomic_read(&ec->irq_count) > 5) {
>> > + pr_err(PREFIX "GPE storm detected, disabling EC GPE\n");
>> > + acpi_disable_gpe(NULL, ec->gpe, ACPI_ISR);
>> > + clear_bit(EC_FLAGS_GPE_MODE, &ec->flags);
>> > + return ACPI_INTERRUPT_HANDLED;
>> > + }
>> > clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags);
>> > if (test_bit(EC_FLAGS_GPE_MODE, &ec->flags))
>> > wake_up(&ec->wait);
>> >
>> >
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
On Tuesday, 18 of March 2008, Alexey Starikovskiy wrote:
> Tim Elliott wrote:
> > I am seeing the same problem on my Lenovo 3000 v100. The function keys
> > stopped working.
> >
> > tim@tim-len:~$ cat /proc/interrupts
> > CPU0 CPU1
> > 0: 164105 0 IO-APIC-edge timer
> > 1: 12560 0 IO-APIC-edge i8042
> > 9: 6 0 IO-APIC-fasteoi acpi
> > 12: 117534 0 IO-APIC-edge i8042
> > 14: 51 0 IO-APIC-edge ide0
> > 16: 31 0 IO-APIC-fasteoi uhci_hcd:usb4,
> > i915@pci:0000:00:02.0
> > 18: 121892 0 IO-APIC-fasteoi uhci_hcd:usb3, iwl3945
> > 19: 36197 0 IO-APIC-fasteoi uhci_hcd:usb2, ahci
> > 20: 7931 0 IO-APIC-fasteoi eth0
> > 22: 11071 0 IO-APIC-fasteoi sdhc0:slot0, HDA Intel
> > 23: 5 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5
> > NMI: 0 0 Non-maskable interrupts
> > LOC: 11296 73879 Local timer interrupts
> > RES: 23199 49164 Rescheduling interrupts
> > CAL: 297 27033 function call interrupts
> > TLB: 838 1286 TLB shootdowns
> > TRM: 0 0 Thermal event interrupts
> > THR: 0 0 Threshold APIC interrupts
> > SPU: 0 0 Spurious interrupts
> > ERR: 0
> >
> > The problem goes away when reverting 2c81ce4c9c37b910210f2640c28e98a0c398dc26
> >
> > Reverting the above and applying the patch in comment #38 of bug #9998
> > also works (http://bugzilla.kernel.org/show_bug.cgi?id=9998).
> reverting the above and patch in comment #38 of #9998 are the same thing.
> I am really interested if after revert (or application of #38) you notice a
> difference in interrupt count before and after applying #37 from #9998.
What is the relationship between this problem and bug #10279?
Rafael
Hi Guillaume,
There are two new patches in #9998.
Could you check if they help without reverting of patch 2c81ce4c9c3?
Thanks,
Alex.
Guillaume Chazarain wrote:
> Hi Alexey,
>
> Thanks for your assistance. Here are the results of various tests:
>
> === vanilla:
> CPU0
> 0: 14637 IO-APIC-edge timer
> 1: 213 IO-APIC-edge i8042
> 3: 2 IO-APIC-edge
> 8: 1 IO-APIC-edge rtc
> 9: 318 IO-APIC-fasteoi acpi
> 12: 3534 IO-APIC-edge i8042
> 14: 12481 IO-APIC-edge ata_piix
> 15: 0 IO-APIC-edge ata_piix
> 16: 14609 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
> radeon@pci:0000:01:00.0
> 17: 5681 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb4, sdhc0:slot0, eth0
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 0 IO-APIC-fasteoi Intel ICH6 Modem
> 23: 4 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 22742 Local timer interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
> MIS: 0
>
> ACPI keys don't work at all
>
> === 2c81ce4c9c3 reverted:
>
> CPU0
> 0: 13379 IO-APIC-edge timer
> 1: 205 IO-APIC-edge i8042
> 3: 2 IO-APIC-edge
> 8: 1 IO-APIC-edge rtc
> 9: 3599 IO-APIC-fasteoi acpi
> 12: 3654 IO-APIC-edge i8042
> 14: 13034 IO-APIC-edge ata_piix
> 15: 0 IO-APIC-edge ata_piix
> 16: 14073 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
> radeon@pci:0000:01:00.0
> 17: 7855 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb4, eth0, sdhc0:slot0
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 0 IO-APIC-fasteoi Intel ICH6 Modem
> 23: 4 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 22153 Local timer interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
> MIS: 0
>
> ACPI keys work fine.
>
> === 2c81ce4c9c3 reverted + call_psw_on_capable_devices.patch
>
> CPU0
> 0: 12372 IO-APIC-edge timer
> 1: 195 IO-APIC-edge i8042
> 3: 2 IO-APIC-edge
> 8: 1 IO-APIC-edge rtc
> 9: 7976 IO-APIC-fasteoi acpi
> 12: 1824 IO-APIC-edge i8042
> 14: 12168 IO-APIC-edge ata_piix
> 15: 0 IO-APIC-edge ata_piix
> 16: 11829 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
> radeon@pci:0000:01:00.0
> 17: 4803 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb4, sdhc0:slot0, eth0
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 0 IO-APIC-fasteoi Intel ICH6 Modem
> 23: 58 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 21962 Local timer interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
> MIS: 0
>
> ACPI keys work fine.
>
> === dont_disable_ec_gpe_completely_at_storm.patch
>
> CPU0
> 0: 19657 IO-APIC-edge timer
> 1: 434 IO-APIC-edge i8042
> 3: 2 IO-APIC-edge
> 8: 1 IO-APIC-edge rtc
> 9: 3310 IO-APIC-fasteoi acpi
> 12: 7224 IO-APIC-edge i8042
> 14: 13055 IO-APIC-edge ata_piix
> 15: 0 IO-APIC-edge ata_piix
> 16: 18637 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
> radeon@pci:0000:01:00.0
> 17: 7281 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
> 18: 0 IO-APIC-fasteoi uhci_hcd:usb4, eth0, sdhc0:slot0
> 19: 0 IO-APIC-fasteoi uhci_hcd:usb3
> 20: 0 IO-APIC-fasteoi Intel ICH6 Modem
> 23: 4 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
> NMI: 0 Non-maskable interrupts
> LOC: 26645 Local timer interrupts
> TRM: 0 Thermal event interrupts
> SPU: 0 Spurious interrupts
> ERR: 0
> MIS: 0
>
> dmesg contains:
> ACPI: EC: GPE storm detected, throttle EC GPE
> ACPI: EC: missing write data confirmation, don't expect it any longer.
>
> ACPI keys quite work but are very laggy (in the order of seconds).
>
>
> Conclusion: I never experienced acpi interrupts flood in any case, in
> vanilla the interrupt count is much lower but then there are no
> interrupts even when I press acpi keys.
> dont_disable_ec_gpe_completely_at_storm.patch does not correctly fix
> the problem for me. When 2c81ce4c9c3 is reverted,
> call_psw_on_capable_devices.patch makes no difference as it still
> works well.
>
> Thanks.
>
I am seeing the same problem on my Lenovo 3000 v100. The function keys
stopped working.
tim@tim-len:~$ cat /proc/interrupts
CPU0 CPU1
0: 164105 0 IO-APIC-edge timer
1: 12560 0 IO-APIC-edge i8042
9: 6 0 IO-APIC-fasteoi acpi
12: 117534 0 IO-APIC-edge i8042
14: 51 0 IO-APIC-edge ide0
16: 31 0 IO-APIC-fasteoi uhci_hcd:usb4,
i915@pci:0000:00:02.0
18: 121892 0 IO-APIC-fasteoi uhci_hcd:usb3, iwl3945
19: 36197 0 IO-APIC-fasteoi uhci_hcd:usb2, ahci
20: 7931 0 IO-APIC-fasteoi eth0
22: 11071 0 IO-APIC-fasteoi sdhc0:slot0, HDA Intel
23: 5 0 IO-APIC-fasteoi uhci_hcd:usb1, ehci_hcd:usb5
NMI: 0 0 Non-maskable interrupts
LOC: 11296 73879 Local timer interrupts
RES: 23199 49164 Rescheduling interrupts
CAL: 297 27033 function call interrupts
TLB: 838 1286 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
SPU: 0 0 Spurious interrupts
ERR: 0
The problem goes away when reverting 2c81ce4c9c37b910210f2640c28e98a0c398dc26
Reverting the above and applying the patch in comment #38 of bug #9998
also works (http://bugzilla.kernel.org/show_bug.cgi?id=9998).
Cheers,
Tim
On 3/18/08, Alexey Starikovskiy <[email protected]> wrote:
> Hi Guillaume,
>
> Please check if the patch to call _PSW methods, attached to bug #9998
> helps to reduce number of ACPI interrupts if you revert the 2c81ce4c9c3
>
> Thanks,
> Alex.
>
>
> Guillaume Chazarain wrote:
> > Hi,
> >
> > There is an ACPI regression in 2.6.25-rc6, which causes the ACPI keys
> > to stop working on my laptop, an Asus V6VA. git bisect identified the
> > appended commit as guilty, and reverting it indeed fixes the problem
> > for me. Attached are my .config, a good dmesg and a bad one. The diff
> > between both dmesg reveals this interesting hunk:
> >
> > @@ -121,8 +121,9 @@
> > ACPI: (supports S0 S1 S3 S4 S5)
> > ACPI: Using IOAPIC for interrupt routing
> > ACPI: EC: non-query interrupt received, switching to interrupt mode
> > +ACPI: EC: GPE storm detected, disabling EC GPE
> > ACPI: EC: GPE = 0x1c, I/O: command/status = 0x66, data = 0x62
> > -ACPI: EC: driver started in interrupt mode
> > +ACPI: EC: driver started in poll mode
> > ACPI: PCI Root Bridge [PCI0] (0000:00)
> > pci 0000:00:1f.0: Enabled ICH6/i801 SMBus device
> > pci 0000:00:1f.0: quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO
> >
> >
> > Thanks.
> >
> >
> > commit 2c81ce4c9c37b910210f2640c28e98a0c398dc26
> > Author: Alexey Starikovskiy <[email protected]>
> > Date: Tue Mar 11 13:30:00 2008 -0400
> >
> > ACPI: EC: Handle IRQ storm on Acer laptops
> >
> > On some Acer systems, the HW fails to clear the GPE source,
> > causing an interrupt storm.
> >
> > So in EC interrupt mode, we count how many interrupts we
> > receive when waiting. If we get more than 5, we give
> > up on interrupt mode and revert to polling mode.
> >
> > Also, for polling mode to work on Acers, we need
> > to insert a delay.
> >
> > Signed-off-by: Alexey Starikovskiy <[email protected]>
> > Signed-off-by: Len Brown <[email protected]>
> >
> > diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
> > index caf873c..2c77359 100644
> > --- a/drivers/acpi/ec.c
> > +++ b/drivers/acpi/ec.c
> > @@ -129,6 +129,7 @@ static struct acpi_ec {
> > struct mutex lock;
> > wait_queue_head_t wait;
> > struct list_head list;
> > + atomic_t irq_count;
> > u8 handlers_installed;
> > } *boot_ec, *first_ec;
> >
> > @@ -181,6 +182,8 @@ static int acpi_ec_wait(struct acpi_ec *ec, enum
> > ec_event event, int force_poll)
> > {
> > int ret = 0;
> >
> > + atomic_set(&ec->irq_count, 0);
> > +
> > if (unlikely(event == ACPI_EC_EVENT_OBF_1 &&
> > test_bit(EC_FLAGS_NO_OBF1_GPE, &ec->flags)))
> > force_poll = 1;
> > @@ -227,6 +230,7 @@ static int acpi_ec_wait(struct acpi_ec *ec, enum
> > ec_event event, int force_poll)
> > while (time_before(jiffies, delay)) {
> > if (acpi_ec_check_status(ec, event))
> > goto end;
> > + msleep(5);
> > }
> > }
> > pr_err(PREFIX "acpi_ec_wait timeout,"
> > @@ -529,6 +533,13 @@ static u32 acpi_ec_gpe_handler(void *data)
> > struct acpi_ec *ec = data;
> >
> > pr_debug(PREFIX "~~~> interrupt\n");
> > + atomic_inc(&ec->irq_count);
> > + if (atomic_read(&ec->irq_count) > 5) {
> > + pr_err(PREFIX "GPE storm detected, disabling EC GPE\n");
> > + acpi_disable_gpe(NULL, ec->gpe, ACPI_ISR);
> > + clear_bit(EC_FLAGS_GPE_MODE, &ec->flags);
> > + return ACPI_INTERRUPT_HANDLED;
> > + }
> > clear_bit(EC_FLAGS_WAIT_GPE, &ec->flags);
> > if (test_bit(EC_FLAGS_GPE_MODE, &ec->flags))
> > wake_up(&ec->wait);
> >
> >
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Hi Alexey,
Thanks for your assistance. Here are the results of various tests:
=== vanilla:
CPU0
0: 14637 IO-APIC-edge timer
1: 213 IO-APIC-edge i8042
3: 2 IO-APIC-edge
8: 1 IO-APIC-edge rtc
9: 318 IO-APIC-fasteoi acpi
12: 3534 IO-APIC-edge i8042
14: 12481 IO-APIC-edge ata_piix
15: 0 IO-APIC-edge ata_piix
16: 14609 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
radeon@pci:0000:01:00.0
17: 5681 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
18: 0 IO-APIC-fasteoi uhci_hcd:usb4, sdhc0:slot0, eth0
19: 0 IO-APIC-fasteoi uhci_hcd:usb3
20: 0 IO-APIC-fasteoi Intel ICH6 Modem
23: 4 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
NMI: 0 Non-maskable interrupts
LOC: 22742 Local timer interrupts
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0
MIS: 0
ACPI keys don't work at all
=== 2c81ce4c9c3 reverted:
CPU0
0: 13379 IO-APIC-edge timer
1: 205 IO-APIC-edge i8042
3: 2 IO-APIC-edge
8: 1 IO-APIC-edge rtc
9: 3599 IO-APIC-fasteoi acpi
12: 3654 IO-APIC-edge i8042
14: 13034 IO-APIC-edge ata_piix
15: 0 IO-APIC-edge ata_piix
16: 14073 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
radeon@pci:0000:01:00.0
17: 7855 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
18: 0 IO-APIC-fasteoi uhci_hcd:usb4, eth0, sdhc0:slot0
19: 0 IO-APIC-fasteoi uhci_hcd:usb3
20: 0 IO-APIC-fasteoi Intel ICH6 Modem
23: 4 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
NMI: 0 Non-maskable interrupts
LOC: 22153 Local timer interrupts
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0
MIS: 0
ACPI keys work fine.
=== 2c81ce4c9c3 reverted + call_psw_on_capable_devices.patch
CPU0
0: 12372 IO-APIC-edge timer
1: 195 IO-APIC-edge i8042
3: 2 IO-APIC-edge
8: 1 IO-APIC-edge rtc
9: 7976 IO-APIC-fasteoi acpi
12: 1824 IO-APIC-edge i8042
14: 12168 IO-APIC-edge ata_piix
15: 0 IO-APIC-edge ata_piix
16: 11829 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
radeon@pci:0000:01:00.0
17: 4803 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
18: 0 IO-APIC-fasteoi uhci_hcd:usb4, sdhc0:slot0, eth0
19: 0 IO-APIC-fasteoi uhci_hcd:usb3
20: 0 IO-APIC-fasteoi Intel ICH6 Modem
23: 58 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
NMI: 0 Non-maskable interrupts
LOC: 21962 Local timer interrupts
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0
MIS: 0
ACPI keys work fine.
=== dont_disable_ec_gpe_completely_at_storm.patch
CPU0
0: 19657 IO-APIC-edge timer
1: 434 IO-APIC-edge i8042
3: 2 IO-APIC-edge
8: 1 IO-APIC-edge rtc
9: 3310 IO-APIC-fasteoi acpi
12: 7224 IO-APIC-edge i8042
14: 13055 IO-APIC-edge ata_piix
15: 0 IO-APIC-edge ata_piix
16: 18637 IO-APIC-fasteoi uhci_hcd:usb5, firewire_ohci,
radeon@pci:0000:01:00.0
17: 7281 IO-APIC-fasteoi yenta, ipw2200, Intel ICH6
18: 0 IO-APIC-fasteoi uhci_hcd:usb4, eth0, sdhc0:slot0
19: 0 IO-APIC-fasteoi uhci_hcd:usb3
20: 0 IO-APIC-fasteoi Intel ICH6 Modem
23: 4 IO-APIC-fasteoi ehci_hcd:usb1, uhci_hcd:usb2
NMI: 0 Non-maskable interrupts
LOC: 26645 Local timer interrupts
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0
MIS: 0
dmesg contains:
ACPI: EC: GPE storm detected, throttle EC GPE
ACPI: EC: missing write data confirmation, don't expect it any longer.
ACPI keys quite work but are very laggy (in the order of seconds).
Conclusion: I never experienced acpi interrupts flood in any case, in
vanilla the interrupt count is much lower but then there are no
interrupts even when I press acpi keys.
dont_disable_ec_gpe_completely_at_storm.patch does not correctly fix
the problem for me. When 2c81ce4c9c3 is reverted,
call_psw_on_capable_devices.patch makes no difference as it still
works well.
Thanks.
--
Guillaume