Broadcom Gigabit Ethernet Slow with Suse 9.3
 

I am having a problem with the integrated Broadcom 5751 Gigabit ethernet adapter (on ST20G5 Shuttle xPC) . The network is super slow. I tried to ping the router in the network and the response times are really bad in addition to some packets getting lost. I am running SUSE 9.3. After installation the adapter worked just fine, but all the sudden this is what I am getting...

64 bytes from 192.168.0.1: icmp_seq=132 ttl=128 time=11895 ms
64 bytes from 192.168.0.1: icmp_seq=133 ttl=128 time=10896 ms
64 bytes from 192.168.0.1: icmp_seq=134 ttl=128 time=9896 ms
64 bytes from 192.168.0.1: icmp_seq=135 ttl=128 time=8896 ms
64 bytes from 192.168.0.1: icmp_seq=136 ttl=128 time=16.5 ms
64 bytes from 192.168.0.1: icmp_seq=137 ttl=128 time=8889 ms
64 bytes from 192.168.0.1: icmp_seq=138 ttl=128 time=7890 ms
64 bytes from 192.168.0.1: icmp_seq=139 ttl=128 time=6890 ms
64 bytes from 192.168.0.1: icmp_seq=140 ttl=128 time=5890 ms
64 bytes from 192.168.0.1: icmp_seq=141 ttl=128 time=4891 ms
64 bytes from 192.168.0.1: icmp_seq=142 ttl=128 time=3891 ms
64 bytes from 192.168.0.1: icmp_seq=143 ttl=128 time=2891 ms
64 bytes from 192.168.0.1: icmp_seq=144 ttl=128 time=1891 ms
64 bytes from 192.168.0.1: icmp_seq=145 ttl=128 time=891 ms
64 bytes from 192.168.0.1: icmp_seq=146 ttl=128 time=15.3 ms

--- 192.168.0.1 ping statistics ---
150 packets transmitted, 146 received, 2% packet loss, time 169108ms
rtt min/avg/max/mdev = 2.362/5047.059/18901.875/4824.975 ms, pipe 11

Any ideas how to debug and fix this problem?

Thanks in advance,

Juha

any errors in dmesg output? what does mii-tool or ethtool say about the state of the cards configuration?

Here is the output from ethtool. Everything looks good. No HW errors message in the boot log / dmesg. Very puzzled with this.

Settings for eth0:
Supported ports: [ MII ]
Supported link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Supports auto-negotiation: Yes
Advertised link modes: 10baseT/Half 10baseT/Full
100baseT/Half 100baseT/Full
1000baseT/Half 1000baseT/Full
Advertised auto-negotiation: Yes
Speed: 100Mb/s
Duplex: Full
Port: Twisted Pair
PHYAD: 1
Transceiver: internal
Auto-negotiation: on
Supports Wake-on: g
Wake-on: d
Current message level: 0x000000ff (255)
Link detected: yes

Here is the dmesg output snapshot.
------------
PCI: Setting latency timer of device 0000:02:00.0 to 64
eth0: Tigon3 [partno(BCM95751) rev 4001 PHY(5750)] (PCIX:100MHz:32-bit) 10/100/1000BaseT Ethernet 00:30:1b:b8:af:a4
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
BIOS EDD facility v0.16 2004-Jun-25, 2 devices found
st: Version 20041025, fixed bufsize 32768, s/g segs 256
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
Attached scsi generic sg1 at scsi1, channel 0, id 0, lun 0, type 0
NET: Registered protocol family 17
tg3: eth0: Link is up at 100 Mbps, full duplex.
tg3: eth0: Flow control is on for TX and on for RX.
bootsplash: status on console 0 changed to on
powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09e)
powernow-k8: BIOS error - no PSB
NET: Registered protocol family 10
Disabled Privacy Extensions on device ffffffff80405f60(lo)
IPv6 over IPv4 tunneling driver
Disabled Privacy Extensions on device ffff81003201f000(sit0)

Started getting these with Ping occasionally in a row, may be a driver buffering problem? And the fight goes on.

ping: sendmsg: no buffer space available.
ping: sendmsg: no buffer space available.
ping: sendmsg: no buffer space available.
ping: sendmsg: no buffer space available.
ping: sendmsg: no buffer space available.
ping: sendmsg: no buffer space available.
ping: sendmsg: no buffer space available.

Thanks for help guys,

Kuhazor

we had some pretty similar problems with tg3 driven cards at work on a blade array. I'd try forcing the speeds to 1000 full with ethtool, see if that clears anything up, as it's only on 100 at the moment, which i'm guessing isn't what you want? might also want to try using ethereal to grab whatever else might be on that LAN segment.