Description of Problem: When card is plugged in, I see an error message in /var/log/messages saying no driver is available (not true, driver has been loaded). Then DHCP fails to kick in and i/f is left unconfigured i.e. with no IP address. Version-Release number of selected component (if applicable): [bill@marcus bill]$ rpm -q kernel-pcmcia-cs hotplug kernel-pcmcia-cs-3.1.27-12 hotplug-2002_01_14-2 Log attached in a sec.
Created attachment 49824 [details] Extracts from /var/log/messages
This is Dell Latitude "CPi R series" if that's any help. I did a clean install (over FTP using the same Xircom card). This worked near-perfectly with 7.2, so something broke. IIRC I saw similar warnings in the log with Enigma, but it worked anyway.
I have the same card AND problem as yours. The following two commands provide a temp solution. With the card hot plugged in, type: cardctl eject 0 cardctl insert 0 ,where 0 the PCMCIA socket number (first slot is 0, second is 1).
I can bring up the interface by typing "ifup eth0" ... it's just annoying that it doesn't come back when I wake the thing up again. I've also noticed that sometimes resuming seems to hang with a blank screen if I've unplugged the card, and the machine will wake up again if I plug the card in. To clarify my earlier statement: under Enigma, I still saw the warnings about a "missing driver" but immediately afterward the DHCP would kick in and the interface came back up. This doesn't happen with the current install, and from testing seems to have been broken in Raw Hide for a while.
Ooh look, my bug blocks bug #61590 ... what is bug #61590? I can't read it!
*** Bug 61557 has been marked as a duplicate of this bug. ***
*** Bug 61661 has been marked as a duplicate of this bug. ***
*** Bug 61730 has been marked as a duplicate of this bug. ***
*** Bug 61706 has been marked as a duplicate of this bug. ***
Whee, this is fun. grep changed in 2.5 to try and detect failures of flushing/closing stdout, and act accordingly. However, when it's run from network-functions via hotplug, it has *no* stdout (its only fd is stdin). The new behavior flags this as an error, causing the grep to fail, causing ifup to think the device isn't there. Since '-q' is defined to not write anything to stdout, I don't think it should care if trying to flush or close stdout failsin this case - fixed with the attached patch.
Created attachment 50404 [details] patch so grep ignores failures of closing stdout when called with '-q'
Thanks, that fixes it
Are we supposed to see that "Status Whiteboard" comment? Or is "Hampton" a working title like "Blue Harvest" ?
Also, will this fix the init order issue? AFAICS, this still won't allow ntpd to start up properly (as there won't be an interface there until "pcmcia" service starts up).
*** Bug 48141 has been marked as a duplicate of this bug. ***
Fixed in grep-2.5.1-1
*** Bug 62222 has been marked as a duplicate of this bug. ***
*** Bug 62254 has been marked as a duplicate of this bug. ***
*** Bug 62608 has been marked as a duplicate of this bug. ***
*** Bug 63596 has been marked as a duplicate of this bug. ***