bluez daemon unstable on Eee 1015

[That Bum]

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.c:adapter_start() Adapter /org/bluez/16390/hci0 without an address
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/daemon.log". This is more useful, I feel.

I have Maverick. It was present in Lucid, too.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: bluez 4.69-0ubuntu2
ProcVersionSignature: Ubuntu 2.6.35-22.34-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic i686
NonfreeKernelModules: wl
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=/boot/vmlinuz-2.6.35-22-generic root=UUID=aae9149c-b9d3-4608-90b7-e508ad6e8c79 ro quiet splash
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.asset.tag: To Be Filled By O.E.M.
dmi.board.name: 1015PE
dmi.board.vendor: ASUSTeK Computer INC.
dmi.board.version: x.xx
dmi.chassis.asset.tag: 0x00000000
dmi.chassis.type: 10
dmi.chassis.vendor: ASUSTeK Computer INC.
dmi.chassis.version: x.x
dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvr0502:bd06/12/2010:svnASUSTeKComputerINC.:pn1015PE:pvrx.x:rvnASUSTeKComputerINC.:rn1015PE:rvrx.xx:cvnASUSTeKComputerINC.:ct10:cvrx.x:
dmi.product.name: 1015PE
dmi.product.version: x.x
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

[That Bum (jzachariou)]

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.

[Konrad Zapałowicz (kzapalowicz)]

This is reported against an old version of Ubuntu and many things has changed since then. Because of that we won't fix this issue however if this behavior repeats on a modern version please fill a bug report against it and we will take it from there.