From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Dan Nicholson" Date: Mon, 23 Apr 2007 23:02:03 +0000 Subject: Re: udev rule does not assign eth0 to ipw3945 device Message-Id: <91705d080704231602h3d7cab75pff110006dfa5dbaf@mail.gmail.com> List-Id: References: <9b53a56d0704221004l77858a10t409ea96566f38094@mail.gmail.com> In-Reply-To: <9b53a56d0704221004l77858a10t409ea96566f38094@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: linux-hotplug@vger.kernel.org On 4/23/07, Bryan Kadzban wrote: > Chris Smith wrote: > > Bryan Kadzban kadzban.is-a-geek.net> writes: > > > >> What about /sys/class/net/*? (And note that it may not be eth*, it > >> may be wifi*/wlan*, or even something different. Look in > >> /sys/class/net.) > > > > Only thing in there is lo > > OK, I've seen that when firmware isn't getting loaded (using a Broadcom > card with the native (not ndiswrapper) driver), and again when the > mini-PCI device for that card didn't get discovered at all (the machine > had a flaky mainboard; about every other boot the NIC wouldn't show up). > > Based on what you said below, it's probably the firmware. :-) I have an ipw3945, so I can probably add some info here. The firmware loads fine by the kernel so long as you have an appropriate udev rule. The pain for me was always getting the daemon running and not having udev think it's an error. There are two reasons, that I could tell: 1. ipw3945d wants to create a pid file in /var/run/ipw3945d.pid so it can track it's state. However, during early boot this may not be writable and so the daemon bombs. Right now I'm invoking it with --pid-file=/dev/null to work around that, but it's a crappy solution. It should just fail and then when udevtrigger is run again after the / is remounted rw, it will retry this event. It never does for me, but it's probably a bug in my udev rule. SUBSYSTEM="drivers", ACTION="add", DEVPATH="/bus/pci/drivers/ipw3945", RUN+="ipw3945d.sh start" 2. I might be wrong here, but ipw3945d will return output on stderr when it's invoked. RUN seems to interpret this as an error. Invoking ipw3945d with --quiet suppresses that output, but I've always meant to see if I could just redirect the output to stdout. Anyway, I hope that helps. I spent days pulling my hair out trying to figure out why things weren't working without resorting to horrible hacks. I'd check in /dev/.udev/failed to see if the event is making it through successfully. Hmm, you may have inspired me to try to resolve my own issues now. -- Dan ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net Linux-hotplug-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel