* Problems getting a stable 100 megabit connection with linksys etherfast switch
@ 2004-02-29 21:30 john
2004-03-01 22:01 ` Denis Vlasenko
0 siblings, 1 reply; 3+ messages in thread
From: john @ 2004-02-29 21:30 UTC (permalink / raw)
To: Andrewm, netdev, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 502 bytes --]
Hi,
I am having problems getting a stable connection with my linux machines
when trying to connect them at 100 megabit speeds to a linksys etherfast
switch.
I have attached some diagnostic outputs for your review. I hope that someone
can help me with this problem.
I believe using a managed switch will solve the problem, but I don't want to
have to spend $1000.00 to fix this problem, when I should be able to obtain a
stable connection with the equipment I am currently using.
Thanks
John
[-- Attachment #2: 100mb_is_slow.20040229 --]
[-- Type: application/octet-stream, Size: 18929 bytes --]
************** Kernel version uname -a
Linux sid 2.4.24 #1 SMP Sun Feb 15 17:25:41 MST 2004 i686 unknown
************** lspci -vx output
00:09.0 Ethernet controller: Linksys Network Everywhere Fast Ethernet 10/100 model NC100 (rev 11)
Subsystem: Linksys: Unknown device 0574
Flags: bus master, medium devsel, latency 64, IRQ 17
I/O ports at 1400 [size=256]
Memory at e8003000 (32-bit, non-prefetchable) [size=1K]
Expansion ROM at <unassigned> [disabled] [size=128K]
Capabilities: [c0] Power Management version 2
00: 17 13 85 09 17 00 90 02 11 00 00 02 10 40 00 00
10: 01 14 00 00 00 30 00 e8 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 17 13 74 05
30: 00 00 00 00 c0 00 00 00 00 00 00 00 0a 01 40 80
****************** Banner messages from the /var/log/messages file
Feb 29 12:57:58 sid kernel: 3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
Feb 29 12:57:58 sid kernel: See Documentation/networking/vortex.txt
Feb 29 12:57:58 sid kernel: 00:0f.0: 3Com PCI 3c980C Python-T at 0x1c00. Vers LK1.1.18-ac
Feb 29 12:57:58 sid kernel: 00:e0:81:03:bc:77, IRQ 18
Feb 29 12:57:58 sid kernel: product code 0000 rev 00.3 date 00-00-00
Feb 29 12:57:58 sid kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
Feb 29 12:57:58 sid kernel: MII transceiver found at address 24, status 780d.
Feb 29 12:57:58 sid kernel: Enabling bus-master transmits and whole-frame receives.
Feb 29 12:57:58 sid kernel: 00:0f.0: scatter/gather enabled. h/w checksums enabled
Feb 29 12:57:58 sid kernel: See Documentation/networking/vortex.txt
:
Feb 29 12:57:58 sid kernel: 00:10.0: 3Com PCI 3c980C Python-T at 0x1c80. Vers LK1.1.18-ac
Feb 29 12:57:58 sid kernel: 00:e0:81:03:bc:78, IRQ 19
Feb 29 12:57:58 sid kernel: product code 0000 rev 00.3 date 00-00-00
Feb 29 12:57:58 sid kernel: 8K byte-wide RAM 5:3 Rx:Tx split, autoselect/Autonegotiate interface.
Feb 29 12:57:58 sid kernel: MII transceiver found at address 24, status 7809.
Feb 29 12:57:58 sid kernel: Enabling bus-master transmits and whole-frame receives.
Feb 29 12:57:58 sid kernel: 00:10.0: scatter/gather enabled. h/w checksums enabled
***************** dmesg output
sh-2.05a# dmesg|grep eth
eth0: using NWAY device table, not 8
eth0: Initial media type Autonegotiate.
eth0: MII #24 status 780d, link partner capability 0000, info1 0010, setting half-duplex.
eth0: vortex_up() InternalConfig 01800000.
eth0: vortex_up() irq 18 media status 8880.
eth0: Setting full-duplex based on MII #24 link partner capability of 45e1.
****************** The network setup
A Linksys etherfast EF4124 10/100 switch
3 Linux machines (which all have problems connecting at 100 megabits)
2 Windows XP machines
1 Windows 98 machine
The windows machines do not have a problem with their connections to the switch. They autonegotiate
their connections and seem to be stable.
My main problem is with the linux machines. If I let them autonegotiate to 100baseTx-FD they drop their link a lot and the connection becomes very slow. I have even tried to force the connections to make them not auto negotiate, but I have the same problem. They seem to be stable if I force the connection to 10baseT-HD.
I would really like to utilize the 100 megabit speeds, since that is one of the reasons I bought the faster switch.
************** Other things I have tried
I have linked two of the machines together using a cross cable and had no problems what so ever with that type of connection.
==================== diag of slower stable 10 megabit connecton ==============
*************** mii-tool
sh-2.05a# mii-tool
eth0: 10 Mbit, half duplex, link ok
************** mii-diag
sh-2.05a# ./mii-diag -v
mii-diag.c:v2.09 9/06/2003 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Using the default interface 'eth0'.
Using the new SIOCGMIIPHY value on PHY 24 (BMCR 0x0000).
Basic mode control register 0x0000: Auto-negotiation disabled, with
Speed fixed at 10 mbps, half-duplex.
You have link beat, and everything is working OK.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation not complete.
Link partner information is not exchanged when in fixed speed mode.
End of basic transceiver information.
MII PHY #24 transceiver registers:
0000 780d 0041 6800 05e1 0000 0004 2001
0000 0000 0000 0000 0000 0000 0000 0000
0618 3fc9 0030 4001 40c8 a000 0000 0000
d300 0020 8084 9119 0065 1bc1 7fff 0000
***************** vortex-diag
sh-2.05a# ./vortex-diag -aaee
vortex-diag.c:v2.14 12/28/2002 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a 3c982 Dual Port server NIC adapter at 0x1c00.
Station address 00:e0:81:03:bc:77.
Receive mode is 0x07: Normal unicast and all multicast.
The Vortex chip may be active, so FIFO registers will not be read.
To see all register values use the '-f' flag.
Initial window 4, registers values by window:
Window 0: 0000 0000 0000 0000 adad 00bf ffff 0000.
Window 1: FIFO FIFO 0700 0000 0000 007f 0000 2000.
Window 2: e000 0381 77bc 0000 0000 0000 0052 4000.
Window 3: 0000 0180 05ea 0000 000a 0800 0800 6000.
Window 4: 0000 0000 0000 0cc6 0001 8880 4000 8000.
Window 5: 1ffc 0000 0000 0600 0807 06ce 06c6 a000.
Window 6: 0000 0000 0000 fd00 2000 4136 8846 c000.
Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0x1c00
0x1C10: **FIFO** 00000000 0000000d *STATUS*
0x1C20: 00000020 00000000 00080000 00000004
0x1C30: 00000000 f2700d90 2f0e61a0 00080004
0x1C40: 00eb18d7 00000000 000000b7 00000000
0x1C50: 00000000 00000000 00000000 00000000
0x1C60: 00000000 00000000 00000000 00000000
0x1C70: 00001000 00000000 01600160 00000000
DMA control register is 00000020.
Tx list starts at 00000000.
Tx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to empty.
Rx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to full.
Poll period Tx 00 ns., Rx 0 ns.
Maximum burst recorded Tx 352, Rx 352.
Indication enable is 06c6, interrupt enable is 06ce.
No interrupt sources are pending.
Transceiver/media interfaces available: 100baseTx 10baseT.
Transceiver type in use: Autonegotiate.
MAC settings: half-duplex.
Station address set to 00:e0:81:03:bc:77.
Configuration options 0052.
EEPROM format 64x16, configuration table at offset 0:
00: 00e0 8103 bc77 9805 0000 0000 0000 6d50
0x08: 2940 0000 00e0 8103 bc77 0010 0000 00aa
0x10: 72a2 0000 0000 0180 0000 0004 1421 10f1
0x18: 2462 000a 0002 6300 ff43 4343 ffff ffff
0x20: 0063 ffff ffff ffff ffff ffff ffff ffff
0x28: ffff ffff ffff ffff ffff ffff ffff ffff
...
The word-wide EEPROM checksum is 0x0f81.
Saved EEPROM settings of a 3Com Vortex/Boomerang:
3Com Node Address 00:E0:81:03:BC:77 (used as a unique ID only).
OEM Station address 00:E0:81:03:BC:77 (used as the ethernet address).
Device ID 9805, Manufacturer ID 6d50.
Manufacture date (MM/DD/YYYY) 0/0/2000, division , product .
No BIOS ROM is present.
Transceiver selection: Autonegotiate.
Options: negotiated duplex, link beat required.
PCI Subsystem IDs: Vendor 10f1 Device 2462.
100baseTx 10baseT.
Vortex format checksum is incorrect (26 vs. 10f1).
Cyclone format checksum is incorrect (0xbe vs. 0x63).
Hurricane format checksum is correct (0x63 vs. 0x63).
Index #2: Found a 3c982 Dual Port server NIC adapter at 0x1c80.
Station address 00:e0:81:03:bc:78.
Receive mode is 0x07: Normal unicast and all multicast.
The Vortex chip may be active, so FIFO registers will not be read.
To see all register values use the '-f' flag.
Initial window 4, registers values by window:
Window 0: 0000 0000 0000 0000 adad 00bf ffff 0000.
Window 1: FIFO FIFO 0700 0000 0000 007f 0000 2000.
Window 2: e000 0381 78bc 0000 0000 0000 0052 4000.
Window 3: 0000 0180 05ea 0000 000a 0800 0800 6000.
Window 4: 0000 0000 0000 0046 0001 8080 0000 8000.
Window 5: 1ffc 0000 0000 1ffc 0807 0000 0000 a000.
Window 6: 0000 0000 0000 0000 0000 0000 0000 c000.
Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0x1c80
0x1C90: **FIFO** 00000000 00000000 *STATUS*
0x1CA0: 00000000 00000000 00080000 00000004
0x1CB0: 00000000 e22f1dd1 00000000 00080004
0x1CC0: 0050774b 00000000 000000b7 00000000
0x1CD0: 00000000 00000000 00000000 00000000
0x1CE0: 00000000 00000000 00000000 00000000
0x1CF0: 00009000 00000000 00000000 00000000
DMA control register is 00000000.
Tx list starts at 00000000.
Tx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to empty.
==================== diag of faster unstable 100 megabit connecton ==============
****************** mii-tool (with auto negotiation)
sh-2.05a# mii-tool
eth0: negotiated 100baseTx-FD flow-control, link ok
***************** mii-diag
h-2.05a# ./mii-diag -v
mii-diag.c:v2.09 9/06/2003 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Using the default interface 'eth0'.
Using the new SIOCGMIIPHY value on PHY 24 (BMCR 0x1000).
The autonegotiated capability is 01e0.
The autonegotiated media type is 100baseTx-FD.
Basic mode control register 0x1000: Auto-negotiation enabled.
You have link beat, and everything is working OK.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
End of basic transceiver information.
MII PHY #24 transceiver registers:
1000 782d 0041 6800 05e1 45e1 0007 2801
0000 0000 0000 0000 0000 0000 0000 0000
0618 c7d1 0030 4001 40c8 a000 0000 0000
d300 0620 8084 9119 0065 1bec 7fff 0000
*********** vortex-diag
h-2.05a# ./vortex-diag -aaee
vortex-diag.c:v2.14 12/28/2002 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Index #1: Found a 3c982 Dual Port server NIC adapter at 0x1c00.
Station address 00:e0:81:03:bc:77.
Receive mode is 0x07: Normal unicast and all multicast.
The Vortex chip may be active, so FIFO registers will not be read.
To see all register values use the '-f' flag.
Initial window 4, registers values by window:
Window 0: 0000 0000 0000 0000 adad 00bf ffff 0000.
Window 1: FIFO FIFO 0700 0000 0000 007f 0000 2000.
Window 2: e000 0381 77bc 0000 0000 0000 0052 4000.
Window 3: 0000 0180 05ea 0020 000a 0800 0800 6000.
Window 4: 0000 0000 0000 0cc6 0001 8880 4000 8000.
Window 5: 1ffc 0000 0000 0600 0807 06ce 06c6 a000.
Window 6: 0000 0000 0000 7a00 1000 1de2 9aca c000.
Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0x1c00
0x1C10: **FIFO** 00000000 0000000d *STATUS*
0x1C20: 00000020 00000000 00080000 00000004
0x1C30: 00000000 cf0e30f2 2f0e6120 00080004
0x1C40: 007fa65f 00000000 000000b7 00000000
0x1C50: 00000000 00000000 00000000 00000000
0x1C60: 00000000 00000000 00000000 00000000
0x1C70: 00001000 00000000 01600160 00000000
DMA control register is 00000020.
Tx list starts at 00000000.
Tx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to empty.
Rx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to full.
Poll period Tx 00 ns., Rx 0 ns.
Maximum burst recorded Tx 352, Rx 352.
Indication enable is 06c6, interrupt enable is 06ce.
No interrupt sources are pending.
Transceiver/media interfaces available: 100baseTx 10baseT.
Transceiver type in use: Autonegotiate.
MAC settings: full-duplex.
Station address set to 00:e0:81:03:bc:77.
Configuration options 0052.
EEPROM format 64x16, configuration table at offset 0:
00: 00e0 8103 bc77 9805 0000 0000 0000 6d50
0x08: 2940 0000 00e0 8103 bc77 0010 0000 00aa
0x10: 72a2 0000 0000 0180 0000 0004 1421 10f1
0x18: 2462 000a 0002 6300 ff43 4343 ffff ffff
0x20: 0063 ffff ffff ffff ffff ffff ffff ffff
0x28: ffff ffff ffff ffff ffff ffff ffff ffff
...
The word-wide EEPROM checksum is 0x0f81.
Saved EEPROM settings of a 3Com Vortex/Boomerang:
3Com Node Address 00:E0:81:03:BC:77 (used as a unique ID only).
OEM Station address 00:E0:81:03:BC:77 (used as the ethernet address).
Device ID 9805, Manufacturer ID 6d50.
Manufacture date (MM/DD/YYYY) 0/0/2000, division , product .
No BIOS ROM is present.
Transceiver selection: Autonegotiate.
Options: negotiated duplex, link beat required.
PCI Subsystem IDs: Vendor 10f1 Device 2462.
100baseTx 10baseT.
Vortex format checksum is incorrect (26 vs. 10f1).
Cyclone format checksum is incorrect (0xbe vs. 0x63).
Hurricane format checksum is correct (0x63 vs. 0x63).
Index #2: Found a 3c982 Dual Port server NIC adapter at 0x1c80.
Station address 00:e0:81:03:bc:78.
Receive mode is 0x07: Normal unicast and all multicast.
The Vortex chip may be active, so FIFO registers will not be read.
To see all register values use the '-f' flag.
Initial window 4, registers values by window:
Window 0: 0000 0000 0000 0000 adad 00bf ffff 0000.
Window 1: FIFO FIFO 0700 0000 0000 007f 0000 2000.
Window 2: e000 0381 78bc 0000 0000 0000 0052 4000.
Window 3: 0000 0180 05ea 0000 000a 0800 0800 6000.
Window 4: 0000 0000 0000 0046 0001 8080 0000 8000.
Window 5: 1ffc 0000 0000 1ffc 0807 0000 0000 a000.
Window 6: 0000 0000 0000 0000 0000 0000 0000 c000.
Window 7: 0000 0000 0000 0000 0000 0000 0000 e000.
Vortex chip registers at 0x1c80
0x1C90: **FIFO** 00000000 00000000 *STATUS*
0x1CA0: 00000000 00000000 00080000 00000004
0x1CB0: 00000000 becb4135 00000000 00080004
0x1CC0: 00e504de 00000000 000000b7 00000000
0x1CD0: 00000000 00000000 00000000 00000000
0x1CE0: 00000000 00000000 00000000 00000000
0x1CF0: 00001000 00000000 00000000 00000000
DMA control register is 00000000.
Tx list starts at 00000000.
Tx FIFO thresholds: min. burst 256 bytes, priority with 128 bytes to empty.
********************** mii-tool watch command output with poor link
sh-2.05a# mii-tool -v -w eth0
13:45:04 eth0: negotiated 100baseTx-FD flow-control, link ok
13:45:07 eth0: no link
13:45:08 eth0: negotiated 100baseTx-FD flow-control, link ok
13:45:10 eth0: no link
13:45:13 eth0: negotiated 100baseTx-FD flow-control, link ok
13:45:25 eth0: no link
13:45:28 eth0: negotiated 100baseTx-FD flow-control, link ok
13:45:31 eth0: no link
13:45:32 eth0: negotiated 100baseTx-FD flow-control, link ok
13:45:40 eth0: no link
13:45:42 eth0: negotiated 100baseTx-FD flow-control, link ok
13:45:55 eth0: no link
13:45:56 eth0: negotiated 100baseTx-FD flow-control, link ok
13:46:00 eth0: no link
13:46:02 eth0: negotiated 100baseTx-FD flow-control, link ok
************** messages file output after switching to negotiated 100baseTx-FD flow-control connection
Feb 29 14:00:35 sid kernel: eth0: Setting full-duplex based on MII #24 link partner capability of 45e1.
Feb 29 14:00:35 sid kernel: eth0: Setting full-duplex based on MII #24 link partner capability of 45e1.
Feb 29 14:00:35 sid kernel: Setting duplex in Wn3_MAC_Ctrl
Feb 29 14:05:24 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:05:24 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:05:24 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:05:24 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:05:33 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:05:33 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:05:33 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:05:33 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:01 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:01 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:01 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:01 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:17 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:17 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:17 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:17 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:29 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:29 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:35 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:35 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:44 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:44 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:46 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:46 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:48 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:48 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:48 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:48 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:57 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:57 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:57 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:57 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:59 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:59 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:06:59 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:06:59 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:07:07 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:07:07 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:07:09 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:07:09 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:07:09 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:07:09 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:07:11 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:07:11 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:07:11 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:07:11 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:07:15 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:07:50 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:07:15 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:07:50 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:07:50 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:07:50 sid kernel: nfs: server john2.post.fam OK
Feb 29 14:08:57 sid kernel: nfs: server john2.post.fam not responding, still trying
Feb 29 14:08:57 sid kernel: nfs: server john2.post.fam OK
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Problems getting a stable 100 megabit connection with linksys etherfast switch
2004-02-29 21:30 Problems getting a stable 100 megabit connection with linksys etherfast switch john
@ 2004-03-01 22:01 ` Denis Vlasenko
2004-03-04 12:44 ` john
0 siblings, 1 reply; 3+ messages in thread
From: Denis Vlasenko @ 2004-03-01 22:01 UTC (permalink / raw)
To: john, Andrewm, netdev, linux-kernel
On Sunday 29 February 2004 23:30, john wrote:
> Hi,
>
> I am having problems getting a stable connection with my linux machines
> when trying to connect them at 100 megabit speeds to a linksys etherfast
> switch.
>
>
> I have attached some diagnostic outputs for your review. I hope that
> someone can help me with this problem.
>
> I believe using a managed switch will solve the problem, but I don't want
> to have to spend $1000.00 to fix this problem, when I should be able to
> obtain a stable connection with the equipment I am currently using.
Try half duplex. You seldom do lots of xfers in both directions at once,
so half duplex is not a big loss.
Use tcpdump to see what's going on on the wire.
--
vda
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Problems getting a stable 100 megabit connection with linksys etherfast switch
2004-03-01 22:01 ` Denis Vlasenko
@ 2004-03-04 12:44 ` john
0 siblings, 0 replies; 3+ messages in thread
From: john @ 2004-03-04 12:44 UTC (permalink / raw)
To: Denis Vlasenko, Andrewm, netdev, linux-kernel
Hi Denis,
Turns out I had a cable problem. Some of the patch cables that I made, had
the wrong pinout. After replacing them, the connection is stable at 100baseTx-FD.
Thanks
John
On Tue, 2 Mar 2004 00:01:47 +0200, Denis Vlasenko wrote
> On Sunday 29 February 2004 23:30, john wrote:
> > Hi,
> >
> > I am having problems getting a stable connection with my linux machines
> > when trying to connect them at 100 megabit speeds to a linksys etherfast
> > switch.
> >
> >
> > I have attached some diagnostic outputs for your review. I hope that
> > someone can help me with this problem.
> >
> > I believe using a managed switch will solve the problem, but I don't want
> > to have to spend $1000.00 to fix this problem, when I should be able to
> > obtain a stable connection with the equipment I am currently using.
>
> Try half duplex. You seldom do lots of xfers in both directions at
> once, so half duplex is not a big loss.
>
> Use tcpdump to see what's going on on the wire.
> --
> vda
--
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-03-04 12:44 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-02-29 21:30 Problems getting a stable 100 megabit connection with linksys etherfast switch john
2004-03-01 22:01 ` Denis Vlasenko
2004-03-04 12:44 ` john
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).