Comment 300 for bug 268502

Still happens here, while we're stuck on 2.6.31, the userspace is Maverick at today's latest updates. It can't be an HCI 1.1 problem because this one is 2.1, and it has a default link policy :)

hci0: Type: BR/EDR Bus: USB
        BD Address: 00:22:43:D9:D7:84 ACL MTU: 1021:8 SCO MTU: 64:1
        UP RUNNING PSCAN
        RX bytes:1009 acl:0 sco:0 events:34 errors:0
        TX bytes:1103 acl:0 sco:0 commands:34 errors:0
        Features: 0xff 0xff 0x8f 0xfe 0x9b 0xff 0x79 0x83
        Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
        Link policy: RSWITCH HOLD SNIFF PARK
        Link mode: SLAVE ACCEPT
        Name: 'BCM2046B1 Bluetooth Device'
        Class: 0x480000
        Service Classes: Capturing, Telephony
        Device Class: Miscellaneous,
        HCI Version: 2.1 (0x4) Revision: 0x50eb
        LMP Version: 2.1 (0x4) Subversion: 0x420e
        Manufacturer: Broadcom Corporation (15)

Note that while GNOME insists the bluetooth module is "Turned Off" and doesn't turn it back on, all the userspace tools work fine (scanning for devices finds my PC across the room and a mouse..)

We've also noticed that a very strange effect occurs: if there is a Bluetooth device actively pairing (a previously paired mouse for example) and it reconnects, everything is absolutely fine. If not, then it will do the hci0 command timeout... it seems to me that the Bluetooth device is basically being "powered down" or put in a suspend state by gnome-bluetooth if nothing is around (note; our 2.6.31 kernel has no USB autosuspend for btusb, so it must be a Bluetooth suspend command or something).

Thoughts/opinions?