Belkin USB bluetooth device loads wrong module

Bug #140511 reported by Tom Badran
10
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Undecided
Unassigned
Hardy
Fix Released
Medium
Tim Gardner
linux-source-2.6.22 (Ubuntu)
Won't Fix
Undecided
Unassigned
Hardy
Invalid
Undecided
Unassigned
module-init-tools (Ubuntu)
Won't Fix
Undecided
Unassigned
Hardy
Won't Fix
Undecided
Unassigned

Bug Description

Binary package hint: module-init-tools

I have a usb bluetooth adapter (Belkin F8T012xx1, FCC: K7SF8t012, IC: 3632A-F8T012) identified by lsusb as:

Bus 003 Device 003: ID 050d:0121 Belkin Components F5D5050 100Mbps Ethernet

By default the 'pegasus' driver is loaded, however this causes subsequent lsusb commands to hang forever, and actually causes a loud tone to play from the pc speaker, and the system to hang if i unplug and reattach the device. It also doesnt allow the bluetooth functionality to work.

If i blacklist pegasus in /etc/modprobe.d/blacklist then it works correctly.

Obviously a global blacklist on pegasus is not the right solution, but i have no idea how to fix this properly for one device.

Revision history for this message
Chuck Short (zulcss) wrote :

Which driver is it suppose to load? Can you post the output of sudo lsmod?

Thanks
chuck

Changed in linux-source-2.6.22:
status: New → Invalid
Revision history for this message
Tom Badran (tom-badran) wrote :

Sure. I'm not actually sure which is the correct module, but i found a post on some mailing list (sorry, lost the link) that suggested blacklisting pegasus would make it work.

Here is the output of lsmod with the bluetooh dongle working correctly.

Tom Badran (tom-badran)
Changed in linux-source-2.6.22:
status: Invalid → New
Revision history for this message
Carsten Sørensen (cso-rift) wrote :

I'm having the same issue with the same adapter. When you google the device id it would seem that indeed the Belkin F5D5050 shares this id and that the detection should be improved by looking at the type of device (if possible).

This is not limited to Ubuntu, for instance it also happens when you load the GParted LiveCD with the dongle inserted. I'm not sure to where this should be reported though?

Thanks for the tip about blacklisting pegasus, at least that makes my system work.

Revision history for this message
Maxime Chéramy (maxime81) wrote :

This work both on Feisty and Gusty :

echo "blacklist pegasus" >> /etc/modprobe.d/blacklist

echo "bcm203x" >> /etc/modules

Revision history for this message
Maxime Chéramy (maxime81) wrote :

This works both on Feisty and Gusty :

echo "blacklist pegasus" >> /etc/modprobe.d/blacklist

echo "bcm203x" >> /etc/modules

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

The Hardy Heron Alpha2 release will be coming out soon (around Dec 20). It will have an updated version of the kernel. It would be great if you could test with this new release and verify if this issue still exists. I'll be sure to update this report when Alpha2 is available. Thanks!

Changed in linux:
status: New → Incomplete
Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hardy Heron Alpha2 was recently released. It contains an updated version of the kernel. You can download and try the new Hardy Heron Alpha2 release from http://cdimage.ubuntu.com/releases/hardy/alpha-2/ . You should be able to then test the new kernel via the LiveCD. If you can, please verify if this bug still exists or not and report back your results. General information regarding the release can also be found here: http://www.ubuntu.com/testing/hardy/alpha2 . Thanks!

Revision history for this message
Carsten Sørensen (cso-rift) wrote :

I'm sorry to report that the problem still exists in 8.04 Alpha 2.

The system seems to hang on "* Loading hardware drivers...". When the Bluetooth adapter is unplugged during this hang, the pegasus module prints out a screenfull of errors and the boot sequence then continues. This is exactly the same behaviour as 7.10.

It would seem that the pegasus module is still being loaded to handle the adapter in question.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Thanks for testing. Per the kernel team's bug policy, can you please attach the following information for the newer Hardy Alpha2 kernel:

* uname -a > uname-a.log
* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

