Re: whereami, hibernate & ifconfig
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.
> Looking at the file list in the package, it would probably only work with
> APM suspends. In a perfect world, since the driver module gets removed on
It seems so, but it is poorly documented. (I don't blame the ifplugd
author, but it seems that the Debian package is 'less than mature'.)
> 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. :-)
> 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.
Koen
Reply to: