Re: [Bluez-devel] HCI Events and errors

[Marcel Holtmann <marcel@holtmann.org>]

Hi Victor,

> I've been experimenting with bluetooth on a HP iPAQ h5550 with a modified
> kernel, with mixed success.
> 
> The h5550 is running a kernel based on the handhelds.org CVS tree (hh36?)
> plus a recent BlueZ, Mipv6, etc.  The ipaq can receive bluetooth data at
> a good rate (observed 690 kbps), but has problems transmitting.

what does "hciconfig -a" say? If I remember correctly then there is
neither a CSR nor a Zeevo chip in this model.

> The tests are done with a program which opens and writes to an l2cap
> socket, repeatedly sending messages of arbitrary size and with arbitrary
> delays between each message.  One end of the link is the ipaq, the other
> is a desktop machine with a USB bluetooth dongle.

Who is sending to whom?

> If I reduce the effective outgoing rate by using a suitable combination
> of message size and delay between messages, outgoing communications can
> be sustained, but not beyond roughly 50kpbs or so.  Above this approximate
> rate, the data is sent successfully for a few minutes, until the
> application code receives a 'resource unavailable' error after a send()
> call.
> 
> hcidump shows that the data flows for a while, at some point gets a HCI
> Hardware Error event, and then data soon ceases to flow.  I've enabled
> debug messages in the bluez modules, and it shows that the eventual error
> at send() is due to bluez being unable to allocate a sk_buf for an outgoing
> fragment.  BlueZ was correctly sending ACL packets for each, but after a
> while the lower layers stop working and presumably the sk_buf's just queue
> up unserviced.

Show me that part, because I don't believe that this is an allocation
problem inside BlueZ.

> Subsequent bluetooth comms, eg 'hcitool inq', result in timeouts, needing
> a reload of the stack before things will work again.
> 
> Looking at a combination of the BlueZ code, the hcidump trace, and the kernel
> log, shows that after the last successful message is sent, the stack appears
> to have received a HCI event with event code 0x10 from the HCI controller.
> 
> According to the Bluetooth spec (v1.1), a HCI event packet with event code
> of 0x10 is a HCI Hardware Error Event.  There is no #define for this in
> hci.h, probably need something like HCI_EV_HARDWARE_ERROR.
> 
> Appendix H:4 (HCI UART Transport layer), section 4 reads: "If the UART 
> synchronization is lost in the communication from Host to Host Controller,
> then the Host Controller shall send a Hardware Error Event to tell the
> Host about the synchronization error. The Host Controller will then expect
> to receive an HCI_Reset command from the Host in order to perform a reset.
> The Host Controller will also use the HCI_Reset command in the byte stream
> from Host to Host Controller to re-synchronize."
> 
> So it appears that the BlueZ code (hci_event_packet()) is not handling the
> hardware error event, it just falls out the bottom of the switch statement
> when instead it should be detecting the condition and somehow sending the
> HCI_Reset command.

We don't handle hardware errors. Feel free to play with adding a reset
in that case and see if it helps. I doubt it, because using H4 with a
buggy UART is always a bad thing. In general the HCI flow control should
prevent us to send to much data to the chip. However we don't have flow
control for the other way round. It is on the todo list.

Regards

Marcel




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel