Bug 154613 - USB devices are is gone after waking from sleep
Summary: USB devices are is gone after waking from sleep
Keywords:
Status: CLOSED CURRENTRELEASE
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: 2005-04-13 01:18 UTC by Brian G. Anderson
Modified: 2015-01-04 22:18 UTC (History)
3 users (show)

Fixed In Version: 2.6.15-1.1830_FC4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-02-03 14:08:22 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Brian G. Anderson 2005-04-13 01:18:18 UTC
Description of problem:
Not sure if this is a kernel thing, but when I boot my Thinkpad T42p the
bluetooth interface comes up fine and I can query it with hciconfig fine.  The
IBM has a little status light indicating bluetooth is active.

When I put the system to sleep and then wake it, the entire system is fine
except that bluetooth doesn't work any more.  The status light is off and
hciconfig complains about the hci0 device timing out. If I stop the bluetooth
service and unload all the modules and then restart bluetooth,  hciconfig finds
no more devices.


Version-Release number of selected component (if applicable):
kernel 2.6.11-1.1236_FC4
bluez-utils-2.15-5

the bluetooth version info is
hci0:   Type: USB
        BD Address: 00:20:E0:CC:53:ED ACL MTU: 192:8 SCO MTU: 64:8
        HCI Ver: 1.1 (0x1) HCI Rev: 0x222 LMP Ver: 1.1 (0x1) LMP Subver: 0x222
        Manufacturer: Cambridge Silicon Radio (10)


How reproducible:
on every sleep

Steps to Reproduce:
1. boot the system
2. put the system to sleep and then wake it
3.
  
Actual results:
hci0 is no longer functioning

Expected results:
bluetooth restores correctly and hci0 is working.

Additional info:
I tried stopping the bluetooth service, taking hci0 down, and unloading all the
modules both before sleeping and after waking.  Still can get hci0 to appear

On waking I get the following debug message.  I'm not sure if its related, but I
include it here for information.

Apr 12 18:12:44 bartali kernel: Stopping tasks:
==================================================================================================|
Apr 12 18:12:44 bartali kernel: Debug: sleeping function called from invalid
context at mm/slab.c:2096
Apr 12 18:12:44 bartali kernel: in_atomic():0, irqs_disabled():1
Apr 12 18:12:44 bartali kernel:  [<c015c3b4>] kmem_cache_alloc+0x63/0x78
Apr 12 18:12:44 bartali kernel:  [<c0247e4e>] acpi_pci_link_set+0x3f/0x17f
Apr 12 18:12:44 bartali kernel:  [<c0248298>] irqrouter_resume+0x14/0x28
Apr 12 18:12:44 bartali kernel:  [<c029144e>] sysdev_resume+0x3d/0xb5
Apr 12 18:12:44 bartali kernel:  [<c02956ed>] device_power_up+0x5/0xa
Apr 12 18:12:44 bartali kernel:  [<c014a7eb>] suspend_enter+0x44/0x46
Apr 12 18:12:44 bartali kernel:  [<c014a779>] suspend_prepare+0x57/0x85
Apr 12 18:12:44 bartali kernel:  [<c014a85e>] enter_state+0x49/0x54
Apr 12 18:12:44 bartali kernel:  [<c0245316>] acpi_system_write_sleep+0x5a/0x6c
Apr 12 18:12:44 bartali kernel:  [<c02452bc>] acpi_system_write_sleep+0x0/0x6c
Apr 12 18:12:44 bartali kernel:  [<c017bbc8>] vfs_write+0x9e/0x110
Apr 12 18:12:44 bartali kernel:  [<c017bce5>] sys_write+0x41/0x6a
Apr 12 18:12:44 bartali kernel:  [<c0103a61>] syscall_call+0x7/0xb
Apr 12 18:12:44 bartali kernel: psmouse.c: TouchPad at isa0060/serio1/input0
lost synchronization, throwing 4 bytes away.
Apr 12 18:12:44 bartali kernel: hub 3-0:1.0: resubmit --> -108
Apr 12 18:12:44 bartali kernel: hub 4-0:1.0: resubmit --> -108
Apr 12 18:12:44 bartali kernel: hub 2-0:1.0: resubmit --> -108
Apr 12 18:12:44 bartali kernel: ehci_hcd 0000:00:1d.7: USB 2.0 restarted, EHCI
1.00, driver 10 Dec 2004
Apr 12 18:12:44 bartali kernel: ACPI: PCI Interrupt 0000:00:1f.1[A] -> Link
[LNKC] -> GSI 11 (level, low) -> IRQ 11
Apr 12 18:12:44 bartali kernel: ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link
[LNKB] -> GSI 11 (level, low) -> IRQ 11
Apr 12 18:12:44 bartali kernel: ACPI: PCI Interrupt 0000:00:1f.6[B] -> Link
[LNKB] -> GSI 11 (level, low) -> IRQ 11
Apr 12 18:12:44 bartali gpm[2681]: *** info [mice.c(1766)]:
Apr 12 18:12:44 bartali gpm[2681]: imps2: Auto-detected intellimouse PS/2
Apr 12 18:12:44 bartali kernel: ACPI: PCI Interrupt 0000:02:01.0[A] -> Link
[LNKA] -> GSI 11 (level, low) -> IRQ 11
Apr 12 18:12:44 bartali kernel: ACPI: PCI Interrupt 0000:02:02.0[A] -> Link
[LNKC] -> GSI 11 (level, low) -> IRQ 11
Apr 12 18:12:44 bartali kernel: Restarting tasks... done

Comment 1 David Woodhouse 2005-04-13 06:42:48 UTC
Is there a hotkey which enables and disables the bluetooth adapter? Is it
disabled by the system after a sleep? I still have Bluetooth after a
suspend/resume cycle on my PowerBook where I know the adapter itself isn't disabled.

