Distribution: Debian unstable Hardware Environment: Sharp PC-MM10 (see bug 2438) Software Environment: debian unstable udev 0.024-7 gcc 3.3.3-2 module-init-tools 3.0-pre10-2 modutils 2.4.26-1 Problem Description: after a suspend/resume cycle the kernel doesen't receive any acpi event (LID, BAT, FF) and the Fn-XX hardware control buttons are disabled (Backlight brightness, speaker volume, screen switch, antenna on/off, etc) Steps to reproduce: suspend to ram (S3) resume try hardware button
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)); }