nate wrote:
Robert Moskowitz wrote:
Intel the first time, DLink (Realtek) currently. Both 10/100Mb
There's a lot of different Realtek chips out there, can you
send the output of lspci -v (and capture the network card only since
it spits out a lot of output). I've heard lots of bad things over
the years about Realtek cards though my personal experience with
them has been fine(last one I used I bought probably 6 years ago).
00:0e.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
Subsystem: D-Link System Inc Unknown device 1301
Flags: bus master, medium devsel, latency 66, IRQ 10
I/O ports at 1000 [size=256]
Memory at 40000000 (32-bit, non-prefetchable) [size=256]
Capabilities: [50] Power Management version 2
See my prior post for mseg info on this card.
- What driver is it using?
How do I tell?
Check in /etc/modprobe.conf, also you can include the output of
'lsmod'
- Can you verify that the speed and duplex settings match on both ends of
the connection?
The switch has its 100Mb LED on. One of the switch ports has my
Speedstream router which is only 10Mb, so we can believe the 100Mb LED.
This is a dumb switch (my public network, so I am not going to plug into
one of my Procurves).
Since it's a dumb switch there's probably no way to confirm duplex settings.
One thing you could try is hard setting the NIC to the various different
options and see if things improve. It could be that auto negotiation is
failing so they are running at mismatched duplexes. Which depending on
the quality of the switch will depend on the results. About 10 years ago
I had a 3COM network card and a Linksys switch that just refused to
co-operate. Of course 3COM blamed Linksys and Linksys blamed 3COM. Ended
up going with a netgear switch and that 'fixed' it.
You should be able to use the 'ethtool' command to force duplex/speed
changes.
I will change addresses on this card and plug it into one of my Procurve
switches. That will tell me part of what is going on.
No and no.
eth1 Link encap:Ethernet HWaddr 00:50:BA:42:82:49
inet addr:208.83.67.132 Bcast:208.83.67.135 Mask:255.255.255.248
inet6 addr: fe80::250:baff:fe42:8249/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1709 errors:0 dropped:0 overruns:0 frame:0
TX packets:1033 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:535351 (522.8 KiB) TX bytes:117321 (114.5 KiB)
Interrupt:10 Base address:0xa000
Quite unusual..
ho, ho. MTU of 1500. Is this not doing MTU path discovery? But these are
little PINGs so there should not be any frag problems (my WAN link is
PPPoE, so you want pathMTU or have to hard config everything to
1415bytes per the pppoe man pages).
The only experience I have with MTU discovery is with jumbo frames, and
as far as I know MTU discovery is only available for TCP, not UDP or
ICMP. You could certainly manually set your MTU to 1415 with
ifconfig eth1 mtu 1415, but as you say the packets your sending are
tiny anyways so it probably won't have any impact.
- Try replacing the card itself? maybe it is bad.
On my 2nd card already.
Of the same type? Try another brand/model? Get another Intel card,
or a broadcom-based card(3COM or something).
Different types. I have to use what I have sitting around for right now.
I wouldn't expect IRQ conflicts to be much of an issue with this type
of problem, such tiny amounts of traffic on the card. I can't even
remember the last time I had to deal with IRQs, 4-5-6 years? Things
seem to work pretty well these days.
Same here, but when you are groping for answers, you fall back on old
experiences.
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
