* [Bluez-users] hciconfig hci0 reset bug
@ 2008-02-28 22:51 Odysseus Flappington
2008-03-03 1:21 ` Dave Young
0 siblings, 1 reply; 15+ messages in thread
From: Odysseus Flappington @ 2008-02-28 22:51 UTC (permalink / raw)
To: bluez-users
So, it turns out that in order for any external usb bluetooth adapters
to re-connect to paired input devices on reboot, you need to issue an
'hciconfig hci0 reset' command after rebooting in order to reconnect.
More info can be found in bug #133690 on Launchpad
(https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
This bug isn't Ubuntu-specific since I have reproduced in Fedora 8, so
I'm posting here.
Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth in
source would solve this bug. Is this a reasonable solution?
What is required in order to get a fix implemented?
Thanks,
Alex (Jackflap/OdyTheDog)
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-02-28 22:51 [Bluez-users] hciconfig hci0 reset bug Odysseus Flappington
@ 2008-03-03 1:21 ` Dave Young
2008-03-03 1:24 ` Dave Young
0 siblings, 1 reply; 15+ messages in thread
From: Dave Young @ 2008-03-03 1:21 UTC (permalink / raw)
To: BlueZ users
On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
<deriziotis@gmail.com> wrote:
> So, it turns out that in order for any external usb bluetooth adapters
> to re-connect to paired input devices on reboot, you need to issue an
> 'hciconfig hci0 reset' command after rebooting in order to reconnect.
>
> More info can be found in bug #133690 on Launchpad
> (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
>
> This bug isn't Ubuntu-specific since I have reproduced in Fedora 8, so
> I'm posting here.
>
> Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth in
> source would solve this bug. Is this a reasonable solution?
>
> What is required in order to get a fix implemented?
>
> Thanks,
> Alex (Jackflap/OdyTheDog)
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Bluez-users mailing list
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-03-03 1:21 ` Dave Young
@ 2008-03-03 1:24 ` Dave Young
2008-03-03 11:35 ` Odysseus Flappington
0 siblings, 1 reply; 15+ messages in thread
From: Dave Young @ 2008-03-03 1:24 UTC (permalink / raw)
To: BlueZ users
On Mon, Mar 3, 2008 at 9:21 AM, Dave Young <hidave.darkstar@gmail.com> wrote:
> On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> <deriziotis@gmail.com> wrote:
>
>
> > So, it turns out that in order for any external usb bluetooth adapters
> > to re-connect to paired input devices on reboot, you need to issue an
> > 'hciconfig hci0 reset' command after rebooting in order to reconnect.
> >
> > More info can be found in bug #133690 on Launchpad
> > (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> >
> > This bug isn't Ubuntu-specific since I have reproduced in Fedora 8, so
> > I'm posting here.
> >
> > Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth in
> > source would solve this bug. Is this a reasonable solution?
> >
> > What is required in order to get a fix implemented?
Sorry for previous blank reply.
For your problem, if you don't want to patch kernel you can also try
load the bluetooth module with parameter "reset=1"
Could you send the lsusb output?
Regards
dave
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-03-03 1:24 ` Dave Young
@ 2008-03-03 11:35 ` Odysseus Flappington
2008-03-03 22:19 ` Odysseus Flappington
0 siblings, 1 reply; 15+ messages in thread
From: Odysseus Flappington @ 2008-03-03 11:35 UTC (permalink / raw)
To: BlueZ users
Hi Dave,
Thanks for the help. I can probably get a recompile of my kernel done
by the end of the weekend, maybe end of week, if it'll help.
In the meantime, I'll try loading the bluetooth module with reset=1
and get the lsusb output to you tonight when I get home from work.
Thanks,
Alex (Jackflap)
On 03/03/2008, Dave Young <hidave.darkstar@gmail.com> wrote:
> On Mon, Mar 3, 2008 at 9:21 AM, Dave Young <hidave.darkstar@gmail.com> wrote:
> > On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> > <deriziotis@gmail.com> wrote:
> >
> >
> > > So, it turns out that in order for any external usb bluetooth adapters
> > > to re-connect to paired input devices on reboot, you need to issue an
> > > 'hciconfig hci0 reset' command after rebooting in order to reconnect.
> > >
> > > More info can be found in bug #133690 on Launchpad
> > > (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> > >
> > > This bug isn't Ubuntu-specific since I have reproduced in Fedora 8, so
> > > I'm posting here.
> > >
> > > Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth in
> > > source would solve this bug. Is this a reasonable solution?
> > >
> > > What is required in order to get a fix implemented?
>
>
> Sorry for previous blank reply.
>
> For your problem, if you don't want to patch kernel you can also try
> load the bluetooth module with parameter "reset=1"
>
> Could you send the lsusb output?
>
> Regards
>
> dave
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Bluez-users mailing list
> Bluez-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bluez-users
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-03-03 11:35 ` Odysseus Flappington
@ 2008-03-03 22:19 ` Odysseus Flappington
2008-03-17 12:28 ` Odysseus Flappington
0 siblings, 1 reply; 15+ messages in thread
From: Odysseus Flappington @ 2008-03-03 22:19 UTC (permalink / raw)
To: BlueZ users
Ok,
I passed reset=1 to hci_usb by adding the following line to
/etc/modprobe.d/options:
options hci_usb reset=1
and that's fixed the problem!
Wasn't sure about my lsusb output, didn't seem to show very much, so
here's my lsusb -v output for my bluetooth device:
Bus 001 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
Bluetooth Dongle (HCI mode)
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 224 Wireless
bDeviceSubClass 1 Radio Frequency
bDeviceProtocol 1 Bluetooth
bMaxPacketSize0 64
idVendor 0x0a12 Cambridge Silicon Radio, Ltd
idProduct 0x0001 Bluetooth Dongle (HCI mode)
bcdDevice 31.64
iManufacturer 0
iProduct 0
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 177
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
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 0x02 EP 2 OUT
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 0x82 EP 2 IN
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 0x03 EP 3 OUT
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 0x83 EP 3 IN
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 0x03 EP 3 OUT
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 0x83 EP 3 IN
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 0x03 EP 3 OUT
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 0x83 EP 3 IN
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 0x03 EP 3 OUT
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 0x83 EP 3 IN
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 0x03 EP 3 OUT
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 0x83 EP 3 IN
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 0x03 EP 3 OUT
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 0x83 EP 3 IN
bmAttributes 1
Transfer Type Isochronous
Synch Type None
Usage Type Data
wMaxPacketSize 0x0031 1x 49 bytes
bInterval 1
Device Status: 0x0001
Self Powered
Thanks,
Alex
On 03/03/2008, Odysseus Flappington <deriziotis@gmail.com> wrote:
> Hi Dave,
>
> Thanks for the help. I can probably get a recompile of my kernel done
> by the end of the weekend, maybe end of week, if it'll help.
>
> In the meantime, I'll try loading the bluetooth module with reset=1
> and get the lsusb output to you tonight when I get home from work.
>
> Thanks,
> Alex (Jackflap)
>
>
> On 03/03/2008, Dave Young <hidave.darkstar@gmail.com> wrote:
> > On Mon, Mar 3, 2008 at 9:21 AM, Dave Young <hidave.darkstar@gmail.com> wrote:
> > > On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> > > <deriziotis@gmail.com> wrote:
> > >
> > >
> > > > So, it turns out that in order for any external usb bluetooth adapters
> > > > to re-connect to paired input devices on reboot, you need to issue an
> > > > 'hciconfig hci0 reset' command after rebooting in order to reconnect.
> > > >
> > > > More info can be found in bug #133690 on Launchpad
> > > > (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> > > >
> > > > This bug isn't Ubuntu-specific since I have reproduced in Fedora 8, so
> > > > I'm posting here.
> > > >
> > > > Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth in
> > > > source would solve this bug. Is this a reasonable solution?
> > > >
> > > > What is required in order to get a fix implemented?
> >
> >
> > Sorry for previous blank reply.
> >
> > For your problem, if you don't want to patch kernel you can also try
> > load the bluetooth module with parameter "reset=1"
> >
> > Could you send the lsusb output?
> >
> > Regards
> >
> > dave
> >
> >
> > -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Microsoft
> > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > _______________________________________________
> > Bluez-users mailing list
> > Bluez-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bluez-users
> >
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-03-03 22:19 ` Odysseus Flappington
@ 2008-03-17 12:28 ` Odysseus Flappington
2008-03-18 7:14 ` Dave Young
0 siblings, 1 reply; 15+ messages in thread
From: Odysseus Flappington @ 2008-03-17 12:28 UTC (permalink / raw)
To: Dave Young; +Cc: BlueZ users
[-- Attachment #1.1: Type: text/plain, Size: 12717 bytes --]
Hi Dave,
So I got around to recompiling my kernel this weekend, and ran off a test on
the patch attached and it worked like a charm.
I have to wonder though why the line was commented out in the first place.
Could it be because internal adapters don't need the line?
Anyway, I'd love to see this fixed in future kernels. If there's anything
else I can do to help test, let me know. Now that I've got my head around
recompiling kernels again, I can probably turn around tests a lot faster.
Many thanks,
Alex
On 03/03/2008, Odysseus Flappington <deriziotis@gmail.com> wrote:
>
> Ok,
>
> I passed reset=1 to hci_usb by adding the following line to
> /etc/modprobe.d/options:
>
> options hci_usb reset=1
>
> and that's fixed the problem!
>
> Wasn't sure about my lsusb output, didn't seem to show very much, so
> here's my lsusb -v output for my bluetooth device:
>
> Bus 001 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> Bluetooth Dongle (HCI mode)
> Device Descriptor:
> bLength 18
> bDescriptorType 1
> bcdUSB 2.00
> bDeviceClass 224 Wireless
> bDeviceSubClass 1 Radio Frequency
> bDeviceProtocol 1 Bluetooth
> bMaxPacketSize0 64
> idVendor 0x0a12 Cambridge Silicon Radio, Ltd
> idProduct 0x0001 Bluetooth Dongle (HCI mode)
> bcdDevice 31.64
> iManufacturer 0
> iProduct 0
> iSerial 0
> bNumConfigurations 1
> Configuration Descriptor:
> bLength 9
> bDescriptorType 2
> wTotalLength 177
> bNumInterfaces 2
> bConfigurationValue 1
> iConfiguration 0
> bmAttributes 0xc0
> Self Powered
> 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 0x02 EP 2 OUT
> 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 0x82 EP 2 IN
> 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 0x03 EP 3 OUT
> 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 0x83 EP 3 IN
> 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 0x03 EP 3 OUT
> 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 0x83 EP 3 IN
> 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 0x03 EP 3 OUT
> 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 0x83 EP 3 IN
> 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 0x03 EP 3 OUT
> 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 0x83 EP 3 IN
> 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 0x03 EP 3 OUT
> 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 0x83 EP 3 IN
> 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 0x03 EP 3 OUT
> 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 0x83 EP 3 IN
> bmAttributes 1
> Transfer Type Isochronous
> Synch Type None
> Usage Type Data
> wMaxPacketSize 0x0031 1x 49 bytes
> bInterval 1
> Device Status: 0x0001
> Self Powered
>
> Thanks,
> Alex
>
>
>
>
> On 03/03/2008, Odysseus Flappington <deriziotis@gmail.com> wrote:
> > Hi Dave,
> >
> > Thanks for the help. I can probably get a recompile of my kernel done
> > by the end of the weekend, maybe end of week, if it'll help.
> >
> > In the meantime, I'll try loading the bluetooth module with reset=1
> > and get the lsusb output to you tonight when I get home from work.
> >
> > Thanks,
> > Alex (Jackflap)
> >
> >
> > On 03/03/2008, Dave Young <hidave.darkstar@gmail.com> wrote:
> > > On Mon, Mar 3, 2008 at 9:21 AM, Dave Young <hidave.darkstar@gmail.com>
> wrote:
> > > > On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> > > > <deriziotis@gmail.com> wrote:
> > > >
> > > >
> > > > > So, it turns out that in order for any external usb bluetooth
> adapters
> > > > > to re-connect to paired input devices on reboot, you need to
> issue an
> > > > > 'hciconfig hci0 reset' command after rebooting in order to
> reconnect.
> > > > >
> > > > > More info can be found in bug #133690 on Launchpad
> > > > > (
> https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> > > > >
> > > > > This bug isn't Ubuntu-specific since I have reproduced in
> Fedora 8, so
> > > > > I'm posting here.
> > > > >
> > > > > Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth
> in
> > > > > source would solve this bug. Is this a reasonable solution?
> > > > >
> > > > > What is required in order to get a fix implemented?
> > >
> > >
> > > Sorry for previous blank reply.
> > >
> > > For your problem, if you don't want to patch kernel you can also try
> > > load the bluetooth module with parameter "reset=1"
> > >
> > > Could you send the lsusb output?
> > >
> > > Regards
> > >
> > > dave
> > >
> > >
>
> > > -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > _______________________________________________
> > > Bluez-users mailing list
> > > Bluez-users@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/bluez-users
> > >
> >
>
[-- Attachment #1.2: Type: text/html, Size: 35748 bytes --]
[-- Attachment #2: diff.hci_reset --]
[-- Type: application/octet-stream, Size: 609 bytes --]
net/bluetooth/hci_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -upr linux/net/bluetooth/hci_core.c linux.new/net/bluetooth/hci_core.c
--- linux/net/bluetooth/hci_core.c 2008-03-01 10:53:34.000000000 +0800
+++ linux.new/net/bluetooth/hci_core.c 2008-03-01 10:53:07.000000000 +0800
@@ -485,7 +485,7 @@ int hci_dev_open(__u16 dev)
atomic_set(&hdev->cmd_cnt, 1);
set_bit(HCI_INIT, &hdev->flags);
- //__hci_request(hdev, hci_reset_req, 0, HZ);
+ __hci_request(hdev, hci_reset_req, 0, HZ);
ret = __hci_request(hdev, hci_init_req, 0,
msecs_to_jiffies(HCI_INIT_TIMEOUT));
[-- Attachment #3: Type: text/plain, Size: 228 bytes --]
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
[-- Attachment #4: Type: text/plain, Size: 164 bytes --]
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-03-17 12:28 ` Odysseus Flappington
@ 2008-03-18 7:14 ` Dave Young
2008-03-20 17:19 ` Odysseus Flappington
0 siblings, 1 reply; 15+ messages in thread
From: Dave Young @ 2008-03-18 7:14 UTC (permalink / raw)
To: Odysseus Flappington; +Cc: BlueZ users
On Mon, Mar 17, 2008 at 8:28 PM, Odysseus Flappington
<deriziotis@gmail.com> wrote:
> Hi Dave,
>
> So I got around to recompiling my kernel this weekend, and ran off a test on
> the patch attached and it worked like a charm.
>
> I have to wonder though why the line was commented out in the first place.
> Could it be because internal adapters don't need the line?
>
> Anyway, I'd love to see this fixed in future kernels. If there's anything
> else I can do to help test, let me know. Now that I've got my head around
> recompiling kernels again, I can probably turn around tests a lot faster.
Hi thanks
About the reset issue, I get some response from marcel about reset csr dongles
-------- Marcel said :
this is a clear NAK since you gonna break all old CSR based dongles.
Within the Bluetooth 1.0b and 1.1 specification there was an issues
with if HCI_Reset should only reset the Bluetooth internals or also
the transport. So issuing HCI_Reset on an old dongle will cause an USB
reset.
The solution is to find the build id when CSR produced correct
firmware and set the HCI_RESET quirk based on that. I meant to do this
for a long time, but so far never got around to inquiry the correct
build id where this got fixed.
--------
But I think it's hard to find that build id, so ...
Regards
dave
>
> Many thanks,
>
>
> Alex
>
> On 03/03/2008, Odysseus Flappington <deriziotis@gmail.com> wrote:
> > Ok,
> >
> > I passed reset=1 to hci_usb by adding the following line to
> > /etc/modprobe.d/options:
> >
> > options hci_usb reset=1
> >
> > and that's fixed the problem!
> >
> > Wasn't sure about my lsusb output, didn't seem to show very much, so
> > here's my lsusb -v output for my bluetooth device:
> >
> > Bus 001 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> > Bluetooth Dongle (HCI mode)
> > Device Descriptor:
> > bLength 18
> > bDescriptorType 1
> > bcdUSB 2.00
> > bDeviceClass 224 Wireless
> > bDeviceSubClass 1 Radio Frequency
> > bDeviceProtocol 1 Bluetooth
> > bMaxPacketSize0 64
> > idVendor 0x0a12 Cambridge Silicon Radio, Ltd
> > idProduct 0x0001 Bluetooth Dongle (HCI mode)
> > bcdDevice 31.64
> > iManufacturer 0
> > iProduct 0
> > iSerial 0
> > bNumConfigurations 1
> > Configuration Descriptor:
> > bLength 9
> > bDescriptorType 2
> > wTotalLength 177
> > bNumInterfaces 2
> > bConfigurationValue 1
> > iConfiguration 0
> > bmAttributes 0xc0
> > Self Powered
> > 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 0x02 EP 2 OUT
> > 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 0x82 EP 2 IN
> > 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 0x03 EP 3 OUT
> > 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 0x83 EP 3 IN
> > 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 0x03 EP 3 OUT
> > 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 0x83 EP 3 IN
> > 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 0x03 EP 3 OUT
> > 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 0x83 EP 3 IN
> > 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 0x03 EP 3 OUT
> > 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 0x83 EP 3 IN
> > 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 0x03 EP 3 OUT
> > 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 0x83 EP 3 IN
> > 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 0x03 EP 3 OUT
> > 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 0x83 EP 3 IN
> > bmAttributes 1
> > Transfer Type Isochronous
> > Synch Type None
> > Usage Type Data
> > wMaxPacketSize 0x0031 1x 49 bytes
> > bInterval 1
> > Device Status: 0x0001
> > Self Powered
> >
> > Thanks,
> > Alex
> >
> >
> >
> >
> > On 03/03/2008, Odysseus Flappington <deriziotis@gmail.com> wrote:
> > > Hi Dave,
> > >
> > > Thanks for the help. I can probably get a recompile of my kernel done
> > > by the end of the weekend, maybe end of week, if it'll help.
> > >
> > > In the meantime, I'll try loading the bluetooth module with reset=1
> > > and get the lsusb output to you tonight when I get home from work.
> > >
> > > Thanks,
> > > Alex (Jackflap)
> > >
> > >
> > > On 03/03/2008, Dave Young <hidave.darkstar@gmail.com> wrote:
> > > > On Mon, Mar 3, 2008 at 9:21 AM, Dave Young
> <hidave.darkstar@gmail.com> wrote:
> > > > > On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> > > > > <deriziotis@gmail.com> wrote:
> > > > >
> > > > >
> > > > > > So, it turns out that in order for any external usb bluetooth
> adapters
> > > > > > to re-connect to paired input devices on reboot, you need to
> issue an
> > > > > > 'hciconfig hci0 reset' command after rebooting in order to
> reconnect.
> > > > > >
> > > > > > More info can be found in bug #133690 on Launchpad
> > > > > >
> (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> > > > > >
> > > > > > This bug isn't Ubuntu-specific since I have reproduced in
> Fedora 8, so
> > > > > > I'm posting here.
> > > > > >
> > > > > > Simply adding 'hciconfig hci0 reset' in /etc/default/bluetooth
> in
> > > > > > source would solve this bug. Is this a reasonable solution?
> > > > > >
> > > > > > What is required in order to get a fix implemented?
> > > >
> > > >
> > > > Sorry for previous blank reply.
> > > >
> > > > For your problem, if you don't want to patch kernel you can also try
> > > > load the bluetooth module with parameter "reset=1"
> > > >
> > > > Could you send the lsusb output?
> > > >
> > > > Regards
> > > >
> > > > dave
> > > >
> > > >
> > > >
> -------------------------------------------------------------------------
> > > > This SF.net email is sponsored by: Microsoft
> > > > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > > _______________________________________________
> > > > Bluez-users mailing list
> > > > Bluez-users@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/bluez-users
> > > >
> > >
> >
>
>
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-03-18 7:14 ` Dave Young
@ 2008-03-20 17:19 ` Odysseus Flappington
2008-03-22 0:29 ` Dave Young
2008-03-26 12:50 ` Peter Stephenson
0 siblings, 2 replies; 15+ messages in thread
From: Odysseus Flappington @ 2008-03-20 17:19 UTC (permalink / raw)
To: marcel; +Cc: Dave Young, BlueZ users
[-- Attachment #1: Type: text/plain, Size: 16644 bytes --]
Hi Marcel, Dave,
I've been looking around to see if I could figure out the build id where the
dongles started shipping with the correct HCI_Reset. I think I may have
found something.
http://www.csr.com/ contains the docs regarding the release of the CSR
firmware and the specs that each adhere's to. Looking at the following HCI
overall Implementation doc, I think we can find the relevant build id:
https://www.csrsupport.com/document.php?did=141
Firstly, i found confirmation that the problem has been solved in
HCIStack1.1v12.x:
"In builds before HCIStack1.1v12.x, the HCI Reset command rebooted the
BlueCore device. This implied the host
transport was reset. This was a consequence of the way the firmware team
understood an early version of the
Bluetooth specification (probably 0.7).
Rebooting the BlueCore device is incorrect behaviour. Version 1.1 [BT] now
makes it clear that the Reset
command must reinitialise radio, LC, LM and HCI state, but leave the host
transport in place. Builds since
HCIStack1.1v12.x obey [BT]."
So this should be fixed in HCIStack1.1v12.x, the doc outlines the build ids
for each version of of the stack, here is the build id for HCIStack1.1v12.1:
BuildID (hex) BuildID (decimal) Build Name
0x0077 119 HCIStack1.1v12.1
So, if I'm reading this correctly, you should issue the reset for all
CSR-based dongles with build id > 118.
Am I on the right track here? Does this information look accurate to you
guys?
If there's anything else I can to do re this issue, please let feel free to
ask me.
Many thanks,
Alex (Jackflap)
On 18/03/2008, Dave Young <hidave.darkstar@gmail.com> wrote:
>
> On Mon, Mar 17, 2008 at 8:28 PM, Odysseus Flappington
>
> <deriziotis@gmail.com> wrote:
> > Hi Dave,
> >
>
> > So I got around to recompiling my kernel this weekend, and ran off a
> test on
> > the patch attached and it worked like a charm.
> >
> > I have to wonder though why the line was commented out in the first
> place.
> > Could it be because internal adapters don't need the line?
> >
> > Anyway, I'd love to see this fixed in future kernels. If there's
> anything
> > else I can do to help test, let me know. Now that I've got my head
> around
> > recompiling kernels again, I can probably turn around tests a lot
> faster.
>
>
> Hi thanks
>
> About the reset issue, I get some response from marcel about reset csr
> dongles
> -------- Marcel said :
> this is a clear NAK since you gonna break all old CSR based dongles.
> Within the Bluetooth 1.0b and 1.1 specification there was an issues
> with if HCI_Reset should only reset the Bluetooth internals or also
> the transport. So issuing HCI_Reset on an old dongle will cause an USB
> reset.
>
> The solution is to find the build id when CSR produced correct
> firmware and set the HCI_RESET quirk based on that. I meant to do this
> for a long time, but so far never got around to inquiry the correct
> build id where this got fixed.
> --------
>
> But I think it's hard to find that build id, so ...
>
> Regards
>
> dave
>
>
> >
> > Many thanks,
> >
> >
> > Alex
> >
> > On 03/03/2008, Odysseus Flappington <deriziotis@gmail.com> wrote:
> > > Ok,
> > >
> > > I passed reset=1 to hci_usb by adding the following line to
> > > /etc/modprobe.d/options:
> > >
> > > options hci_usb reset=1
> > >
> > > and that's fixed the problem!
> > >
> > > Wasn't sure about my lsusb output, didn't seem to show very much, so
> > > here's my lsusb -v output for my bluetooth device:
> > >
> > > Bus 001 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> > > Bluetooth Dongle (HCI mode)
> > > Device Descriptor:
> > > bLength 18
> > > bDescriptorType 1
> > > bcdUSB 2.00
> > > bDeviceClass 224 Wireless
> > > bDeviceSubClass 1 Radio Frequency
> > > bDeviceProtocol 1 Bluetooth
> > > bMaxPacketSize0 64
> > > idVendor 0x0a12 Cambridge Silicon Radio, Ltd
> > > idProduct 0x0001 Bluetooth Dongle (HCI mode)
> > > bcdDevice 31.64
> > > iManufacturer 0
> > > iProduct 0
> > > iSerial 0
> > > bNumConfigurations 1
> > > Configuration Descriptor:
> > > bLength 9
> > > bDescriptorType 2
> > > wTotalLength 177
> > > bNumInterfaces 2
> > > bConfigurationValue 1
> > > iConfiguration 0
> > > bmAttributes 0xc0
> > > Self Powered
> > > 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 0x02 EP 2 OUT
> > > 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 0x82 EP 2 IN
> > > 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 0x03 EP 3 OUT
> > > 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 0x83 EP 3 IN
> > > 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 0x03 EP 3 OUT
> > > 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 0x83 EP 3 IN
> > > 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 0x03 EP 3 OUT
> > > 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 0x83 EP 3 IN
> > > 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 0x03 EP 3 OUT
> > > 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 0x83 EP 3 IN
> > > 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 0x03 EP 3 OUT
> > > 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 0x83 EP 3 IN
> > > 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 0x03 EP 3 OUT
> > > 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 0x83 EP 3 IN
> > > bmAttributes 1
> > > Transfer Type Isochronous
> > > Synch Type None
> > > Usage Type Data
> > > wMaxPacketSize 0x0031 1x 49 bytes
> > > bInterval 1
> > > Device Status: 0x0001
> > > Self Powered
> > >
> > > Thanks,
> > > Alex
> > >
> > >
> > >
> > >
> > > On 03/03/2008, Odysseus Flappington <deriziotis@gmail.com> wrote:
> > > > Hi Dave,
> > > >
> > > > Thanks for the help. I can probably get a recompile of my kernel
> done
> > > > by the end of the weekend, maybe end of week, if it'll help.
> > > >
> > > > In the meantime, I'll try loading the bluetooth module with reset=1
> > > > and get the lsusb output to you tonight when I get home from work.
> > > >
> > > > Thanks,
> > > > Alex (Jackflap)
> > > >
> > > >
> > > > On 03/03/2008, Dave Young <hidave.darkstar@gmail.com> wrote:
> > > > > On Mon, Mar 3, 2008 at 9:21 AM, Dave Young
> > <hidave.darkstar@gmail.com> wrote:
> > > > > > On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> > > > > > <deriziotis@gmail.com> wrote:
> > > > > >
> > > > > >
> > > > > > > So, it turns out that in order for any external usb
> bluetooth
> > adapters
> > > > > > > to re-connect to paired input devices on reboot, you need
> to
> > issue an
> > > > > > > 'hciconfig hci0 reset' command after rebooting in order to
> > reconnect.
> > > > > > >
> > > > > > > More info can be found in bug #133690 on Launchpad
> > > > > > >
> > (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> > > > > > >
> > > > > > > This bug isn't Ubuntu-specific since I have reproduced in
> > Fedora 8, so
> > > > > > > I'm posting here.
> > > > > > >
> > > > > > > Simply adding 'hciconfig hci0 reset' in
> /etc/default/bluetooth
> > in
> > > > > > > source would solve this bug. Is this a reasonable
> solution?
> > > > > > >
> > > > > > > What is required in order to get a fix implemented?
> > > > >
> > > > >
> > > > > Sorry for previous blank reply.
> > > > >
> > > > > For your problem, if you don't want to patch kernel you can also
> try
> > > > > load the bluetooth module with parameter "reset=1"
> > > > >
> > > > > Could you send the lsusb output?
> > > > >
> > > > > Regards
> > > > >
> > > > > dave
> > > > >
> > > > >
> > > > >
> >
> -------------------------------------------------------------------------
> > > > > This SF.net email is sponsored by: Microsoft
> > > > > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > > > _______________________________________________
> > > > > Bluez-users mailing list
> > > > > Bluez-users@lists.sourceforge.net
> > > > > https://lists.sourceforge.net/lists/listinfo/bluez-users
> > > > >
> > > >
> > >
> >
> >
>
[-- Attachment #2: Type: text/html, Size: 42730 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-03-20 17:19 ` Odysseus Flappington
@ 2008-03-22 0:29 ` Dave Young
2008-03-26 16:22 ` Marcel Holtmann
2008-03-26 12:50 ` Peter Stephenson
1 sibling, 1 reply; 15+ messages in thread
From: Dave Young @ 2008-03-22 0:29 UTC (permalink / raw)
To: Odysseus Flappington; +Cc: marcel, BlueZ users, linux-bluetooth
On Fri, Mar 21, 2008 at 1:19 AM, Odysseus Flappington
<deriziotis@gmail.com> wrote:
> Hi Marcel, Dave,
>
> I've been looking around to see if I could figure out the build id where the
> dongles started shipping with the correct HCI_Reset. I think I may have
> found something.
Thanks a lot.
Marcel, I think it's what you want. I would like to file a patch.
>
> http://www.csr.com/ contains the docs regarding the release of the CSR
> firmware and the specs that each adhere's to. Looking at the following HCI
> overall Implementation doc, I think we can find the relevant build id:
>
> https://www.csrsupport.com/document.php?did=141
>
> Firstly, i found confirmation that the problem has been solved in
> HCIStack1.1v12.x:
>
> "In builds before HCIStack1.1v12.x, the HCI Reset command rebooted the
> BlueCore device. This implied the host
> transport was reset. This was a consequence of the way the firmware team
> understood an early version of the
> Bluetooth specification (probably 0.7).
>
> Rebooting the BlueCore device is incorrect behaviour. Version 1.1 [BT] now
> makes it clear that the Reset
> command must reinitialise radio, LC, LM and HCI state, but leave the host
> transport in place. Builds since
> HCIStack1.1v12.x obey [BT]."
>
> So this should be fixed in HCIStack1.1v12.x, the doc outlines the build ids
> for each version of of the stack, here is the build id for HCIStack1.1v12.1:
>
> BuildID (hex) BuildID (decimal) Build Name
> 0x0077 119 HCIStack1.1v12.1
>
> So, if I'm reading this correctly, you should issue the reset for all
> CSR-based dongles with build id > 118.
>
> Am I on the right track here? Does this information look accurate to you
> guys?
>
> If there's anything else I can to do re this issue, please let feel free to
> ask me.
>
> Many thanks,
> Alex (Jackflap)
>
>
>
>
>
> On 18/03/2008, Dave Young <hidave.darkstar@gmail.com> wrote:
> > On Mon, Mar 17, 2008 at 8:28 PM, Odysseus Flappington
> >
> > <deriziotis@gmail.com> wrote:
> > > Hi Dave,
> > >
> >
> > > So I got around to recompiling my kernel this weekend, and ran off a
> test on
> > > the patch attached and it worked like a charm.
> > >
> > > I have to wonder though why the line was commented out in the first
> place.
> > > Could it be because internal adapters don't need the line?
> > >
> > > Anyway, I'd love to see this fixed in future kernels. If there's
> anything
> > > else I can do to help test, let me know. Now that I've got my head
> around
> > > recompiling kernels again, I can probably turn around tests a lot
> faster.
> >
> >
> > Hi thanks
> >
> > About the reset issue, I get some response from marcel about reset csr
> dongles
> > -------- Marcel said :
> > this is a clear NAK since you gonna break all old CSR based dongles.
> > Within the Bluetooth 1.0b and 1.1 specification there was an issues
> > with if HCI_Reset should only reset the Bluetooth internals or also
> > the transport. So issuing HCI_Reset on an old dongle will cause an USB
> > reset.
> >
> > The solution is to find the build id when CSR produced correct
> > firmware and set the HCI_RESET quirk based on that. I meant to do this
> > for a long time, but so far never got around to inquiry the correct
> > build id where this got fixed.
> > --------
> >
> > But I think it's hard to find that build id, so ...
> >
> > Regards
> >
> > dave
> >
> >
> > >
> > > Many thanks,
> > >
> > >
> > > Alex
> > >
> > > On 03/03/2008, Odysseus Flappington <deriziotis@gmail.com> wrote:
> > > > Ok,
> > > >
> > > > I passed reset=1 to hci_usb by adding the following line to
> > > > /etc/modprobe.d/options:
> > > >
> > > > options hci_usb reset=1
> > > >
> > > > and that's fixed the problem!
> > > >
> > > > Wasn't sure about my lsusb output, didn't seem to show very much, so
> > > > here's my lsusb -v output for my bluetooth device:
> > > >
> > > > Bus 001 Device 002: ID 0a12:0001 Cambridge Silicon Radio, Ltd
> > > > Bluetooth Dongle (HCI mode)
> > > > Device Descriptor:
> > > > bLength 18
> > > > bDescriptorType 1
> > > > bcdUSB 2.00
> > > > bDeviceClass 224 Wireless
> > > > bDeviceSubClass 1 Radio Frequency
> > > > bDeviceProtocol 1 Bluetooth
> > > > bMaxPacketSize0 64
> > > > idVendor 0x0a12 Cambridge Silicon Radio, Ltd
> > > > idProduct 0x0001 Bluetooth Dongle (HCI mode)
> > > > bcdDevice 31.64
> > > > iManufacturer 0
> > > > iProduct 0
> > > > iSerial 0
> > > > bNumConfigurations 1
> > > > Configuration Descriptor:
> > > > bLength 9
> > > > bDescriptorType 2
> > > > wTotalLength 177
> > > > bNumInterfaces 2
> > > > bConfigurationValue 1
> > > > iConfiguration 0
> > > > bmAttributes 0xc0
> > > > Self Powered
> > > > 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 0x02 EP 2 OUT
> > > > 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 0x82 EP 2 IN
> > > > 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 0x03 EP 3 OUT
> > > > 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 0x83 EP 3 IN
> > > > 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 0x03 EP 3 OUT
> > > > 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 0x83 EP 3 IN
> > > > 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 0x03 EP 3 OUT
> > > > 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 0x83 EP 3 IN
> > > > 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 0x03 EP 3 OUT
> > > > 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 0x83 EP 3 IN
> > > > 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 0x03 EP 3 OUT
> > > > 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 0x83 EP 3 IN
> > > > 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 0x03 EP 3 OUT
> > > > 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 0x83 EP 3 IN
> > > > bmAttributes 1
> > > > Transfer Type Isochronous
> > > > Synch Type None
> > > > Usage Type Data
> > > > wMaxPacketSize 0x0031 1x 49 bytes
> > > > bInterval 1
> > > > Device Status: 0x0001
> > > > Self Powered
> > > >
> > > > Thanks,
> > > > Alex
> > > >
> > > >
> > > >
> > > >
> > > > On 03/03/2008, Odysseus Flappington <deriziotis@gmail.com> wrote:
> > > > > Hi Dave,
> > > > >
> > > > > Thanks for the help. I can probably get a recompile of my kernel
> done
> > > > > by the end of the weekend, maybe end of week, if it'll help.
> > > > >
> > > > > In the meantime, I'll try loading the bluetooth module with reset=1
> > > > > and get the lsusb output to you tonight when I get home from work.
> > > > >
> > > > > Thanks,
> > > > > Alex (Jackflap)
> > > > >
> > > > >
> > > > > On 03/03/2008, Dave Young <hidave.darkstar@gmail.com> wrote:
> > > > > > On Mon, Mar 3, 2008 at 9:21 AM, Dave Young
> > > <hidave.darkstar@gmail.com> wrote:
> > > > > > > On Fri, Feb 29, 2008 at 6:51 AM, Odysseus Flappington
> > > > > > > <deriziotis@gmail.com> wrote:
> > > > > > >
> > > > > > >
> > > > > > > > So, it turns out that in order for any external usb
> bluetooth
> > > adapters
> > > > > > > > to re-connect to paired input devices on reboot, you need
> to
> > > issue an
> > > > > > > > 'hciconfig hci0 reset' command after rebooting in order to
> > > reconnect.
> > > > > > > >
> > > > > > > > More info can be found in bug #133690 on Launchpad
> > > > > > > >
> > > (https://bugs.launchpad.net/ubuntu/+source/bluez-utils/+bug/133690).
> > > > > > > >
> > > > > > > > This bug isn't Ubuntu-specific since I have reproduced in
> > > Fedora 8, so
> > > > > > > > I'm posting here.
> > > > > > > >
> > > > > > > > Simply adding 'hciconfig hci0 reset' in
> /etc/default/bluetooth
> > > in
> > > > > > > > source would solve this bug. Is this a reasonable
> solution?
> > > > > > > >
> > > > > > > > What is required in order to get a fix implemented?
> > > > > >
> > > > > >
> > > > > > Sorry for previous blank reply.
> > > > > >
> > > > > > For your problem, if you don't want to patch kernel you can also
> try
> > > > > > load the bluetooth module with parameter "reset=1"
> > > > > >
> > > > > > Could you send the lsusb output?
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > dave
> > > > > >
> > > > > >
> > > > > >
> > >
> -------------------------------------------------------------------------
> > > > > > This SF.net email is sponsored by: Microsoft
> > > > > > Defy all challenges. Microsoft(R) Visual Studio 2008.
> > > > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > > > > > _______________________________________________
> > > > > > Bluez-users mailing list
> > > > > > Bluez-users@lists.sourceforge.net
> > > > > > https://lists.sourceforge.net/lists/listinfo/bluez-users
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-03-20 17:19 ` Odysseus Flappington
2008-03-22 0:29 ` Dave Young
@ 2008-03-26 12:50 ` Peter Stephenson
2008-03-26 16:24 ` Marcel Holtmann
1 sibling, 1 reply; 15+ messages in thread
From: Peter Stephenson @ 2008-03-26 12:50 UTC (permalink / raw)
To: BlueZ users
On Thu, 20 Mar 2008 17:19:22 +0000
"Odysseus Flappington" <deriziotis@gmail.com> wrote:
>...
> So, if I'm reading this correctly, you should issue the reset for all
> CSR-based dongles with build id > 118.
>
> Am I on the right track here? Does this information look accurate to you
> guys?
This is basically correct in that the fix appeared in firmware around then
(the internal log says 117, but possibly that was never released---I've
confined my search to the development side).
However, it's not that simple in that releases of earlier firmware branches
were still being made for some time. Our ID numbers increase monotonically
so these would have later numbers. I haven't done an exhaustive search;
mostly these releases had L2CAP + RFCOMM on chip for embedded applications,
so you wouldn't care about them. I don't see any evidence of a later HCI
release based on the old code, offhand (but don't take this as gospel).
If you want to be quite sure not to pick up a build which didn't have the
fix for reset, you could restrict the change to BlueCore 2 and later chips
using the "bcget chipver" call. The early branches without the fix
only ever ran on BlueCore 1: the fix was made in major release 12 and
BlueCore 2 first ran on major release 14.
--
Peter Stephenson <pws@csr.com> Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-03-22 0:29 ` Dave Young
@ 2008-03-26 16:22 ` Marcel Holtmann
2008-04-04 8:58 ` Odysseus Flappington
2008-07-21 20:53 ` Odysseus Flappington
0 siblings, 2 replies; 15+ messages in thread
From: Marcel Holtmann @ 2008-03-26 16:22 UTC (permalink / raw)
To: Dave Young; +Cc: Odysseus Flappington, BlueZ users, linux-bluetooth
Hi Dave,
>> I've been looking around to see if I could figure out the build id
>> where the
>> dongles started shipping with the correct HCI_Reset. I think I may
>> have
>> found something.
>
> Thanks a lot.
>
> Marcel, I think it's what you want. I would like to file a patch.
yes, but I already got it via CSR internals. They have always been
helpful when it comes to BlueZ. CSR is an open source friendly
company. I didn't have time to actually produce that patch since we
have to turn the whole logic around.
Regards
Marcel
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-03-26 12:50 ` Peter Stephenson
@ 2008-03-26 16:24 ` Marcel Holtmann
0 siblings, 0 replies; 15+ messages in thread
From: Marcel Holtmann @ 2008-03-26 16:24 UTC (permalink / raw)
To: BlueZ users
Hi Peter,
>> So, if I'm reading this correctly, you should issue the reset for all
>> CSR-based dongles with build id > 118.
>>
>> Am I on the right track here? Does this information look accurate
>> to you
>> guys?
>
> This is basically correct in that the fix appeared in firmware
> around then
> (the internal log says 117, but possibly that was never released---
> I've
> confined my search to the development side).
>
> However, it's not that simple in that releases of earlier firmware
> branches
> were still being made for some time. Our ID numbers increase
> monotonically
> so these would have later numbers. I haven't done an exhaustive
> search;
> mostly these releases had L2CAP + RFCOMM on chip for embedded
> applications,
> so you wouldn't care about them. I don't see any evidence of a
> later HCI
> release based on the old code, offhand (but don't take this as
> gospel).
this is what Steven told me. We don't have to worry about the RFCOMM
builds since they don't include a HCI interface.
> If you want to be quite sure not to pick up a build which didn't
> have the
> fix for reset, you could restrict the change to BlueCore 2 and later
> chips
> using the "bcget chipver" call. The early branches without the fix
> only ever ran on BlueCore 1: the fix was made in major release 12 and
> BlueCore 2 first ran on major release 14.
No vendor specific setup/init quirks that would have to call vendor
commands :)
Regards
Marcel
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
_______________________________________________
Bluez-users mailing list
Bluez-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-users
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-03-26 16:22 ` Marcel Holtmann
@ 2008-04-04 8:58 ` Odysseus Flappington
2008-07-21 20:53 ` Odysseus Flappington
1 sibling, 0 replies; 15+ messages in thread
From: Odysseus Flappington @ 2008-04-04 8:58 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Dave Young, BlueZ users, linux-bluetooth
[-- Attachment #1: Type: text/plain, Size: 1725 bytes --]
Hey Marcel,
On 26/03/2008, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Dave,
>
> I've been looking around to see if I could figure out the build id where
> > > the
> > > dongles started shipping with the correct HCI_Reset. I think I may
> > > have
> > > found something.
> > >
> >
> > Thanks a lot.
> >
> > Marcel, I think it's what you want. I would like to file a patch.
> >
>
> yes, but I already got it via CSR internals. They have always been helpful
> when it comes to BlueZ. CSR is an open source friendly company. I didn't
> have time to actually produce that patch since we have to turn the whole
> logic around.
Does this mean we have all the information needed to write the patch? Have
you got the logic for a solution ready, but just need time to get it
written?
If I understand correctly, we can't be sure that all non-L2CAP/RFCOMM dongles
with build id > 118 will need a reset since they possibly still released
older firmware on newer builds. If this is the case, it seems like the only
way to be sure of the build id is by testing as many dongles as possible.
I don't see how we can do this other than trying to buy as many older
bluetooth dongles as possible. I can't imagine any of us would be willing to
do this, so perhaps the best thing to do is to reset all build ids > 118 and
adjust the build id as people submit bug-reports related to this issue as
time goes on. Asking whoever submitted a bug report to report their build id
should be reasonable in order to make the fix more accurate.
I would really like to see this fix released since as a user my experience
with external bluetooth dongles in Linux was very disappointing due to this
bug.
Many thanks,
Alex Deriziotis (Jackflap)
[-- Attachment #2: Type: text/html, Size: 2364 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-03-26 16:22 ` Marcel Holtmann
2008-04-04 8:58 ` Odysseus Flappington
@ 2008-07-21 20:53 ` Odysseus Flappington
2008-07-22 5:02 ` Dave Young
1 sibling, 1 reply; 15+ messages in thread
From: Odysseus Flappington @ 2008-07-21 20:53 UTC (permalink / raw)
To: Marcel Holtmann; +Cc: Dave Young, BlueZ users
[-- Attachment #1.1: Type: text/plain, Size: 1158 bytes --]
Hi Marcel,
I keep reading kernel developers saying that we should be persistent, so I'm
following up on this, has any progress been made regarding the following
issue?
This one's a bit of an old one, regarding bluetooth adapters after a certain
build number to require a reset command every boot before they'll work
properly, I've attached a previous discussion as a reminder to the issue.
If there's anything I can do (non-code writing though), please let me know,
I'll be glad to help get this sorted.
Alexander Deriziotis
On 26/03/2008, Marcel Holtmann <marcel@holtmann.org> wrote:
>
> Hi Dave,
>
> I've been looking around to see if I could figure out the build id where
>>> the
>>> dongles started shipping with the correct HCI_Reset. I think I may have
>>> found something.
>>>
>>
>> Thanks a lot.
>>
>> Marcel, I think it's what you want. I would like to file a patch.
>>
>
> yes, but I already got it via CSR internals. They have always been helpful
> when it comes to BlueZ. CSR is an open source friendly company. I didn't
> have time to actually produce that patch since we have to turn the whole
> logic around.
>
> Regards
>
> Marcel
>
>
[-- Attachment #1.2: Type: text/html, Size: 1845 bytes --]
[-- Attachment #2: Google Mail - hciconfig hci0 reset bug.html --]
[-- Type: text/html, Size: 4088 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [Bluez-users] hciconfig hci0 reset bug
2008-07-21 20:53 ` Odysseus Flappington
@ 2008-07-22 5:02 ` Dave Young
0 siblings, 0 replies; 15+ messages in thread
From: Dave Young @ 2008-07-22 5:02 UTC (permalink / raw)
To: Odysseus Flappington; +Cc: Marcel Holtmann, BlueZ users
On Tue, Jul 22, 2008 at 4:53 AM, Odysseus Flappington
<deriziotis@gmail.com> wrote:
> Hi Marcel,
>
> I keep reading kernel developers saying that we should be persistent, so I'm
> following up on this, has any progress been made regarding the following
> issue?
Hi, I ever tried to implement it, but I'm occupied by other projects.
The key problem is that bluetooth drivers can only set the flags
during the probe now, but we need to send bluetooth commands to get
the revision.
>
> This one's a bit of an old one, regarding bluetooth adapters after a certain
> build number to require a reset command every boot before they'll work
> properly, I've attached a previous discussion as a reminder to the issue.
>
> If there's anything I can do (non-code writing though), please let me know,
> I'll be glad to help get this sorted.
>
> Alexander Deriziotis
>
> On 26/03/2008, Marcel Holtmann <marcel@holtmann.org> wrote:
>>
>> Hi Dave,
>>
>>>> I've been looking around to see if I could figure out the build id where
>>>> the
>>>> dongles started shipping with the correct HCI_Reset. I think I may have
>>>> found something.
>>>
>>> Thanks a lot.
>>>
>>> Marcel, I think it's what you want. I would like to file a patch.
>>
>> yes, but I already got it via CSR internals. They have always been helpful
>> when it comes to BlueZ. CSR is an open source friendly company. I didn't
>> have time to actually produce that patch since we have to turn the whole
>> logic around.
>>
>> Regards
>>
>> Marcel
>>
>
>
--
Regards
dave
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2008-07-22 5:02 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-02-28 22:51 [Bluez-users] hciconfig hci0 reset bug Odysseus Flappington
2008-03-03 1:21 ` Dave Young
2008-03-03 1:24 ` Dave Young
2008-03-03 11:35 ` Odysseus Flappington
2008-03-03 22:19 ` Odysseus Flappington
2008-03-17 12:28 ` Odysseus Flappington
2008-03-18 7:14 ` Dave Young
2008-03-20 17:19 ` Odysseus Flappington
2008-03-22 0:29 ` Dave Young
2008-03-26 16:22 ` Marcel Holtmann
2008-04-04 8:58 ` Odysseus Flappington
2008-07-21 20:53 ` Odysseus Flappington
2008-07-22 5:02 ` Dave Young
2008-03-26 12:50 ` Peter Stephenson
2008-03-26 16:24 ` Marcel Holtmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox