See https://bugs.gentoo.org/show_bug.cgi?id=142518#c4 for the details.
I've done some testing and messing around and I think that, basically, there are three ways of fixing this. 1. Get udev to use modules.conf somehow. I have no idea on how to do this, and one would still be left with #140067. Also, the current system with the modules.d entry runs ipw3945d as root. 2. Get udev to start ipw3945d when ipw3945 is loaded, for instance with a DRIVER rule. The big problem with this is that udev only starts to act if both the ipw3945 module AND ipw3945d are loaded. If the module is loaded without the daemon it acts rather strange, possibly causing this behaviour. It is present in lsmod and shows up in ps -A, yet when I unload it with modprobe -r it says something about it not being present. Without the daemon, the module acts like an empty shell. While one could write an udev rule to start the daemon without any condition, I do not think this would be a great solution. 3. Use an init script. This was apparently also what brix was working on (see http://dev.gentoo.org/~brix/files/overlay/net-wireless/ipw3945d/). While this may seem like the best solution I think there is at least one drawback: I guess the daemon will start to late for RC_PLUG_SERVICES to work.
https://forums.gentoo.org/viewtopic-t-434817-postdays-0-postorder-asc-start-150.html That guy has a much simpler init script that actually works.
I have ipw3945-1.1.0 and ipw3945d-1.7.22-r2 On boot, there is no connectivity. There are no errors in dmesg lsmod indicates ipw3945 is loaded ps ax shows ipw3945d is running However, the only way to get connectivity is to follow seemant's suggestion in http://bugs.gentoo.org/show_bug.cgi?id=142518 and rmmod ipw3945 modprobe ipw3945 both ip3945 and ipw3945d are recent upgrades, and this is when thing stopped working. Am I in the right bug or is this something new?
as noted on the forum thread (page 11), the init script in ipw3945d-1.7.22-r2 works as expected if you remove the --chuid.
starts okay now, but doesn't shut down if you do /etc/init.d/ipw3945 stop.
At my PC when the initial load of the IPW3954 driver succeded, the network will be up before the ipw3945d script will try to reload the driver. The result is that the driver is reloaded from an up eth link. After that I will have to reboot my system to get a working wireless again. :-(
*** Bug 153778 has been marked as a duplicate of this bug. ***
Created attachment 104887 [details] /etc/init.d/ipw3945d (In reply to comment #7) > *** Bug 153778 has been marked as a duplicate of this bug. *** > I found the same problem, but kept noticing an error that stated something along the lines of an invalid command concerning the checking for a PID file. I traced it back to /etc/init.d/ipw3945d, specifically the lines reading: <ul> start-stop-daemon --start --exec /sbin/ipw3945d --pidfile ${PIDFILE} -- \ --pid-file=${PIDFILE} ${ARGS} </ul> Anyhow, I reverted back to an older /etc/inid.d/ipw3945d file and everything works perfectly now. Don't know if this is the solution, but it could help troubleshoot. Attached is the file I'm using now.
I just upgraded to ipw3945d-1.7.22-r4 and now ipw3945d won't start. I found out that the problem is that /var/run/ipw3945d isn't writable by the user ipw3945d. The ebuild says that it is "Fixing ownership of /var/run/ipw3945d" but it doesn't seem to work. I manually had to chown /var/run/ipw3945d to ipw3945d. That fixed the problem for me.
(In reply to comment #9) > I just upgraded to ipw3945d-1.7.22-r4 and now ipw3945d won't start. I found out > that the problem is that /var/run/ipw3945d isn't writable by the user ipw3945d. > The ebuild says that it is "Fixing ownership of /var/run/ipw3945d" but it > doesn't seem to work. I manually had to chown /var/run/ipw3945d to ipw3945d. > That fixed the problem for me. Problem is with fperms / fowners. Looks like they don't behave like they should do. Fixed now to use chown / chmod.
(In reply to comment #10) > Problem is with fperms / fowners. Looks like they don't behave like they should > do. Fixed now to use chown / chmod. Forgot to mention. Sync up in an hour or so and then remerge the package.
*** Bug 159710 has been marked as a duplicate of this bug. ***