Re: whereami, hibernate & ifconfig
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
Reply to: