Talk:Broadcom Wireless: Difference between revisions
(Explanation of changes wrt /etc/modprobe.d/) |
(→Issue with ssb as a dependency of the b44 module: new section) |
||
| (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.