2011-12-28 16:50:15

by Andres Cimmarusti

[permalink] [raw]
Subject: firmware loading failure for AR3011 (0cf3:3000 or 0cf3:3005 ?)

Dear all,

This is an upstream bug report for known bugs in at least 3 linux distros:

Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=641749
Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=702375

***Steps to reproduce***

- Boot current Debian testing / Fedora 16 / Ubuntu 11.10 (using
kernels 3.1.x and 3.0.x)

***Expected behavior***

- Working bluetooth and no problems in rebooting laptop as occurs
using Ubuntu 11.04 / Fedora 15 and/or Debian Squeeze (using kernels
2.6.38 or newer)

- lsusb reveals this:

Bus 001 Device 004: ID 0cf3:3005 Atheros Communications, Inc. AR3011 Bluetooth

***Actual Result***

- Boot process stalls and fails to load firmware for this Atheros
AR3011 bluetooth module:

[ 9.335184] ath3k_load_firmware: Can't change to loading configuration err
[ 9.335413] ath3k: probe of 1-1.3:1.0 failed with error -110
[ 9.335459] usbcore: registered new interface driver ath3k

- lsusb of the device shows this:

Bus 001 Device 003: ID 0cf3:3000 Atheros Communications, Inc. AR3011
Bluetooth (no firmware)

- After login bluetooth does not work. Furthermore, choosing to
"Restart" the laptop causes it to hang at first pre-bios post screen.

***Things I've tried***

The weird part about this bug is that using Debian squeeze as a base,
I can run the newest kernels (2.6.39, 3.0.x and 3.1.x) and I have no
problems at all. Also the output of lsusb differs substantially from
the working vs broken system. Ubuntu 11.04 and Fedora 15 also work
fine using kernel 2.6.38.

Here is an example dmesg, using kernel 3.0.8 on Squeeze (no problem):

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=56;filename=dmesg_stable%2B3.0.8.txt;att=2;bug=641749

And here is a similar 3.0.x Debian mainline kernel running on top of
Debian testing (wheezy):

http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=56;filename=dmesg_testing%2B3.0.0-2.txt;att=1;bug=641749

If you browse the Debian bug report link listed at the beginning of
this email, you will also be able to get logs for kernel 3.1.x.
Furthermore, I've tested downgrading the version of udev to the one
found in Debian squeeze (version 164) as well as usb-modeswitch (also
tried upgrading to the latest versions in Debian unstable), but this
has yielded no progress and no clues at all...the error messages
remain the same.

Help debugging this issue would be most welcome.

Best Regards

Andres Cimmarusti

PS: For reference this is a Linux Certified laptop model LC2131, also
known as the Zareason Strata Pro 13 or the ASI SpringPeak 13


2012-01-24 06:38:02

by Jonathan Nieder

[permalink] [raw]
Subject: Re: firmware loading failure for AR3011 (0cf3:3000 or 0cf3:3005 ?)

Jonathan Nieder wrote:
> Andres Cimmarusti wrote:

>> [ 9.335184] ath3k_load_firmware: Can't change to loading configuration err
>> [ 9.335413] ath3k: probe of 1-1.3:1.0 failed with error -110
>
> Further investigation revealed that the problem seems to be in
> userspace: various kernels including a 2.6.32.y-based and 3.1.8-based
> one reproducibly exhibit this behavior with a Debian wheezy userspace
> and do _not_ exhibit the problem in Debian squeeze, Ubuntu 11.10, or
> Fedora 16. More results:

Erm, I can't read. Let's try that again:

working userspace: Debian squeeze, Ubuntu 11.04, Fedora 15
broken userspace: Debian wheezy, Ubuntu 11.10, Fedora 16

Sorry for the confusion.

2012-01-24 06:14:30

by Jonathan Nieder

[permalink] [raw]
Subject: Re: firmware loading failure for AR3011 (0cf3:3000 or 0cf3:3005 ?)

Hi,

Andres Cimmarusti wrote[1]:

> This is my device:
>
> Bus 001 Device 003: ID 0cf3:3000 Atheros Communications, Inc. AR3011 Bluetooth (no firmware)
>
> It does not turn on and kern.log shows following errors:
>
> [ 9.335184] ath3k_load_firmware: Can't change to loading configuration err
> [ 9.335413] ath3k: probe of 1-1.3:1.0 failed with error -110

