First off, the modules added to /etc/modules.autoload will not load on boot at Nazgul's machine (he's on #gentoo from time to time). Secondly, cardmgr does not create a pid file in /var/run; it does so when I start it manually, but not from the pcmcia script that's part of pcmcia-cs-3.1.33-r2, thus the cardmgr will not unload when we run pcmcia stop. Thirdly, but this is probably not our fault. The kernel modules' "Used by" counts are completely wrong: orinoco 32640 0 (unused) hermes 3520 0 [orinoco] tulip_cb 32192 2 cb_enabler 2560 3 [tulip_cb] ds 6624 2 [cb_enabler] i82365 22672 2 pcmcia_core 47968 0 [cb_enabler ds i82365] In this case, the tulip_cb is actually used by one, not two programs, so unloading it is impossible.
Nazgul is reachable at madill@inreach.com. Also, we must update the installation guide. Upgraded to blocker because of this.
I need more than this. /var/run/cardmgr.pid is created just fine for me. The problem may be that cardmgr is not starting correctly. The modules problem is certainly not our fault. Feel free to report a bug to the module maintainers. As for the modules not loading at boot, that is probably the real problem here. I suggest searching the web to make sure you are loading the correct drivers. Also need to make sure that if you are using pcmcia-cs drivers that pcmcia-cs is emerged after kernel installation. If not using pcmcia-cs driver, then make you are loading yenta_socket and not i82365. For further debugging, here is what I will need: - output of dmesg after booting - log output showing cardmgr's output - exact network card - init script - /etc/init.d/pcmcia - /etc/modules.autoload feel free to e-mail these to chadh@gentoo.org. I won't be able to get to it for a few days, though.
and this is the first problem that I have heard of, so I would hardly call that "numerous".
The pid file wasn't created because the pcmcia script sent -f to cardmgr. This seems to have been fixed, but the ChangeLog does not make any mention of it.
The Changelog describes both why the -f is there in some scripts and why I removed it from the script (although it is the default in /etc/conf.d/pcmcia). I don't know why the -f was keeping cardmgr.pid from being created, except that cardmgr was not initializing correctly, which means a configuration error, not a problem with the init scripts.
Which changelog are you referring to ? The sys-apps/pcmcia-cs/ChangeLog file does not contain any useful info on this.
yes. sys-apps/pcmcia-cs/Changelog: *pcmcia-cs-3.1.31-r4 (14 Mar 2002) 14 Mar 2002; Chad Huneycutt <chadh@gentoo.org>: many fixes: 1. added USE variables for trusted apps, apm, cardbus, and pnp 2. updated init script to die slightly more gracefully when cardmgr cannot start 3. changed configuration settings for init script (previously /etc/pcmcia.conf) to install instead to /etc/conf.d as the Gentoo-specific config 4. Undid drobbins "-f" fix below, as it is not a very good default behavior, if , say, cardmgr starts dhcpcd, which can take a while to obtain information. There is a CARDMGR_OPTS variable in /etc/conf.d/pcmcia where users can specify this if they want. 5. I also put hermes.conf in ${FILESDIR}, but I am not installing it, as it causes cardmgr to choose the orinoco_cs driver over wvlan_cs, which may not be what the user wants. It is documented pretty well that it must be downloaded, so I think it is safe to leave it out. *pcmcia-cs-3.1.31-r3 (05 Mar 2002) 05 Mar 2002; Daniel Robbins <drobbins@gentoo.org>: properly install the pcmcia rc script into /etc/init.d; add -f option to cardmgr so that it stays in the foreground until it's done doing its thing. This ensures that any network interfaces are set up after it detaches. This closes bug #972.
I'm closing this one, as the more recent versions of pcmcia-cs have improved drastically (especially with the new orinoco driver). Also, upgrading baselayout is a necessity if the pcmcia-cs is to work, but I think that's been done by most of our users now anyway.