ssb interferes with ndiswrapper (bcm4311, bcm4318)

Bug #218763 reported by dkoes
32
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Medium
Unassigned
Nominated for Hardy by matt_hargett
Nominated for Intrepid by Pablo Castellano

Bug Description

This is a continuation of bug#197558 ssb module breaks BCM4328 with ndiswrapper (regression from 2.6.24-10)
which refers to a very specific issue, but became a dumping ground for a larger issue. Specifically, it appears that ssb prevents ndiswrapper from getting control of the wireless card. Since for several people the default b43 driver does not work, or does not work well, it is desirable to use ndiswrapper instead.

There is a workaround, which is to have a startup script modprobe -r b43,b44,ssb,ndiswrapper and then modprobe ndiswrapper,b43,b44, but this isn't a very elegant solution.

Tags: cft-2.6.27
Revision history for this message
Wrath (alan1212) wrote :

I have the same issue with a bcm4318 in hardy. The ssb module would not allow ndiswrapper to take control over the wireless card without messing with the modules after boot.

Revision history for this message
SireeBob (sireebob) wrote :

Thanks for the new report. I don't really understand why the previous one couldn't be expanded to include bcm4311 and bcm4318 because it's the same problem, but whatever gets this bug the proper attention.

I have a bcm4318 and the same problem here (I'm on Kubuntu 8.04 Beta). This is definitely a regression from Gutsy. Argh. I'm using ndiswrapper because b43 offers a very unstable connection, just like bcm43xx. It was too unstable for me to even download the driver I needed for ndiswrapper, so I had to plug in.

Any ideas for a clean way to make ndiswrapper load before ssb, solving this problem?

Revision history for this message
dkoes (koes) wrote :

The workaround I'm currently using is just removing ssb, b43, and b44 altogether. My initial attempts at doing this (adding them to the blacklist file) failed (ssb insisted on loading) but somehow, after reinstalling the kernel, it started working.

Revision history for this message
SireeBob (sireebob) wrote :

I gave in and used an init script with info from https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197558/comments/14 and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/197558/comments/16 . A better solution or a fix before release would be nice.

Revision history for this message
Antonello Lobianco (blackhole-lobianco) wrote :

hello.. I have ubuntu 8.04 beta plus all the upgrades and I am affected by this bug as well. I have a BCM4311 card and I needs ndiswrapper as the native driver works fine if close to the router, but perform badly when little far away...

I never got problems till ubuntu 7.10, but now I have to manually remove the modules and then modprobe them back as stated in the bug description to have the card working.
Can someone tell me in which script should I add the "modprobe -r" & "modprobe" commands to have it automatically working at start-up??

Thanks, Antonello

Revision history for this message
Tayroni Alves (tay-fisica) wrote :

Confirmed on Hardy Release Candidate. I have a bcm4311.

Revision history for this message
Antonello Lobianco (blackhole-lobianco) wrote :

I am no longer affected by this bug. All I done was to remove (modprobe -r) b43,b44,ssb,ndiswrapper and then modprobe them back.
I didn't need to place this commands in any init script.. with my surprice, I got everything working even after reboot.

Revision history for this message
Rogier de Groot (rogier-de-groot) wrote :

Confirmed on a clean install of Hardy final (both i386 and amd64 variants tried). Very [censored] annoying.
Fixed with adding "rmmod ssb && rmmod ndiswrapper && modprobe ndiswrapper" to /etc/rc.local, BUT once my laptop boots it takes a looong time trying to connect to the wireless network, which eventually fails. If I try again by clicking on the network manager applet and selecting the default network, it connects nearly instantly though.
On Gutsy my wireless (once ndiswrapper was up and running) had been more reliable than on Vista (which frequently refuses to connect because the HP driver sucks, ndiswrapper uses an older Dell driver, which appearently works better on a HP laptop. WTF).
I've heard in other discussions of this problem that the hardy kernel was compiled with an option which always loads ssb. If this is true, please get me a kernel update with that option off!

Revision history for this message
Larry Finger (larry-finger) wrote :

If you want to use ndiswrapper with a BCM43xx card with Hardy, you _MUST_ blacklist ssb. The reason is that ssb owns the BCM43xx PCI ID's. It then uses internal information in the card to decide whether to load b43 or b43legacy depending on the age of the equipment.

With the bcm43xx driver, the ssb driver was built in, not separate.

Revision history for this message
Rogier de Groot (rogier-de-groot) wrote :

Blacklisting ssb (in /etc/modprobe.d/blacklist) has no effect, the ssb module gets loaded anyway.
Blacklisting b43, b43legacy and b44 also does not help - this is with bcm43xx still blacklisted as per default.

Revision history for this message
Rogier de Groot (rogier-de-groot) wrote :

Now fixed by blacklist the ssb module - in the initrd image, not on the regular system.

Revision history for this message
John Rose (johnaaronrose) wrote :

Rogier,

How do you blacklist the ssb module in the initrd image?

Revision history for this message
Gareth Westwood (gareth-westwoodfamily) wrote :

@ John Rose

just worked round this myself. See my post on the ubuntu forums for details of how to rebuild the initrd on Hardy

http://ubuntuforums.org/showthread.php?p=4960867#post4960867

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

There hasn't been any recent activity in this bug report and we were wondering if this is still an issue? The Ubuntu kernel team is actively working on the upcoming Intrepid Ibex 8.10 release. If you could please test the latest Alpha release for Intrepid it would be much appreciated - http://www.ubuntu.com/testing . Please let us know your results. If the issue still exists, please also provide the appropriate debugging information as outlined at https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks in advance.

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

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

Revision history for this message
Andreas (andreas-kotowicz) wrote :

I'm still having this problem with kernel 2.6.27-2-generic. The only solution to prevent this problem to happen was to black list the ssb driver in the initrd file that come with the kernel.

Changed in linux:
assignee: nobody → ubuntu-kernel-team
importance: Undecided → Medium
status: Incomplete → Triaged
Revision history for this message
Pablo Castellano (pablocastellano) wrote :

In my opinion, #227158 is not a bug duplicate but a related one.

Revision history for this message
Przemek K. (azrael) wrote :

What about bug #188621? Is it a duplicate then? Or reverse?

description: updated
Revision history for this message
yazdzik (yazdzik) wrote :

Dear Friends,

Issue with 4312(01) ndiswrapper remains for me the same in ibex, 2.6.27, grml rc, 2.6.26-7, and my own debian unstable, which is very stable indeed, using 2.6.27-4.

Thus, while related or not to the above captioned bug, it is my experience than ssb and ndiswrapper conflict, and blacklisting ssb, b43, and b44, still seems to be the least elegant, but only effective workaround for many of us.

All good wishes,

Yazdzik

Revision history for this message
Greg (greg-thesantosfamily) wrote :

I get this on 2.6.27-8 as well. SSB interferes with ndiswrapper. I cannot seem to blacklist ssb. I use b44/ssb for my wired link BCM4401. I just want ndiswrapper to run my wireless and leave ssb and b44 alone. What do I do?

Revision history for this message
AnAnonymousKiller (iggy-mon) wrote :

Dell Vostro 1500
Ubuntu 8.10 Intrepid Ibex

   uname -r
                2.6.27-9-generic
   lspci
  0c:00.0 Network controller: Broadcom Corporation BCM4328 802.11a/b/g/n (rev 03)
   lspci -n
  0c:00.0 0280: 14e4:4328 (rev 03)

Module 'ssb' inhibits ndiswrapper from functioning properly. Blacklisting 'ssb' in '/etc/modprobe.d/blacklist does not work as it is being called by module 'b44'.
   lsmod | grep ssb
               ssb 46340 1 b44

Unload module 'b44' which also unloads module 'ssb'...
   sudo modprobe -r b44

...then unload and reload module 'ndiswrapper'...
   sudo modprobe -r ndiswrapper
   sudo modprobe ndiswrapper

...and finally reload module 'b44'
   sudo modprobe b44

All this is assuming that you followed the directions here to install ndiswrapper...
   https://help.ubuntu.com/community/WifiDocs/Driver/Ndiswrapper

***
Footnote: i did not have to blacklist modules 'bcm43xx', 'b43', 'b43legacy' or 'ssb'. Remember, blacklisting 'ssb' won't work anyway as it's being called by another module.

Also: lsmod | grep ssb would show any modules calling 'ssb'. I would assume, but not be 100% certain, that any other listed modules would also have to be unloaded before restarting the 'ndiswrapper' module and be reloaded afterwards.

Lastly: it seems that the order in which the modules are loaded is what matters and not that any one module or another is conflicting. Is there any way to load module 'ndiswrapper' BEFORE any module that lists 'ssb' for lsmod | grep ssb?

Revision history for this message
Przemek K. (azrael) wrote :

If blacklisting ssb doesn't work for you then run sudo update-initramfs -u
See bug #227158 for details.

Revision history for this message
Launchpad Janitor (janitor) wrote : Kernel team bugs

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.

Revision history for this message
Przemek K. (azrael) wrote :

Can anyone check if this is still an issue on Ubuntu 9.10?

Revision history for this message
Tim (tim-cooper) wrote :

Sadly I can confirm it's still an issue on Ubuntu 9.10. Despite blacklisting ssb after each reboot it's back again and no wifi.... I'll be trying one of the not-so-nice work arounds suggested above.

Revision history for this message
Anand Hebbal (hebbal1273) wrote :

It is still a problem on Ubuntu 10.04 :(

Revision history for this message
felicity (info-herx) wrote :

I can confirm that the problem persists in 10.04 or actually has become a problem since upgrade any ideas how to restore it easily to its glorious past would be useful

Revision history for this message
penalvch (penalvch) wrote :

dkoes, this bug report is being closed due to your last comment https://bugs.launchpad.net/ubuntu/+source/linux/+bug/218763/comments/3 regarding this being fixed by reinstalling the kernel. For future reference you can manage the status of your own bugs by clicking on the current status in the yellow line and then choosing a new status in the revealed drop down box. You can learn more about bug statuses at https://wiki.ubuntu.com/Bugs/Status. Thank you again for taking the time to report this bug and helping to make Ubuntu better. Please submit any future bugs you may find.

Changed in linux (Ubuntu):
status: Triaged → 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.