Further investigation revealed that the problem seems to be in
userspace: various kernels including a 2.6.32.y-based and 3.1.8-based
one reproducibly exhibit this behavior with a Debian wheezy userspace
and do _not_ exhibit the problem in Debian squeeze, Ubuntu 11.10, or
Fedora 16. More results:

* The problem does not seem to be udev: downgrading udev in wheezy
does not make the problem go away, and upgrading udev in squeeze
does not provoke trouble.

* The problem does not seem to be firmware-atheros: upgrading the
firmware in squeeze does not provoke trouble.

* The problem does not seem to be usb-modeswitch, for similar
reasons. (You can see us grasping at straws here.)

I guess the next natural component to blame is bluez.

Any hints (e.g., debugging switches) for tracking this down?

Thanks,
Jonathan

[1] http://bugs.debian.org/641749

2012-02-12 17:44:50

by Andres Cimmarusti

[permalink] [raw]
Subject: Re: firmware loading failure for AR3011 (0cf3:3000 or 0cf3:3005 ?)

I believe I have finally narrowed down the problem. It lies in the
'libmtp-runtime' package with the command 'mtp-probe' (only present in
wheezy or newer).

I'm not sure what this is doing to my system, but when the package
mentioned is installed, it "messes" up my atheros bluetooth device so
that the kernel/udev cannot load the firmware into it.

As soon as I uninstalled this package and thus caused the boot process
to throw some errors about missing mtp-probe command, my bluetooth
module was correctly loaded and the led turned on.

>> Inexplicably yesterday's (and the day before) Debian testing snapshot
>> seems to have the problem fixed!

I guess this snapshot that I tested earlier didn't have that package installed

I found out about this completely by chance. For whatever reason, on
my second upgrade to wheezy 'apt-get dist-upgrade' didn't pull
'libmtp-runtime' and my bluetooth module just worked.

I tried to get the bootlog messages so I can send this info, but even
with bootlogd enabled these messages happen too early on the boot
process to be logged in /var/log/boot.

I feel this is not necessarily a kernel bug anymore (all kernels
tested work fine 3.0.x, 3.1.x, 3.2.x and even 3.3.0-rc3). But the
experts will know better.

This is definitely progress!

Cheers

Andres

PS: please forward the info to other bug reports I don't have access
to, like Red Hat / Fedora and Ubuntu. Additional testing is needed.

2012-02-10 05:28:21

by Andres Cimmarusti

[permalink] [raw]
Subject: Re: firmware loading failure for AR3011 (0cf3:3000 or 0cf3:3005 ?)

> Inexplicably yesterday's (and the day before) Debian testing snapshot
> seems to have the problem fixed!
>
> I tested kernel 3.2.x and 3.1.x. udev still is at version 175.
>
> I'm completely ignorant to what change in Debian testing led to the
> fixing of this problem. I guess I should have tested everyday, for
> every round of updates to testing, but I lacked the time.
>
> I'm attaching a dmesg, though it shows nothing of interest AFAIK.
>
> I hope this issue doesn't come back to haunt me. I'll upgrade to
> wheezy on this machine soon so I can monitor everything more closely
> instead of relying on live images.

I finally installed wheezy by default on the laptop... it ended up
being rather hard...
Anyways the problem is back. I don't know what change in the Usb
images I tested days ago may have resulted in a fix.

I've tested the most recent Debian kernel -> basically 3.2.5 and also 3.3.0-rc3
Both throw the same error. I'm attaching dmesg from 3.3.0-rc3, but
there's absolutely no new information.
Should I enable the debugging symbols to test if there's more output?
my build had them disabled, otherwise the kernel image was huge.

Andres


Attachments:
dmesg_3.3-rc3_wheezy.txt (46.67 kB)

2012-02-03 13:49:49

by Andres Cimmarusti

[permalink] [raw]
Subject: Re: firmware loading failure for AR3011 (0cf3:3000 or 0cf3:3005 ?)

Inexplicably yesterday's (and the day before) Debian testing snapshot
seems to have the problem fixed!

I tested kernel 3.2.x and 3.1.x. udev still is at version 175.

I'm completely ignorant to what change in Debian testing led to the
fixing of this problem. I guess I should have tested everyday, for
every round of updates to testing, but I lacked the time.

I'm attaching a dmesg, though it shows nothing of interest AFAIK.

I hope this issue doesn't come back to haunt me. I'll upgrade to
wheezy on this machine soon so I can monitor everything more closely
instead of relying on live images.

Cheers,

Andres


Attachments:
dmesg_2012-02-02_wheezy.txt (49.28 kB)