Bug 2643

I've also noticed the same thing happen with my notebook (Fujitsu S6010).  If
you remove the module, suspend and resume, the hardware control buttons work again.

Trying to remove the button module segfaults rmmod and the system goes to a
highly unstable state (spontaneous lockups without any detectable pattern)

upgraded to 2.6.6-mm1 without any change

Hardware Environment: IBM ThinkPad T30 (See
http://www.2good.nu/thinkpad_t30_fc2/ for details.)
Software Environment: kernel-2.6.5-1.358
Problem Description:

I have the same problem on my system.

I filed http://bugzilla.kernel.org/show_bug.cgi?id=2744 for what happens to me
when I unload the "button" module.

Created attachment 3125 [details]
proposed patch

Could you please try this workaround? i have the same issue in T40. After apply
this patch, ACPI events come back. Thanks.

The patch works for me (S6010).

*** Bug 2596 has been marked as a duplicate of this bug. ***

applied the patch to 2.6.7 and got a copiler warning:

drivers/acpi/sleep/main.c: In function `acpi_pm_finish':
drivers/acpi/sleep/main.c: warning: implicit declaration of function
`acpi_pic_sci_set_trigger'

tested the resulting kernel (2.6.7 with only this patch applied)
* entering suspend (S3)
* resuming 
heureka!! - got my buttons back :-)

Created attachment 3221 [details]
proposed patch

Ok, updated one

acpi_sci_flags seems to be marked as __initdata, so when I resume trigger tends
to be 0, which results in my interrupt being set to edge triggered rather than
level triggered. Removing __initdata from the declaration in
arch/i386/kernel/acpi/boot.c seems to fix this, and I get reliable functionality.

Created attachment 3247 [details]
proposed patch

