Scientific Linux Forum.org



  Reply to this topicStart new topicStart Poll

> My "experience" with Atheros AR3011 Bluetooth adapter, Trick to get it working
gjakob
 Posted: Dec 23 2013, 01:59 PM
Quote Post


SLF Newbie


Group: Members
Posts: 10
Member No.: 237
Joined: 2-June 11









My hardware consists of a MSI Z77 MPower mainboard which is equipped with wireless adapters for both WLAN and Bluetooth from Atheros. Both these adapters get their firmware loaded by the operating system of the PC at boot time using the corresponding (kernel) drivers ath9k (for WLAN adapter) and ath3k (for Bluetooth adapter).
After having installed the firmware RPMs from ELREPO, the WLAN adapter works without any problems with both the latest official EL6 kernel, i.e. kernel-2.6.32-431.1.2.el6.x86_64, and also with kernel-lt-3.10.25-1.el6.elrepo.x86_64. However, the Bluetooth adapter does not - at least not after any boot directly from power-off.
Since the EL6 kernel 2.6.32 does not come with the ath3k.ko module, it is not a surprise that after a boot from system-off the Bluetooth adapter does not have its firmware loaded and hence does not work. However, the 3.10.25 kernel contains this driver and sends the following information during boot:
QUOTE
kernel: Bluetooth: Can't change to loading configuration err
kernel: ath3k: probe of 1-1.5:1.0 failed with error -110
kernel: usbcore: registered new interface driver btusb

As a result the Bluetooth adapter does not work. Once the system is up, the command "lsusb"gives me the following output:
QUOTE
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 001 Device 003: ID 058f:6362 Alcor Micro Corp. Flash Card Reader/Writer
Bus 001 Device 004: ID 0cf3:3002 Atheros Communications, Inc. AR3011 Bluetooth
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 005 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 006 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 0cf3:9271 Atheros Communications, Inc. AR9271 802.11n
Bus 005 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 005 Device 003: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth


I have highlighted the info regarding the Bluetooth adapter. As you can see, there are no complaints about any missing firmware. However, the system does not see any bluetooth adapter and also any attempt to stop resp. start the bluetooth daemon "by hand" fails.
If I then just reboot the system with kernel 2.6.32 - note that the system must not be powered down in order that the adapter keeps its firmware - the Bluetooth adapter works (!) and I am able to communicate with all available cell phones via their corresponding interfaces...
The kernel message regarding bluetooth issued during boot with kernel 2.6.32 is the following:
QUOTE
kernel: Bluetooth: Core ver 2.15
kernel: NET: Registered protocol family 31
kernel: Bluetooth: HCI device and connection manager initialized
kernel: Bluetooth: HCI socket layer initialized
kernel: Bluetooth: Generic Bluetooth USB driver ver 0.6
kernel: usbcore: registered new interface driver btusb


This "experience" indicates to me that the 3.x kernels featuring the ath3k driver actually successfully download the firmware to the adapter, but don't get it working due to some (unknown) problem in the interaction between the btusb and ath3k drivers. If then a kernel is loaded without the ath3k driver, the adapter works.
I made the following experiment: Once the system had been powered and booted with the 3.10.25 kernel, I added the ath3k driver to the blacklist of modprobe and expected to get the adapter also working after a subsequent reboot (the same as with the 2.6.32 kernel). However, this method did not work!

Does anybody have ideas or hints how to get this Bluetooth adapter work "permanently"?
PM
^
Phil_P
 Posted: Dec 23 2013, 05:15 PM
Quote Post


SLF Newbie


Group: Members
Posts: 6
Member No.: 2862
Joined: 23-December 13









This is interesting, at least to me :-)

I'm Phil, who maintains the ath3k packages at elrepo.org.

I think you are pretty much correct in what you have concluded. The ath3k driver is simply a "firmware loader" which loads the firmware (provided by our ath3k-firmware package) to the btusb.ko bluetooth driver.

In kernel-3.10.25 this all should just work (assuming you have the firmware present on your machine). I'm sorry I don't know why it's not working for you on that kernel.

As to the interesting bit - yes, I agree with your conclusion that when you boot the 3.10.25 kernel it is loading the firmware to the device, and then when you perform a soft reboot to the distro kernel (2.6.32) the device now works using the distro btusb driver as the firmware is still present in the device. Presumably the device can now survive multiple soft reboots, but the moment you perform a hard reboot the device loses the firmware and again fails to operate?

