2007-10-22 15:02:34

by Robert Rawlins

[permalink] [raw]
Subject: [Bluez-users] Device Not Initing Properly

Hello Guys,

Another problem I've been having recently is with the chips not initing properly, more precisely, hci0 wont init properly. I've got this same issue on several systems with different sets of BT chips, so I think I can probably rule out any type of hardware based issue. When I boot the system the devices will work perfectly for an amount of time, then out of the blue (no pun intended) hci0 will fall to 'down' and I can't get him to come back up. Even after a software reboot, or a system 'reset' performed by the main system boards watchdog, the chip still stays down, like so:
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:27 acl:0 sco:0 commands:9 errors:0
hci1: Type: USB BD Address: 00:80:98:C4:51:DE ACL MTU: 310:10 SCO MTU: 64:8 UP RUNNING PSCAN
RX bytes:2805 acl:0 sco:0 events:153 errors:0 TX bytes:2396 acl:0 sco:0 commands:144 errors:0

However, if I completely disconnect the systems power supply from the inlet, and reconnect it a second or so later then the chip will come back to life, again only for a certain amount of time before going down again. This is on an embedded system so being able to disconnect the power isn't really an option for us.

I have also noticed that whilst the chip is down, every few seconds the hciconfig will return the following, stating that its attempting to init the chip, this is performed by a script I've build on the system to run 'hciconfig hci up' in the event the chip goes down every 10 seconds or so to try and bring it up again:

hci0: Type: USB BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0 DOWN INIT RUNNING RX bytes:0 acl:0 sco:0 events:0 errors:0 TX bytes:27 acl:0 sco:0 commands:9 errors:0
hci1: Type: USB BD Address: 00:80:98:C4:51:DE ACL MTU: 310:10 SCO MTU: 64:8 UP RUNNING PSCAN RX bytes:2805 acl:0 sco:0 events:153 errors:0 TX bytes:2396 acl:0 sco:0 commands:144 errors:0

However the chip will still remain in the down position. This would suggest to me that the chip is definitely connected and visible to system, its obviously just throwing errors when trying to initialize. I'm not quite sure why this is however, is there any advice you can offer? or perhaps some diagnostics suggestions to give us a little more information as to the root of the problem?

I took the liberty of running hcidump for a few minutes just to see if it threw anything interesting, but its giving some very simple output:

voyage:~# hcidump -i hci0HCI sniffer - Bluetooth packet analyzer ver 1.39device: hci0 snap_len: 1028 filter: 0xffffffff< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0< HCI Command: Read Local Supported Features (0x04|0x0003) plen 0

We're running a debian based build running kernel 2.6.17 and blue-z 3.12. Thanks guys, I really appreciate your time and help.

Robert
_________________________________________________________________
100?s of Music vouchers to be won with MSN Music
https://www.musicmashup.co.uk


Attachments:
(No filename) (314.00 B)
(No filename) (164.00 B)
Download all attachments