[tulip] netgear's fa310-tx and d-link switch
Karl Hammar
karl@kalle.csb.ki.se
Mon, 11 Dec 2000 23:24:15 +0100
[ Please don't cc me, I'm on the list ]
Regarding Jaap Brinks problem.
Something stops the card, but what?
The only clues I have so far is:
1, the switch support flow-control, can that be a problem
Don't think so, my mii-diag output says the same and I don't yet
have any problems with tulip v0.92.
2, the nic might have full buffers and there is nothing that helps
it empty them, could it be an irq conflict thing.
Well, it worked with 10BaseT, so that should not be it.
I append a discussion below.
Regards,
/Karl
-----------------------------------------------------------------------
Karl Hammar Aspö Data karl@kalle.csb.ki.se
Lilla Aspö 2340 +46 173 140 57 Networks
S-742 94 Östhammar +46 70 511 97 84 Computers
Sweden Consulting
-----------------------------------------------------------------------
Let's see if I get this right. This I found out by reading mii-diag.c,
libmii.c and http://www.scyld.com/diag/mii-status.html.
Start with the ./mii-diag output, your register output is
Basic registers of MII PHY #1: 3000 782d 0040 6212 01e1 45e1 0003 0000
reg 0: bit 0x2000 set, i.e. autonegation enabled
reg 1: 78*d is good value according to mii-status.html
reg 2 and 3 is
0 0 4 0 6 2 1 2
00000000010000000110001000010010
add two zero bits from the left and split as below, it becomes:
000000000001000000011000 100001 0010
0 0 1 0 1 8 2 1 2
\--------- oui --------/ model rev
$ wget http://standards.ieee.org/regauth/oui/oui.txt
$ grep -A5 ^00-10-18 oui.txt
00-10-18 (hex) BROADCOM CORPORATION
001018 (base 16) BROADCOM CORPORATION
16215 ALTON PARKWAY
P.O. BOX 57013
IRVINE CA 92619-7013
so it is a broadcom tranceiver (im I right?) but then
> eth0: Lite-On 82c168 PNIC rev 32 at 0xf800, 00:A0:CC:65:B9:99, IRQ 11.
$ grep -A4 -i 00-A0-CC oui.txt
00-A0-CC (hex) LITE-ON COMMUNICATIONS, INC.
00A0CC (base 16) LITE-ON COMMUNICATIONS, INC.
720 S. HILLVIEW DRIVE
MILPITAS CA 95035
so the chip maker has set the ethernet address to one in its own
range. And the card maker is a third company.
That should not be any problems I hope.
reg 4 (01e1), you got:
0x0100 100baseTx-FD supported
0x0080 100baseTx supported
0x0040 10baseT-FD supported
0x0020 10baseT supported
0x001F Protocol selection bits, always 0x0001 for Ethernet.
which looks good.
reg 5 (45e1), you got:
0x4000 Link partner got our advertised abilities.
0x0400 Flow control supported (currently uncommon)
0x0100 100baseTx-FD (full duplex) supported
0x0080 100baseTx supported
0x0040 10baseT-FD supported
0x0020 10baseT supported
0x001F Protocol selection bits, always 0x0001 for Ethernet.
which looks good,
except that I don't know about the flow control thing
Note!
Even if booth sides of a cable agree (done at low speed) about link
capabilities, they don't check cables and such, so when the traffic
starts you could get a lot of link errors due to faulty cables,
patch panels and such.
Next, tulip-diag's output which I cannot yet fully desciphre, but
it says that both the Rx and Tx process is in 'Stopped' state.
Is it anybody on this list who knows what can stop them. My guess
for the Rx process is that something in the kernel don't want to
receive anything anymore, for the Tx process is that it somehow don't
have contact with sending functions on the nic, but just disconnecting
the cable don't trigger that.
Is it anyone who knows anything about the (from mii-diag) reported
flowcontrol support?
------------------------------------------------------------------------
From: Jaap Brink <brink@tiger.3dem.bioch.bcm.tmc.edu>
Subject: Re: [tulip] netgear's fa310-tx and d-link switch
Date: Sun, 10 Dec 2000 16:53:49 -0600 (CST)
>
> Dear Karl (and others reading this):
>
> I've done some more checking and am still very confused. But, I tried to
> do my homework, so here's the wrap on the story. My linux box masquarades
> for my home network. It has a cheetah (rtl8193) and netgear (tulip).
> Heres the info from the boot detection:
>
> > eth0: Lite-On 82c168 PNIC rev 32 at 0xf800, 00:A0:CC:65:B9:99, IRQ 11.
> > eth0: MII transceiver #1 config 3000 status 782d advertising 01e1.
>
> Plugged this nic into a 10/100 switch (dlink dss8+) and verified that both
> nic and switch are in full-duplex. Here's what tulip-diag and mii-diag
> report:
>
> host>./tulip-diag
> tulip-diag.c:v2.04 9/26/2000 Donald Becker (becker@scyld.com)
> http://www.scyld.com/diag/index.html
> Index #1: Found a Lite-On 82c168 PNIC adapter at 0xf800.
> Lite-On 82c168 PNIC chip registers at 0xf800:
> 00008000 01ff0000 00000000 00951810 00951a10 02000112 814c0200 00000000
> 00000000 00000000 00951ac0 01200a30 00000020 00000000 00000000 10000001
> 00000000 00000000 f0041385 000000bf 6086782d 00951810 00838010 0201f178
> 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> Port selection is MII, full-duplex.
> Transmit stopped, Receive stopped, full-duplex.
> The Rx process state is 'Stopped'.
> The Tx process state is 'Stopped'.
> The transmit threshold is 72.
>
> host>./mi-diag
> Basic registers of MII PHY #1: 3000 782d 0040 6212 01e1 45e1 0003 0000.
> Basic mode control register 0x3000: Auto-negotiation enabled.
> You have link beat, and everything is working OK.
> Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx
> 10baseT-FD 10baseT, w/ 802.3X flow control.
>
> Problem was that this linux box couldn't see the home network. It could
> still see the cable connection. So, I thought perhaps the nic in one of
> the machine it failed to see was in half-duplex? Well, this is what
> rtl8139-diag reported:
>
> host>./rtl8139-diag
> rtl8139-diag.c:v2.00 4/19/2000 Donald Becker (becker@scyld.com)
> http://www.scyld.com/diag/index.html
> Index #1: Found a SMC1211TX EZCard 10/100 (RealTek RTL8139) adapter at
> 0xcc00.
> The RealTek chip appears to be active, so some registers will not be read.
> To see all register values use the '-f' flag.
> RealTek chip registers at 0xcc00
> 0x000: 06b51000 0000a7f7 00000000 00000000 00002000 00002000 00002000
> 00002000
> 0x020: 06896000 06896600 06896c00 06897200 06780000 0d000000 0000fff0
> 0000c07f
> 0x040: 73000400 00009c0e ec78f23d 00000000 006c1000 00000000 0000c180
> 00100000
> 0x060: 1100000f 05e1782d 000145e1 00000001 00000004 000307c8 78fa8388
> a538de43.
> No interrupt sources are pending.
> The chip configuration is 0x10 0x6c, MII full-duplex mode.
> EEPROM size test returned 6, 0x204a4 / 0x2.
>
>
>
> As you can see, both ends of the chain are in full-duplex. I've tried
> several different nics in my linux box, plus different cable
> runs. Everything to no avail. Could it be that the switch not in full
> duplex? Seems to make little sense to me, but nothing right now has ;-)
>
>
> Jaap
...