You might not be aware, but I just released a kmod driver package for the ath3k driver (kmod-ath3k) for el6. This is a straight backport of the ath3k driver from kernel-3.10.24 for el6. From what I can ascertain from your post, you have not yet tried this driver on SL6?

Please would you try this driver. Now, I'm not necessarily expecting it to work out of the box for your hardware as there are some interactions between the ath3k and btusb drivers specific to your chipset. Specifically, there was a commit to the btusb.c source code relating to your device:

https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/bluetooth/btusb.c?id=be93112accb42c5586a459683d71975cc70673ca

which I believe is related to ensuring the firmware is able to load before the driver tries to connect the device.

I did have a look at backporting an updated btusb driver at the same time I backported the ath3k driver, but it wasn't trivial and also wasn't required for the user in question at the time (his ath3k hardware works seamlessly with the distro btusb driver and doesn't require the patch above).

However, what I could do is try backporting just that patch for you to the distro btusb driver to see if that helps you. What concerns me slightly is that as it stands the 3.10.25 driver set doesn't actually work for you, so I don't want to spend a huge amount of effort working towards a solution that you've shown doesn't actually work. However, a patched btusb driver as opposed to a full backport should be quick and easy to do, and based upon your observations above has a reasonable chance of working for you.

If you are interested, please could I ask you to create an account at elrepo.org/bugs and file an RFE (request for enhancement) for an updated btusb bluetooth driver and we can track the issue there.

Regards,

Phil

PM
^
Phil_P
 Posted: Dec 23 2013, 07:16 PM
Quote Post


SLF Newbie


Group: Members
Posts: 6
Member No.: 2862
Joined: 23-December 13









WRT your idea of blacklisting, having read the source code I think it is probably the btusb driver that you would want to blacklist. The idea being that you want to get the firmware loaded onto the device before the btusb driver loads and probes the device, thus you want to be able to control the order in which the drivers are loaded - ath3k first, to load the firmware, then bring up the device with the btusb driver.

It might even be worth unloading the drivers (modprobe -r) if things fail, then manually reloading them, ath3k and then btusb (ath3k should actually load btusb as a module dependency if you are using modprobe).

Anyway, all this is a bit of an aside, and hopefully we can get this working as intended.

PM
^
gjakob
 Posted: Dec 23 2013, 09:35 PM
Quote Post


SLF Newbie


Group: Members
Posts: 10
Member No.: 237
Joined: 2-June 11









QUOTE (Phil_P @ Dec 23 2013, 08:16 PM)
WRT your idea of blacklisting, having read the source code I think it is probably the btusb driver that you would want to blacklist. The idea being that you want to get the firmware loaded onto the device before the btusb driver loads and probes the device, thus you want to be able to control the order in which the drivers are loaded - ath3k first, to load the firmware, then bring up the device with the btusb driver.

It might even be worth unloading the drivers (modprobe -r) if things fail, then manually reloading them, ath3k and then btusb (ath3k should actually load btusb as a module dependency if you are using modprobe).

Anyway, all this is a bit of an aside, and hopefully we can get this working as intended.


Hi Phil,

first of all, thank you very much for your replies. In the meantime, I made a big progress!
I booted two Live CDs/DVDs, both after a hard reset, namely the new Fedora 20 and Ubuntu LTS 12.04. With Fedora 20, which out-of-the-box also provides the firmware file /lib/firmware/ath3k-1.fw, my bluetooth adapter did not work either, however with Ubuntu it did!
After I shutdown the Ubuntu Live DVD, I "soft booted" into SL 6.4 using the 3.10.25 kernel and - the bluetooth adapter did work! It even still worked after I resumed the system from standby mode, which was not the case anymore with the 2.6.32 kernel. This experience made me convinced that there is nothing wrong with the drivers of your 3.10.25 kernel.
I finally downloaded the package linux-firmware_1.79.1_all.deb from Ubuntu and extracted the ath3k-1.fw file from there
Prior to replacing my "original" firmware file, which I got from your your ath3k-firmware package, I compared the md5sum of both.
"Your" file yields 1211fa34c09e10ba48381586b7c3883d /lib/firmware/ath3k-1.fw, while the one from Ubuntu yields 24cfee59a24f336dfae838a0de6445a0 /lib/firmware/ath3k-1.fw.
Your 3.10.25 kernel now brings up my bluetooth adapter under all circumstances (i.e. both after a hard and soft reset), since I am using the firmware file from the Ubuntu kernel firmware package.

So, it was indeed an issue (at least with the Atheros AR3011 adapter of the MSI Z77 MPower mainboard) with the ath3k-1.fw file shipped with the Fedora disbribution and also provided by your ath3k-firmware package.

Tomorrow (it's already late evening in Germany), I will try your kmod-ath3k package and see whether it's working with the 2.6.32 kernel from official EL6, even though I avoid using this kernel, since the latest update causes problems with resume after standby in general - see my other report. huh.gif
PM
^
Phil_P
 Posted: Dec 24 2013, 12:15 AM
Quote Post


SLF Newbie


Group: Members
Posts: 6
Member No.: 2862
Joined: 23-December 13









QUOTE (gjakob @ Dec 23 2013, 09:35 PM)

I finally downloaded the package linux-firmware_1.79.1_all.deb from Ubuntu and extracted the ath3k-1.fw file from there
Prior to replacing my "original" firmware file, which I got from your your ath3k-firmware package, I compared the md5sum of both.
"Your" file yields 1211fa34c09e10ba48381586b7c3883d  /lib/firmware/ath3k-1.fw, while the one from Ubuntu yields 24cfee59a24f336dfae838a0de6445a0  /lib/firmware/ath3k-1.fw.
Your 3.10.25 kernel now brings up my bluetooth adapter under all circumstances (i.e. both after a hard and soft reset), since I am using the firmware file from the Ubuntu kernel firmware package.

So, it was indeed an issue (at least with the Atheros AR3011 adapter of the MSI Z77 MPower mainboard) with the ath3k-1.fw file shipped with the Fedora disbribution and also provided by your ath3k-firmware package.


Hmm, I have no idea where they got that firmware. To check I just cloned the linux-firmware.git repository again and the md5sum matches the version we ship:

http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/plain/ath3k-1.fw

[phil@Quad linux-firmware]$ md5sum ath3k-1.fw
1211fa34c09e10ba48381586b7c3883d ath3k-1.fw

but if the Ubuntu version works for you then great :-)

Let me know if there's anything more I can do to help.

PM
^
gjakob
 Posted: Dec 24 2013, 08:57 AM
Quote Post


SLF Newbie


Group: Members
Posts: 10
Member No.: 237
Joined: 2-June 11









QUOTE (Phil_P @ Dec 24 2013, 01:15 AM)

Hmm, I have no idea where they got that firmware. To check I just cloned the linux-firmware.git repository again and the md5sum matches the version we ship:

http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/plain/ath3k-1.fw


A "ls -l" on the Ubuntu version returns July 20th, 2012 as date for the creation or last modification, while the one provided by the package ath3k-firmware-1.0-1.el6.elrepo.noarch is dated December 21st, 2012, i.e. is newer by five months. So, obviously some patch, which broke the proper interaction with the corresponding kernel drivers, has later been applied to the version provided by the kernel git and your package respectively..

QUOTE (Phil_P @ Dec 24 2013, 01:15 AM)

but if the Ubuntu version works for you then great :-)


The question that raises to me is rather whether anybody has actually succeded to get a properly working Atheros AR3011 Bluetooth adapter with the firmware version provided by the Fedora and RHEL based distributions?
This question may not so easy to be answered though, since there are certainly not so many Linux users who use a specific hardware component (especially if it's one just relevant to desktop computers) and a certain linux distribution at the same time.
Most of the discussion threads about desktop relevant hardware components (e.g. Bluetooth adapters) and problems related with those are created by Ubuntu users anyway...

QUOTE (Phil_P @ Dec 24 2013, 01:15 AM)

Let me know if there's anything more I can do to help.


Not for the moment. But thank's anyway...
PM
^
gjakob
 Posted: Dec 24 2013, 12:15 PM
Quote Post


SLF Newbie


Group: Members
Posts: 10
Member No.: 237
Joined: 2-June 11









Some additional remarks on this topic:

I have found the bug report Atheros Bluetooth 0cf3:3002 is not working at Bugzilla, where somebody with a Dell Vostro V130 also got his Atheros bluetooth adapter (with same product id as mine) only working after he had started using the firmware file with the same md5sum as the one has that I had extracted from Ubuntu's Debian package just yesterday.
Comment 3 of this thread even refers to the patch from Linux Kernel Development resolving the problem.

But, obviously and - at the same time - strangely, the patch did never make it into the official kernel git. The person who wrote the last comment of this thread wondered why this patch has not made it into the official kernel git. Only the Ubuntu resp. Debian community seems to have included it by now...
So, from this bugzilla report I strongly assume that this patched firmware is necessary to get any Atheros Bluetooth 0cf3:3002 devices properly working.
Are there any objections to ship this firmware file also in the Fedora and RHEL (supported by ELRepo) based distributions?
PM
^
Phil_P
 Posted: Dec 25 2013, 12:03 AM
Quote Post


SLF Newbie


Group: Members
Posts: 6
Member No.: 2862
Joined: 23-December 13









yes, it would appear that patch has not been committed at the upstream kernel.org.

The solution is to get it committed upstream, then it filters down to everyone, Fedora, RHEL, elrepo.

My previous tester, for whom I originally developed the kmod-ath3k package, had no problem with the standard firmware but his hardware was slightly different to yours - it was an Atheros AR3011 but it had a different device ID.

http://elrepo.org/bugs/view.php?id=442

Looking at the driver code I think this issue only affects sflash firmware devices.

Thanks for your investigations.

PM
^
gjakob
 Posted: Dec 25 2013, 08:46 AM
Quote Post


SLF Newbie


Group: Members
Posts: 10
Member No.: 237
Joined: 2-June 11









First of all, I wish you a Merry Christmas!

QUOTE (Phil_P @ Dec 25 2013, 01:03 AM)
yes, it would appear that patch has not been committed at the upstream kernel.org.

The solution is to get it committed upstream, then it filters down to everyone, Fedora, RHEL, elrepo.


You're right - this is the proper way how it should go. However, this bug has already been reported roughly 1.5 years ago and nothing has happened so far. The reason for this might be that it simply affects only very few people - maybe more on the Debian / Ubuntu side where a fixed version is provided already since quite a while, but not on the RedHat / Fedora side... mad.gif

QUOTE

My previous tester, for whom I originally developed the kmod-ath3k package, had no problem with the standard firmware but his hardware was slightly different to yours - it was an Atheros AR3011 but it had a different device ID.

http://elrepo.org/bugs/view.php?id=442

Looking at the driver code I think this issue only affects sflash firmware devices.


Of couse - at least according to my understanding, it does only affect the adapters with sflash configuration, i.e. with product IDs greater than 0x3000, because only these need the firmware file to be loaded by the kernel during boot. See also Linux Wireless and the paragraph "AR3011 with SFLASH configurations" therein.
So unfortunately, you did not have a tester who - aside from the ath3k.ko kernel driver - also actually needed the ath3k-1.fw file for his device.... huh.gif

The "working version" of the ath3k-1.fw file changes the product ID of the device from 0x3002 to 0x3005, which I have verified in my case. See also Linux Kernel Development, which contains comments regarding the applied patch. The kernel can handle this device for "some" not further specified reasons only in this case. This solution certainly appears more as a "quick and dirty" workaround rather than a "serious" software bug fix. By the way: Under MS Windows, I have seen that the adapter keeps its original PID also under working conditions (as you would "normally" expect), i.e. the firmware shipped together with the Windows driver does not need such "tricks" that modify the identity of the device...
So maybe, from a proper software design perspective, it might be a better solution to leave the firmware file unchanged and make the necessary modifications on the kernel driver side, but just from a user perspective I only care about a properly working device, which unfortunately is not provided by the current combination of firmware file and driver contained in the official kernel git.

Do you know the proper procedure of how to get the working solution for this Bluetooth adapter into the official kernel git ?
PM
^
toracat
 Posted: Dec 25 2013, 03:10 PM
Quote Post


SLF Geek
****

Group: Members
Posts: 302
Member No.: 11
Joined: 10-April 11









QUOTE (gjakob @ Dec 25 2013, 12:46 AM)

Do you know the proper procedure of how to get the working solution for this Bluetooth adapter into the official kernel git ?

I would try kernel bug tracker first.

--------------------
ELRepo: repository specializing in hardware support for EL
PMUsers Website
^
gjakob
 Posted: Dec 25 2013, 06:48 PM
Quote Post


SLF Newbie


Group: Members
Posts: 10
Member No.: 237
Joined: 2-June 11









QUOTE (toracat @ Dec 25 2013, 04:10 PM)
QUOTE (gjakob @ Dec 25 2013, 12:46 AM)

Do you know the proper procedure of how to get the working solution for this Bluetooth adapter into the official kernel git ?

I would try kernel bug tracker first.


Done!
See Kernel Bugzilla.
So let's hope that anything will actually happen...
PM
^
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

Topic Options Reply to this topicStart new topicStart Poll