|Summary:||USB devices are is gone after waking from sleep|
|Product:||[Fedora] Fedora||Reporter:||Brian G. Anderson <bikehead>|
|Component:||kernel||Assignee:||Dave Jones <davej>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Brian Brock <bbrock>|
|Version:||4||CC:||davej, pfrields, wtogami|
|Fixed In Version:||2.6.15-1.1830_FC4||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2006-02-03 14:08:22 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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: *** info [mice.c(1766)]: Apr 12 18:12:44 bartali gpm: 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 (126.96.36.199). 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.