Please be sure to attach each file as a separate attachment. For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help and feedback.

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

I'm opened a new task against the actively developed kernel and am closing the report against linux-source-2.6.22. Thanks!

Changed in linux-source-2.6.22:
status: New → Won't Fix
Revision history for this message
Sebastien Estienne (sebest) wrote :

I have the same issue, i attached the requested files.
I have to blacklist pegasus module to get this working, then it loads these modules: bluetooth and hci_usb.
Everything is ok after this.

Revision history for this message
Sebastien Estienne (sebest) wrote :
Revision history for this message
Sebastien Estienne (sebest) wrote :
Revision history for this message
Sebastien Estienne (sebest) wrote :
Revision history for this message
Sebastien Estienne (sebest) wrote :
Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Incomplete → Triaged
Revision history for this message
Tom Badran (tom-badran) wrote :

Updated to hardy today, bug still present

Stefan Bader (smb)
Changed in linux:
assignee: ubuntu-kernel-team → stefan-bader-canonical
Revision history for this message
Stefan Bader (smb) wrote :

Could someone please attach an lspci -vvv output with the USB dongle inserted?

Revision history for this message
Tom Badran (tom-badran) wrote :

I assume you mean lsusb? Either way i have attached output from both lspci -vvv and lsusb -vvv

Revision history for this message
Tom Badran (tom-badran) wrote :
Revision history for this message
Stefan Bader (smb) wrote :

Blacklisting the pegasus module would disable all the other devices which are supported by this driver. I don't think this should be done. It is a work-around for those using the bluetooth dongle.

Changed in module-init-tools:
status: New → Won't Fix
Revision history for this message
Stefan Bader (smb) wrote :

The problem is that there seem to be two devices using the same vendor and model string. We have the info for the bluetooth dongle (0x050d:0x0121, Class=224 (wireless), SubClass=1 (radio) and Protocol=1 (bluetooth) from the lsusb output). The whole thing has to be fixed in the driver and the following patch could be a start. However, this has to be done upstream. Even more because the quick approach below (if it works) would be the wrong direction. Rather than checking special non-working cases, I guess it would make sense to extend the matching criteria more specifically to the supported classes. But that would be the decission of the maintainer anyways.

USB PEGASUS DRIVER
P: Petko Manolov
M: <email address hidden>
L: <email address hidden>
L: <email address hidden>
W: http://pegasus2.sourceforge.net/
S: Maintained

Tim Gardner (timg-tpi)
Changed in linux:
status: Triaged → In Progress
Revision history for this message
Stefan Bader (smb) wrote :

Is anybody having that problem willing/able to try the provided patch?

Revision history for this message
Tom Badran (tom-badran) wrote : Re: [Bug 140511] Re: Belkin USB bluetooth device loads wrong module

I'm happy to try it, whats the name of the source package i can apt-get
source for the linux kernel?

Revision history for this message
Stefan Bader (smb) wrote :

The source package would (currently) be linux-image-2.6.24-11-generic. You get the config with:
cat debian/config/i386/config{,.generic} >.config
It should be sufficient to replace the pegasus module with the new one.

Revision history for this message
Tom Badran (tom-badran) wrote :

Thanks stefan, i was being an idiot and didnt have the deb-src lines
enabled. Currently downloading now and i'll get it built and tested in the
next few hours.

Revision history for this message
Tom Badran (tom-badran) wrote :

Patch does not work, it still hangs trying to load the pegasus module.

Revision history for this message
Stefan Bader (smb) wrote :

Hm, which could either mean the ids do not match exactly, the wrong module was loaded (just to be sure, you rebuild the initramdisk?), or the codepath wasn't hit. If anything else fails, do you feel comfortable to play around with some printk's to give more information?

Revision history for this message
Tom Badran (tom-badran) wrote :

I did rebuild the initramdisk (not manually, i rebuilt the kernel using the
source pacakge and replaced the installed one, which did rebuild that), my
guess would be the if condition isnt exactly right, but im not even slightly
familiar with the code.

Revision history for this message
Stefan Bader (smb) wrote :

The patch below should print out that information to the console. Remove the previous one with "patch -R" and use this one. Maybe this brings us a step ahead.

Revision history for this message
Tom Badran (tom-badran) wrote :

Stefan, here's the output with the new patch (it doesn't do the second printk for obvious reasons):

[ 134.488058] usb 6-2.3: new full speed USB device using ehci_hcd and address 5
[ 134.584448] usb 6-2.3: configuration #1 chosen from 1 choice
[ 134.719346] pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver
[ 134.719868] We got 50d:121 class=0 proto=0

Looking at the patch now, should it not be:

if (id->bDeviceClass != USB_CLASS_WIRELESS_CONTROLLER && id->bDeviceProtocol != 1)

It looks to my untrained eye as if we are doing the "goto out"in the case of it actually being a pegasus usb network device, rather than _not_ a pegasus usb network device?

Revision history for this message
Stefan Bader (smb) wrote :

Yes, the goto_out was intended to happen if the conditions are met. The exitcode should then tell the usb subsystem that the driver does not want this device. So, the expected way would be to hit the second printk and bail out. What puzzles me is that class and proto are 0 here, while in the lsusb output you pasted they were different. Maybe I look at the wrong variables...

Revision history for this message
Tom Badran (tom-badran) wrote :

I did try looking at some of the kernel code to see if i could figure it
out, but im at a deadline for some work right now so just cant spare the
time to go too in depth. I'm happy to try any new patches though if you can
figure out whats going on.

Revision history for this message
Stefan Bader (smb) wrote :

Sorry it took a while to understand the code and come up with something new. The following patch (as before a complete replacement of the previous ones) is a bit more elaborate and should access the right fields.

@Tom

could you give this one a try and tell whether it help? Thanks!

Revision history for this message
Tom Badran (tom-badran) wrote :

Sure, downloading the latest kernel source now, will let you know hoe it
works out.

Revision history for this message
Tom Badran (tom-badran) wrote :

Ok, good and bad news. Bad news is, i still cant boot my machine with it plugged in, it just hangs, even after unplugging the device which it didnt used to, but i cant debug that as i have a geforce 8/amd64 box and the console is currently completely broken.

Good news though, if i plug the device into a booted system, it works fine now. The dmesg output for that is :

[ 142.004237] pegasus: v0.6.14 (2006/09/27), Pegasus/Pegasus II USB Ethernet driver
[ 142.004813] pegasus: checking blacklist for 050d:0121
[ 142.004817] pegasus: class=224 protocol=1
[ 142.004818] pegasus: blacklisted!
[ 142.005638] pegasus: checking blacklist for 050d:0121
[ 142.005641] pegasus: class=224 protocol=1
[ 142.005643] pegasus: blacklisted!
[ 142.006350] pegasus: checking blacklist for 050d:0121
[ 142.006353] pegasus: class=224 protocol=1
[ 142.006354] pegasus: blacklisted!
[ 142.007024] pegasus: checking blacklist for 050d:0121
[ 142.007027] pegasus: class=224 protocol=1
[ 142.007028] pegasus: blacklisted!
[ 142.007701] usbcore: registered new interface driver pegasus
[ 142.067996] Bluetooth: HCI USB driver ver 2.9
[ 142.069660] usbcore: registered new interface driver hci_usb

Revision history for this message
Stefan Bader (smb) wrote :

For the boot problem: could a "update-initramdisk -u" help?

Revision history for this message
Tom Badran (tom-badran) wrote :

There is no update-initramdisk, do you mean update-initramfs?

I rebuilt the whole kernel package though, and it it do that as part of the
install

Revision history for this message
Stefan Bader (smb) wrote :

Right, I remember. Just something not working at boot but later always triggers that thought. Does console completely broken mean that removing "splash" and "quiet" from the grub entry on boot doesn't help or is it just that after the xserver started, you cannot switch back?

Revision history for this message
Tom Badran (tom-badran) wrote :

Yes, that fixes it!

