Description of problem: Kernel 2.6.9-1.3_FC2 apparently aquired new debouncing issues with ACPI. On older kernels used on Acer Travelmate 230 I had the following in /etc/acpi/events/powerb.conf: # sleep on hitting power button event=button/power.* action=/sbin/modprobe -r ehci_hcd; sync; sync; sleep 2 ; \ echo -n "mem" > /sys/power/state and this worked ('modprobe -r ehci_hcd' is crucial here). That means that a short tap on a power button was putting that laptop to sleep and was also waking it up without much fuss. The same approach with 2.6.9-1.3_FC2 gets that laptop into a suspend loop. It wakes up and it goes to sleep right away. In /var/log/acpid received event "button/power PWRF 00000080 00000001" notifying client 2494[0:0] executing action "/sbin/modprobe -r ehci_hcd; sync; sync; sleep 2 ; echo -n "mem" > /sys/power/state" BEGIN HANDLER MESSAGES END HANDLER MESSAGES action exited with status 0 completed event "button/power PWRF 00000080 00000001" received event "button/power PWRF 00000080 00000002" notifying client 2494[0:0] executing action "/sbin/modprobe -r ehci_hcd; sync; sync; sleep 2 ; echo -n "mem" > /sys/power/state" and the only way out of this loop is to power it off and reboot. At the same time on ever suspend this shows up in /var/log/messages before going to sleep Stopping tasks: .... =====================| usbhid 2-1:1.0: resume is unsafe! zapping low mappings. Debug: sleeping function called from invalid context at mm/slab.c:2063 in_atomic():0[expected: 0], irqs_disabled():1 [<0211c967>] __might_sleep+0x82/0x8c [<0214c429>] __kmalloc+0x42/0x7d [<021f5301>] acpi_os_allocate+0xa/0xb [<02208ea7>] acpi_ut_allocate+0x34/0x57 [<02208e38>] acpi_ut_initialize_buffer+0x42/0x7d [<02205ce6>] acpi_rs_create_byte_stream+0x23/0x39 [<022070a6>] acpi_rs_set_srs_method_data+0x1b/0x9d [<0220e80d>] acpi_pci_link_set+0xde/0x155 [<0220eb91>] irqrouter_resume+0x1c/0x30 [<02243d66>] sysdev_resume+0x3e/0xc7 [<02246d8c>] device_power_up+0x5/0xa [<0213de2e>] suspend_enter+0x25/0x2d [<0213de9c>] enter_state+0x3f/0x5e [<0213df96>] state_store+0x7e/0x93 [<0213df18>] state_store+0x0/0x93 [<021abd63>] subsys_attr_store+0x19/0x21 [<021abed6>] flush_write_buffer+0x1d/0x22 [<021abefd>] sysfs_write_file+0x22/0x35 [<0216610e>] vfs_write+0xb8/0xe4 [<021661d8>] sys_write+0x3c/0x62 ACPI: PCI interrupt 0000:00:02.0[A] -> GSI 10 (level, low) -> IRQ 10 and after a return from sleep this: ACPI: PCI interrupt 0000:00:1d.7[D] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 11 (level, low) -> IRQ 11 ACPI: PCI interrupt 0000:00:1f.5[B] -> GSI 10 (level, low) -> IRQ 10 ACPI: PCI interrupt 0000:00:1f.6[B] -> GSI 10 (level, low) -> IRQ 10 eth0: link up, 10Mbps, half-duplex, lpa 0x0000 Restarting tasks... done usb 2-1: USB disconnect, address 5 where pci devices look like that: -[0000:00]-+-00.0 Intel Corp. 82845G/GL[Brookdale-G]/GE/PE DRAM Controller/Host-Hub Interface +-02.0 Intel Corp. 82845G/GL[Brookdale-G]/GE Chipset Integrated Graphics Device +-1d.0 Intel Corp. 82801DB (ICH4) USB UHCI #1 +-1d.1 Intel Corp. 82801DB (ICH4) USB UHCI #2 +-1d.2 Intel Corp. 82801DB (ICH4) USB UHCI #3 +-1d.7 Intel Corp. 82801DB (ICH4) USB2 EHCI Controller +-1e.0-[0000:02]--+-05.0 Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ | \-09.0 O2 Micro, Inc. OZ6912 Cardbus Controller +-1f.0 Intel Corp. 82801DB (ICH4) LPC Bridge +-1f.1 Intel Corp. 82801DB (ICH4) Ultra ATA 100 Storage Controller +-1f.3 Intel Corp. 82801DB/DBM (ICH4) SMBus Controller +-1f.5 Intel Corp. 82801DB (ICH4) AC'97 Audio Controller \-1f.6 Intel Corp. 82801DB (ICH4) AC'97 Modem Controller To get around this debounce problem I wrote a script #!/bin/sh sleepf=/var/run/sleeping if [ -f $sleepf ] ; then /bin/rm -f $sleepf else /sbin/modprobe -r ehci_hcd touch $sleepf sync; sync; sleep 2 echo -n "mem" > /sys/power/state fi and changed 'action' in /etc/acpi/events/powerb.conf to run it. With this I see in /var/log/acpid for a full suspend/wake up cycle: received event "button/power PWRF 00000080 00000003" notifying client 2597[0:0] executing action "/usr/local/sbin/suspend_helper" BEGIN HANDLER MESSAGES END HANDLER MESSAGES action exited with status 0 completed event "button/power PWRF 00000080 00000003" received event "button/power PWRF 00000080 00000004" notifying client 2597[0:0] executing action "/usr/local/sbin/suspend_helper" BEGIN HANDLER MESSAGES END HANDLER MESSAGES action exited with status 0 completed event "button/power PWRF 00000080 00000004" but then it works. Floppy is still unusable after a suspend and resume, even if I will 'modprobe -r floppy' before putting that laptop to sleep and insert afterwards but this is another issue (see bug #127163). Version-Release number of selected component (if applicable): kernel 2.6.9-1.3_FC2 How reproducible: 100%
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
Thanks for this update. I am afraid that the laptop in question is now "somewhere in the wild" and I will not see it before the end of August. Only then I will have chances to test it.
I tried the same with 2.6.12-1.1447_FC4. I am afraid that the problem is still there although it seems to be hitting at random. Possibly depending on what modules were loaded/unloaded but I had trouble finding a pattern. Here is some sample from /var/log/acpid: .... [Sun Sep 11 18:19:34 2005] received event "button/power PWRF 00000080 00000001" [Sun Sep 11 18:19:34 2005] notifying client 2227[0:0] [Sun Sep 11 18:19:34 2005] executing action "/sbin/modprobe -r ehci_hcd; sync; sync; sleep 2 ; echo -n "mem" > /sys/power/state" [Sun Sep 11 18:19:34 2005] BEGIN HANDLER MESSAGES [Sun Sep 11 18:19:51 2005] END HANDLER MESSAGES [Sun Sep 11 18:19:51 2005] action exited with status 0 [Sun Sep 11 18:19:51 2005] completed event "button/power PWRF 00000080 00000001"[Sun Sep 11 18:19:51 2005] received event "button/power PWRF 00000080 00000002" [Sun Sep 11 18:19:51 2005] notifying client 2227[0:0] [Sun Sep 11 18:19:51 2005] executing action "/sbin/modprobe -r ehci_hcd; sync; sync; sleep 2 ; echo -n "mem" > /sys/power/state" [Sun Sep 11 18:19:51 2005] BEGIN HANDLER MESSAGES [Sun Sep 11 18:20:20 2005] END HANDLER MESSAGES [Sun Sep 11 18:20:20 2005] action exited with status 0 [Sun Sep 11 18:20:20 2005] completed event "button/power PWRF 00000080 00000002"[Sun Sep 11 18:20:20 2005] received event "battery BAT0 00000080 00000001" [Sun Sep 11 18:20:20 2005] notifying client 2227[0:0] [Sun Sep 11 18:20:20 2005] completed event "battery BAT0 00000080 00000001" [Sun Sep 11 18:20:20 2005] received event "button/power PWRF 00000080 00000003" [Sun Sep 11 18:20:20 2005] notifying client 2227[0:0] [Sun Sep 11 18:20:20 2005] executing action "/sbin/modprobe -r ehci_hcd; sync; sync; sleep 2 ; echo -n "mem" > /sys/power/state" [Sun Sep 11 18:20:20 2005] BEGIN HANDLER MESSAGES [Sun Sep 11 18:20:45 2005] END HANDLER MESSAGES .... and quite a bit more of that. It is quite hard to get out of such loop. Sometimes one can drop it "Alt-Ctrl-Del" on a console; othertimes holding power button down can switch power off. BTW - without 'acpi_sleep=s3_bios' given to a kernel that laptop does suspend and wake-up, to an extent, with this catch that after such cycle a video is gone. Not particularly desired outcome.
This is a mass-update to all currently open Fedora Core 3 kernel bugs. Fedora Core 3 support has transitioned to the Fedora Legacy project. Due to the limited resources of this project, typically only updates for new security issues are released. As this bug isn't security related, it has been migrated to a Fedora Core 4 bug. Please upgrade to this newer release, and test if this bug is still present there. This bug has been placed in NEEDINFO_REPORTER state. Due to the large volume of inactive bugs in bugzilla, if this bug is still in this state in two weeks time, it will be closed. Should this bug still be relevant after this period, the reporter can reopen the bug at any time. Any other users on the Cc: list of this bug can request that the bug be reopened by adding a comment to the bug. Thank you.
*** This bug has been marked as a duplicate of 118353 ***