[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#641749: ath3k_load_firmware: Can't change to loading configuration err

Andres Cimmarusti wrote:

> I tested two kernels on Squeeze:
> - 3.1.8 from squeeze-backports, which was compiled using gcc 4.4.5 (as
> my own compiled 3.0.x and 3.1.x kernels)
> - 3.1.8 from wheezy, compiled using gcc 4.6.2
> Both kernels loaded the firmware correctly without any problems. The
> backport comes from the version in testing, so they have the same
> .config file. I've attached both dmesg.
> Using wheezy, This same kernel fails to load the firmware everytime,
> as compiled with gcc 4.6.2

Excellent.  So now we've confirmed it's not a kernel problem.

I just noticed the following change upstream:

	commit c3eae82a844b
	Author: Paul Fertser <fercerpav@gmail.com>
	Date:   Sat Oct 29 21:52:49 2011 +0400

	    Bluetooth: ath3k: output firmware filename when request_firmware failed

	    This makes it much easier for the users to understand why the driver
	    refuses to load when the firmware is unavailable.

which gives me hope that upstream is looking at this kind of thing
(that patch was merged in v3.3-rc1).  This suggests two possible next

 - Please attach output from "dpkg-query -L firmware-atheros" on a
   squeeze (unaffected) and wheezy (affected) system.

 - Could you try v3.3-rc1 or newer on wheezy?  It works like this:

	# prerequisites
	apt-get install git build-essential

	# get the latest kernel
	git clone \

	# or, if you already have a kernel handy:
	cd linux
	git fetch origin

	# check it out
	git checkout origin/master

	# configure it
	cp /boot/config-$(uname -r) .config
	make localmodconfig; # optional: minimize configuration

	# build it
	make deb-pkg; # can add -j<n> for parallel build

	# install and test
	dpkg -i ../<name of package>

I don't expect 3.3-rc1 to work any better, but it should give a more
useful error message.

If that doesn't provide any insight, I have a message ready in my
drafts folder asking upstream for more help.


Reply to: