Talk:Broadcom Wireless: Difference between revisions

From SlackWiki
Jump to navigation Jump to search
(Explanation of changes wrt /etc/modprobe.d/)
 
 
(One intermediate revision by one other user not shown)
Line 1: Line 1:
I just made a couple of relatively minor edits to the page (20140402):
I just made a couple of relatively minor edits to the page (20140402):
First, admins shouldn't edit files in /lib/modprobe.d/ - those get overwritten on package upgrades; only /etc/modprobe.d/ or /run/modprobe.d/ should be used for local sysadmin edits, as they are not overwritten on upgrades.  However, /run is on a tmpfs, so it is not persistent across reboots; as such, it would applicable for e.g. rules that are auto-generated on system startup based on some nonstable attributes (whether that's a good idea is another discussion entirely, but I think not).  Given all of that, /etc/modprobe.d/ is the best location -- its intent is for sysadmins to copy files from /lib/modprobe.d/ and edit the copies if needed (same-named files in both /etc/modprobe.d/ and /lib/modprobe.d/ are handled such that the file in /etc/modprobe.d/ takes precedence).  This leads up to my second point:
First, admins shouldn't edit files in /lib/modprobe.d/ - those get overwritten on package upgrades; only /etc/modprobe.d/ or /run/modprobe.d/ should be used for local sysadmin edits, as they are not overwritten on upgrades.  However, /run is on a tmpfs, so it is not persistent across reboots; as such, it would applicable for e.g. rules that are auto-generated on system startup based on some nonstable attributes (whether that's a good idea is another discussion entirely, but I think not).  Given all of that, /etc/modprobe.d/ is the best location -- its intent is for sysadmins to copy files from /lib/modprobe.d/ and edit the copies if needed (same-named files in both /etc/modprobe.d/ and /lib/modprobe.d/ are handled such that the file in /etc/modprobe.d/ takes precedence).  This leads up to my second point:
Second, since there's no need in this particular case to override *all* of what's in /lib/modprobe.d/blacklist.conf (you only want to *add* content to it), it's a bit cleaner to just create a new file in /etc/modprobe.d/ with a sensible name and put what you want in it.
Second, since there's no need in this particular case to override *all* of what's in /lib/modprobe.d/blacklist.conf (you only want to *add* content to it), it's a bit cleaner to just create a new file in /etc/modprobe.d/ with a sensible name and put what you want in it.  --rworkman
 
== Issue with ssb as a dependency of the b44 module ==
 
Copying /lib/modprobe.d/bcm43xx.conf to /etc/modprobe.d/bcm43xx.conf and then adding the blacklist entries there worked except for the ssb module. It seems ssb is a dependency of module b44 and is being successfully loaded which blocked the function of the wl module.
The fix was to run sbo packages b43-fwcutter and b43-firmware.
 
This page is a valuable resource for checking compliance.
http://linuxwireless.org/en/users/Drivers/b43/
 
Does anybody mind if I add a section referencing that? At the check where the reader runs the blacklisted modules in lsmod expecting a null return, put a fork in there and suggest if he gets a value after blacklisting and reboot, try the b43-fwcutter/b43-firmware approach.
Or he might check for b44 at the outset and opt for the sbo packages if it's loaded with ssb as a dependency.

Latest revision as of 00:06, 27 January 2015

I just made a couple of relatively minor edits to the page (20140402): First, admins shouldn't edit files in /lib/modprobe.d/ - those get overwritten on package upgrades; only /etc/modprobe.d/ or /run/modprobe.d/ should be used for local sysadmin edits, as they are not overwritten on upgrades. However, /run is on a tmpfs, so it is not persistent across reboots; as such, it would applicable for e.g. rules that are auto-generated on system startup based on some nonstable attributes (whether that's a good idea is another discussion entirely, but I think not). Given all of that, /etc/modprobe.d/ is the best location -- its intent is for sysadmins to copy files from /lib/modprobe.d/ and edit the copies if needed (same-named files in both /etc/modprobe.d/ and /lib/modprobe.d/ are handled such that the file in /etc/modprobe.d/ takes precedence). This leads up to my second point: Second, since there's no need in this particular case to override *all* of what's in /lib/modprobe.d/blacklist.conf (you only want to *add* content to it), it's a bit cleaner to just create a new file in /etc/modprobe.d/ with a sensible name and put what you want in it. --rworkman

Issue with ssb as a dependency of the b44 module

Copying /lib/modprobe.d/bcm43xx.conf to /etc/modprobe.d/bcm43xx.conf and then adding the blacklist entries there worked except for the ssb module. It seems ssb is a dependency of module b44 and is being successfully loaded which blocked the function of the wl module. The fix was to run sbo packages b43-fwcutter and b43-firmware.

This page is a valuable resource for checking compliance. http://linuxwireless.org/en/users/Drivers/b43/

Does anybody mind if I add a section referencing that? At the check where the reader runs the blacklisted modules in lsmod expecting a null return, put a fork in there and suggest if he gets a value after blacklisting and reboot, try the b43-fwcutter/b43-firmware approach. Or he might check for b44 at the outset and opt for the sbo packages if it's loaded with ssb as a dependency.