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.
Is the bluetooth service still running on resume? Did you upgrade from F7, or is this a clean install?
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.
Yesterday, after yum updating the system, I can no longer reproduce this bug.
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.
This problem seems to happen after several days of hibernating/resume procedures without actually rebooting the OS.
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?
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.
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.
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?
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.
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.
Created attachment 293680 [details] Resume messages Resume log taken from /var/log/messages
[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.
I can't find any defunct hcid processes as bug #242816.
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?
# 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.
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.
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.
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 :).
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
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!