Hi,
I'm seeing a strange issue with a USB-attached internal Bluetooth dongle
(I believe it's on a dual mini PCI-Express/USB card).
Normally, if I start the machine from cold straight into Linux,
everything works fine. The dongle at first shows up as an "IMC Networks"
dongle (13d3:3304) until ath3k loads, then it re-identifies itself as an
"Atheros Communications, Inc." device (0cf3:3005) and works.
However, if I cold-start to Windows 7 first, then reboot into Linux,
frequently the device will get stuck as 13d3:3304 and stop responding.
Attempting to reload ath3k results in a short pause before a message like
[ 131.835217] Bluetooth: Can't change to loading configuration err
[ 131.835315] ath3k: probe of 1-1.2:1.0 failed with error -110
shows up in dmesg. Furthermore, with the device in this state, lsusb -v pauses
for about 5 seconds part-way through printing out the dongle's
properties.
If I then suspend/resume the notebook, and then reload ath3k, generally
it works. The dongle flips its USB ID, and normal service ensues.
This is currently with kernel 3.4.2, but I've seen it with earlier ones as well.
Firmware md5sum:
1211fa34c09e10ba48381586b7c3883d /lib/firmware/ath3k-1.fw
Attached is:
- lsusb-v-dongle-notworking.log
Output of lsusb -v for the Bluetooth adapter (the one that pauses)
- lsusb-v-dongle-working.log
The same when it's working (after suspend/resume)
- lspci.log
lspci output showing the notebook's USB controllers
Any ideas what's going on here?
Thanks,
James.
Am Samstag, 23. Juni 2012, 10:46:12 schrieb James:
> On Fri, 2012-06-22 at 08:26 +0200, Oliver Neukum wrote:
>
> > Basically the device is semi-reset and ath3k cannot deal with a device
> > in that state. But that doesn't tell us what can be done. Please post "lsusb -v"
> > of your device _before_ ath3k is loaded (you should disable ath3k and btusb
> > for that test) in both states, after cold boot and warm reboot from Windows.
>
> I blacklisted ath3k and btusb and captured the following lsusb -v
> outputs for the device, which are attached with names as follows:
>
> 1. lsusb-cold_linux.log
> Taken from a cold boot straight into Linux. [Manually loaded ath3k
> and btusb afterwards, and everything worked properly.]
>
> 2. lsusb-after_win7.log
> Taken after warm reboot into Linux from Windows 7. Here, lsusb -v
> worked without the strange delay.
Hm. This is a bit problematic as we already do a reset in the enumeration
process. And we cannot tell the states apart based on the descriptors.
Al, any idea?
Regards
Oliver
On Fri, 2012-06-22 at 08:26 +0200, Oliver Neukum wrote:
> Basically the device is semi-reset and ath3k cannot deal with a device
> in that state. But that doesn't tell us what can be done. Please post "lsusb -v"
> of your device _before_ ath3k is loaded (you should disable ath3k and btusb
> for that test) in both states, after cold boot and warm reboot from Windows.
I blacklisted ath3k and btusb and captured the following lsusb -v
outputs for the device, which are attached with names as follows:
1. lsusb-cold_linux.log
Taken from a cold boot straight into Linux. [Manually loaded ath3k
and btusb afterwards, and everything worked properly.]
2. lsusb-after_win7.log
Taken after warm reboot into Linux from Windows 7. Here, lsusb -v
worked without the strange delay.
I then unblacklisted ath3k and btusb, and modprobe'd ath3k. As usual,
there was a delay and error -110 showed up in dmesg. I then took another
lsusb -v --- this time, it did pause.
3. lsusb-after_win7+ath3k.log
Taken after failed attempt to load ath3k
Finally, immediately after a suspend/resume cycle:
4. lsusb-after_win7+ath3k+sr.log
and everything then started to work once I reloaded ath3k and btusb.
Hope this is useful. [As far as I can see, the only difference is in
(3), where the device status is 0x0000, rather than 0x0003.]
Thanks,
James.
Am Donnerstag, 21. Juni 2012, 23:01:28 schrieb James:
> Hi,
>
> I'm seeing a strange issue with a USB-attached internal Bluetooth dongle
> (I believe it's on a dual mini PCI-Express/USB card).
>
> Normally, if I start the machine from cold straight into Linux,
> everything works fine. The dongle at first shows up as an "IMC Networks"
> dongle (13d3:3304) until ath3k loads, then it re-identifies itself as an
> "Atheros Communications, Inc." device (0cf3:3005) and works.
>
> However, if I cold-start to Windows 7 first, then reboot into Linux,
> frequently the device will get stuck as 13d3:3304 and stop responding.
> Attempting to reload ath3k results in a short pause before a message like
>
> [ 131.835217] Bluetooth: Can't change to loading configuration err
> [ 131.835315] ath3k: probe of 1-1.2:1.0 failed with error -110
static int ath3k_load_fwfile(struct usb_device *udev,
const struct firmware *firmware)
{
u8 *send_buf;
int err, pipe, len, size, count, sent = 0;
int ret;
count = firmware->size;
send_buf = kmalloc(BULK_SIZE, GFP_KERNEL);
if (!send_buf) {
BT_ERR("Can't allocate memory chunk for firmware");
return -ENOMEM;
}
size = min_t(uint, count, FW_HDR_SIZE);
memcpy(send_buf, firmware->data, size);
pipe = usb_sndctrlpipe(udev, 0);
ret = usb_control_msg(udev, pipe, ATH3K_DNLOAD,
USB_TYPE_VENDOR, 0, 0, send_buf,
size, USB_CTRL_SET_TIMEOUT);
if (ret < 0) {
BT_ERR("Can't change to loading configuration err");
kfree(send_buf);
return ret;
}
ath3k has determined that your device needs additional firmware but cannot
switch to firmware download mode.
> If I then suspend/resume the notebook, and then reload ath3k, generally
> it works. The dongle flips its USB ID, and normal service ensues.
This cuts power to the module and it reverts to its default state like after
a cold boot.
> Any ideas what's going on here?
Basically the device is semi-reset and ath3k cannot deal with a device
in that state. But that doesn't tell us what can be done. Please post "lsusb -v"
of your device _before_ ath3k is loaded (you should disable ath3k and btusb
for that test) in both states, after cold boot and warm reboot from Windows.
Regards
Oliver
On 02/07/12 20:58, Oliver Neukum wrote:
>
> The rfkill switch should do the job.
>
> Regards
> Oliver
>
Unfortunately, it seems the rfkill switch on this notebook only toggles
the hard block on the wlan (judging by rkfill list and continued
Bluetooth activity).
[A more detailed aside: there are two keys on this notebook with a
little antenna icon --- a "special" button separate from the keyboard,
and Fn+F2. Under Linux, only Fn+F2 has any effect. Neither button
generates any X events or show up in showkey or even report an unknown
code in dmesg. (Other multimedia keys work.)
For Windows 7, there seems to be some extra driver that can pick up
keypresses of "special" wireless button. It brings up an on-screen
display when I press the Fn key:
- Fn+F2 and the "special" button disable wlan, but not Bluetooth.
- Fn+F3 is marked as the Bluetooth toggle in some OSD, but also
has no effect.
The only way to turn off Bluetooth I've seen on this notebook is to
soft-block it, either in Windows 7 or Linux.]
Sorry I've not been able to come up with anything helpful here!
Thanks,
James.
Am Montag, 2. Juli 2012, 18:50:16 schrieb James:
> On 02/07/12 11:22, Al Cho wrote:
> >>
> >
> > Yes,
> > James,would you please help us to get these log from test with unplug
> > and plug-in,
> > after warm reboot into Linux from Windows 7 ?
> >
> > Sincerely,
> > AL
> >
>
>
> Hello,
>
> I think the device is built into the notebook on a dual USB/mini PCI
> Express card, so I can't hotplug it. As far as I can tell, there's no
> special keyboard combination to toggle it either. Closest I believe I
> can get is a suspend/resume (unless you know of a USB trick to power
> down the internal hub).
The rfkill switch should do the job.
Regards
Oliver
On 02/07/12 11:22, Al Cho wrote:
>>
>
> Yes,
> James,would you please help us to get these log from test with unplug
> and plug-in,
> after warm reboot into Linux from Windows 7 ?
>
> Sincerely,
> AL
>
Hello,
I think the device is built into the notebook on a dual USB/mini PCI
Express card, so I can't hotplug it. As far as I can tell, there's no
special keyboard combination to toggle it either. Closest I believe I
can get is a suspend/resume (unless you know of a USB trick to power
down the internal hub).
Thanks,
James.
On Mon, Jun 25, 2012 at 8:29 PM, Oliver Neukum <[email protected]> wrote:
> Am Samstag, 23. Juni 2012, 10:46:12 schrieb James:
>> On Fri, 2012-06-22 at 08:26 +0200, Oliver Neukum wrote:
>>
>> > Basically the device is semi-reset and ath3k cannot deal with a device
>> > in that state. But that doesn't tell us what can be done. Please post "lsusb -v"
>> > of your device _before_ ath3k is loaded (you should disable ath3k and btusb
>> > for that test) in both states, after cold boot and warm reboot from Windows.
>>
>> I blacklisted ath3k and btusb and captured the following lsusb -v
>> outputs for the device, which are attached with names as follows:
>>
>> 1. lsusb-cold_linux.log
>> Taken from a cold boot straight into Linux. [Manually loaded ath3k
>> and btusb afterwards, and everything worked properly.]
>>
>> 2. lsusb-after_win7.log
>> Taken after warm reboot into Linux from Windows 7. Here, lsusb -v
>> worked without the strange delay.
>
> Hm. This is a bit problematic as we already do a reset in the enumeration
> process. And we cannot tell the states apart based on the descriptors.
> Al, any idea?
>
Yes,
James,would you please help us to get these log from test with unplug
and plug-in,
after warm reboot into Linux from Windows 7 ?
Sincerely,
AL