* [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-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 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
* 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-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
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