any easy way to force 10/100 nics to 10?

any easy way to force 10/100 nics to 10?

[Kevin B. Hendricks]

Hi,

My new dsl router seems to hate 100 connections from my 10/100 nics.

Is there an easy way to force 10mb speed (a /proc setting?)?

Thanks,

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: any easy way to force 10/100 nics to 10?

[Jeff Garzik]

"Kevin B. Hendricks" wrote:
>
> Hi,
>
> My new dsl router seems to hate 100 connections from my 10/100 nics.
>
> Is there an easy way to force 10mb speed (a /proc setting?)?

The standard way, in this order, is (a) via ethtool, (b) via mii-tool,
or (c) using a command line option at kernel boot time.

--
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: any easy way to force 10/100 nics to 10?

[Benjamin Herrenschmidt]

>> My new dsl router seems to hate 100 connections from my 10/100 nics.
>>
>> Is there an easy way to force 10mb speed (a /proc setting?)?
>
>The standard way, in this order, is (a) via ethtool, (b) via mii-tool,
>or (c) using a command line option at kernel boot time.

ethtool support isn't in our network drivers yet. That's something
I started working on for sungem, and will add to bmac at least
later on.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: any easy way to force 10/100 nics to 10?

[Kevin B. Hendricks]

Hi Jeff,

On October 23, 2001 08:48, Jeff Garzik wrote:
> "Kevin B. Hendricks" wrote:
> > Hi,
> >
> > My new dsl router seems to hate 100 connections from my 10/100 nics.
> >
> > Is there an easy way to force 10mb speed (a /proc setting?)?
>
> The standard way, in this order, is (a) via ethtool, (b) via mii-tool,
> or (c) using a command line option at kernel boot time.

Okay I added an AsanteFast 10/100 card using the tulip driver so that I
would have a card capable of controlling media type (that would still work
when I boot into the MacOSX).

Then I grabbed the net-tools src rpm and hacked the Makefile so that it
would build mii-tool (I could not find a package with ethtool anyplace.)

I then tried all of the following to force the card to only advertise
10baseT-FD or force 10baseT-FD but nothing seems to impact the actual
negotiated speed at all.


Before plugging in the ethernet cable:

[root@localhost rc.d]# /usr/local/bin/mii-tool --advertise=10baseT-FD eth0
restarting autonegotiation...
[root@localhost rc.d]# /usr/local/bin/mii-tool -v eth0
eth0: no link
  product info: vendor 00:00:00, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: no link
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseT4 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD

The above shows it is still advertising the same thing as before.

[root@localhost rc.d]# /usr/local/bin/mii-tool -v eth0
eth0: no link
  product info: vendor 00:00:00, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: no link
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseT4 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD

After pluggin in the cable.  The router lights now shows a 100mb link
[root@localhost rc.d]# /usr/local/bin/mii-tool --force=10baseT-FD eth0
[root@localhost rc.d]# mii-tool -v eth0
eth0: autonegotiation failed, link ok
  product info: vendor 00:00:00, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseT4 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
[root@localhost rc.d]# /usr/local/bin/mii-tool --force=10baseT-FD eth0
[root@localhost rc.d]# /usr/local/bin/mii-tool --restart eth0
restarting autonegotiation...
[root@localhost rc.d]# mii-tool -v eth0
eth0: autonegotiation failed, link ok
  product info: vendor 00:00:00, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseT4 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
[root@localhost rc.d]# mii-tool -v -v eth0
eth0: autonegotiation failed, link ok
  registers for MII PHY 32:
    1000 786c 0000 0000 03e1 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000
    0000 0000 0000 0000 0000 0000 0000 0000
  product info: vendor 00:00:00, model 0 rev 0
  basic mode:   autonegotiation enabled
  basic status: autonegotiation complete, link ok
  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
  advertising:  100baseT4 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
[root@localhost rc.d]#


If I try to use the nic at 100mb speed all I seem to get is lots of
dropped packets and errors.  If I directly connect the dsl modem to my
machine it forces the card to 10mb mode and all is well.  If I put the
dsl/cable router (with 10/100 capabilities in between) I am hosed.

The same thing holds for my internal nic too.

