Bug 384591 - Hibernate disables bluetooth usb dongle
Hibernate disables bluetooth usb dongle
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: bluez-utils (Show other bugs)
9
i686 Linux
low Severity medium
: ---
: ---
Assigned To: David Woodhouse
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-15 08:46 EST by Pedro Silva
Modified: 2008-12-15 05:19 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-15 05:19:45 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Resume messages (6.22 KB, text/plain)
2008-01-31 21:09 EST, Pedro Silva
no flags Details

  None (edit)
Description Pedro Silva 2007-11-15 08:46:01 EST
Description of problem:

After resuming from hibernate, bluetooth usb dongle is no longer detected.
This is a regression from fedora 7.

Steps to Reproduce:
1. Bluetooth dongle detected and working.
2. Hibernate.
3. Resume.
4. Bluetooth dongle is no longer detected.
5. Reboot.

Expected results:

Bluetooth dongle still detected and working.

Additional info:

I tried to use another usb port but the result is the same. I have a usb mouse
and it still works after hibernate.
Comment 1 Bastien Nocera 2007-11-15 09:27:50 EST
Is the bluetooth service still running on resume? Did you upgrade from F7, or is
this a clean install?
Comment 2 Pedro Silva 2007-11-15 10:35:02 EST
It's a clean install of Fedora 8. I'm not sure if the bluetooth service is
running, I'll check this and provide feedback later.
Comment 3 Pedro Silva 2007-11-16 06:25:52 EST
Yesterday, after yum updating the system, I can no longer reproduce this bug.
Comment 4 Pedro Silva 2007-11-20 17:37:47 EST
It happened again.

After resume:

service bluetooth status
hcid morto mas o subsistema está trancado (that would mean, hcid dead but
subsystem is locked)

service bluetooth restart
Stopping Bluetooth services:                               [FALHOU]
A iniciar os serviços Bluetooth:                           [  OK  ]

Restarting the bluetooth service made it work again.

Comment 5 Pedro Silva 2007-11-21 12:00:28 EST
This problem seems to happen after several days of hibernating/resume procedures
without actually rebooting the OS.
Comment 6 Bastien Nocera 2008-01-17 11:53:52 EST
See also bug 242816.

Could you please make sure your machine is fully upgraded to the latest F8 and
check whether there are any relevant messages in /var/log/messages?
Comment 7 Pedro Silva 2008-01-23 12:21:11 EST
Today, I started a week long of hibernating and resume tests on a fully updated
fedora 8 machine to see if the bug is still there.

I'll get back to you as soon as I have some more info.
Comment 8 Pedro Silva 2008-01-30 06:07:32 EST
I run into the problem this morning.

Resumed and hcid is dead and subsystem locked.

Found this in /var/log/messages:

Jan 30 09:54:50 localhost hcid[1989]: HCI dev 0 down
Jan 30 09:54:50 localhost hcid[1989]: Stopping security manager 0
Jan 30 09:54:50 localhost hcid[1989]: Device hci0 has been disabled
Jan 30 09:54:50 localhost hcid[1989]: HCI dev 0 unregistered
Jan 30 09:54:50 localhost hcid[1989]: Unregister path: /org/bluez/hci0

The dongle never left the laptop and it was disabled.
Comment 9 Pedro Silva 2008-01-30 06:16:24 EST
If I restart bluetooth service, this shows up in /var/log/messages:

Jan 30 11:11:47 localhost hcid[1752]: Bluetooth HCI daemon
Jan 30 11:11:47 localhost hcid[1752]: HCI dev 0 registered
Jan 30 11:11:47 localhost hcid[1752]: Starting SDP server
Jan 30 11:11:48 localhost hcid[1752]: Created local server at
unix:abstract=/var/run/dbus-RB7CQbYqrW,guid=c9d19a4a09de254d9eb9f90047a05b74
Jan 30 11:11:48 localhost input[1758]: Bluetooth Input daemon
Jan 30 11:11:48 localhost input[1758]: Registered input manager
path:/org/bluez/input
Jan 30 11:11:48 localhost input[1758]: Failed to listen on control channel
Jan 30 11:11:48 localhost hcid[1752]: HCI dev 0 up
Jan 30 11:11:48 localhost hcid[1752]: Device hci0 has been added
Jan 30 11:11:48 localhost hcid[1752]: Starting security manager 0
Jan 30 11:11:48 localhost hcid[1752]: Device hci0 has been activated
Jan 30 11:11:48 localhost hcid[1752]: Default passkey agent (:1.29,
/org/bluez/passkey) registered
Jan 30 11:11:48 localhost hcid[1752]: Default authorization agent (:1.29,
/org/bluez/auth) registered