I had look at the package install log, and it seems update-initramfs takes some shortcuts when installing a kernel package over an existing one. I'm glad as console completely broken means all my tty's are completely blank, no matter what, so im glad i didnt have to debug it there.

Thanks for getting that patch working.

Revision history for this message
Tom Badran (tom-badran) wrote :

Any reason this hasn't gone into the recent kernel uploads?

Revision history for this message
Stefan Bader (smb) wrote :

@Tom,

yes sorry about that. This is a bit of a upstream integration problem. I sent that patch to the maintainer and the mailing list and it wasn't liked the way it is. I have been working on an alternate version but am still waiting for feedback on that. Since the final solution will lokk different I am reluctant to put that patch into the kernel, since it generates additional effort to maintain.

Revision history for this message
Tom Badran (tom-badran) wrote :

Ah ok, no worries. There wasn't any more traffic on the bug so i had assumed
everthing was ok.

Revision history for this message
Stefan Bader (smb) wrote :

For completeness this is the rewritten approach of the fix. Though this would require someone in the possession of the normal network adapter (that should use the pegasus module) to ack or nack the usb details.

Revision history for this message
Stefan Bader (smb) wrote :

After some pondering I am adding the blacklist patch to the repo. The fix might be different in future but the current one is tested and is not intrusive, while the work in progress might prevent the Belkin network adapter from working.

Changed in linux:
milestone: none → ubuntu-8.04
status: In Progress → Fix Committed
Revision history for this message
Martin Capitanio (capnm) wrote :

yeah, in the future :-) It's sitting about 1 year in the kernel bugzila, but who knows, some day ...
http://bugzilla.kernel.org/show_bug.cgi?id=8294

Tim Gardner (timg-tpi)
Changed in linux:
assignee: stefan-bader-canonical → timg-tpi
milestone: ubuntu-8.04 → ubuntu-8.04.1
Revision history for this message
Tim Gardner (timg-tpi) wrote :

SRU Justification:

Though this bug shows up in the -17.31 changelog, the fix was actually released in 8.04. There must some kind of problem with the kernel 'debian/rules insertchanges' code.

Revision history for this message
Colin Watson (cjwatson) wrote :

Accepted into hardy-proposed.

Revision history for this message
Tim Gardner (timg-tpi) wrote :

Ignore that last comment, there appears to be some 'git' confusion with merge times. The -16.30 pegasus code in the archive does _not_ have the black list patch.

SRU Justification:

Impact: The Pegasus USB ethernet driver is erroneously loaded which causes a kernel hang.

Fix description: Detect the bluetooth protocol in the pegasus ethernet driver and refuse to load.

Patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=77d6ec19785ff831150378a1073c21024e88fb05

TEST CASE: Boot with the Belkin Bluetooth 050d:0121 dongle inserted. The kernel usually hangs, at the very least the bluetooth device does not function.

Belkin has released 2 devices, both with the same USB vendor and device identifiers. These 2 devices are distinguishable only by virtue of the fact that the bluetooth device specifies the bluetooth protocol. However, this isn't something that UDEV looks at when deciding what device driver to load.

Revision history for this message
Tom Badran (tom-badran) wrote :

Updated to 2.6.24.17.19 linux-image today from hardy-proposed. Plugging the bluetooth module in now no longer hangs the kernel, and the gnome bluetooth applet shows up in my status bar.

Thanks for getting this in.

Steve Langasek (vorlon)
Changed in linux-source-2.6.22:
status: New → Invalid
Changed in linux:
assignee: nobody → timg-tpi
importance: Undecided → Medium
milestone: none → ubuntu-8.04.1
status: New → Fix Committed
milestone: ubuntu-8.04.1 → none
Changed in module-init-tools:
status: New → Won't Fix
Revision history for this message
Martin Pitt (pitti) wrote :

linux 2.6.24-17.31 copied to hardy-updates.

Changed in linux:
status: Fix Committed → Fix Released
Tim Gardner (timg-tpi)
Changed in linux (Ubuntu):
assignee: Tim Gardner (timg-tpi) → nobody
importance: Medium → Undecided
status: Fix Committed → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.