RE: connecting two hosts with crossover cable and autonegotiation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> -----Original Message-----
> From: linux-net-owner@xxxxxxxxxxxxxxx 
> [mailto:linux-net-owner@xxxxxxxxxxxxxxx] On Behalf Of Matt Zagrabelny
> Sent: Wednesday, May 28, 2008 2:45 PM
> To: linux-net@xxxxxxxxxxxxxxx
> Subject: connecting two hosts with crossover cable and autonegotiation
> 
> Greetings,
> 
> I am working on creating a GNU/Linux HA cluster and have a (non-gig)
> crossover cable connecting eth2 on both nodes. The question I have is
> how do cards like this auto-negotiate. They are negotiating to 10/half
> whereas I would expect them to negotiate to 100/full.
> 
> Some details:
> 
> Debian GNU/Linux Etch
> # uname -a
> Linux squash 2.6.18-6-686 #1 SMP Thu May 8 07:34:27 UTC 2008 i686
> GNU/Linux
> 
> 
> The NICs on both nodes are 3Com 10/100:
> 
> Ethernet controller: 3Com Corporation 3c905C-TX/TX-M 
> [Tornado] (rev 6c)
> Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management
> NIC
> 
> Here are the results of 'mii-tool'.
> 
> node1# mii-tool -v eth2
> eth2: no autonegotiation, 10baseT-HD, link ok
>   product info: vendor 00:10:18, model 23 rev 4
>   basic mode:   autonegotiation enabled
>   basic status: autonegotiation complete, link ok
>   capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>   advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> flow-control
>   link partner: 10baseT-HD
> 
> node2# mii-tool -v eth2
> eth2: link ok
>   product info: vendor 00:10:18, model 23 rev 4
>   basic mode:   autonegotiation enabled
>   basic status: link ok
>   capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>   advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> flow-control
> 
> 
> Here are the results of 'mii-diag'.
> 
> node1# mii-diag eth2
> Basic registers of MII PHY #24:  3000 782d 0040 6174 05e1 0021 0000
> 0000.
>  Basic mode control register 0x3000: Auto-negotiation enabled.
>  You have link beat, and everything is working OK.
>  Your link partner is generating 10baseT link beat  (no
> autonegotiation).
>    End of basic transceiver information.
> 
> node2# mii-diag eth2
> Basic registers of MII PHY #24:  3000 780d 0040 6174 05e1 0000 0000
> 0000.
>  Basic mode control register 0x3000: Auto-negotiation enabled.
>  You have link beat, and everything is working OK.
>  Your link partner does not do autonegotiation, and this transceiver
> type
>   does not report the sensed link speed.
>    End of basic transceiver information.
> 
> So why are the results of 'mii-tool' and 'mii-diag' different (I would
> expect the same)?
> 
> Is it possible for these types of cards to autonegotiate to 100/full?
> How?
> 
> TIA,
> 
> -- 
> Matt Zagrabelny - mzagrabe@xxxxxxxxx - (218) 726 8844
> University of Minnesota Duluth
> Information Technology Systems & Services
> PGP key 1024D/84E22DA2 2005-11-07
> Fingerprint: 78F9 18B3 EF58 56F5 FC85  C5CA 53E7 887F 84E2 2DA2
> 
> He is not a fool who gives up what he cannot keep to gain 
> what he cannot
> lose.
> -Jim Elliot
> 

FYI, mii-tool -vvv eth2 will dump more of the PHY register values (at
least on the version of mii-tool that I use, which is admitted rather
old). That can be useful if you can get a copy of the particular PHY's
data sheet. The contents of PHY registers beyond the first 7 are
manufacturer specific, but they often have the more interesting data in
them. The contents of the first 7 are supposed to be standard and are
defined in one of the IEEE docs, though some manufacturers, e.g.
Marvell, don't even implement those first 7 right.

The 782d in the status register of one indicates that the PHY completed
the autonegotiation sequence (bit 5 on). The 780d in the other indicates
that PHY did not. They both report they got link.

With 10/100 Base-T, the NLP pulses that are used to indicate link are
encoded to carry 4 bits that indicate which modes of operation that
device is willing to autonegotiate to. So it looks like one peer
received and interpreted the coded pulses ("FLP"s or "Fast Link Pulses"
is the term, I believe) whereas the other peer saw only unencoded NLPs.
This is all pretty low level, OSI layer 1 stuff.

You might have a bad PHY. You might have a bad cable. If you flip the
cable around, does the output of mii-tool on the two ports flip around
too? If so, suspect the cable since that would happen if one of the
twisted pairs was bad.

A lot of the recent PHYs implement auto-crossover that works so long as
autonegotiation is enabled, which by the 3000s in the control registers
was enabled on both PHYs. You might want to try connecting them with a
non-crossover cable to see if anything changes.

Jeff Haran
The opinions expressed here are mine and not those of my employer.
--
To unsubscribe from this list: send the line "unsubscribe linux-net" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Netdev]     [Ethernet Bridging]     [Linux 802.1Q VLAN]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Git]     [Bugtraq]     [Yosemite News and Information]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux PCI]     [Linux Admin]     [Samba]

  Powered by Linux