A friend and I encountered a problem with sco transfers to a headset using
linux (vanilla 2.6.15). While all sco packets sent by the headset were
received there was no outgoing traffic.
After switching debugging output on we found that actually sco_cnt was always
zero in hci_sched_sco.
hciconfig hci0 shows sco_mtu to be 64:0. Changing that to 64:8 did not help.
This was because in hci_cc_info_param hdev->sco_pkts is set to zero. When we
changed this line so that hdev->sco_pkts is set to 8 if bs->sco_max_pkt is 0
sco transfer to the headset started to work just fine.
Here the patch:
--- linux-2.6.15/net/bluetooth/hci_event.c 2006-01-03 04:21:10.000000000 +0100
+++ linux-2.6.15-dbg/net/bluetooth/hci_event.c 2006-01-12 00:35:48.000000000 +0100
@@ -322,7 +322,7 @@
hdev->acl_mtu = __le16_to_cpu(bs->acl_mtu);
hdev->sco_mtu = bs->sco_mtu ? bs->sco_mtu : 64;
hdev->acl_pkts = hdev->acl_cnt = __le16_to_cpu(bs->acl_max_pkt);
- hdev->sco_pkts = hdev->sco_cnt = __le16_to_cpu(bs->sco_max_pkt);
+ hdev->sco_pkts = hdev->sco_cnt = (bs->sco_max_pkt ? __le16_to_cpu(bs->sco_max_pkt) : 8);
BT_DBG("%s mtu: acl %d, sco %d max_pkt: acl %d, sco %d", hdev->name,
hdev->acl_mtu, hdev->sco_mtu, hdev->acl_pkts, hdev->sco_pkts);
--
Wolfgang Walter
Studentenwerk M?nchen
Anstalt des ?ffentlichen Rechts
Leiter EDV
Leopoldstra?e 15
80802 M?nchen
Tel: +49 89 38196-276
Fax: +49 89 38196-144
[email protected]
http://www.studentenwerk.mhn.de/
Hi Marcel,
Am Freitag, 13. Januar 2006 09:27 schrieb Marcel Holtmann:
> Hi Wolfgang,
>
> > > send in the information from "hciconfig -a" for this device, because
> > > this is a hardware bug and you can't be sure that you can have eight
> > > outstanding SCO packets.
>
> does anything changes if you load the hci_usb driver with reset=3D1 ?
>
So, I tested this today: changed nothing. Neither the output of hciconfig h=
as=20
changed nor any data is sent to the headset.
Regards,
=2D-=20
Wolfgang Walter
Studentenwerk M=FCnchen
Anstalt des =F6ffentlichen Rechts
Leiter EDV
Leopoldstra=DFe 15
80802 M=FCnchen
Tel: +49 89 38196 276
=46ax: +49 89 38196 144
[email protected]
http://www.studentenwerk.mhn.de/
Hi Wolfgang,
> > send in the information from "hciconfig -a" for this device, because
> > this is a hardware bug and you can't be sure that you can have eight
> > outstanding SCO packets.
does anything changes if you load the hci_usb driver with reset=1 ?
Regards
Marcel
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bluez-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bluez-devel
Am Freitag, 13. Januar 2006 00:31 schrieb Wolfgang Walter:
> Hi Marcel,
>
>
> >/usr/sbin/hciconfig -a
>
> hci0: Type: USB
> BD Address: 00:00:3A:6A:18:D1 ACL MTU: 1017:8 SCO MTU: 64:8
SCO MTU: 64:8 because is of our patch. Without patch it is 64:0
--
Wolfgang Walter
Studentenwerk M?nchen
Anstalt des ?ffentlichen Rechts
Leiter EDV
Leopoldstra?e 15
80802 M?nchen
Tel: +49 89 38196 276
Fax: +49 89 38196 144
[email protected]
http://www.studentenwerk.mhn.de/
Hi Marcel,
Am Donnerstag, 12. Januar 2006 10:14 schrieb Marcel Holtmann:
> Hi Wolfgang,
>
>
> send in the information from "hciconfig -a" for this device, because
> this is a hardware bug and you can't be sure that you can have eight
> outstanding SCO packets.
>
Here the output of 'hciconfig -a' and 'lsusb -v'
>/usr/sbin/hciconfig -a
hci0: Type: USB
BD Address: 00:00:3A:6A:18:D1 ACL MTU: 1017:8 SCO MTU: 64:8
UP RUNNING PSCAN ISCAN
RX bytes:4348 acl:99 sco:0 events:105 errors:0
TX bytes:1924 acl:78 sco:0 commands:39 errors:0
Features: 0xff 0xfb 0x8d 0xfe 0x9f 0xf9 0x00 0x80
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'r062032-0'
Class: 0x3e0100
Service Classes: Networking, Rendering, Capturing
Device Class: Computer, Uncategorized
HCI Ver: 2.0 (0x3) HCI Rev: 0x2073 LMP Ver: 2.0 (0x3) LMP Subver: 0=
x410e
Manufacturer: Broadcom Corporation (15)
> lsusb -v
Bus 004 Device 002: ID 050d:0013 Belkin Components
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x050d Belkin Components
idProduct 0x0013
bcdDevice 0.00
iManufacturer 1 Broadcom Corp
iProduct 2 Belkin Bluetooth Device
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 216
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0019 1x 25 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0021 1x 33 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 5
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 0
iInterface 0
Device Status: 0x0000
(Bus Powered)
=2D-=20
Wolfgang Walter
Studentenwerk M=FCnchen
Anstalt des =F6ffentlichen Rechts
Leiter EDV
Leopoldstra=DFe 15
80802 M=FCnchen
Tel: +49 89 38196 276
=46ax: +49 89 38196 144
[email protected]
http://www.studentenwerk.mhn.de/
Hi Marcel,
> so it seems that Broadcom really messed the SCO MTU settings up and we
> have to workaround with some sane values.
Maybe flow control for SCO must be explicitly switched on on broadcom? It=20
seems that one can switch on and off flow control for SCO (but switched off=
=20
completion events should not be sent at all).
There is another thing with flow-control in in bluez: as far as I see the c=
ode=20
assumes to get a completion event for every packet submitted to the=20
controller. But this is not necessarily the case. A HCI_EV_DISCONN_COMPLETE=
=20
for a connection implicitly completes all packets of that connection.
I don't know if any controller uses this feature, though.
>
> Please also include the lspci for these devices.
>
Regards,
=2D-=20
Wolfgang Walter
Studentenwerk M=FCnchen
Anstalt des =F6ffentlichen Rechts
Leiter EDV
Leopoldstra=DFe 15
80802 M=FCnchen
Tel: +49 89 38196 276
=46ax: +49 89 38196 144
[email protected]
http://www.studentenwerk.mhn.de/
Bus 002 Device 003: ID 03f0:011d Hewlett-Packard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x03f0 Hewlett-Packard
idProduct 0x011d
bcdDevice 0.17
iManufacturer 1 Broadcom
iProduct 2 HP integrated Bluetooth module
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 216
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0009 1x 9 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 2
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0011 1x 17 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 3
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 4
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 5
bNumEndpoints 2
bInterfaceClass 224 Wireless
bInterfaceSubClass 1 Radio Frequency
bInterfaceProtocol 1 Bluetooth
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 255 Vendor Specific Subclass
bInterfaceProtocol 255 Vendor Specific Protocol
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 1
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 254 Application Specific Interface
bInterfaceSubClass 1 Device Firmware Update
bInterfaceProtocol 0
iInterface 0
Device Status: 0x0001
Self Powered
Hi Patrick,
> >>A friend and I encountered a problem with sco transfers to a headset using
> >>linux (vanilla 2.6.15). While all sco packets sent by the headset were
> >>received there was no outgoing traffic.
> >>
> >>After switching debugging output on we found that actually sco_cnt was always
> >>zero in hci_sched_sco.
>
> I'm seeing the exact same problem with a Logitech "mobile Freedom"
> headset. I'm using this patch to work around the problem:
so it seems that Broadcom really messed the SCO MTU settings up and we
have to workaround with some sane values.
Please also include the lspci for these devices.
Regards
Marcel
Marcel Holtmann wrote:
>>A friend and I encountered a problem with sco transfers to a headset using
>>linux (vanilla 2.6.15). While all sco packets sent by the headset were
>>received there was no outgoing traffic.
>>
>>After switching debugging output on we found that actually sco_cnt was always
>>zero in hci_sched_sco.
I'm seeing the exact same problem with a Logitech "mobile Freedom"
headset. I'm using this patch to work around the problem:
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -1239,7 +1239,7 @@ static inline void hci_sched_sco(struct
BT_DBG("%s", hdev->name);
- while (hdev->sco_cnt && (conn = hci_low_sent(hdev, SCO_LINK,
"e))) {
+ while (/* hdev->sco_cnt && */ (conn = hci_low_sent(hdev,
SCO_LINK, "e))) {
while (quote-- && (skb = skb_dequeue(&conn->data_q))) {
BT_DBG("skb %p len %d", skb, skb->len);
hci_send_frame(skb);
> send in the information from "hciconfig -a" for this device, because
> this is a hardware bug and you can't be sure that you can have eight
> outstanding SCO packets.
In my case:
hci0: Type: USB
BD Address: 00:10:C6:86:64:27 ACL MTU: 377:10 SCO MTU: 48:64
UP RUNNING PSCAN ISCAN
RX bytes:622370 acl:27 sco:12167 events:69 errors:0
TX bytes:588454 acl:25 sco:11520 commands:35 errors:0
Features: 0xff 0xfe 0x0d 0x38 0x08 0x08 0x00 0x00
Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy: RSWITCH HOLD SNIFF PARK
Link mode: SLAVE ACCEPT
Name: 'krusty-0'
Class: 0x3e0100
Service Classes: Networking, Rendering, Capturing
Device Class: Computer, Uncategorized
HCI Ver: 1.2 (0x2) HCI Rev: 0x11 LMP Ver: 1.2 (0x2) LMP Subver:
0x6963
Manufacturer: Broadcom Corporation (15)
Hi Marcel,
Am Donnerstag, 12. Januar 2006 10:14 schrieb Marcel Holtmann:
> Hi Wolfgang,
>
> > A friend and I encountered a problem with sco transfers to a headset
> > using linux (vanilla 2.6.15). While all sco packets sent by the headset
> > were received there was no outgoing traffic.
> >
> > After switching debugging output on we found that actually sco_cnt was
> > always zero in hci_sched_sco.
> >
> > hciconfig hci0 shows sco_mtu to be 64:0. Changing that to 64:8 did not
> > help.
> >
> > This was because in hci_cc_info_param hdev->sco_pkts is set to zero. Wh=
en
> > we changed this line so that hdev->sco_pkts is set to 8 if
> > bs->sco_max_pkt is 0 sco transfer to the headset started to work just
> > fine.
>
> send in the information from "hciconfig -a" for this device, because
> this is a hardware bug and you can't be sure that you can have eight
> outstanding SCO packets.
I'll send you that information that information this evening because I don=
't=20
have access to the hardware now.
=46or the bluetooth usb-dongle: it is the Belkin F8T013de and it has a broa=
dcom=20
chip. As it is a usb 2.0 device and supports bluetooth 2.0 + edr.
The headset is a Siemens HHB-600.
>
> I personally prefer to implement this as a quirk which can be activated
> by the driver. Once I have seen the device information, I will think
> about how we might deal with it.
>
To be true, I don't know how exactly the driver hci_usb.c sets the maximum=
=20
number of outstanding sco packets.
We only found out using scotest that no packets are sent (tx_sco remains 0 =
and=20
hcidump shows no outgoing sco-traffic) and tried to find out where in the=20
stack they get lost. We found that hci_sched_sco is called but actually nev=
er=20
sent any packets because sco_cnt was always zero.
This is because sco_pkts is set to zero in hci_cc_info_param (hci_event.c)=
in=20
case OCF_READ_BUFFER_SIZE bs->sco_max_pkt is always zero.
We found several error reports of the same kind dating from 2005 and 2004 b=
ut=20
we didn't found any answer with a solution. We thought it might be a good=20
idea to send this patch so that others can give it a try and see if there=20
bluetooth-dongles will work at all. And it may helps others with a deeper=20
underst=E4nding of bluetooth to find the real problem of those
It is clear that hardwiring sco_pkts to 8 if (and only if) bs->sco_max_pkt =
is=20
zero is probably not the final solution (we arbitrary chose 8). But zero=20
certainly makes no much sense at all, either. If sco_pkts is zero no sco=20
packets will be sent.
Correct me if I'm wrong:
* sco_pkts says how many packets may be sent to the hardware without=20
completion. At the beginning sco_cnt is set do sco_pkts. For every packet w=
e=20
send it is decremented, for every completion it is incremented (but not=20
beyond sco_pkts).
* when usb device is opened cmd OGF_INFO_PARAM, OCF_READ_BUFFER_SIZE is sen=
t.=20
The device answers with an event OCF_READ_BUFFER_SIZE and then sco_pkts and=
=20
sco_cnt is set.
Therefor in our case sco_mtu is 64:0 unpatched and 64:8 patched.
* hciconfig hci0 scomtu 64:8 wil change sco_pkts to 8 (and it does) in=20
hci_dev_cmd. But sco_cnt remains zero. As long as there is no completion=20
message sco_cnt will remain zero and as there never has been sent any sco=20
packet there will never be a completion message.
By the way: even if sco_pkts was initially > 0: if one increase sco_pkts th=
is=20
will have no effect as sco_cnt will only be increased by completions and=20
therefore only reach the initial value of sco_pkts. Why can it be set at al=
l=20
(it seems one can only decrease it and then never increase it again without=
=20
reinitialisation).
The same holds for acl_pkts.
As far as I can see bs->sco_max_pk =3D=3D 0 only would make sense for=20
OCF_READ_BUFFER_SIZE events which are sent after initialisiation when the=20
device is already sending. I don't know if a device will sent such an event=
=20
unrequested and I don't see the stack sending a OCF_READ_BUFFER_SIZE cmd=20
after initialisation.
=2D-=20
Wolfgang Walter
Studentenwerk M=FCnchen
Anstalt des =F6ffentlichen Rechts
Leiter EDV
Leopoldstra=DFe 15
80802 M=FCnchen
Tel: +49 89 38196 276
=46ax: +49 89 38196 144
[email protected]
http://www.studentenwerk.mhn.de/
Hi Wolfgang,
> A friend and I encountered a problem with sco transfers to a headset using
> linux (vanilla 2.6.15). While all sco packets sent by the headset were
> received there was no outgoing traffic.
>
> After switching debugging output on we found that actually sco_cnt was always
> zero in hci_sched_sco.
>
> hciconfig hci0 shows sco_mtu to be 64:0. Changing that to 64:8 did not help.
>
> This was because in hci_cc_info_param hdev->sco_pkts is set to zero. When we
> changed this line so that hdev->sco_pkts is set to 8 if bs->sco_max_pkt is 0
> sco transfer to the headset started to work just fine.
send in the information from "hciconfig -a" for this device, because
this is a hardware bug and you can't be sure that you can have eight
outstanding SCO packets.
I personally prefer to implement this as a quirk which can be activated
by the driver. Once I have seen the device information, I will think
about how we might deal with it.
Regards
Marcel