Why does the hci0 device "disappear" during a hibernate/resume procedure?
Comment 10 Pedro Silva 2008-01-30 07:10:06 EST
I've added "-d" to the line "daemon /usr/sbin/hcid -s" in /etc/init.d/bluetooth
and I'm going to hibernate and resume for a few days to hit the problem again.
Comment 11 Pedro Silva 2008-01-30 20:55:24 EST
It happened again.

/var/log/messages before hibernate:

Jan 30 11:36:03 localhost hcid[3013]: Bluetooth HCI daemon
Jan 30 11:36:03 localhost hcid[3013]: Enabling debug information
Jan 30 11:36:03 localhost hcid[3013]: HCI dev 0 registered
Jan 30 11:36:03 localhost hcid[3013]: HCI dev 0 already up
Jan 30 11:36:03 localhost hcid[3013]: Device hci0 has been added
Jan 30 11:36:03 localhost hcid[3013]: Starting security manager 0
Jan 30 11:36:03 localhost hcid[3013]: Device hci0 has been activated
Jan 30 11:36:03 localhost hcid[3013]: Starting SDP server
Jan 30 11:36:03 localhost hcid[3013]: Created local server at
unix:abstract=/var/run/dbus-rACq8Tl3NN,guid=11c1189f8be87e57ded5240047a06123
Jan 30 11:36:03 localhost input[3021]: Bluetooth Input daemon
Jan 30 11:36:03 localhost input[3021]: Registered input manager
path:/org/bluez/input
Jan 30 11:36:03 localhost input[3021]: Failed to listen on control channel
Jan 30 11:36:04 localhost hcid[3013]: Default passkey agent (:1.29,
/org/bluez/passkey) registered
Jan 30 11:36:04 localhost hcid[3013]: Default authorization agent (:1.29,
/org/bluez/auth) registered


/var/log/messages after resume:

Jan 31 01:37:38 localhost hcid[3013]: HCI dev 0 down
Jan 31 01:37:44 localhost hcid[3013]: Stopping security manager 0
Jan 31 01:37:44 localhost hcid[3013]: Device hci0 has been disabled
Jan 31 01:37:44 localhost hcid[3013]: HCI dev 0 unregistered
Jan 31 01:37:44 localhost hcid[3013]: Unregister path: /org/bluez/hci0


service bluetooth status
hcid dead but subsystem locked.

service bluetooth restart (/var/log/messages)

Jan 31 01:51:39 localhost hcid[11490]: Bluetooth HCI daemon
Jan 31 01:51:39 localhost hcid[11490]: Enabling debug information
Jan 31 01:51:39 localhost hcid[11490]: HCI dev 0 registered
Jan 31 01:51:39 localhost hcid[11490]: Starting SDP server
Jan 31 01:51:39 localhost hcid[11490]: Created local server at
unix:abstract=/var/run/dbus-b85FWjXRHA,guid=b478fb938b5bb287f1d8820047a129ab
Jan 31 01:51:39 localhost hcid[11490]: HCI dev 0 up
Jan 31 01:51:39 localhost hcid[11490]: Device hci0 has been added
Jan 31 01:51:39 localhost hcid[11490]: Starting security manager 0
Jan 31 01:51:39 localhost input[11494]: Bluetooth Input daemon
Jan 31 01:51:39 localhost hcid[11490]: Device hci0 has been activated
Jan 31 01:51:39 localhost input[11494]: Registered input manager
path:/org/bluez/input
Jan 31 01:51:39 localhost hcid[11490]: Default passkey agent (:1.29,
/org/bluez/passkey) registered
Jan 31 01:51:39 localhost hcid[11490]: Default authorization agent (:1.29,
/org/bluez/auth) registered
Jan 31 01:51:39 localhost input[11494]: Failed to listen on control channel

And bluetooth service is up and running again.

I've some more messages about usb devices connecting/disconnecting during
resume, since this is usb dongle, maybe it has something to do with it.
Comment 12 Pedro Silva 2008-01-31 21:09:36 EST
Created attachment 293680 [details]
Resume messages