eth0: Lite-On PNIC-II rev 37 at 0xe2128000, 00:00:94:C6:05:2E, IRQ 24.
eth1: BMAC+ at 00:50:e4:70:2e:08

What kernel params do I have to send to the AsanteFast card (syntax?) to
force it to 10baseT-FD only?

Ideas anyone?

Thanks,

Kevin


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: any easy way to force 10/100 nics to 10?

[Kevin B. Hendricks]

Hi,

One other question:

Why are we advertising more than our capabilities and what is 100baseT4?

>   capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>   advertising:  100baseT4 100baseTx-FD 100baseTx-HD 10baseT-FD

Kevin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: any easy way to force 10/100 nics to 10?

[Geert Uytterhoeven]

On Thu, 25 Oct 2001, Kevin B. Hendricks wrote:
> Why are we advertising more than our capabilities and what is 100baseT4?

100baseT4 is 100 Mbps over 4 pairs of CAT-4 instead of 2 pairs of CAT-5.
Obsoleted by 100baseTX.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: any easy way to force 10/100 nics to 10?

[Jeff Garzik]

"Kevin B. Hendricks" wrote:
>
> Hi,
>
> One other question:
>
> Why are we advertising more than our capabilities and what is 100baseT4?
>
> >   capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
> >   advertising:  100baseT4 100baseTx-FD 100baseTx-HD 10baseT-FD

Looks like a bug...

--
Jeff Garzik      | Only so many songs can be sung
Building 1024    | with two lips, two lungs, and one tongue.
MandrakeSoft     |         - nomeansno


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

tulip (was Re: any easy way to force 10/100 nics to 10?)

[Timothy A. Seufert]

At 10:54 AM -0400 10/25/01, Jeff Garzik wrote:
>"Kevin B. Hendricks" wrote:
>>
>>  Hi,
>>
>>  One other question:
>>
>>  Why are we advertising more than our capabilities and what is 100baseT4?
>>
>>  >   capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD
>>  >   advertising:  100baseT4 100baseTx-FD 100baseTx-HD 10baseT-FD
>
>Looks like a bug...

Speaking of tulip and PPC, I think I sent you the attached endianness fix
for ADMTek Comet chips a while back, but it doesn't appear to have gotten
into any trees yet.  The first and last parts fix problems where the
ethernet MAC address would get mangled during the process of reading &
writing the hardware MAC address registers.  The middle part does the same
for the write to the multicast hash filter registers (which appear to be
similar to the MAC address registers).  I don't know how to test multicast
so I don't know if that part of the patch is necessary, but the MAC address
fix is necessary to get the chip working properly on PPC (& other BE cpus).

I still have problems with poor Tx performance on PPC.  In an x86 notebook,
the card can transmit with full 100 Mbps throughput, but in two different
PPC notebooks it only manages ~20-30 Mbps.  Both architectures receive at
100 Mbps.  Haven't figured out what's going on there.

What's really needed for accessing the MAC and multicast hash registers are
nonswapping forms of outl and inl.  I looked at insl_ns and outsl_ns but
they appeared to be enough different in implementation from outl and inl
that I didn't want to risk using them (the calculation of the I/O address
appeared to be different, at least on PPC).


