* patch: problem with sco
@ 2006-01-12 0:38 Wolfgang Walter
2006-01-12 9:14 ` Marcel Holtmann
0 siblings, 1 reply; 11+ messages in thread
From: Wolfgang Walter @ 2006-01-12 0:38 UTC (permalink / raw)
To: bluez-devel, linux-kernel; +Cc: marcel, maxk
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
wolfgang.walter@studentenwerk.mhn.de
http://www.studentenwerk.mhn.de/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch: problem with sco
2006-01-12 0:38 patch: problem with sco Wolfgang Walter
@ 2006-01-12 9:14 ` Marcel Holtmann
2006-01-12 11:47 ` Wolfgang Walter
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Marcel Holtmann @ 2006-01-12 9:14 UTC (permalink / raw)
To: Wolfgang Walter; +Cc: bluez-devel, linux-kernel, maxk
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch: problem with sco
2006-01-12 9:14 ` Marcel Holtmann
@ 2006-01-12 11:47 ` Wolfgang Walter
2006-01-12 12:26 ` Patrick McHardy
2006-01-12 23:31 ` Wolfgang Walter
2 siblings, 0 replies; 11+ messages in thread
From: Wolfgang Walter @ 2006-01-12 11:47 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: bluez-devel, linux-kernel, maxk, Andrew Morton
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. 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'll send you that information that information this evening because I don't
have access to the hardware now.
For the bluetooth usb-dongle: it is the Belkin F8T013de and it has a broadcom
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
number of outstanding sco packets.
We only found out using scotest that no packets are sent (tx_sco remains 0 and
hcidump shows no outgoing sco-traffic) and tried to find out where in the
stack they get lost. We found that hci_sched_sco is called but actually never
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
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 but
we didn't found any answer with a solution. We thought it might be a good
idea to send this patch so that others can give it a try and see if there
bluetooth-dongles will work at all. And it may helps others with a deeper
underständing 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
zero is probably not the final solution (we arbitrary chose 8). But zero
certainly makes no much sense at all, either. If sco_pkts is zero no sco
packets will be sent.
Correct me if I'm wrong:
* sco_pkts says how many packets may be sent to the hardware without
completion. At the beginning sco_cnt is set do sco_pkts. For every packet we
send it is decremented, for every completion it is incremented (but not
beyond sco_pkts).
* when usb device is opened cmd OGF_INFO_PARAM, OCF_READ_BUFFER_SIZE is sent.
The device answers with an event OCF_READ_BUFFER_SIZE and then sco_pkts and
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
hci_dev_cmd. But sco_cnt remains zero. As long as there is no completion
message sco_cnt will remain zero and as there never has been sent any sco
packet there will never be a completion message.
By the way: even if sco_pkts was initially > 0: if one increase sco_pkts this
will have no effect as sco_cnt will only be increased by completions and
therefore only reach the initial value of sco_pkts. Why can it be set at all
(it seems one can only decrease it and then never increase it again without
reinitialisation).
The same holds for acl_pkts.
As far as I can see bs->sco_max_pk == 0 only would make sense for
OCF_READ_BUFFER_SIZE events which are sent after initialisiation when the
device is already sending. I don't know if a device will sent such an event
unrequested and I don't see the stack sending a OCF_READ_BUFFER_SIZE cmd
after initialisation.
--
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
wolfgang.walter@studentenwerk.mhn.de
http://www.studentenwerk.mhn.de/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch: problem with sco
2006-01-12 9:14 ` Marcel Holtmann
2006-01-12 11:47 ` Wolfgang Walter
@ 2006-01-12 12:26 ` Patrick McHardy
2006-01-12 13:31 ` Marcel Holtmann
2006-01-12 23:31 ` Wolfgang Walter
2 siblings, 1 reply; 11+ messages in thread
From: Patrick McHardy @ 2006-01-12 12:26 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Wolfgang Walter, bluez-devel, linux-kernel, maxk
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)
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch: problem with sco
2006-01-12 12:26 ` Patrick McHardy
@ 2006-01-12 13:31 ` Marcel Holtmann
2006-01-12 13:56 ` Patrick McHardy
2006-01-12 14:59 ` Wolfgang Walter
0 siblings, 2 replies; 11+ messages in thread
From: Marcel Holtmann @ 2006-01-12 13:31 UTC (permalink / raw)
To: Patrick McHardy; +Cc: Wolfgang Walter, bluez-devel, linux-kernel, maxk
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch: problem with sco
2006-01-12 13:31 ` Marcel Holtmann
@ 2006-01-12 13:56 ` Patrick McHardy
2006-01-12 14:59 ` Wolfgang Walter
1 sibling, 0 replies; 11+ messages in thread
From: Patrick McHardy @ 2006-01-12 13:56 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Wolfgang Walter, bluez-devel, linux-kernel, maxk
[-- Attachment #1: Type: text/plain, Size: 409 bytes --]
Marcel Holtmann wrote:
>>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.
Its an USB device. I've attached the output of "lsusb -v", in case
that helps.
[-- Attachment #2: x --]
[-- Type: text/plain, Size: 10546 bytes --]
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch: problem with sco
2006-01-12 13:31 ` Marcel Holtmann
2006-01-12 13:56 ` Patrick McHardy
@ 2006-01-12 14:59 ` Wolfgang Walter
1 sibling, 0 replies; 11+ messages in thread
From: Wolfgang Walter @ 2006-01-12 14:59 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Patrick McHardy, bluez-devel, linux-kernel, maxk
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
seems that one can switch on and off flow control for SCO (but switched off
completion events should not be sent at all).
There is another thing with flow-control in in bluez: as far as I see the code
assumes to get a completion event for every packet submitted to the
controller. But this is not necessarily the case. A HCI_EV_DISCONN_COMPLETE
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,
--
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
wolfgang.walter@studentenwerk.mhn.de
http://www.studentenwerk.mhn.de/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch: problem with sco
2006-01-12 9:14 ` Marcel Holtmann
2006-01-12 11:47 ` Wolfgang Walter
2006-01-12 12:26 ` Patrick McHardy
@ 2006-01-12 23:31 ` Wolfgang Walter
2006-01-12 23:33 ` Wolfgang Walter
2006-01-13 8:27 ` Marcel Holtmann
2 siblings, 2 replies; 11+ messages in thread
From: Wolfgang Walter @ 2006-01-12 23:31 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: bluez-devel, linux-kernel, maxk
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: 0x410e
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)
--
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
wolfgang.walter@studentenwerk.mhn.de
http://www.studentenwerk.mhn.de/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch: problem with sco
2006-01-12 23:31 ` Wolfgang Walter
@ 2006-01-12 23:33 ` Wolfgang Walter
2006-01-13 8:27 ` Marcel Holtmann
1 sibling, 0 replies; 11+ messages in thread
From: Wolfgang Walter @ 2006-01-12 23:33 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: bluez-devel, linux-kernel, maxk
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
wolfgang.walter@studentenwerk.mhn.de
http://www.studentenwerk.mhn.de/
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch: problem with sco
2006-01-12 23:31 ` Wolfgang Walter
2006-01-12 23:33 ` Wolfgang Walter
@ 2006-01-13 8:27 ` Marcel Holtmann
2006-01-15 14:40 ` Wolfgang Walter
1 sibling, 1 reply; 11+ messages in thread
From: Marcel Holtmann @ 2006-01-13 8:27 UTC (permalink / raw)
To: Wolfgang Walter; +Cc: bluez-devel, linux-kernel, maxk
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: patch: problem with sco
2006-01-13 8:27 ` Marcel Holtmann
@ 2006-01-15 14:40 ` Wolfgang Walter
0 siblings, 0 replies; 11+ messages in thread
From: Wolfgang Walter @ 2006-01-15 14:40 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: bluez-devel, linux-kernel, maxk
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=1 ?
>
So, I tested this today: changed nothing. Neither the output of hciconfig has
changed nor any data is sent to the headset.
Regards,
--
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
wolfgang.walter@studentenwerk.mhn.de
http://www.studentenwerk.mhn.de/
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2006-01-15 14:40 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-01-12 0:38 patch: problem with sco Wolfgang Walter
2006-01-12 9:14 ` Marcel Holtmann
2006-01-12 11:47 ` Wolfgang Walter
2006-01-12 12:26 ` Patrick McHardy
2006-01-12 13:31 ` Marcel Holtmann
2006-01-12 13:56 ` Patrick McHardy
2006-01-12 14:59 ` Wolfgang Walter
2006-01-12 23:31 ` Wolfgang Walter
2006-01-12 23:33 ` Wolfgang Walter
2006-01-13 8:27 ` Marcel Holtmann
2006-01-15 14:40 ` Wolfgang Walter
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).