Koen Vermeer wrote: > On Wed, 2005-10-12 at 13:03 -0300, Derek Broughton wrote: >> > Just some additional comments: In my case, with ifplugd running, I >> > cannot even get eth0 down. That is, if I remove the cable, do 'ifconfig >> > eth0 down', eth0 is still UP. Only after stopping ifplugd, I can take >> > eth0 down. >> That seems a little weak. The default setup is supposed to issue 'ifdown >> eth0' when it loses the link beat. What value is there to ifplugd if it >> doesn't notice your cable is unplugged? > > There is a difference between 'ifdown/ifup eth0' and 'ifconfig eth0 > down/up'. I think 'ifconfig eth0 up' puts the network card in an 'up' > state as far as the kernel concerns, while 'ifup eth0' does everything > you tell it to in the /etc/network/interfaces file (such as calling the > dhcp client). So, if the device is still down, ifplugd cannot do > anything with it. It needs to be up, so ifplugd can 'scan' it (with > whatever method you tell it to use). Once the link is detected, ifplugd > calls ifup.
Ah - what you mean is that with ifplugd running, if you do "ifconfig eth0 down", _ifplugd_ still thinks the interface is up. After "ifconfig eth0 down", the interface is definitely _down_. > >> acpi hibernate and reloaded on resume, ifplugd should take the interface >> down when it sees the missing link-beat (which would be right after the >> initial reloading of the module), and bring it up again on it's own. >> Likely there isn't enough up-time between losing the link-beat and >> getting it back for ifplugd to notice it's gone - ime, ifplugd is fairly >> slow to >> react. I find that when I unplug the laptop, take it down the hall to >> the >> conference room, and plug it back in, ifplugd works fine. It's when I >> want it to react within 20 or 30 seconds (which is about the observed >> time it experiences between hibernate & resume) that it gets confused. > > ifplugd may not notice a missing link at all. It's like falling to sleep > and waking up at a different place. If you don't know you were sleeping, > you're pretty confused when you open your eyes in a different > environment. This also happens to the network config. So, the interfaces > should be reconfigured after resuming. > > But more importantly: I don't find ifplugd slow, so that again points at > the b44 driver... In my case, it detects (the loss of) the link-beat > nearly instantaneously. After that, it waits the specified number of > seconds before actually (de)configuring the network device. > > You mentioned that ifplugd requires mii-tool. AFAIK, that's not correct; > you can specify the method of link-beat detection, and one of them is > mii-tool. Maybe it's just a matter of configuring ifplugd. I'm not > saying it is, I'm only saying it may be. :-) Oh?? Interesting. It's not anywhere in the /etc/defaults/ifplugd or the debconf configuration, or the man page. However, you're right - it _doesn't_ have a dependency on mii-tool, and implies that there's more than one way to tell... > >> It's not so much "before", as when I start a shutdown, and then pull the >> cable before it gets to shutting down ifplugd. It was actually something >> in /etc/init.d/networking (unmount samba shares??) that was preventing >> ifplugd from closing the interface. As long as I either shut down with >> the cable still connected, or remove the cable far enough in advance to >> let ifplugd get the interface down before it gets to ".../networking >> stop", all is well. > > I can imaging that both ifplugd and /etc/init.d/whatever are trying to > do things, but I don't see why it freezes your system. I've never seen > that behaviour, and I do remove the network cable during shutdown. It's not strictly a freeze - there's a timeout period reached at some point. -- derek -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
