Created attachment 89471 [details] fix for ID 1310:0001 Roper Class 1 Bluetooth Dongle my bluetooth dongle (ID 1310:0001 Roper Class 1 Bluetooth Dongle) stopped work in kernel-2.6.39 (kernel-2.6.38 all work fine). Now i test kernel-3.7-rc8 - nothing change, but ... for kernel-2.6.39 my bluetooth work with remark, in net/bluetooth/hci_core.c:106 if (test_bit(HCI_INIT, &hdev->flags) && hdev->init_last_cmd != cmd) return; by //if (test_bit(HCI_INIT, &hdev->flags) && hdev->init_last_cmd != cmd) //return; All work good - I test it on 2.6.39 In the kernel-3.7-rc8 i use these attached patch and after this patch my ID 1310:0001 Roper Class 1 Bluetooth Dongle initing and work properly. no "timeout 110" more and i can use my bluetooth dongle.
Created attachment 89481 [details] modprobe btusb on 3.7-rc8 modprobe btusb on 3.7-rc8 for bluetooth EXTRA_CFLAGS += -DDEBUG Bus 005 Device 002: ID 1310:0001 Roper Class 1 Bluetooth Dongle modprobe btusb
Created attachment 89491 [details] hciconfig hci0 up on 3.7-rc8 hciconfig hci0 up on 3.7-rc8 for bluetooth EXTRA_CFLAGS += -DDEBUG Bus 005 Device 002: ID 1310:0001 Roper Class 1 Bluetooth Dongle hciconfig hci0 up
Created attachment 89501 [details] fix applied modprobe btusb on 3.7-rc8 fix applied modprobe btusb on 3.7-rc8 after previous patch https://bugzilla.kernel.org/attachment.cgi?id=88711 modprobe btusb on 3.7-rc8 for bluetooth EXTRA_CFLAGS += -DDEBUG Bus 005 Device 002: ID 1310:0001 Roper Class 1 Bluetooth Dongle modprobe btusb all initing ok without problem (bnep disabled/not builded in my case)
See SubmittingPatches in the kernel source tree - we can't take patches via bugzilla easily as we need a Signed-off-by: for any patch so we have a trace of its origin/ownership. The best approach is to email it with the Signed-off-by: to linux-bluetooth@vger.kernel.org (you don't need to be subscribed)
Alan's advice is best -- please do that. But if you don't want to do that, then could you at least explain what your patch is supposed to be doing? I'm not sure that I understand how it is supposed to work...
I have very old bluetooth dongle "ID 1310:0001 Roper Class 1 Bluetooth Dongle". Without my patch they dont work. After plug i have hci0 device in "down" state. ( hciconfig hci0 up Can't init device hci0: Connection timed out (110) ) As in https://bbs.archlinux.org/viewtopic.php?pid=1083428 and https://bugzilla.kernel.org/show_bug.cgi?id=42932 With my patch (skip some reset command in init state on some old bluetooth dongle) they work (After plug i have hci0 device and can do hciconfig hci0 up succesfull). If You can - analyze it (by log in https://bugzilla.kernel.org/attachment.cgi?id=89481 and https://bugzilla.kernel.org/attachment.cgi?id=89501) and do the right patch for fixing these problem. I can test these on my hardware
(In reply to comment #5) > Alan's advice is best -- please do that. But if you don't want to do that, > then could you at least explain what your patch is supposed to be doing? I'm > not sure that I understand how it is supposed to work... I'm also have such dongle and made some code digging. Looks like this commit break the initialization: commit a5040efa2017f3e4f1b4d5f40fd989567f3994c1 Author: Johan Hedberg <johan.hedberg@nokia.com> Date: Mon Jan 10 13:28:59 2011 +0200 Bluetooth: Add special handling with __hci_request and HCI_INIT To support a more dynamic HCI initialization sequence the __hci_request behavior requires some more changes. Particularly, the init sequence should be able to have conditionals in it (sending some HCI commands depending on the outcome of a previous command) instead of being a fixed list as it is right now. The reasons for these additional requirements are the moving all previously user space driven initialization commands to the kernel side as well as the support the Low Energy controllers. To fulfull these requirements the init sequence is made the only special case for multi-command requests and req_last_cmd is renamed to init_last_cmd. The hci_send_cmd function is changed to update init_last_cmd as long as the HCI_INIT flag is set. Signed-off-by: Johan Hedberg <johan.hedberg@nokia.com> Signed-off-by: Gustavo F. Padovan <padovan@profusion.mobi> If I revert this (at least first part with HCI_INIT check), everything working fine. Maybe we need some device-specific hack there?
Hi, If this issue is still present on 3.8 (there was a fix for handling hci reset command) please provide hci logs with btmon (it is part of BlueZ 5 and you can grab it from [1], 'monitor' folder) so we can better see what went wrong with init sequence. BR Szymon Janc [1] http://ftp.kernel.org/pub/linux/bluetooth/bluez-5.3.tar.xz
Created attachment 129281 [details] btmon output on insertion 1310:0001 dongle Output of btmon in insert dongle 1310:0001
If You need more information or another logs - please, write detailed command.
kernel 3.10.25-gentoo bluez-5.15
*** This bug has been marked as a duplicate of bug 60901 ***