Broadcom STA "wl" module conflict with "ssb" module, Where is "ssb" coming from?

[northd_tech]

I've recently moved to SL6.1 from Ubuntu 10.04.3 LTS. When I boot up SL6.1, my wireless is not working. When I run a lsmod command, I see the "ssb" module that is known to cause problems for Broadcom wireless chipsets. Opening a root terminal and issuing rmmod ssb does remove it though.

Then sometimes I need to modprobe wl and exit the root terminal to get my wireless to recognize my wireless network(s). Other times I wll need to rmmod wl first and then modprobe wl in order to get the Broadcom wireless to take hold. After a few days, I 'm getting a little tired of this process every time I start or restart my computer to get wireless working.

No problem right? A little blacklisting and a couple of lines to load that "wl.ko" Broadcom STA module should fix me right up- in theory. Working down that path, I added these lines to /etc/modprobe.d/blacklist.conf to prevent the offending "ssb" module from loading at boot time:

QUOTE

# blacklisting "ssb" module that OEM SciLinux6.1 loaded by DEFAULT blacklist b43legacy blacklist bcma blacklist b43xx blacklist b43 blacklist ssb blacklist openfwwf blacklist ssb

Except that "ssb" module gets loaded every time I boot. I even added that 2nd "blacklist ssb" line to see if that might help, but it didn't work.

Here is where I find the offending "ssb" module:

QUOTE

$ locate ssb.ko /lib/modules/2.6.32-131.21.1.el6.x86_64/kernel/drivers/ssb/ssb.ko /lib/modules/2.6.32-131.6.1.el6.x86_64/kernel/drivers/ssb/ssb.ko

I've tried searching the /etc/rc.d/ directories to see what keeps requesting that "ssb.ko" to be loaded into my SL6.1 kernel:

QUOTE

user@localhost rc.d]$ pwd /etc/rc.d [user@localhost rc.d]$ grep ssb * [user@localhost rc.d]$ grep b43 * [user@localhost rc.d]$ grep wl * rc.local:modprobe wl [/B]

I've looked all over manually using Xterm, dolphin, and natilus under /etc/rc.d/ for where that "ssb" module is getting loaded.

Turning to where I'm loading the "wl" module (that works for my Broadcom 4321AG/"4328" wireless after a little messing around):

QUOTE (/etc/rc.d/rc.local)

# load Broadcom "STA" wireless module version 5.100.82.112 # load from /lib/modules/2.6.32-131.21.1.el6.x86_64/kernel/drivers/net/wireless/wl.ko modprobe wl

I can't seem to find where that "ssb" module is being requested from and it shows up after EVERY boot or restart- could it be part of this SL6.1 kernel?

QUOTE

Linux localhost.localdomain 2.6.32-131.21.1.el6.x86_64 #1 SMP Tue Nov 22 14:15:09 CST 2011 x86_64 x86_64 x86_64 GNU/Linux

I know that in Ubuntu, the modules to be loaded are listed in the file /etc/modules (which I believe translates to /etc/rc.d/rc.local in Red Hat, Fedora, CentOS6, RHEL6, and SL6.1). I"m pretty sure that blacklisting works the same way in SL6.1 as Ubuntu: any file ending in ".conf" in directory /etc/modprobe.d/ should contain the blaclkisted modules.

So if I have blacklisted "ssb' at least twice, why does it load every time that I start my SL6.1 installation?

Edit: Notes to self (and others):

Am I missing something when it comes to /etc/rc.local?
http://www.linuxquestions.org/questions/linux-general-1/am-i-missing-something-when-it-comes-to-etc-rc-local-627844/

An introduction to services, runlevels, and rc.d scripts
https://www.linux.com/news/enterprise/systems-management/8116-an-introduction-to-services-runlevels-and-rcd-scripts

Debian Linux Kernel Handbook
Chapter 6 - Managing the kernel modules
http://kernel-handbook.alioth.debian.org/ch-modules.html

QUOTE

Normally, the devices are detected and neccessary kernel modules are loaded by udev during boot time. Occasionally, one may need finer control over the loading of kernel modules, for example to pass the additional parameters to the module, force loading of some modules on startup, or prevent certain module(s) from being loaded. If some modules are not loaded automatically by udev, but you would like them to be loaded during boot, it is possible to force it by listing the names of the modules in one of the files     /etc/modules-version     /etc/modules-major     /etc/modules where version and major are the kernel version as returned by uname -r (like 2.6.18-3-686) and the major part of the kernel version (like 2.6), respectively

[tux99]

QUOTE (northd_tech @ Dec 7 2011, 01:18 PM)

So if I have blacklisted "ssb' at least twice, why does it load every time that I start my SL6.1 installation?

I'ts probably being loaded as a dependency for some other module.

