Re: second scan timing out, bisected to 314b2381a79c6bfe3ddc4ba3806ecb6aec27a3db

[Johan Hedberg <johan.hedberg@gmail.com>]

Hi Oliver,

On Tue, Aug 30, 2011, Oliver Neukum wrote:
> I am seeing with newer kernels a regression in "hcitool scan" failing if it
> is issued a second or further times by timing out. I can bisect this in the
> kernel to
> 
> commit 314b2381a79c6bfe3ddc4ba3806ecb6aec27a3db
> Author: Johan Hedberg <johan.hedberg@nokia.com>
> Date:   Wed Apr 27 10:29:57 2011 -0400
> 
>     Bluetooth: Add discovering event to the Management interface
>     
>     This patch adds a new event to the Management interface to track when
>     local adapters are discovering remote devices. For now this only tracks
>     BR/EDR discovery procedures.
> 
> Is this a known issue. Might this be an issue with too old bluez utils?
> I am using bluez-4.64

I think this is a real issue, but it only happens with the HCIINQUIRY
ioctl which bluetoothd doesn't use (but hcitool does). I think the
problems is with the following type of additions in the patch:

+       if (test_bit(HCI_MGMT, &hdev->flags) &&
+                               test_and_clear_bit(HCI_INQUIRY, &hdev->flags))
+               mgmt_discovering(hdev->id, 0);

Because of the ordering of the if-statement the HCI_INQUIRY flags
doesn't get cleared if HCI_MGMT is not set and so the HCIINQUIRY ioctl
doesn't trigger inquiry even though it should (see hci_inq_req in
net/bluetooth/hci_core.c). Can you try to flip the ordering of the
test_bit and test_and_clear_bit calls in all relevant if-statements in
the patch and see if it resolves your issue?

Johan