--- tulip_core.c.orig	Mon Sep 24 02:55:16 2001
+++ tulip_core.c	Thu Oct  4 22:27:09 2001
@@ -306,7 +306,7 @@
  	}
  	if (tp->flags & MC_HASH_ONLY) {
  		u32 addr_low = cpu_to_le32(get_unaligned((u32
*)dev->dev_addr));
-		u32 addr_high = cpu_to_le32(get_unaligned((u16
*)(dev->dev_addr+4)));
+		u32 addr_high = cpu_to_le32(get_unaligned((u32
*)(dev->dev_addr+4)));
  		if (tp->chip_id == AX88140) {
  			outl(0, ioaddr + CSR13);
  			outl(addr_low,  ioaddr + CSR14);
@@ -1175,12 +1175,12 @@
  				;				/* No
change. */
  			else if (tp->flags & IS_ASIX) {
  				outl(2, ioaddr + CSR13);
-				outl(mc_filter[0], ioaddr + CSR14);
+				outl(cpu_to_le32(mc_filter[0]),
ioaddr + CSR14);
  				outl(3, ioaddr + CSR13);
-				outl(mc_filter[1], ioaddr + CSR14);
+				outl(cpu_to_le32(mc_filter[1]),
ioaddr + CSR14);
  			} else if (tp->flags & COMET_MAC_ADDR) {
-				outl(mc_filter[0], ioaddr + 0xAC);
-				outl(mc_filter[1], ioaddr + 0xB0);
+				outl(cpu_to_le32(mc_filter[0]), ioaddr + 0xAC);
+				outl(cpu_to_le32(mc_filter[1]), ioaddr + 0xB0);
  			}
  			tp->mc_filter[0] = mc_filter[0];
  			tp->mc_filter[1] = mc_filter[1];
@@ -1551,8 +1551,8 @@
  		}
  	} else if (chip_idx == COMET) {
  		/* No need to read the EEPROM. */
-		put_unaligned(inl(ioaddr + 0xA4), (u32 *)dev->dev_addr);
-		put_unaligned(inl(ioaddr + 0xA8), (u16 *)(dev->dev_addr + 4));
+		put_unaligned(le32_to_cpu(inl(ioaddr + 0xA4)), (u32
*)dev->dev_addr);
+		put_unaligned(le32_to_cpu(inl(ioaddr + 0xA8)), (u32
*)(dev->dev_addr + 4));
  		for (i = 0; i < 6; i ++)
  			sum += dev->dev_addr[i];
  	} else {

--
Tim Seufert

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: tulip (was Re: any easy way to force 10/100 nics to 10?)

[Timothy A. Seufert]

[-- Attachment #1: Type: text/plain, Size: 120 bytes --]

Darn it, my mailer wrapped lines on that patch even though I told it
not to.  Here's a uuencoded version.
--
Tim Seufert

[-- Attachment #2: tulip-diff-2 --]
[-- Type: application/octet-stream, Size: 2167 bytes --]

begin 644 tulip-di
M+2TM('1U;&EP7V-O<F4N8RYO<FEG"4UO;B!397`@,C0@,#(Z-34Z,38@,C`P
M,0HK*RL@='5L:7!?8V]R92YC"51H=2!/8W0@(#0@,C(Z,C<Z,#D@,C`P,0I`
M0"`M,S`V+#<@*S,P-BPW($!`"B`)?0H@"6EF("AT<"T^9FQA9W,@)B!-0U](
M05-(7T].3%DI('L*(`D)=3,R(&%D9')?;&]W(#T@8W!U7W1O7VQE,S(H9V5T
M7W5N86QI9VYE9"@H=3,R("HI9&5V+3YD979?861D<BDI.PHM"0EU,S(@861D
M<E]H:6=H(#T@8W!U7W1O7VQE,S(H9V5T7W5N86QI9VYE9"@H=3$V("HI*&1E
M=BT^9&5V7V%D9'(K-"DI*3L**PD)=3,R(&%D9')?:&EG:"`](&-P=5]T;U]L
M93,R*&=E=%]U;F%L:6=N960H*'4S,B`J*2AD978M/F1E=E]A9&1R*S0I*2D[
M"B`)"6EF("AT<"T^8VAI<%]I9"`]/2!!6#@X,30P*2!["B`)"0EO=71L*#`L
M(&EO861D<B`K($-34C$S*3L*(`D)"6]U=&PH861D<E]L;W<L("!I;V%D9'(@
M*R!#4U(Q-"D["D!`("TQ,3<U+#$R("LQ,3<U+#$R($!`"B`)"0D).PD)"0DO
M*B!.;R!C:&%N9V4N("HO"B`)"0EE;'-E(&EF("AT<"T^9FQA9W,@)B!)4U]!
M4TE8*2!["B`)"0D);W5T;"@R+"!I;V%D9'(@*R!#4U(Q,RD["BT)"0D);W5T
M;"AM8U]F:6QT97);,%TL(&EO861D<B`K($-34C$T*3L**PD)"0EO=71L*&-P
M=5]T;U]L93,R*&UC7V9I;'1E<ELP72DL(&EO861D<B`K($-34C$T*3L*(`D)
M"0EO=71L*#,L(&EO861D<B`K($-34C$S*3L*+0D)"0EO=71L*&UC7V9I;'1E
M<ELQ72P@:6]A9&1R("L@0U-2,30I.PHK"0D)"6]U=&PH8W!U7W1O7VQE,S(H
M;6-?9FEL=&5R6S%=*2P@:6]A9&1R("L@0U-2,30I.PH@"0D)?2!E;'-E(&EF
M("AT<"T^9FQA9W,@)B!#3TU%5%]-04-?041$4BD@>PHM"0D)"6]U=&PH;6-?
M9FEL=&5R6S!=+"!I;V%D9'(@*R`P>$%#*3L*+0D)"0EO=71L*&UC7V9I;'1E
M<ELQ72P@:6]A9&1R("L@,'A","D["BL)"0D);W5T;"AC<'5?=&]?;&4S,BAM
M8U]F:6QT97);,%TI+"!I;V%D9'(@*R`P>$%#*3L**PD)"0EO=71L*&-P=5]T
M;U]L93,R*&UC7V9I;'1E<ELQ72DL(&EO861D<B`K(#!X0C`I.PH@"0D)?0H@
M"0D)='`M/FUC7V9I;'1E<ELP72`](&UC7V9I;'1E<ELP73L*(`D)"71P+3YM
M8U]F:6QT97);,5T@/2!M8U]F:6QT97);,5T["D!`("TQ-34Q+#@@*S$U-3$L
M."!`0`H@"0E]"B`)?2!E;'-E(&EF("AC:&EP7VED>"`]/2!#3TU%5"D@>PH@
M"0DO*B!.;R!N965D('1O(')E860@=&AE($5%4%)/32X@*B\*+0D)<'5T7W5N
M86QI9VYE9"AI;FPH:6]A9&1R("L@,'A!-"DL("AU,S(@*BED978M/F1E=E]A
M9&1R*3L*+0D)<'5T7W5N86QI9VYE9"AI;FPH:6]A9&1R("L@,'A!."DL("AU
M,38@*BDH9&5V+3YD979?861D<B`K(#0I*3L**PD)<'5T7W5N86QI9VYE9"AL
M93,R7W1O7V-P=2AI;FPH:6]A9&1R("L@,'A!-"DI+"`H=3,R("HI9&5V+3YD
M979?861D<BD["BL)"7!U=%]U;F%L:6=N960H;&4S,E]T;U]C<'4H:6YL*&EO
M861D<B`K(#!X03@I*2P@*'4S,B`J*2AD978M/F1E=E]A9&1R("L@-"DI.PH@
M"0EF;W(@*&D@/2`P.R!I(#P@-CL@:2`K*RD*(`D)"7-U;2`K/2!D978M/F1E
6=E]A9&1R6VE=.PH@"7T@96QS92!["@``
`
end

Re: tulip (was Re: any easy way to force 10/100 nics to 10?)

[Benjamin Herrenschmidt]

>Speaking of tulip and PPC, I think I sent you the attached endianness fix
>for ADMTek Comet chips a while back, but it doesn't appear to have gotten
>into any trees yet.  The first and last parts fix problems where the
>ethernet MAC address would get mangled during the process of reading &
>writing the hardware MAC address registers.  The middle part does the same
>for the write to the multicast hash filter registers (which appear to be
>similar to the MAC address registers).  I don't know how to test multicast
>so I don't know if that part of the patch is necessary, but the MAC address
>fix is necessary to get the chip working properly on PPC (& other BE cpus).
>
>I still have problems with poor Tx performance on PPC.  In an x86 notebook,
>the card can transmit with full 100 Mbps throughput, but in two different
>PPC notebooks it only manages ~20-30 Mbps.  Both architectures receive at
>100 Mbps.  Haven't figured out what's going on there.
>
>What's really needed for accessing the MAC and multicast hash registers are
>nonswapping forms of outl and inl.  I looked at insl_ns and outsl_ns but
>they appeared to be enough different in implementation from outl and inl
>that I didn't want to risk using them (the calculation of the I/O address
>appeared to be different, at least on PPC).

insl_ns and outsl_ns are "stream" (or string) versions, they are used to
read/write fifos. Address calc. should be the same, but they don't have,
I beleive, the protection against machine check we have in inl/outl.

Ben.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/