Bug 140205 - kernel 2.6.9-1.3_FC2 - ACPI has troubles with debounce
Summary: kernel 2.6.9-1.3_FC2 - ACPI has troubles with debounce
Keywords:
Status: CLOSED DUPLICATE of bug 118353
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 4
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Dave Jones
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2004-11-21 02:54 UTC by Michal Jaegermann
Modified: 2015-01-04 22:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-01-18 09:49:05 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Michal Jaegermann 2004-11-21 02:54:22 UTC
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%

Comment 1 Dave Jones 2005-07-15 17:38:27 UTC
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.

Comment 2 Michal Jaegermann 2005-07-15 17:49:40 UTC
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.

Comment 3 Michal Jaegermann 2005-09-12 01:58:04 UTC
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.

Comment 4 Dave Jones 2006-01-16 22:11:09 UTC
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.


Comment 5 Len Brown 2006-01-18 09:49:05 UTC

*** This bug has been marked as a duplicate of 118353 ***


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