whereami, hibernate & ifconfig - Debian

This is a discussion on whereami, hibernate & ifconfig - Debian ; When my broadcom (b44) ethernet interface is first activated, it seems to take some time to settle down - it often gives messages like: [5062528.574000] NETDEV WATCHDOG: eth0: transmit timed out [5062528.574000] b44: eth0: transmit timed out, resetting Hibernating the ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: whereami, hibernate & ifconfig

  1. whereami, hibernate & ifconfig

    When my broadcom (b44) ethernet interface is first activated, it seems to
    take some time to settle down - it often gives messages like:
    [5062528.574000] NETDEV WATCHDOG: eth0: transmit timed out
    [5062528.574000] b44: eth0: transmit timed out, resetting

    Hibernating the Dell 6000 laptop works fine, both my eth0 (b44) and eth1
    (ipw2200 wireless) interfaces are taken down. On resume, the modules are
    loaded and whereami runs but almost inevitably doesn't find eth0 and tries
    to connect wirelessly. Simply running whereami again never works, because
    the "testmii" script in whereami does "ifconfig eth0 down" when it's
    unsuccessful, then future whereamis won't even try eth0 until I do
    "ifconfig eth0 up".

    I'm not sure what the best solution to fix this is. I'd rather not hack the
    whereami scripts unless I felt I was doing something worth submitting a
    patch for. I could probably do "ifconfig eth0 up" as a last step from
    whereami, so that a future invocation could at least test it.

    There doesn't seem to be a way to force the interface up _before_ starting
    the whereami's detection (which probably wouldn't help anyway, as the first
    time it _is_ coming up, it just isn't there when I need it).

    I might stick something in /etc/default/acpi-support to lengthen the time
    before whereami gets invoked (I added whereami to STOP_SERVICES), but that
    seems a bit dicey.

    Any ideas? (Please don't suggest some other network detection scheme - the
    problem is not whereami, it's the fact that the interface needs time to
    settle down before it can be tested, and that's going to be the same no
    matter what detection method I use).
    --
    derek


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  2. Re: whereami, hibernate & ifconfig

    On Tue, 2005-10-11 at 16:15 -0300, Derek Broughton wrote:
    > Any ideas? (Please don't suggest some other network detection scheme - the
    > problem is not whereami, it's the fact that the interface needs time to
    > settle down before it can be tested, and that's going to be the same no
    > matter what detection method I use).


    Two comments:
    - There are more people experiencing the timeout problem with b44. I
    don't know if there is a solution, but search for 'b44 transmit timed
    out' and maybe you'll find a solution.
    - You might leave some more room for people to help you. IMHO, it's the
    combination of a buggy b44 and the way whereami works that bites you.
    There may be other 'network detection schemes' that will work even with
    the b44 problems. I would suggest ifplugd, but I'm not, because I think
    it's what you call a 'network detection scheme'.

    Koen


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  3. Re: whereami, hibernate & ifconfig

    Koen Vermeer wrote:

    > On Tue, 2005-10-11 at 16:15 -0300, Derek Broughton wrote:
    >> Any ideas? (Please don't suggest some other network detection scheme -
    >> the problem is not whereami, it's the fact that the interface needs time
    >> to settle down before it can be tested, and that's going to be the same
    >> no matter what detection method I use).

    >
    > Two comments:
    > - There are more people experiencing the timeout problem with b44. I
    > don't know if there is a solution, but search for 'b44 transmit timed
    > out' and maybe you'll find a solution.


    Oh s**t! Of course, I really should have looked to see if there's a fix for
    the _underlying_ problem.

    > - You might leave some more room for people to help you. IMHO, it's the
    > combination of a buggy b44 and the way whereami works that bites you.


    I think you're wrong but even if not, I've invested too much time in making
    whereami work the way I want to want to do all this all over again with a
    completely different scheme. In any case, after watching this and other
    lists for years, it's clear that 'whereami' has the _best_ support from its
    developer (I already have a fix from Andrew [1], thanks).

    > There may be other 'network detection schemes' that will work even with
    > the b44 problems.


    > I would suggest ifplugd, but I'm not, because I think
    > it's what you call a 'network detection scheme'.


    I've got no problem with a solution that doesn't prevent me using whereami -
    I just don't want to get into something that requires me to completely redo
    what I did for whereami.

    afaict, ifplugd doesn't help, but that might be because of whereami's
    action. I have ifplugd. However, ifplugd requires mii-tool, and mii-tool
    requires the link to be configured (and the link isn't configured because
    whereami took it down again).

    Perhaps, as I suggested in my first post, all I need is to "ifconfig eth0
    up" as the last step in whereami. Then ifplugd might eventually catch the
    link-status change and bring up the link. However, ime, ifplugd hasn't
    been doing a very good job. If ifplugd was really working, I shouldn't
    even need to run whereami from the resume script - ifplugd should run it
    when the link comes up. I'll look at ifplugd again, but what I've been
    seeing is that it sees the link-beat, tries to bring up the interface, then
    I get the b44 timeout and it takes down the interface. Eventually it's
    successful but it takes quite a while. (Incidentally, I've also had
    ifplugd completely freeze my laptop for somewhere around 10 minutes if I
    make the mistake of removing the ethernet cable immediately _before_
    shutting down the computer).

    Thanks for your suggestions. I _will_ look deeper into ifplugd but I won't
    be ditching whereami :-)

    [1] Andrew Macmillan's solution, which doesn't appear to have been cc'd to
    the list was to add the following to the whereami detect.conf:
    > # Always sleep 5 (with dummy location)
    > always sleep 5 dummy
    >
    > # Test for the presence of an ethernet connection plugged into eth0
    > testmii eth0 lan


    I hadn't figured out how to force an arbitrary command to execute in the
    detect script.
    --
    derek


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  4. Re: whereami, hibernate & ifconfig

    Hi Derek,

    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.

    Additionally, I restart ifplugd on resume, because otherwise the network
    would still be in its old state after resuming (meaning an incorrect IP
    address or something like that). Restarting ifplugd fixed that. (I see
    there is also a SUSPEND_ACTION in /etc/default/ifplugd, but I don't know
    in which way that is used.)

    It's strange that ifplugd freezes the laptop if you remove the cable
    before shutting down. I'm still thinking on how to explain that.

    Koen


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  5. Re: whereami, hibernate & ifconfig

    Koen Vermeer wrote:

    > Hi Derek,
    >
    > 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?

    > Additionally, I restart ifplugd on resume, because otherwise the network
    > would still be in its old state after resuming (meaning an incorrect IP
    > address or something like that). Restarting ifplugd fixed that. (I see
    > there is also a SUSPEND_ACTION in /etc/default/ifplugd, but I don't know
    > in which way that is used.)


    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
    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.
    >
    > It's strange that ifplugd freezes the laptop if you remove the cable
    > before shutting down. I'm still thinking on how to explain that.


    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.
    --
    derek


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  6. 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


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  7. Re: [debian] Re: whereami, hibernate & ifconfig

    > ... (Incidentally, I've also had
    > ifplugd completely freeze my laptop for somewhere around 10 minutes if I
    > make the mistake of removing the ethernet cable immediately _before_
    > shutting down the computer)....


    Hi.

    I also use a Dell with a b44 chip (mine's an Insprion 8600).

    After a couple years of running well, except for taking 10
    seconds to settle down, it started to give me errors on the
    console (something about interrupts) and then freezing the
    machine would hard-lock after a few minutes.

    Thinking there was some issue with the kernel I'd installed,
    I tried going back to a 2.4 kernel, and then thinking there
    was some issue with having recently dist-upgraded to sid,
    etc., I reinstalled, which turned out to be dumb, because
    even having gone back, it still started giving me errors and
    locking up, *but only when the ethernet cable was plugged in*.

    Aha! So I dug out my old PCMCIA ethernet cards and USB
    ethernet adapter, went through them to find the ones that
    still worked, and am back in business. I'll send the laptop
    in for Dell to fix it some day before my extended warranty
    expires, but for now it would be very hard to live without
    its 150dpi display.

    So, anyhow, the moral of the story is this:

    Don't be too quick to blame software.

    T



    PS: I used to use whereami too, but went back to a
    config based on /network/interfaces and a little custom
    mapping script. which, by the way, let me put a timeout
    for the b44 to settle down. And it's based on
    iputils-arping, which is lightning fast when it detects...

    arping -D -f -c4 -w5 -I$iface $ip

    ....and works without coming up on the network with an ip
    address (i.e. it's less disruptive).


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  8. 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


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  9. Re: [debian] Re: whereami, hibernate & ifconfig

    Tony Godshall wrote:
    >
    > So, anyhow, the moral of the story is this:
    >
    > Don't be too quick to blame software.


    I'm not quite sure where that moral was to be found :-) After all, we've
    already agreed that there's a basic problem with the b44 - whether it's the
    driver software or the hardware is hard to say - but it's how the software
    deals with that that's causing my issues.
    >
    > PS: I used to use whereami too, but went back to a
    > config based on /network/interfaces and a little custom
    > mapping script. which, by the way, let me put a timeout
    > for the b44 to settle down. And it's based on
    > iputils-arping, which is lightning fast when it detects...
    >
    > arping -D -f -c4 -w5 -I$iface $ip
    >
    > ...and works without coming up on the network with an ip
    > address (i.e. it's less disruptive).


    There's an arping test in Whereami, too, which I primarily use for exactly
    that reason.
    --
    derek


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  10. Re: whereami, hibernate & ifconfig

    On Wed, 2005-10-12 at 19:26 -0300, Derek Broughton wrote:
    > 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_.


    No, if ifplugd is running and you run a 'ifconfig eth0 down' command,
    then normally the interface is still UP. ifplugd does that. You can tell
    it not to. For more information, see FAQ #3 on the ifplugd site. I
    haven't checked to see if with my driver, ifplugd functions without this
    'auto-UP' feature. [...] I just checked, and it doesn't work with my
    driver (tg3) if the interface isn't UP.

    > > 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...


    That's why I said I think the packaging is not that mature :-) But it is
    on the man page. Look at the -m option. By default, it doesn't use mii.

    Koen


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  11. Re: [debian] Re: whereami, hibernate & ifconfig

    Don't know if this has been mentioned since I can't find all the thread,
    why not compile the bcm4400 module using module-assistant and use it
    instead of the opensource b44 module since it is causing problems? I
    have used it several times on different machines. I prefer opensource
    drivers but when you really need something to work.....


    On Wed, 2005-10-12 at 19:18 -0300, Derek Broughton wrote:

    > Tony Godshall wrote:
    > >
    > > So, anyhow, the moral of the story is this:
    > >
    > > Don't be too quick to blame software.

    >
    > I'm not quite sure where that moral was to be found :-) After all, we've
    > already agreed that there's a basic problem with the b44 - whether it's the
    > driver software or the hardware is hard to say - but it's how the software
    > deals with that that's causing my issues.


    Different driver may help here.

    > >
    > > PS: I used to use whereami too, but went back to a
    > > config based on /network/interfaces and a little custom
    > > mapping script. which, by the way, let me put a timeout
    > > for the b44 to settle down. And it's based on
    > > iputils-arping, which is lightning fast when it detects...
    > >


    I always use /etc/network/interfaces. Have not had problems other the
    WPA-PSK wireless security not supported directly.

    > > arping -D -f -c4 -w5 -I$iface $ip
    > >
    > > ...and works without coming up on the network with an ip
    > > address (i.e. it's less disruptive).

    >
    > There's an arping test in Whereami, too, which I primarily use for exactly
    > that reason.
    > --
    > derek
    >
    >



  12. Re: whereami, hibernate & ifconfig

    Koen Vermeer wrote:

    > On Wed, 2005-10-12 at 19:26 -0300, Derek Broughton wrote:
    >> 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_.

    >
    > No, if ifplugd is running and you run a 'ifconfig eth0 down' command,
    > then normally the interface is still UP.


    Not on my system... if I "ifconfig eth0 down", it goes down and stays down.
    ifplugd will start the system beeping at me as it gains and loses link
    beat, but once the b44 stabilizes, it never runs dhclient again. I can't
    tell if it's something be misconfigured in ifplugd or another conflict with
    the b44 problem or just that by taking the link down physically without
    changing the ifupdown status ifplugd just refuses to do anything more.

    > ifplugd does that. You can tell
    > it not to. For more information, see FAQ #3 on the ifplugd site.


    I'm off to check it...

    [regarding non-dependency on mii-tool]

    > That's why I said I think the packaging is not that mature :-) But it is
    > on the man page. Look at the -m option. By default, it doesn't use mii.


    Thanks. I can't see how I missed that. My interpretation is different to
    yours though - by default it will use _all_ of the possible tools until one
    works - in no specified order. It actually seems to use ethtool first in
    my case, at least sometimes.
    --
    derek


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  13. Re: whereami, hibernate & ifconfig

    On Thu, 2005-10-13 at 11:23 -0300, Derek Broughton wrote:
    > Not on my system... if I "ifconfig eth0 down", it goes down and stays down.
    > ifplugd will start the system beeping at me as it gains and loses link
    > beat, but once the b44 stabilizes, it never runs dhclient again. I can't
    > tell if it's something be misconfigured in ifplugd or another conflict with
    > the b44 problem or just that by taking the link down physically without
    > changing the ifupdown status ifplugd just refuses to do anything more.


    Just for reference, could you give me the list of options that is passed
    to your ifplugd for that interface? In my case, it's '-i eth0 -q -f -u0
    -d2 -I -b'.

    > > ifplugd does that. You can tell
    > > it not to. For more information, see FAQ #3 on the ifplugd site.

    > I'm off to check it...


    Back already? :-)

    > Thanks. I can't see how I missed that. My interpretation is different to
    > yours though - by default it will use _all_ of the possible tools until one
    > works - in no specified order. It actually seems to use ethtool first in
    > my case, at least sometimes.


    You're right, it also uses mii. You're also wrong, because judging from
    the source, it calls ethtool, mii, wlan and iff, in that order. priv
    apparently isn't used in auto-mode, as far as I can tell.

    Koen


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  14. Re: [debian] Re: whereami, hibernate & ifconfig

    Robert Goley wrote:

    > Don't know if this has been mentioned since I can't find all the thread,
    > why not compile the bcm4400 module using module-assistant and use it
    > instead of the opensource b44 module since it is causing problems? I
    > have used it several times on different machines. I prefer opensource
    > drivers but when you really need something to work.....


    It hasn't been mentioned, but thanks for the suggestion. I hadn't realized
    there was another option. I prefer "working" to caring about the
    license. :-)
    --
    derek


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

  15. Re: whereami, hibernate & ifconfig

    Koen Vermeer wrote:

    > On Thu, 2005-10-13 at 11:23 -0300, Derek Broughton wrote:
    >> Not on my system... if I "ifconfig eth0 down", it goes down and stays
    >> down. ifplugd will start the system beeping at me as it gains and loses
    >> link
    >> beat, but once the b44 stabilizes, it never runs dhclient again. I can't
    >> tell if it's something be misconfigured in ifplugd or another conflict
    >> with the b44 problem or just that by taking the link down physically
    >> without changing the ifupdown status ifplugd just refuses to do anything
    >> more.

    >
    > Just for reference, could you give me the list of options that is passed
    > to your ifplugd for that interface? In my case, it's '-i eth0 -q -f -u0
    > -d2 -I -b'.
    >

    -i eth0 -f -u0 -d20 -w

    Neither -d value is default (for the program - yours may be the debian
    installed default). I suspect I lengthened mine because of the b44 issues.
    I'd be willing to bet that -q option would eliminate the hang I get
    sometimes on shutdown. I'm sure though that I didn't add the -w - that
    looks like a recipe for problems. I think I'm going to purge and reinstall
    it, to find the real default settings, then play with the different options
    (starting with yours) until I make it work. Obviously it _does_ work for
    you.

    >> > ifplugd does that. You can tell
    >> > it not to. For more information, see FAQ #3 on the ifplugd site.

    >> I'm off to check it...

    >
    > Back already? :-)


    You bet.
    >
    > You're right, it also uses mii. You're also wrong, because judging from
    > the source, it calls ethtool, mii, wlan and iff, in that order. priv
    > apparently isn't used in auto-mode, as far as I can tell.


    Source! That's cheating :-)
    --
    derek


    --
    To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
    with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

+ Reply to Thread