If you do lsmod|grep ssb right after boot (before removing ssb yourself) what output do you get?

[northd_tech]

It listed "ssb" and a "mmc_ _____" module linked to it right after booting (I don't have access to my notes under Vista right now), but now I appear to have broken the wireless under SL6.1 completely- I cannot get it to connect at all (posting from M$ Vista right now). The wireless interface is listed correctly as "eth1" under iwconfig, but the [GNOME] Network-Manager just is not picking up any wireless routers after modprobe wl. According to lsmod, the wl module and its related "802.11" encryption/authentication modules are loaded into the kernel, so I'm not sure why the wireless no longer works. Of course the wireless broke immediately after the restart for checking the "ssb" module status...

I did discover that CentOS uses a different blacklist file than what I am very accustomed to (that being blacklist.conf or more 'specialized' "broadcom____.conf" files under /etc/modprobe.d/ directory):

QUOTE

Edit the /etc/modprobe.d/blacklist file adding the lines: blacklist bcm43xx blacklist ndiswrapper blacklist b43 blacklist b43legacy By doing so, you're preventing these modules from being loaded into kernel at boot time.

Does SL6.1 use the same blacklisting scheme as CentOS6 (because all my blacklisting efforts appear to have been in vain so far)?

That CentOS Broadcom page also states this:

QUOTE

Also, if there is a line in the /etc/modprobe.conf assigning the driver to your wireless interface, like: alias eth1 bcm43xx or alias eth1 b43 or alias eth1 b43legacy have the line commented out: #alias eth1 bcm43xx or #alias eth1 b43 or #alias eth1 b43legacy and add the new driver alias for your wireless card: alias eth1 wl All this assuming the device file for your wireless interface is 'eth1'. Now, edit the /etc/modprobe.d/modprobe.conf.dist file and add the following lines to it (in some cases, the following may not be necessary): alias ieee80211_crypt_tkip ieee80211_crypt_tkip alias eth1 wl Your driver should now load every time you reboot (except of course, when you install the new kernel, in which case the driver has to be re-compiled for it following these same steps).

I'm not certain which method(s) are correct for Scientific Linux 6.1 (with the multilib m32/m64 library thing going on on a 64bit HP DV9800 series laptop). I had very little trouble under Ubuntu versions from 8.04 through 10.10 (spanning at least 3 years).

In fact, I usually just needed to "Activate" the proprietary Broadcom STA driver under System > Adminstration > Hardware Drivers [under GNOME 2.x] and restart. Of course all that stuff is long gone now (I got mad at 64-bit only vs 32-bit only Linux after several years of "incorrect architecture" messages)...

Anyway, here is that CentOS Broadcom reference if it is applicable to SL6.1 (I believe that CentOS6 and RHEL6 are very close to SL6.1, aren't they?):

http://wiki.centos.org/HowTos/Laptops/Wireless/Broadcom

It did look like the VMware Workstation (and VMware Player packaged with it) virtual networking driver modules might have been interfering with the "wl" eth1 wireless setup (they were "bridged" together under VMware Player under Ubuntu). It is much more important to me to have the wireless working right now than to experiment with virtual machines, so I ran the VMware uninstall script that took quite a bit of hunting to locate. That uninstall appears to have ran successfully with no errors. I can probably re-install VMWare Workstation later without much trouble once I get my wireless working much more reliably/conveniently.

I'm seeing Oracle's VirtualBox modules now though (I suspect the VMware installation had blacklisted the VirtualBox ones when VMware was installed). I am/was seeing multiple "vb___" wireless "interfaces" under iwconfig, so that could be a source or part of the wireless troubles.

Originally, I had VMware Workstation/VMware Player, Oracle VirtualBox, and the KVM virtual machine packages installed (and the wireless had been working fine for several days after a little modprobe -ing to scare it back to life).

So far, I have only uninstalled the VMware Workstation/VMware Player package and I tried to blacklist the other VirtualBox and KVM 'virtual' modules (but I now think that /etc/modprobe.d/blacklist.conf was the wrong place to do that under SL6.1).

NOTE: Looking a little closer at that CentOS page, I didn't see it mention CentOS6 anywhere (but it did mention CentOS5)- it may not have been updated for the newer "6.x" versions of 'Red Hat-or-so'

[northd_tech]

QUOTE (tux99 @ Dec 7 2011, 06:00 AM)

QUOTE (northd_tech @ Dec 7 2011, 01:18 PM) So if I have blacklisted "ssb' at least twice, why does it load every time that I start my SL6.1 installation? I'ts probably being loaded as a dependency for some other module. If you do lsmod|grep ssb right after boot (before removing ssb yourself) what output do you get?

I'm currently using an ethernet cable (but I don't have much access to that and am operating off a 3+ year old laptop battery (which is actually amazingly 'healthy' and is currently at 87.5%) to post these results. I included nearly everything that I could think of that might have diagnostic value:

"Broken" Broadcom wireless connection after removing VMware Workstation and several restarts ("clean" at the top of the output, and all commands & output are in chronological order):
http://sharetext.org/CEBK

The weirdest thing: iwlist scan works and "sees" my wireless router , although my wireless connection (actually Network Manager Applet 0.8.1) "doesn't" now- see around line 280 in that SharetextOrg link.

These apparently "virtual networking"/"network bridge" modules look a little suspicious to me now:

QUOTE

[root@localhost ~]# lsmod | egrep 'nat|macv' ebtable_nat 1975 0 ebtables 18101 1 ebtable_nat iptable_nat 6124 1 nf_nat 22788 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 9440 13 iptable_nat,nf_nat ip_tables 17765 3 iptable_nat,iptable_mangle,iptable_filter nf_conntrack 79611 8 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4,nf_conntrack_netbios_ns,nf_conntrack_broadcast,nf_conntrack_ipv6,xt_state macvtap 7867 1 vhost_net macvlan 9986 1 macvtap

Any advice would be appreciated at this point- I'm kind of in 'uncharted' SL6.1 waters right now...

That "ssb.ko" does appear to be loaded by/during the dracut sequence (something that I am competely UN-familar with right now):

QUOTE

[root@localhost log]# cat /var/log/dracut.log | grep ssb Wed Jul 27 13:54:07 EDT 2011 Info: Installing ///lib/modules/2.6.32-131.6.1.el6.x86_64/kernel/drivers/ssb/ssb.ko Fri Dec 2 22:22:43 MST 2011 Info: Installing ///lib/modules/2.6.32-131.6.1.el6.x86_64/kernel/drivers/ssb/ssb.ko Sat Dec 3 05:55:44 MST 2011 Info: Installing ///lib/modules/2.6.32-131.21.1.el6.x86_64/kernel/drivers/ssb/ssb.ko Sat Dec 3 05:57:11 MST 2011 Info: Installing ///lib/modules/2.6.32-131.21.1.el6.x86_64/kernel/drivers/ssb/ssb.ko

Edit: I've had reason(s) in the past to not like the [GNOME] Network Manager- do any SL6.x users have experience runing Wicd to connect wirelessly?

http://wicd.sourceforge.net/

Edit2:

QUOTE

[root@localhost log]# nm-tool NetworkManager Tool State: connected - Device: eth0  [Auto eth0] ----------------------------------------------------   Type:              Wired   Driver:            forcedeth   State:            connected   Default:          yes   HW Address:      [nForce MAC address]   Capabilities:     Carrier Detect:  yes     Speed:          100 Mb/s   Wired Properties     Carrier:        on   IPv4 Settings:     Address:        192.168.0.10     Prefix:          24 (255.255.255.0)     Gateway:        192.168.0.1     DNS:            192.168.0.1     DNS:            205.171.2.25 - Device: eth1 -----------------------------------------------------------------   Type:              802.11 WiFi   Driver:            wl   State:            unavailable   Default:          no   HW Address:      [Broadcom MAC address]   Capabilities:   Wireless Properties     WEP Encryption:  yes     WPA Encryption:  yes     WPA2 Encryption: yes   Wireless Access Points

[northd_tech]

Well, I tried everything that I could think of to get my wireless working and nothing worked. I did a reinstall of SL6.1 this morning and it is working now (after building the STA module from Broadcom's sourcecode and the rmmod ssb, modprobe wl, exit [root login] ritual). This time, it took a lot longer to see my wireless networks, and I issued a nm-tool command before the wireless sprang to life.

This appears to have been some kind of 'train wreck' between the Broadcom "wl" driver module and the VirtualBox virtual machine drivers- I no longer have VirtualBox or VMware Workstation installed and wireless is now working (but I'm still back to square one on my blacklisting problem).

I wanted to watch the SL6.1 installation a little closer the 2nd time anyway for educational reasons, and I have taken more thorough notes this time.

So does anyone know whether SL6.1 uses the same blacklisting scheme as CentOS [5 was what I found in an online search, not version 6]?

Here is what I believe is the 'virgin' module blacklisting directory, and I don't see a "blacklist" file although I do see a "blacklist.conf" from May of 2011:

QUOTE

$ pwd /etc/modprobe.d $ ls -l total 28 -rw-r--r--. 1 root root  884 May 20  2011 blacklist.conf -rw-r--r--. 1 root root   16 May 20  2009 blacklist-visor.conf -rw-r--r--. 1 root root  382 Nov 23  2010 dist-alsa.conf -rw-r--r--. 1 root root 5596 Nov 23  2010 dist.conf -rw-r--r--. 1 root root  473 Nov 23  2010 dist-oss.conf -rw-r--r--. 1 root root   30 Oct  9  2009 openfwwf.conf

Edit: Right now, it does not appear that I have any virtual machine programs isntalled (although I thought that KVM was installed by default on my 1st install of SL6.1):

QUOTE

[$ lsmod | grep vb $ lsmod | grep vm $ lsmod | grep kv

[northd_tech]

QUOTE (northd_tech @ Dec 8 2011, 07:51 PM)

This appears to have been some kind of 'train wreck' between the Broadcom "wl" driver module and the VirtualBox virtual machine drivers- I no longer have VirtualBox or VMware Workstation installed and wireless is now working (but I'm still back to square one on my blacklisting problem).

It looks like these might have been my "problem areas" from the big text linked above:

QUOTE

# lsmod | egrep 'vbox|kvm|vm' vboxpci 14094 0 vboxnetadp 5742 0 vboxnetflt 16551 0 vboxdrv 1868541 3 vboxpci,vboxnetadp,vboxnetflt # iwconfig lo no wireless extensions. eth0 no wireless extensions. virbr0 no wireless extensions. virbr0-nic no wireless extensions. [root@localhost ~]# lsmod | egrep 'nat|macv' ebtable_nat 1975 0 ebtables 18101 1 ebtable_nat iptable_nat 6124 1 nf_nat 22788 2 ipt_MASQUERADE,iptable_nat nf_conntrack_ipv4 9440 13 iptable_nat,nf_nat ip_tables 17765 3 iptable_nat,iptable_mangle,iptable_filter nf_conntrack 79611 8 ipt_MASQUERADE,iptable_nat,nf_nat,nf_conntrack_ipv4,nf_conntrack_netbios_ns,nf_conntrack_broadcast,nf_conntrack_ipv6,xt_state macvtap 7867 1 vhost_net macvlan 9986 1 macvtap

So far, I haven't had any troubles once I get "wl" inserted into the kernel. I have NOT been in a hurry to install any virtual machine hosts however.

Edit: Also it appears that "ssb" module is being loaded very early (in the dracut sequence). I don't know much if anything about dracut- are there any gurus that know about that here?

http://people.redhat.com/harald/dracut.html

QUOTE

Adding dracut Modules Some dracut modules are turned off by default and have to be activated manually. You can do this by adding the dracut modules to the configuration file /etc/dracut.conf or /etc/dracut.conf.d/myconf.conf. See the man page dracut.conf(5). You can also add dracut modules on the command line by using the -a or --add option: # dracut --add bootchart initramfs-bootchart.img To see a list of available dracut modules, use the --list-modules option: # dracut --list-modules or, if you have a dracut version earlier than 008, issue the command: # for mod in /usr/share/dracut/modules.d/*; do echo ${mod##*/??}; done Omitting dracut Modules Sometimes you don't want a dracut module to be included for reasons of speed, size or functionality. To do this, either specify the omit_dracutmodules variable in the dracut.conf or /etc/dracut.conf.d/myconf.conf configuration file (see man page dracut.conf(5)), or use the -o or --omit option on the command line: # dracut -o "multipath lvm" no-multipath-lvm.img Adding Kernel Modules If you need a special kernel module in the initramfs, which is not automatically picked up by dracut, you have the use the --add-drivers option on the command line or the drivers vaiable in the /etc/dracut.conf or /etc/dracut.conf.d/myconf.conf configuration file (see man page dracut.conf(5)): # dracut --add-drivers mymod initramfs-with-mymod.img

[northd_tech]

I'm going to try changing this:

QUOTE

# Dracut modules to omit #omit_dracutmodules+="" # Dracut modules to add to the default #add_dracutmodules+="" # additional kernel modules to the default #add_drivers+=""

to this in /etc/dracut.conf :

QUOTE

# Dracut modules to omit omit_dracutmodules+="ssb" # having issues with "ssb" module and Broadcom 4321 STA driver # Dracut modules to add to the default #add_dracutmodules+="" # additional kernel modules to the default add_drivers+="wl" # hopefully this will work to make Broadcom STA driver load at boot time (for 4321AG/"4328" wireless)

I'll probably know more after a restart or 3...

[northd_tech]

Well I had wireless working "automatically" at boot time for a while (until I installed another 'backup' kernel). Now I'm back to the modprobe wl drill above, probably related to the 2 new 'initramfs' entries in GRUB from the 'newer' kernels.

I needed to use dracut to "omit" the ssb module in initramfs-2.6.32-[...].img (but this looks like it has a very high probability of 'crashing' SL6.x booting). I would read up VERY THOROUGHLY on dracut and dracut.conf before attempting something similar, and go forewarned!

I nearly 'crashed' my working kernel trying to get rid of that ssb module (but I re-ran dracut with the proper parameters before a restart, or else I might have been unable to boot SL6.1).