Bug 2643 - No ACPI Events after Suspend
No ACPI Events after Suspend
Status: CLOSED CODE_FIX
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake
i386 Linux
: P2 normal
Assigned To: Shaohua
:
: 2438 2596 2965 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-05 07:51 UTC by Martin Lorenz
Modified: 2004-10-17 20:18 UTC (History)
15 users (show)

See Also:
Kernel Version: 2.6.6-rc3-mm1
Tree: Mainline
Regression: ---


Attachments
proposed patch (512 bytes, patch)
2004-06-09 23:53 UTC, Shaohua
Details | Diff
proposed patch (1.34 KB, patch)
2004-06-23 03:52 UTC, Shaohua
Details | Diff
proposed patch (1.56 KB, patch)
2004-06-24 18:18 UTC, Shaohua
Details | Diff
More reasonable patch (724 bytes, patch)
2004-06-27 23:13 UTC, Shaohua
Details | Diff
patch port to x86_64 (2.31 KB, patch)
2004-06-29 01:09 UTC, Shaohua
Details | Diff
proposed patch (2.35 KB, patch)
2004-06-30 21:21 UTC, Shaohua
Details | Diff
dmesg output (16.54 KB, text/plain)
2004-07-01 02:06 UTC, Matthew Garrett
Details
Use ACPI_NOT_ISR (582 bytes, patch)
2004-07-02 06:32 UTC, Matthew Garrett
Details | Diff
dmesg. Boot + suspend/resume (15.11 KB, text/plain)
2004-07-06 07:25 UTC, Stefan D
Details

Description Martin Lorenz 2004-05-05 07:51:42 UTC
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
Comment 1 Adrian Yee 2004-05-06 18:48:04 UTC
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.
Comment 2 Martin Lorenz 2004-05-12 11:56:38 UTC
Trying to remove the button module segfaults rmmod and the system goes to a
highly unstable state (spontaneous lockups without any detectable pattern)

Comment 3 Martin Lorenz 2004-05-13 05:31:38 UTC
upgraded to 2.6.6-mm1 without any change
Comment 4 David Eriksson 2004-05-21 06:17:33 UTC
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.
Comment 5 Shaohua 2004-06-09 23:53:49 UTC
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.
Comment 6 Adrian Yee 2004-06-12 16:51:19 UTC
The patch works for me (S6010).
Comment 7 Shaohua 2004-06-21 02:55:44 UTC
*** Bug 2596 has been marked as a duplicate of this bug. ***
Comment 8 Martin Lorenz 2004-06-23 03:11:42 UTC
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 :-)
Comment 9 Shaohua 2004-06-23 03:52:15 UTC
Created attachment 3221 [details]
proposed patch

Ok, updated one
Comment 10 Matthew Garrett 2004-06-24 07:38:45 UTC
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.
Comment 11 Shaohua 2004-06-24 18:18:13 UTC
Created attachment 3247 [details]
proposed patch

Thanks pointed out. I should have check it carefully :(.
Comment 12 Shaohua 2004-06-27 18:21:47 UTC
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.
Comment 13 Shaohua 2004-06-27 23:13:05 UTC
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.
Comment 14 Marek Lotke 2004-06-28 04:53:11 UTC
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! 
Comment 15 Martin Lorenz 2004-06-28 05:55:36 UTC
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.
Comment 16 Herman Sheremetyev 2004-06-28 09:53:01 UTC
this latest patch worked for me as well, ipw2100 and snd-intel8x0 now work
reliably after an S3 resume.  Thanks!
Comment 17 Luming Yu 2004-06-28 23:21:27 UTC
*** Bug 2438 has been marked as a duplicate of this bug. ***
Comment 18 Shaohua 2004-06-29 01:09:03 UTC
Created attachment 3274 [details]
patch port to x86_64

Hmm, per Len's comment, port the patch to x86_64.
Comment 19 Shaohua 2004-06-29 18:55:29 UTC
*** Bug 2965 has been marked as a duplicate of this bug. ***
Comment 20 Matthew Garrett 2004-06-30 04:49:31 UTC
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?
Comment 21 Shaohua 2004-06-30 21:21:30 UTC
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
Comment 22 Matthew Garrett 2004-07-01 00:01:12 UTC
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.
Comment 23 Shaohua 2004-07-01 00:08:27 UTC
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.
Comment 24 Matthew Garrett 2004-07-01 02:06:28 UTC
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.
Comment 25 Shaohua 2004-07-01 02:28:46 UTC
>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
Comment 26 Matthew Garrett 2004-07-01 12:01:14 UTC
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?
Comment 27 Shaohua 2004-07-01 18:18:43 UTC
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.
Comment 28 Matthew Garrett 2004-07-02 06:32:27 UTC
Created attachment 3298 [details]
Use ACPI_NOT_ISR

This patch fixes things
Comment 29 Stefan D 2004-07-06 07:25:22 UTC
Created attachment 3310 [details]
dmesg. Boot + suspend/resume
Comment 30 Stefan D 2004-07-06 07:26:46 UTC
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.  
  
Comment 31 Georg Greve 2004-07-27 04:25:13 UTC
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?
Comment 32 Stefan Schweizer 2004-07-31 14:44:43 UTC
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?
Comment 33 Bernhard Gruber 2004-07-31 15:08:32 UTC
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...
Comment 34 Nathan Bryant 2004-07-31 19:14:15 UTC
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".
Comment 35 Stefan Schweizer 2004-08-01 03:21:27 UTC
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?
Comment 36 Nathan Bryant 2004-08-02 08:33:49 UTC
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));
        }

Note You need to log in before you can comment on or make changes to this bug.