Resume log taken from /var/log/messages
Comment 13 Pedro Silva 2008-01-31 21:12:09 EST
[root@localhost ~]# lsusb
Bus 005 Device 001: ID 0000:0000  
Bus 001 Device 007: ID 174f:a311  
Bus 001 Device 001: ID 0000:0000  
Bus 002 Device 003: ID 046d:c016 Logitech, Inc. M-UV69a/HP M-UV96 Optical Wheel
Mouse
Bus 002 Device 001: ID 0000:0000  
Bus 004 Device 001: ID 0000:0000  
Bus 003 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle
(HCI mode)
Bus 003 Device 001: ID 0000:0000  

174f:a311 - This a webcam, i have a driver for it but it wasn't loaded at
hibernate or resume time, not a problem.
Comment 14 Pedro Silva 2008-01-31 21:17:57 EST
I can't find any defunct hcid processes as bug #242816.
Comment 15 Bastien Nocera 2008-03-26 09:00:39 EDT
Feb  1 00:28:55 localhost hcid[2020]: HCI dev 0 registered

It's back up and running when you resume. Could you please check that hcid is
still running ("service bluetooth status"), and that hci0 appears in the output
of hciconfig?
Comment 16 Pedro Silva 2008-04-07 15:48:12 EDT
# service bluetooth status
hcid morto mas o subsistema está trancado (hcid dead but subsystem is locked)

# hciconfig
hci0:   Type: USB
        BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
        DOWN 
        RX bytes:0 acl:0 sco:0 events:0 errors:0
        TX bytes:0 acl:0 sco:0 commands:0 errors:0

I didn't rewrite that BD Address, it really shows zeros. Should it?

# service bluetooth restart
Stopping Bluetooth services:                               [FALHOU]
A iniciar os serviços Bluetooth:                           [  OK  ]

# hciconfig
hci0:   Type: USB
        BD Address: xx:xx:xx:xx:xx:xx ACL MTU: 310:10 SCO MTU: 64:8
        UP RUNNING PSCAN 
        RX bytes:949 acl:0 sco:0 events:24 errors:0
        TX bytes:342 acl:0 sco:0 commands:23 errors:0

Now I really changed the BD Address to Xs, and bluetooth is working again.
Comment 17 Aniket 2008-06-03 14:02:39 EDT
I can confirm this bug on fedora 9 (clean install). The bluetooth daemon dies
after suspend to disk and resume, and further , "service bluetooth start" doesnt
start it again. I have to type "hcid" to get the bluetooth working again. 
A reboot fixes all these issues, till the next suspend. 
Comment 18 Bastien Nocera 2008-10-14 15:53:18 EDT
I finally nailed down and fixed this bug at the last BlueZ meeting. And it turns out that bug I was seeing was probably also the one causing crashes here.

Please test those builds:
http://koji.fedoraproject.org/koji/buildinfo?buildID=66331 (F-9)
http://koji.fedoraproject.org/koji/buildinfo?buildID=66332 (F-8)

and I'll file those for updates if it fixes the problems with resume killing hcid.
Comment 19 Pedro Silva 2008-10-21 21:17:30 EDT
As suggested, in F9, I updated the following packages:

bluez-utils-cups-3.36-2.fc9.i386
bluez-utils-alsa-3.36-2.fc9.i386
bluez-utils-gstreamer-3.36-2.fc9.i386
bluez-utils-3.36-2.fc9.i386
bluez-libs-3.36-1.fc9.i386 (depency)

Bluetooth seems to work correctly after resume. I'm basing this fact on a single hibernate/resume cycle. I'll run some more during the following days and report back.

Btw, gnome energy manager blew up on resume. Maybe it was due to the fact that gnome-phone-manager was running using the bt link to phone and supplying phone's battery info to gnome energy manager. If needed, I'll file a bug report on this. Gnome bug buddy catchs it :).
Comment 20 Bug Zapper 2008-11-26 03:27:12 EST
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 21 Pedro Silva 2008-12-15 05:17:37 EST
I'm already running F10 and using:

bluez-gnome-1.8-8.fc10.i386
bluez-4.19-1.fc10.i386
bluez-libs-4.19-1.fc10.i386
bluez-cups-4.19-1.fc10.i386
bluez-alsa-4.19-1.fc10.i386

This bug hasn't shown up for several days using hibernate/resume loop, also, i'm still using the exact same hardware since this bug opened. I've been shutting off current bluetooth connections before entering hibernate mode, like gnome-phone-manager or a nautilus window to the phone. Gnome-power-manager seems to work between cycles, gnome-phone-manager always reconnects when I run it after resume and updates gnome-power-manager accordingly. Great! :)

I think it's ok to close this one. Thanks for the great support once more!

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