Comment 2 Brian G. Anderson 2005-04-13 17:24:06 UTC
There is one.  I checked after resume and the state /proc/acpi/ibm/bluetooth
reports 'enabled', but the status light on the case is off (it was on when the
machine was put to sleep).  I tried the hotkey repeatedly with no effect.  I
checked /proc/acpi/ibm/bluetooth each time and the state toggles from 'enable'
to 'disabled' when I hit the button.

However, the hci0 device still fails to respond even after making sure the
/proc/acpi/ibm/bluetooth is 'enabled'.

Comment 3 David Woodhouse 2005-04-13 17:32:07 UTC
What if you disable it before sleep and then resume it afterwards?


Comment 4 Brian G. Anderson 2005-04-13 21:02:24 UTC
I tried disabling it, stopping the bluetooth service, and unloading the kernel
modules rfcomm, l2cap, hci_usb, and bluetooth.  No success.

Comment 5 David Woodhouse 2005-04-13 21:12:05 UTC
Does the bluetooth device appear in the output of 'lsusb' after a suspend/resume
cycle?

I suspect we're reaching a dead end, unless we can obtain chipset documentation
and write proper suspend/resume support for the machine instead of using the
proprietary binary-only ACPI bytecode. ACPI is no more supportable than other
forms of binary-only code which we might execute in the kernel -- it doesn't
make a great deal of difference that we're actually running it through an
interpreter instead of directly on the CPU; it's still code that we can't easily
modify or debug.

Comment 6 Brian G. Anderson 2005-04-13 22:49:28 UTC
lsusb shows the device as there after resume.  However, I do notice two things:

1.  Before sleep, if I hotkey bluetooth off, hci0 disappears and so does the usb
device, and when I hotkey it back on they both reappear.  However, if I hotkey
bluetooth off, sleep and then resume, then hotkey-ing bluetooth on will not
bring the devices back.

2. If I leave bluetooth up, sleep and resume, then hci0 and the usb device are
present, but hotkey-ing bluetooth off doesn't remove the devices.

It seems as if the bluetooth hardware is no longer talking the the kernel, but
that is my completely clueless guess.

I suspect you are right about the ACPI, but I did notice that the version of the
ibm-acpi level for devel kernel is 0.8 while the home page says the latest
version is 0.11.  This is just a stab in the dark since I have no clue if this
has any bearing on the problem other than the module mentions ibm, acpi and
bluetooth in the same sentance of its readme.

Is there any documentation, wikis, etc about debugging/modifying ACPI bytecode?



Comment 7 David Woodhouse 2005-04-13 23:01:20 UTC
Are any other USB devices visible after the suspend/resume cycle? Does it help
if you unload and reload uhci_hcd and/or ehci_hcd modules? If ehci_hcd is
loaded, try _just_ unloading that first.

Comment 8 Brian G. Anderson 2005-04-14 03:29:01 UTC
Yes that did it!  After resuming I seem to have to unload and load both ehci_hcd
and uhci_hcd to bring bluetooth back on line.  What do these modules do?  My usb
key seems to be restored on startup automatically so they don't seem to be
necessay for usb.  How do I get them automatically unloaded/loaded on resume?  I
notice from messages that resume is restarting other modues .

Comment 9 David Woodhouse 2005-08-09 16:51:00 UTC
Those are the USB host controller drivers. This is a kernel bug which is
probably fixed now -- can you confirm that this is no longer a problem with
current kernels?

Comment 10 Brian G. Anderson 2005-08-09 19:51:09 UTC
I'm running 2.6.12-1.1398_FC4 and I still have to rmmod uhci_hcd and then
modprobe uhci_hcd to make bluetooth come back after a sleep.

Comment 12 Dave Jones 2005-09-30 06:37:23 UTC
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.


Comment 13 Dave Jones 2005-11-10 19:39:54 UTC
2.6.14-1.1637_FC4 has been released as an update for FC4.
Please retest with this update, as a large amount of code has been changed in
this release, which may have fixed your problem.

Thank you.


Comment 14 Brian G. Anderson 2005-11-11 23:58:24 UTC
After the 2.6.14-1.1637_FC4 update, it is worse than before:  unloading the
modules no longer restores blue tooth.  However,  I notice that no USB device is
working after a resume.  For example if I resume and plug in a USB mouse I get:

Nov 11 16:56:21 bartali kernel: hub 3-0:1.0: over-current change on port 1
Nov 11 16:56:22 bartali kernel: hub 3-0:1.0: over-current change on port 1
Nov 11 16:56:22 bartali kernel: hub 3-0:1.0: over-current change on port 2
Nov 11 16:56:22 bartali kernel: hub 3-0:1.0: over-current change on port 1
Nov 11 16:56:22 bartali kernel: hub 3-0:1.0: over-current change on port 2

I tried unloading and loading hci_usb, but this doesn't clear it either.  Since
bluetooth devices go through the USB system,  I'm wondering if this is
preventing bluetooth from working now.  Perhaps this is a new bug?

Comment 15 Dave Jones 2006-02-03 05:36:24 UTC
This is a mass-update to all currently open kernel bugs.

A new kernel update has been released (Version: 2.6.15-1.1830_FC4)
based upon a new upstream kernel release.

Please retest against this new kernel, as a large number of patches
go into each upstream release, possibly including changes that
may address this problem.

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.

If this bug is a problem preventing you from installing the
release this version is filed against, please see bug 169613.

Thank you.


Comment 16 Brian G. Anderson 2006-02-03 14:06:53 UTC
The 2.6.15 kernel fixed this problem.


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