Thanks pointed out. I should have check it carefully :(.

According to the discussion in mail-list, the patch is not sufficient. Besides 
ACPI interrupt, other level trigger IRQ should be reset as well. A final fix 
should set correct polarity for all IRQ. Will try later.

Created attachment 3263 [details]
More reasonable patch

Besides ACPI, other level triggered IRQ such as some PCI interrupts should be
reset to level trigger after resume. The patch handles this.

David, your patch fixed my problem with network card not working after resume 
from S3 (see http://bugme.osdl.org/show_bug.cgi?id=2438). Thank you very much! 

applied to 2.6.7 vanilla kernel ...

... you are a hero!

fixed the ACPI-events (this bug) as well as the network card bug
(http://bugzilla.kernel.org/show_bug.cgi?id=2438) for me

thanks a lot.

this latest patch worked for me as well, ipw2100 and snd-intel8x0 now work
reliably after an S3 resume.  Thanks!

*** Bug 2438 has been marked as a duplicate of this bug. ***

Created attachment 3274 [details]
patch port to x86_64

Hmm, per Len's comment, port the patch to x86_64.

*** Bug 2965 has been marked as a duplicate of this bug. ***

This doesn't seem to entirely work. After applying it, ACPI tends to stop
working after resume, though other interrupts work correctly. It also seems to
result in two ACPI events happening. The first thing that springs to mind is
that the patch writes back state which indicates a serviced interrupt when there
is actually an interrupt pending - does this seem plausible?

Created attachment 3292 [details]
proposed patch

Len doesn't like the idea to use global variables, so do a small clean. 
Matthew, can you claify your problem? Thanks

After applying this patch, ACPI interrupts stop working again. The initial patch
(simply setting the trigger value of the ACPI interrupt) works - I get
interrupts after resume. Other interrupts work correctly, including interrupts
that don't work without this patch.

The first thing that springs to mind is that restoring the state of the 8259
interferes with a pending interrupt (ie, there's an ACPI interrupt raised
because the user has pressed the power button to resume, but the patch
overwrites that state with one indicating that the event has been handled), but
I'm not familiar enough with PC hardware to know if this is plausible.

The patch just sets the level/edger trigger, it doesn't involve pending bit. I 
guess your system has wrong ACPI trigger, could you please send the complete 
dmesg to me (after resume)? Thanks.

Created attachment 3297 [details]
dmesg output

dmesg from boot to resume. After resume, IRQ 9 doesn't increment for lid switch
events or anything requiring the Fn key to be held down. The power button does
cause IRQ 9 to increment, and also generates an ACPI event. Interestingly, the
other system hotkeys (like brightness) also stop working, despite not
generating ACPI events normally.

The first patch for this bug (the acpi_sci_set_trigger one) allows me to get
correct behaviour after resume, so something is causing a difference between
the two.

>The power button does cause IRQ 9 to increment
Hmm,it appears that it's another problem. But I'm curious why first patch 
makes your system work. It should have same behavior. Suspect it's wakeup GPE 
problem. could you please try latest ACPI test tree (with the patch). There is 
big change for wakeup GPE. Thanks

This is more interesting. It seems that removing the resume code from the 8259 driver's device struct and instead calling it from sleep/main.c (in the same place as the original patch put the acpi_pic_sci_trigger_interrupt() call) results in it working, so it seems to be some sort of timing issue. Looking more closely at my ACPI table, it's things on the embedded controller that stop working - the power button isn't connected to that, so continues working.

What happens if the trigger style gets rewritten while an interrupt is pending?

Great finding. I guess 'acpi_leave_sleep_state' did some wrong operation which 
causes GPE interrupts lost. previous patch is invoked 
before 'acpi_leave_sleep_state', so no side effect. I will dig it deeply.

Created attachment 3298 [details]
Use ACPI_NOT_ISR

This patch fixes things

Created attachment 3310 [details]
dmesg. Boot + suspend/resume

I experience a similar problem on my Acer Travelmate 803. Some IRQs seem dead  
after S3, the devices do not work. I tried all patches uploaded here, but no  
one works. Instead they prevent the system from resuming if ipw2100 is loaded.  
  
Passing pci=noacpi to the kernel improves the behavior, but there are still  
problems. I can use wlan(ipw2100) and usb OR sound(i810_audio or snd-intel8x0)  
and the ethernt card(b44), but I can't use sound AND wlan / usb AND ethernet.  
  
dmesg with acpi debug is attached, using 2.6.7 and the patch from 2004-6-29. I  
also tried the other patches.  
  

This patch breaks suspend to ram (s3_bios) on ASUS M2N with i855GM chipset.

See http://article.gmane.org/gmane.linux.acpi.devel/8968 for more info.

Should this bug be reopened?

The code in 2.6.8-rc2-mm1 does not work for me ... although it suspends/resumes
very fast i cannot make use of it if I do not have my interrupts :( Removeing
the latest patch from this site and trying the older one does not help too. I
currently try to figure out if this is because of the acpi updates or because of
any other updates ..

Should I open a new bug report for this or should this bug be reopened?

The patches don't work on my Thinkpad 570E, too. It just isn't able to wake up 
any more (there's simply no reaction when I switch the power button as 
usually). So I think, it should be reopened and further investigated...

The NOT_ISR patch is in a different form in 2.6.8-rc2-mm1. Those people who are
seeing regressions caused by the patches in this bug might want to try the
bk-acpi patch from -mm1 / broken-out. Some interrupt issues may also be helped
with kernel parameters "acpi=noirq" or, if that doesn't work, "pci=noacpi".

thanks, with acpi=noirq it works perfectly

But is this something to worry about?

[ACPI Debug] Buffer: Length 0x06ACPI: PCI Interrupt Link [LNKH] (IRQs 5) *11
ACPI: Embedded Controller [EC0] (gpe 28)
PCI: Probing PCI hardware
PCI: Using IRQ router PIIX/ICH [8086/2440] at 0000:00:1f.0
PCI: IRQ 0 for device 0000:02:00.0 doesn't match PIRQ mask - try pci=usepirqmask
PCI: IRQ 0 for device 0000:02:00.1 doesn't match PIRQ mask - try pci=usepirqmask
Simple Boot Flag at 0x36 set to 0x1
Machine check exception polling timer started.


Should I add pci=usepirqmask?

That sounds a little odd, but I don't think it's anything to worry about. Due to
the fact that the code uses 0 to indicate that an IRQ assignment is needed, it
should fall through and continue handling IRQ routing. The net effect is that
this block does the same thing whether or not that flag is defined:

        if (!((1 << newirq) & mask)) {
                if ( pci_probe & PCI_USE_PIRQ_MASK) newirq = 0;
                else printk(KERN_WARNING "PCI: IRQ %i for device %s doesn't
match PIRQ mask - try pci=usepirqmask\n", newirq
, pci_name(dev));
        }