You are not logged in.
Pages: 1
I updated Arch yesterday and since then the bluetoothd process is using 100% of one of the CPU cores (displays as 50%). Tried restarting but to no avail.
Bluetooth received is off (through the applet) and there is nothing connected to it.
Any ideas?
Last edited by Lockheed (2011-07-21 07:35:20)
Offline
Seeing precisely the same down here.
Offline
Same here too!
Offline
I can confirm this, too. Stopping the daemon as a work around.
Offline
i have the same problem:(
Offline
For me it usually happens after a resume from suspend. Can't look into the log files because somehow they're all empty... (but that's for another topic)
Offline
I get bluetoothd running rampant at 100% CPU every time I resume from suspend. It's fine after it's restarted. Rebuilding bluez from ABS didn't help.
It should be possible to work around this by restarting the "bluetooth" daemon from /etc/pm/sleep.d, but I'd rather find a proper fix.
Offline
Same here when i resume from sleep mode.
Offline
In my case it is like this at all times, not just after resume.
Last edited by Lockheed (2011-07-28 05:34:11)
Offline
Same here. It happens every time i switch off my bluetooth.
Offline
same here, after resume from suspend
Offline
I created the following file at /etc/pm/sleep.d/90bluetoothd-workaround as a temporary workaround:
#!/bin/sh
#
# Workaround for bluetoothd CPU usage after suspend
case "$1" in
hibernate|suspend)
;;
thaw|resume)
/etc/rc.d/bluetooth restart
;;
*) exit $NA
;;
esac
Offline
I created the following file at /etc/pm/sleep.d/90bluetoothd-workaround as a temporary workaround:
#!/bin/sh # # Workaround for bluetoothd CPU usage after suspend case "$1" in hibernate|suspend) ;; thaw|resume) /etc/rc.d/bluetooth restart ;; *) exit $NA ;; esac
That is very nice but what about those of us who have the deamon using 100% of cpu regardless of the system being resumed or freshly restarted (basically ALWAYS)?
Offline
I would probably stop the "bluetooth" daemon and only start it when I actually *need* bluetooth, which for me is not very often at all. If it was really a priority issue, I might spend some time with strace or a similar tool to try & find out why bluetoothd is locked up, and search around for a related patch.
Offline
The problem is the daemon does not really work. It crashes when I try to transfer files, so even keeping it off (as I do now) and enabling when needed, would not work.
Offline
I assume you've tried rebuilding bluez from ABS, yeah? That's usually my first port of call.
Then I'd suggest you try to get a backtrace (if it crashes), or strace, or similar debug information, and search for a related bug report against bluez, or file a new one. It seems pretty likely that it's an upstream bug.
Offline
This seems to have been fixed for me with the recent upgrade to bluez 4.96-1.
Offline
Hallelujah.
Offline
Pages: 1