linux-kernel - Re: firmware loading failure for AR3011 (0cf3:3000 or 0cf3:3005 ?)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20120124061430.GB30210@burratino>
Date:	Tue, 24 Jan 2012 00:14:30 -0600
From:	Jonathan Nieder <jrnieder@...il.com>
To:	linux-bluetooth@...r.kernel.org
Cc:	Andres Cimmarusti <acimmarusti@...il.com>,
	linux-kernel@...r.kernel.org, info@...uxcertified.com,
	Paul Fertser <fercerpav@...il.com>,
	"Gustavo F. Padovan" <padovan@...fusion.mobi>,
	Marcel Holtmann <marcel@...tmann.org>
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/