Hi Marcel,
>> I'm running kernel 3.8.11 on a x86_64 and BlueZ 5.4. The hardware is a
>> chromebook (I saw it with different hardware and I can also repro it
>> on my ubuntu) that uses the ath9k and ath3k drivers for the wifi/bt
>> chip (MD222)
>
> I do not have a Chromebook or actually looked into what Bluetooth chip it uses. Is that one also an ath3k one? Hope the hardware does not have a bug here. It is on USB, right?
Is an ath3k, and bluetooth is conected to the usb.
> Can you reproduce this with a off the shelf CSR or Broadcom chip. Maybe I should send you some of the Intel chips so you can test on our silicon as well ;)
I just tried it again on my desktop with a Broadcom usb 0a5c:21e8 (I
think that one is a BCM20702) and I was able to reproduce it with
btmgmt as well (bluez compiled from tip of tree). It took more
iterations (about 50) but eventually the repro case works (in a
different point, see the btmon traces below). I have a bunch of
different Broadcom, Atheros and CSR usb bluetooth adapters here, but
none from Intel ;)
> I can't say this for sure, but if this is our fault and not a hardware issue then this seems to be a pretty nasty race condition.
>
> To debug this you might need to work with dynamic_debug for Bluetooth core and add a few more DBG statements so we get timing information that we can compare with the btmon trace.
>
> So in theory all modern chips should send HCI_Reset on devup. Only a few old broken ones will send HCI_Reset on devdown. Can you check that the ath3k does not send a quirk here and really does HCI_Reset on devup. And that the ath3k firmware loading part not accidentally gets in the way.
>
> It would be also good to verify if devup or devdown is the root cause here.
I don't understand how this could be a hardware problem. I must be
missing something. The host is sending to the controller two
consecutive commands, the second one is a HCI_Reset caused by the
power off/on, but the spec says that we should not send more than one
command at that point (ncmd of the last event is 1). So, since we are
out of spec the firmware is happy to block itself in a bad way :)
right?
Regards,
Alex
< HCI Command: Write LE Host Supported (0x03|0x006d) plen 2
[hci0] 58988.081654
Supported: 0x01
Simultaneous: 0x01
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 58988.084618
Write LE Host Supported (0x03|0x006d) ncmd 1
Status: Success (0x00)
< HCI Command: LE Set Advertising Data (0x08|0x0008) plen 32
[hci0] 58988.084713
Length: 18
Flags: 0x18
Simultaneous LE and BR/EDR (Controller)
Simultaneous LE and BR/EDR (Host)
TX power: 4 dBm
Name (complete): Drink Mate
@ New Settings: 0x02d3
powered connectable pairable ssp br/edr le
@ New Settings: 0x02d2
connectable pairable ssp br/edr le
< HCI Command: Reset (0x03|0x0003) plen 0
[hci0] 58988.087811
-----------------------------------------------------------------------------------------------------------------------------------
other case:
< HCI Command: Write LE Host Supported (0x03|0x006d) plen 2
[hci0] 61133.028188
Supported: 0x01
Simultaneous: 0x01
> HCI Event: Command Complete (0x0e) plen 4 [hci0] 61133.031169
Write LE Host Supported (0x03|0x006d) ncmd 1
Status: Success (0x00)
@ New Settings: 0x02d3
powered connectable pairable ssp br/edr le
< HCI Command: LE Set Advertising Data (0x08|0x0008) plen 32
[hci0] 61133.031261
Length: 18
Flags: 0x18
Simultaneous LE and BR/EDR (Controller)
Simultaneous LE and BR/EDR (Host)
TX power: 4 dBm
Name (complete): Drink Mate
@ New Settings: 0x02d2
connectable pairable ssp br/edr le
< HCI Command: Reset (0x03|0x0003) plen 0
[hci0] 61133.035268
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
