[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [bluetooth-dev] bug in COMMAND_COMPLETE and COMMAND_STATUS events processing

Oliver, thanks!

We are currently working on HCI and this is fixed for the upcoming release. We are also fixing several possible race situations which might occur when running multipoint.

We want all hci commands that are triggered from btd to block, but since the Ericsson modules (since P9A) sends the reply on the new baudrate we can't have set_ericsson_baudrate() to block. We now it's ugly but we don't have a better solution but to bypass the command queue.


Axis Bluetooth team

-----Original Message-----
From: Oliver Kasten [mailto:kasten@xxxxxxx.ch]
Sent: Monday, December 04, 2000 12:47 PM
To: bluetooth-dev@xxxxxxx.com
Subject: [bluetooth-dev] bug in COMMAND_COMPLETE and COMMAND_STATUS
events processing

in hci.c in process_event(...) case COMMAND_COMPLETE (hci.c:1005) and
COMMAND_STATUS(hci.c:1020) the Num_HCI_Command_Packets parameter of both
events is interpreted relative. however, it is an meant to be an
absolute value!

to fix replace
(hci.c:1007)hci_ctrl.hc_buf.cmd_num += buf[0];
(hci.c:1027)hci_ctrl.hc_buf.cmd_num =+buf[1];

hci_ctrl.hc_buf.cmd_num = buf[0];
hci_ctrl.hc_buf.cmd_num = buf[1];
respectively. also the current version containes a typo in line
hci.c:1027 ("=+").

the Num_HCI_Command_Packets parameter of the COMMAND_COMPLETE and
COMMAND_STATUS events tell the host how many command packets it can send
to the host controller. this value must be interpreted as a total
number. in your implementation, however, the value is added to the value
kept by the stack locally. that isn't a problem with the current stack
and the bt-implementations available these days.

however, i ran into a problem while implementing a new scheduler for the
stack (in usermade), that does not require threads. your implementation
of set_ericsson_baudrate(...) (with P9A defined) sends the set-baudrate
command packet bypassing the command queue. when the queue is full
(hci_ctrl.hc_buf.cmd_num==0) i ended up with
hci_ctrl.hc_buf.cmd_num==-1; command complete event returned a
Num_HCI_Command_Packets parameter of 1, resulting in
hci_ctrl.hc_buf.cmd_num to be 0. no events were sent ever after...

it may also become a general problem, when implementations of the host
controller (the bt hardware) dynamically change the value during runtime
(e.g. an emulated bt-device utilizing some other protocol).

Oliver Kasten                                phone: +41/ 1/ 63-2 06 63
ETH-Zurich                                     fax: +41/ 1/ 63-2 16 59
Haldeneggsteig 4, IFW D48.1                  email: kasten@xxxxxxx.ch
CH-8092 Zuerich, Switzerland           http://www.inf.ethz.ch/~kasten/
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com
To unsubscribe from this list: send the line "unsubscribe bluetooth-dev" in
the body of a message to majordomo@xxxxxxx.com