Created attachment 44842 [details] dmesg output of an attempt to load firmware. I have a bluetooth USB adapter. There's „ASUS USB-BT211“ printed on it, but it looks like there's an atheros chip inside. It reports itself as „idVendor=0cf3, idProduct=3002“ in dmesg (http://www.asus.com/product.aspx?P_ID=GfCNjYFw5rZAov3S). It stopped working (the device is missing, hcitool dev shows nothing) with an update and I found this in dmesg (complete dmesg from one experiment is attached): [ 104.800127] ehci_hcd 0000:00:13.2: suspend root hub [ 107.756779] usb 3-1: khubd timed out on ep0out len=0/20 [ 107.756782] ath3k_load_firmware: Can't change to loading configuration err [ 107.756790] ath3k: probe of 3-1:1.0 failed with error -5 The „Can't change…“ error message comes from drivers/bluetooth/ath3k.c and it seems it has problems loading firmware into the device (it times out after ~5 seconds). After bisecting, I discovered it is caused by the commit be93112accb42c5586a459683d71975cc70673ca. If I revert this one, it works well with today's version (v2.6.38-rc8). Is it possible that the btusb driver somehow initiated the device so it would accept the firmware from ath3k module and then it got claimed by btusb driver and with the commit it is blacklisted in btusb, therefore not performing the initialization? Is it possible there are two different devices with the same USB ID, so one needs to be blacklisted and one does not? Is there any other info I could provide?
First-Bad-Commit : be93112accb42c5586a459683d71975cc70673ca
As asked by email, I tried with current version (commit 0b0abeaf3d30cec03ac6497fe978b8f7edecc5ae, after v2.6.38-rc3). The problem is still there without any change.
On Monday, February 14, 2011, Michal 'vorner' Vaner wrote: > Good morning > > On Sun, Feb 13, 2011 at 12:38:28AM +0100, Rafael J. Wysocki wrote: > > The following bug entry is on the current list of known regressions > > introduced between 2.6.36 and 2.6.37. Please verify if it still should > > be listed and let the tracking team know (either way). > > > > > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27402 > > Subject : Atheros adapter no longer loads firmware > > The problem is still there and no code changed around the area since last > time. > Tested today with version from git > (795abaf1e4e188c4171e3cd3dbb11a9fcacaf505).
Do you mind submitting the revert with an [RFC] tag on it to: Andrew Morton <akpm@linux-foundation.org> Marcel Holtmann <marcel@holtmann.org> "Gustavo F. Padovan" <padovan@profusion.mobi> linux-bluetooth@vger.kernel.org linux-kernel@vger.kernel.org Put a short description of what and how it broke and a reference to this bug report. See the file Documentation/SubmittingPatches in the kernel sources. Thanks, Flo
On Mon, 28 Feb 2011 13:51:23 +0100 Michal 'vorner' Vaner <vorner@ucw.cz> wrote: > Good morning > > On Mon, Feb 21, 2011 at 11:37:10PM +0100, Rafael J. Wysocki wrote: > > Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=27402 > > Subject : Atheros adapter no longer loads firmware > > Submitter : Michal Vaner <vorner@ucw.cz> > > Date : 2011-01-23 15:29 (30 days old) > > First-Bad-Commit: > http://git.kernel.org/linus/be93112accb42c5586a459683d71975cc70673ca > > It seems it got fixed. I have no clue which of the two commits in the > relevant > files could possibly fix it, but my adapter works now, with current git > version > (493f3358cb289ccf716c5a14fa5bb52ab75943e5). > > Thank you > > With regard > > PS: Sorry for taking so long for the reply, I was abroad last week. > Ok, I'm closing this as unreproducible.
This is still broken for me on 2.6.38.2: [ 15.910093] usb 3-2: new full speed USB device using uhci_hcd and address 4 [ 16.047889] usb 3-2: New USB device found, idVendor=0cf3, idProduct=3002 [ 21.064962] ath3k_load_firmware: Can't change to loading configuration err [ 21.065028] ath3k: probe of 3-2:1.0 failed with error -5 Using a patch of the form --- drivers/bluetooth/ath3k.c.0 2011-03-31 19:41:36.276554728 +0100 +++ drivers/bluetooth/ath3k.c 2011-03-31 19:44:10.952095075 +0100 @@ -36,9 +36,6 @@ /* Atheros AR3011 */ { USB_DEVICE(0x0CF3, 0x3000) }, - /* Atheros AR3011 with sflash firmware*/ - { USB_DEVICE(0x0CF3, 0x3002) }, - /* Atheros AR9285 Malbec with sflash firmware */ { USB_DEVICE(0x03F0, 0x311D) }, --- drivers/bluetooth/btusb.c.0 2011-03-31 19:41:26.543967961 +0100 +++ drivers/bluetooth/btusb.c 2011-03-31 19:44:06.601726760 +0100 @@ -99,9 +99,6 @@ /* Broadcom BCM2033 without firmware */ { USB_DEVICE(0x0a5c, 0x2033), .driver_info = BTUSB_IGNORE }, - /* Atheros 3011 with sflash firmware */ - { USB_DEVICE(0x0cf3, 0x3002), .driver_info = BTUSB_IGNORE }, - /* Atheros AR9285 Malbec with sflash firmware */ { USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE }, makes it work again.
I reverted this patch until we find a solution for this issue, so it should be working again in 2.6.39.
Reversing that patch doesn't work for me: btusb driver tries to manage a device that doesn't work without firmware. I think that reversing that patch only works for people having a 0cf3:3000 device, that, after firmware loading from ath3k, changes to 0cf3:3002 and then it is managed by btusb. But original 2.6.38 version doesn't work for me either. In my case, this is what it's happening in 2.6.38: 1) Device 0cf3:3002 is detected 2) Module ath3k is loaded 3) ath3k loads the firmware in that device 0cf3:3002 4) A new device is detected but it's still 0cf3:3002 5) ath3k tries to load the firmware again and that produces an error I guess the problem is that between steps 3) and 4) the device should change from 0cf3:3002 to 0cf3:3005 for btusb driver to take it over, but it doesn't. I say 0cf3:3005 because of this line in the firmware changelog: "Fix EEPROM radio table issue and change PID to 3005" If somebody wants to check that I'm not using the wrong firmware, it's ath3k-1.fw with the following md5sum (if it's wrong, please tell me where is the right one): 1211fa34c09e10ba48381586b7c3883d By the way, I have this bluetooth device 0cf3:3002 in a Dell Vostro V130 laptop.
Yeah, revert this patch is the wrong thing to do. So we're back to the begin, I still don't know to handle devices with the same PID but with different needs.
We are dealing with, at least, two different devices here: one with PID 3000 and the other with PID 3002 (I mean, both before any PID change). And I think we are also seeing different problems. The problems might be one or more of these: * Using obsolete firmware switching to the wrong PID 3002 * Using current firmware switching to the wrong PID 3002, so it would be a firmware bug * Using current firmware trying to switch to the right PID 3005, but the device is not accepting the change I would ask the original reporter of the bug (Michal Vaner) and the author of the comment #6 (James Ettle) to provide a dmesg output and an md5sum of the firmware they are using to check which problem may correspond in each case. The dmesg output of the original report shows a PID switch from 3000 to 3002, but we don't know which firmware version was being used, and now the problem is solved in that case. Maybe the solution mentioned in comment #5 was a firmware update.
OK, I'll attach my dmesg below. I'm currently testing Fedora 15 beta and Bluetooth isn't working for me now. (Oddly, it's not working with the patched kernels I was using before with F14, either. Strange as it seems to be the same firmware... I'll look into that later.) As far as I'm aware, the F15 beta kernel 2.6.38.2-9.fc15.i686 doesn't have any fancy patches. For lsusb, I see Bus 003 Device 003: ID 0cf3:3005 Atheros Communications, Inc. For lsmod, Module Size Used by fuse 53420 3 cpufreq_ondemand 7674 2 8021q 15564 0 garp 4926 1 8021q stp 1399 1 garp llc 3684 2 garp,stp acpi_cpufreq 6257 1 mperf 1145 1 acpi_cpufreq hid_multitouch 3580 0 ip6t_REJECT 3387 2 nf_conntrack_ipv6 6637 4 nf_defrag_ipv6 7574 1 nf_conntrack_ipv6 ip6table_filter 1227 1 ip6_tables 9790 1 ip6table_filter snd_hda_codec_realtek 244660 1 snd_hda_intel 20294 2 arc4 1097 2 snd_hda_codec 69915 2 snd_hda_codec_realtek,snd_hda_intel snd_hwdep 4986 1 snd_hda_codec ath9k 80727 0 snd_seq 43761 0 snd_seq_device 5118 1 snd_seq snd_pcm 63871 2 snd_hda_intel,snd_hda_codec mac80211 201914 1 ath9k cdc_acm 15691 0 uvcvideo 49026 0 btusb 12340 0 snd_timer 15551 2 snd_seq,snd_pcm ath9k_common 2085 1 ath9k microcode 11108 0 ath9k_hw 254487 2 ath9k,ath9k_common snd 48010 12 snd_hda_codec_realtek,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_seq,snd_seq_device,snd_pcm,snd_timer bluetooth 77640 1 btusb ath 11756 2 ath9k,ath9k_hw cfg80211 116073 3 ath9k,mac80211,ath videodev 54789 1 uvcvideo i2c_i801 7957 0 iTCO_wdt 9288 0 soundcore 5039 1 snd iTCO_vendor_support 2082 1 iTCO_wdt rfkill 13096 3 bluetooth,cfg80211 wmi 7722 0 snd_page_alloc 6112 2 snd_hda_intel,snd_pcm uinput 5434 0 ipv6 234732 29 ip6t_REJECT,nf_conntrack_ipv6,nf_defrag_ipv6 i915 305693 3 drm_kms_helper 24180 1 i915 drm 151935 4 i915,drm_kms_helper i2c_algo_bit 4162 1 i915 i2c_core 21384 6 videodev,i2c_i801,i915,drm_kms_helper,drm,i2c_algo_bit video 10797 1 i915 ath3k doesn't seem to have loaded here. No idea why. (udev problem? Noticed some other unrelated modules that should've loaded hadn't...) The firmware md5sum is: $ md5sum /lib/firmware/ath3k-1.fw 1211fa34c09e10ba48381586b7c3883d /lib/firmware/ath3k-1.fw
Created attachment 54742 [details] dmesg output from James's tablet
Created attachment 54752 [details] dmesg after a suspend-resume cycle Just added a dmesg take after a suspend/resume cycle. There, the Bluetooth adapter does come back up as 3000, ath3k loads, and it then re-attaches as 3005. (Still no support, however.)
(In reply to comment #13) > Created an attachment (id=54752) [details] > dmesg after a suspend-resume cycle > > Just added a dmesg take after a suspend/resume cycle. There, the Bluetooth > adapter does come back up as 3000, ath3k loads, and it then re-attaches as > 3005. (Still no support, however.) It seems that the problem has change since your first post. Now I see a PID switch as expected: from 3000 to 3005. And the firmware version is the same as mine, so it's the current version (if I'm right). But I don't know why it is not working because there are no errors. Maybe not a kernel problem? (You should check things like the output of "hciconfig" and "rfkill list" commands and also check that "bluetoothd" is running). The boot dmesg output with the PID already being 3005 and the lack of ath3k in lsmod... maybe a warm reboot, so the firmware is kept and ath3k is therefore not needed? Thanks Alberto
You're quite right, Alberto... for some reason bluetoothd wasn't starting automatically (before that hcitool reported a 0 address for the device). Starting it manually seems to work. I've no idea what caused the problems (and subsequent confusion) on my end. Thanks for your help.
You're welcome, James :-) You also helped me to verify that the only device still not working is this 0cf3:3002 I have. Now I have to find out why. Using the same firmware, the devices 0cf3:3000 and 0cf3:3002 are behaving differently with respecto to the PID switch, but they are managed in exactly the same way in ath3k, so only two possibilities are left: achieve the same behavior in both devices through changes in the firmware (getting this device 0cf3:3002 to switch PID), or, if it is not possible, modify ath3k (and what's worse, maybe also btusb) to cope with the different behavior (there is a way to detect when the firmware has been loaded; I've seen it in compat-wireless-2.6.36-5-spn, for example, but it's quite ugly and I think it might make suspend/resume related code more complicated).
Shouldn't this bug be reopened? If more reports are needed, see: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/720949 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/714862 Those correspond to the same bug but with different people affected.
(In reply to comment #17) This bug should be reopened, as it is still a problem with the 3.2 kernel. Unfortunately, none of us have reopening privileges, so we may have to open an entirely new bug. That said, I think we have a good understanding of what's going on here: 1) In Michael and James' device (PID 3000), the firmware was accidentally changing to PID 3002, causing problems when btusb and ath3k modules recgnize the real PID 3002 device. It's actually supposed to go to PID 3005, which we know because of dmesg output. In later versions it _does_ go to 3005, evidenced by comment #14 2) In Alberto's _real_ PID 3002 device, reverting the patch causes problems because it removes support 3) In both cases, seeing PID 3002 device after firmware is loaded tells the ath3k kernel module to reload the driver and cause problems as in comment #8. If anyone is still out there on this bug report please let me know if I got it right.
There is already a new bug for this issue, bug 42442
This turned out to be a problem with the firmware. It should be fixed by this modification to the firmware: http://comments.gmane.org/gmane.linux.kernel/1262485