On Wed, Jan 20, 2010 at 7:21 PM, Denis Heidtmann
<denis.heidtm...@gmail.com> wrote:
> On Wed, Jan 20, 2010 at 5:36 PM, Mike Connors <mconno...@gmail.com> wrote:
>> drew wymore wrote:
>>> I think route -n is what I was thinking of. So disregard what I wrote.
>>> Ok .. so next thing I'm thinking of is that the PK5000 according to
>>> the docs I pulled up is 10/100BaseT and since you have a Gigabit NIC,
>>> I'm starting to lean towards a negotiation error of some sort or too
>>> many errored frames.
>> Auto-neg probs would certainly come more into play during bootup. If in fact
>> the PK5000 supports only 10/100BaseT and your onboard NIC is 1000BaseT then I
>> would definitely try disabling auto-neg and forcing speed/dup on your NIC.
>>
>> Here's a good write-up on how to use ethtool to do it.
>>
>> http://www.cyberciti.biz/tips/howto-linux-add-ethtool-duplex-settings-permanent.html
>>
>> I wonder also if you can't replicate the problem by stopping and starting the
>> networking daemon which is akin to rebooting as far as the NIC and tcp/ip 
>> stack is concerned?
>>
>> /etc/init.d/network restart
>>
>> Because if you can this would narrow the problem down to network connection
>> initiation, which points to auto-neg probs...
>>
>
> sudo ethtool eth0
>
> Settings for eth0:
>        Supported ports: [ MII ]
>        Supported link modes:   10baseT/Half 10baseT/Full
>                                100baseT/Half 100baseT/Full
>                                1000baseT/Full
>        Supports auto-negotiation: Yes
>        Advertised link modes:  10baseT/Half 10baseT/Full
>                                100baseT/Half 100baseT/Full
>                                1000baseT/Full
>        Advertised auto-negotiation: Yes
>        Speed: 100Mb/s
>        Duplex: Full
>        Port: MII
>        PHYAD: 3
>        Transceiver: external
>        Auto-negotiation: on
>        Supports Wake-on: g
>        Wake-on: d
>        Link detected: yes
>
> Notice the 1000baseT/full entry under Advertised link modes.  This
> entry is present ONLY when the network is functioning.  It is absent
> when the network is in its failed mode.  Does this support the idea
> that negotiation is a likely source of the problem?

It supports the idea that the card (sorry, controller on the
motherboard) or possible the kernel driver for the card is bad.

>
> I like the idea of trying network restart.  However, I have yet to
> have a change in state (bad->good or good->bad) without powering off
> the computer.   It would be ideal if I could set up a little script to
> performing network restart then ping the modem, then repeat.  That way
> I could exercise the initiation much faster than booting.  If no
> failures are created, then it is on to powering the desktop off.

If you are seeing the list of negotiation rates drop in failed mode
then to be able to
check this while the system is up will require the network to be down
and at least the associated
network driver for the card to be rmmod to allow the driver
initialization to be done again.

To figure out the driver for the card look for eth0 in /etc/modprobe.conf

This is a nice place for a one off script to do the down up test loop.
_______________________________________________
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug

Reply via email to