Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 142560 - ipw3945d does not launch automatically on bootup
Summary: ipw3945d does not launch automatically on bootup
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Christian Heim (RETIRED)
URL:
Whiteboard:
Keywords:
: 153778 159710 (view as bug list)
Depends on:
Blocks: ipw3945-tracker
  Show dependency tree
 
Reported: 2006-08-02 09:06 UTC by Seemant Kulleen (RETIRED)
Modified: 2007-05-31 10:56 UTC (History)
11 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
/etc/init.d/ipw3945d (ipw3945d,286 bytes, text/plain)
2006-12-28 21:27 UTC, D. Travis North
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Seemant Kulleen (RETIRED) gentoo-dev 2006-08-02 09:06:25 UTC
See https://bugs.gentoo.org/show_bug.cgi?id=142518#c4 for the details.
Comment 1 srrijkers 2006-08-02 14:17:22 UTC
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.
Comment 2 Ryan Neufeld 2006-08-13 18:52:42 UTC
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.
Comment 3 Will Briggs 2006-09-07 17:29:57 UTC
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?
Comment 4 Ryan Hill (RETIRED) gentoo-dev 2006-09-08 18:25:00 UTC
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.
Comment 5 Ryan Hill (RETIRED) gentoo-dev 2006-09-09 19:41:50 UTC
starts okay now, but doesn't shut down if you do /etc/init.d/ipw3945 stop.
Comment 6 Cees Koolen 2006-10-17 04:18:20 UTC
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. :-(
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2006-11-02 01:07:15 UTC
*** Bug 153778 has been marked as a duplicate of this bug. ***
Comment 8 D. Travis North 2006-12-28 21:27:35 UTC
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.
Comment 9 Thomas Petersen 2006-12-30 15:28:16 UTC
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.
Comment 10 Christian Heim (RETIRED) gentoo-dev 2007-01-08 20:58:27 UTC
(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.
Comment 11 Christian Heim (RETIRED) gentoo-dev 2007-01-08 20:59:36 UTC
(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.

Comment 12 Christian Heim (RETIRED) gentoo-dev 2007-01-08 21:00:12 UTC
*** Bug 159710 has been marked as a duplicate of this bug. ***