bluez daemon unstable on Eee 1015
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
bluez (Ubuntu) |
Invalid
|
Undecided
|
Unassigned |
Bug Description
Binary package hint: bluez
The bluetooth daemon, bluetoothd, doesn't want to run for a long time. After a while it just...dies. Sometimes it doesn't die, but it says things like this in the log:
Can't read address for hci0: Connection timed out (110)
src/adapter.
unable to set mode: discoverable
I have blueman and not gnome-bluetooth, but it shouldn't matter what client I have if they just interface with the daemon. I've noticed that if I do the temporarily visible thing (a feature not available in gnome-bluetooth), it works once and stays discoverable for 60 seconds and then goes to connectable, but If I try again, it just ignores it. If I try once more, the applet locks up, probably because it got a response from the daemon it didn't expect.
The whole reason I got blueman is that gnome-bluetooth had spotty control over the adapter. I dodn't know how the bluetooth stack worked at the time, so I thought the root of it was in gnome-bluetooth, but I think it's in the daemon.
It's not easily reproducible because it seems to happen at random. Is it a memory leak or something?
I attached a hci.log from hcidumb. The capture time was from when I tried temporarily discoverable in blueman. I don't think it's too helpful.
I also have the output of "grep bluetoothd /var/log/
I have Maverick. It was present in Lucid, too.
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: bluez 4.69-0ubuntu2
ProcVersionSign
Uname: Linux 2.6.35-22-generic i686
NonfreeKernelMo
Architecture: i386
Date: Thu Oct 14 22:32:32 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
InterestingModules: rfcomm sco bnep l2cap btusb bluetooth
MachineType: ASUSTeK Computer INC. 1015PE
ProcCmdLine: BOOT_IMAGE=
ProcEnviron:
LANG=en_US.utf8
SHELL=/bin/bash
SourcePackage: bluez
dmi.bios.date: 06/12/2010
dmi.bios.vendor: American Megatrends Inc.
dmi.bios.version: 0502
dmi.board.
dmi.board.name: 1015PE
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: x.xx
dmi.chassis.
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer INC.
dmi.chassis.
dmi.modalias: dmi:bvnAmerican
dmi.product.name: 1015PE
dmi.product.
dmi.sys.vendor: ASUSTeK Computer INC.
hciconfig:
hci0: Type: BR/EDR Bus: USB
BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0
UP RUNNING
RX bytes:34 acl:0 sco:0 events:3 errors:0
TX bytes:12 acl:0 sco:0 commands:4 errors:0
rfkill:
6: hci0: Bluetooth
Soft blocked: no
Hard blocked: no
Changed in bluez (Ubuntu): | |
status: | New → Confirmed |
Looking through the bugs here, I see many others have had this problem...shoot, I should have looked better before reporting. Oh well, at least I have the apport stuff up for more data for the cause...still, I really wonder what's going on. Bluetooth is the only thing that's not working right on my little Eee. One thing though, it seems to crash more if I put it in standby and bring it back up. The blueman temporarily visible thing is really getting on my nerves though. Seems like a good feature.