<?xml version="1.0"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
	<channel>
		<title>SlackWiki - User contributions [en]</title>
		<link>https://www.slackwiki.com/Special:Contributions/Dijetlo</link>
		<description>User contributions</description>
		<language>en</language>
		<generator>MediaWiki 1.40.0</generator>
		<lastBuildDate>Wed, 08 Apr 2026 11:20:36 GMT</lastBuildDate>
		<item>
			<title>Talk:Broadcom Wireless</title>
			<link>https://www.slackwiki.com/index.php?title=Talk:Broadcom_Wireless&amp;diff=963</link>
			<guid isPermaLink="false">https://www.slackwiki.com/index.php?title=Talk:Broadcom_Wireless&amp;diff=963</guid>
			<description>&lt;p&gt;Dijetlo: /* Issue with ssb as a dependency of the b44 module */ new section&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;I just made a couple of relatively minor edits to the page (20140402):&lt;br /&gt;
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:&lt;br /&gt;
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&lt;br /&gt;
&lt;br /&gt;
== Issue with ssb as a dependency of the b44 module ==&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
The fix was to run sbo packages b43-fwcutter and b43-firmware.&lt;br /&gt;
&lt;br /&gt;
This page is a valuable resource for checking compliance.&lt;br /&gt;
http://linuxwireless.org/en/users/Drivers/b43/&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
Or he might check for b44 at the outset and opt for the sbo packages if it's loaded with ssb as a dependency.&lt;/div&gt;</description>
			<pubDate>Tue, 27 Jan 2015 00:06:24 GMT</pubDate>
			<dc:creator>Dijetlo</dc:creator>
			<comments>https://www.slackwiki.com/Talk:Broadcom_Wireless</comments>
		</item>
</channel></rss>