Using tips provided in the “Sticky” posts, I have identified my wireless device – BCM4322 – and installed the necessary firmware and drivers. The device appears in Network Manager until system reboot, at which time the “ssd” driver module is loaded instead. After each boot I must execute the following commands to remove ssd and load the Broadcom driver:
rmmod ssb
modprobe lib80211
modprobe wl
The Broadcom README file provides directions to load the correct module automatically, but the commands appear to be incompatible with openSUSE 11.4. I’m happy to provide additional detail if needed. Please be specific.
On 03/21/2011 04:06 AM, milehigh wrote:
>
> Using tips provided in the “Sticky” posts, I have identified my wireless
> device – BCM4322 – and installed the necessary firmware and drivers.
> The device appears in Network Manager until system reboot, at which time
> the “ssd” driver module is loaded instead. After each boot I must
> execute the following commands to remove ssd and load the Broadcom
> driver:
Note: ssb, not ssd.
> rmmod ssb
> modprobe lib80211
> modprobe wl
>
> The Broadcom README file provides directions to load the correct module
> automatically, but the commands appear to be incompatible with openSUSE
> 11.4. I’m happy to provide additional detail if needed. Please be
> specific.
Add “blacklist ssb” to the bottom of /etc/modprobe.d/50-blacklist.conf.
Run the command 'sudo /sbin/depmod -a". Now it should work. The commands have
not changed. You did something wrong.
Thank you for your effort to assist. I have confirmed that “blacklist ssb” appears in /etc/modprobe.d/50-blacklist.conf and in /etc/modprobe.d/blacklist.conf (as documented in the README file obtained from Broadcom’s website).
Nonetheless, loading of the “ssb” module persists at system boot, and so I must continue to run ‘rmmod ssb’ and ‘modprobe wl’ to unload “ssb” and load “wl” instead. (Through experimentation I have determined that the ‘modprobe lib80211’ command suggested by Broadcom is unneeded.)
The Broadcom documentation says, “Sometimes blacklisting ssb may not be enough to prevent it from loading and it loads anyway.” (Yes.) And here’s the solution they suggest:
Back up the current boot ramfs and generate a new one.
cp /boot/initrd.img-uname -r somewheresafe
update-initramfs -u
reboot
As you probably know, the ‘update-initramfs -u’ command is unrecognized by openSUSE 11.4. I’m hopeful you or someone else can suggest something comparable if it is a matter of simply “clearing the cache”, so to speak.
On 03/21/2011 08:06 PM, milehigh wrote:
>
> lwfinger;2309480 Wrote:
>> Add “blacklist ssb” to the bottom of /etc/modprobe.d/50-blacklist.conf.
>
> Thank you for your effort to assist. I have confirmed that “blacklist
> ssb” appears in /etc/modprobe.d/50-blacklist.conf and in
> /etc/modprobe.d/blacklist.conf (as documented in the README file
> obtained from Broadcom’s website).
>
> Nonetheless, loading of the “ssb” module persists at system boot, and
> so I must continue to run ‘rmmod ssb’ and ‘modprobe wl’ to unload “ssb”
> and load “wl” instead. (Through experimentation I have determined that
> the ‘modprobe lib80211’ command suggested by Broadcom is unneeded.)
>
> The Broadcom documentation says, “Sometimes blacklisting ssb may not be
> enough to prevent it from loading and it loads anyway.” (Yes.) And
> here’s the solution they suggest:
>
> Back up the current boot ramfs and generate a new one.
> # cp /boot/initrd.img-uname -r somewheresafe
> # update-initramfs -u
> # reboot
>
> As you probably know, the ‘update-initramfs -u’ command is unrecognized
> by openSUSE 11.4. I’m hopeful you or someone else can suggest something
> comparable if it is a matter of simply “clearing the cache”, so to
> speak.
If ssb were in the initial ramdisk, then you would need that command; however,
it never is.
The ‘modprobe lib80211’ command is needed if you use Broadcom’s build procedure
as they are not smart enough to include the crucial ‘depmod -a’ step after
copying the driver to the /lib/modules tree.
Please post the output from ‘sudo /sbin/lspci -nn’. You may have a b44 wired
device on your machine. If so, it needs ssb and the loading procedure gets harder.
Nothing there jumps out at me. However, your comment set me to thinking.
My primary network device is Mobile Broadband, which I’ve been using for about four years. Recently I traded my Novatel CDMA device for a Franklin dual band 3G/4G. Linux doesn’t support the 4G communications chip at this time. Nonetheless YaST showed the presence of a Beceem Communications BCSM250 Mobile WiMAX device as well as the U600 EVDO Modem.
Following installation of the Broadcom WLAN drivers I have discovered that the WiMAX device is no longer listed by YaST. However, the EVDO modem is still there and continues to function normally. Thinking there might be a connection, I have tried booting the system without USB Mobile Broadband installed. No difference. WLAN and the EVDO modem coexist peacefully, and Network Manager handles them side by side.
On 03/22/2011 01:36 AM, milehigh wrote:
>
> Output from ‘sudo /sbin/lspci -nn’
>
> 00:00.0 Host bridge [0600]: Intel Corporation Mobile 4 Series Chipset
> Memory Controller Hub [8086:2a40] (rev 07)
> 00:01.0 PCI bridge [0604]: Intel Corporation Mobile 4 Series Chipset
> PCI Express Graphics Port [8086:2a41] (rev 07)
> 00:19.0 Ethernet controller [0200]: Intel Corporation 82567LM Gigabit
> Network Connection [8086:10f5] (rev 03)
> 00:1a.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
> USB UHCI Controller #4 [8086:2937] (rev 03)
> 00:1a.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
> USB UHCI Controller #5 [8086:2938] (rev 03)
> 00:1a.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
> USB UHCI Controller #6 [8086:2939] (rev 03)
> 00:1a.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
> USB2 EHCI Controller #2 [8086:293c] (rev 03)
> 00:1b.0 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD
> Audio Controller [8086:293e] (rev 03)
> 00:1c.0 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
> Express Port 1 [8086:2940] (rev 03)
> 00:1c.1 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
> Express Port 2 [8086:2942] (rev 03)
> 00:1c.2 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
> Express Port 3 [8086:2944] (rev 03)
> 00:1c.3 PCI bridge [0604]: Intel Corporation 82801I (ICH9 Family) PCI
> Express Port 4 [8086:2946] (rev 03)
> 00:1d.0 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
> USB UHCI Controller #1 [8086:2934] (rev 03)
> 00:1d.1 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
> USB UHCI Controller #2 [8086:2935] (rev 03)
> 00:1d.2 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
> USB UHCI Controller #3 [8086:2936] (rev 03)
> 00:1d.7 USB Controller [0c03]: Intel Corporation 82801I (ICH9 Family)
> USB2 EHCI Controller #1 [8086:293a] (rev 03)
> 00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge
> [8086:2448] (rev 93)
> 00:1f.0 ISA bridge [0601]: Intel Corporation ICH9M-E LPC Interface
> Controller [8086:2917] (rev 03)
> 00:1f.2 SATA controller [0106]: Intel Corporation ICH9M/M-E SATA AHCI
> Controller [8086:2929] (rev 03)
> 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) SMBus
> Controller [8086:2930] (rev 03)
> 01:00.0 VGA compatible controller [0300]: nVidia Corporation G96M
> [Quadro FX 770M] [10de:065c] (rev a1)
> 03:01.0 CardBus bridge [0607]: Ricoh Co Ltd RL5c476 II [1180:0476] (rev
> ba)
> 03:01.1 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 IEEE 1394
> Controller [1180:0832] (rev 04)
> 03:01.2 SD Host controller [0805]: Ricoh Co Ltd R5C822
> SD/SDIO/MMC/MS/MSPro Host Adapter [1180:0822] (rev 21)
> 0c:00.0 Network controller [0280]: Broadcom Corporation BCM4322
> 802.11a/b/g/n Wireless LAN Controller [14e4:432b] (rev 01)
>
> Nothing there jumps out at me. However, your comment set me to
> thinking.
>
> My primary network device is Mobile Broadband, which I’ve been using
> for about four years. Recently I traded my Novatel CDMA device for a
> Franklin dual band 3G/4G. Linux doesn’t support the 4G communications
> chip at this time. Nonetheless YaST showed the presence of a Beceem
> Communications BCSM250 Mobile WiMAX device as well as the U600 EVDO
> Modem.
>
> Following installation of the Broadcom WLAN drivers I have discovered
> that the WiMAX device is no longer listed by YaST. However, the EVDO
> modem is still there and continues to function normally. Thinking there
> might be a connection, I have tried booting the system without USB
> Mobile Broadband installed. No difference. WLAN and the EVDO modem
> coexist peacefully, and Network Manager handles them side by side.
Clearly, you do not have a b44 or a Broadcom gigabit network controller that
need ssb. My only suggestion is that you add the lines ‘/sbin/modprobe -r ssb’
etc. to /etc/init.d/after.local. That way the correct modules will be loaded.
I have no idea what is making the kernel sidestep the blacklisting of ssb. Note
that when 11.5 comes out, b43 will be able to handle your BCM4322 and you will
only need to install the firmware with the install_bcm43xx_firmware script.
While I’d be interested to know whether the problem would recur with a clean install, it just doesn’t seem worthwhile to rerun setup to satisfy my curiosity. Thanks again!
On 03/22/2011 09:36 AM, milehigh wrote:
>
> It’s working now! Thank you very much.
>
> While I’d be interested to know whether the problem would recur with a
> clean install, it just doesn’t seem worthwhile to rerun setup to satisfy
> my curiosity. Thanks again!
I don’t think this is an installation problem, but some hardware quirk that
triggers a software condition, or perhaps even a bug. I have one Broadcom device
that has an Ethernet core in the chip that is not connected to the outside and
is essentially dead. Its presence, however, caused b44 to load. We fixed that
case, but something similar must be happening with your box.