Bug 27402

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