Ethernet problems with Intel 82551ER

Hello,

We have a custom board (PPC 8245 based) using an Intel 82551ER Ethernet
controller. I’m using QNX 6.3.0 and devn-speedo.so on the target.
(The host is Windows XP)

I have some strange problems going on:

#1. When a host computer and the target board are both plugged into a
switch, they can ping each other with no difficulties. However if one
or the other is plugged in to the ‘network’ (through building routers,
etc…) they can’t ping each other. [although, occasionally this works]

#2. When both are plugged in through the switch, they ping each other
no problem, but the target’s(QNX) ftp client can not connect to the
host’s(WinXP) ftp server. Target client complains: “Connection timed out”

#3. I’m specifying speed=100,duplex=1, but the switch’s LED for full
duplex (FDX) does not indicate that the target really is running at
full duplex.

Any help would be appreciated.
Has the ‘speedo’ driver been used before on an Intel 82551ER? The data
sheet for the 82551 says ‘pin and driver’ compatible with the 82559ER.
(which is what ‘pci’ detects the device as.)
I noticed though, that ‘nicinfo’ claims it’s a 82557.

Some output shown below:

Config: (NOTE: We don’t yet have an eprom with a programmed MAC address)

io-net -d speedo mac=112233447766,speed=100,duplex=1 -p tcpip
waitfor /dev/socket
ifconfig en0 10.10.4.188 netmask 255.255.0.0
route add default 10.10.2.1

\

pci

PCI version = 2.10

Class = Network (Ethernet)
Vendor ID = 8086h, Intel Corporation
Device ID = 1209h, 82559ER Ethernet Controller
PCI index = 0h
PCI Mem Address = fbfe0000h enabled
PCI IO Address = afff00h enabled
CPU IO Address = feafff00h
PCI Mem Address = fbfc0000h enabled
PCI Int Pin = INT A
Interrupt line = 28
CPU Interrupt = 1ch

ifconfig

lo0: flags=8009<UP,LOOPBACK,MULTICAST> mtu 33212
capabilities=7<IP4CSUM,TCP4CSUM,UDP4CSUM>
enabled=0<>
inet 127.0.0.1 netmask 0xff000000
en0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
address: 11:22:33:44:77:66
inet 10.10.4.188 netmask 0xffff0000 broadcast 10.10.255.255

ping 10.10.2.187

PING 10.10.2.187 (10.10.2.187): 56 data bytes
64 bytes from 10.10.2.187: icmp_seq=0 ttl=128 time=1 ms
64 bytes from 10.10.2.187: icmp_seq=1 ttl=128 time=1 ms
64 bytes from 10.10.2.187: icmp_seq=2 ttl=128 time=1 ms
64 bytes from 10.10.2.187: icmp_seq=3 ttl=128 time=1 ms

----10.10.2.187 PING Statistics----
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max = 1/1/1 ms variance = 0 ms^2

ftp 10.10.2.187

é connect: Connection timed out
ftp> bye

nicinfo

INTEL 82557 Ethernet Controller

Physical Node ID … FFFFFF FFFFFF
Current Physical Node ID … 112233 447766
Current Operation Rate … 100.00 Mb/s full-duplex
Active Interface Type … MII
Active PHY address … 1
Maximum Transmittable data Unit … 1514
Maximum Receivable data Unit … 1514
Hardware Interrupt … 0x1c
I/O Aperture … 0xfeafff00 - 0xfeafff3f
Memory Aperture … 0xfbfe0000 - 0xfbfe0fff
Promiscuous Mode … Off
Multicast Support … Enabled

Packets Transmitted OK … 12
Bytes Transmitted OK … 968
Broadcast Packets Transmitted OK … 2
Multicast Packets Transmitted OK … 0
Memory Allocation Failures on Transmit … 0

Packets Received OK … 1221
Bytes Received OK … 129043
Broadcast Packets Received OK … 1206
Multicast Packets Received OK … 15
Memory Allocation Failures on Receive … 0

Single Collisions on Transmit … 0
Multiple Collisions on Transmit … 0
Deferred Transmits … 0
Late Collision on Transmit errors … 0
Transmits aborted (excessive collisions) … 0
Transmit Underruns … 0
No Carrier on Transmit … 0
Receive Alignment errors … 0
Received packets with CRC errors … 0
Packets Dropped on receive … 0
Short packets … 0
Total Frames experiencing Collison(s) … 0

John Kiernan <jkiernan@birinc.com> wrote:

Hello,

We have a custom board (PPC 8245 based) using an Intel 82551ER Ethernet
controller. I’m using QNX 6.3.0 and devn-speedo.so on the target.
(The host is Windows XP)

I have some strange problems going on:

#1. When a host computer and the target board are both plugged into a
switch, they can ping each other with no difficulties. However if one
or the other is plugged in to the ‘network’ (through building routers,
etc…) they can’t ping each other. [although, occasionally this works]

See if the situation is improved after 2) and 3) are addressed.

#2. When both are plugged in through the switch, they ping each other
no problem, but the target’s(QNX) ftp client can not connect to the
host’s(WinXP) ftp server. Target client complains: “Connection timed out”

This would be a symptom of the fact that the mac address you
specified is not a valid station address, it’s a multicast
address. The least significant bit of the first byte must
not be set.

#3. I’m specifying speed=100,duplex=1, but the switch’s LED for full
duplex (FDX) does not indicate that the target really is running at
full duplex.

When you explicitly specify speed and duplex, this disables
autonegotiation. Without autonegotiation, the switch has no way
of knowing that it’s supposed to go to full duplex. You must either
explicitly force the switch to full duplex, somehow, or else get rid of
the speed and duplex options, and let autonegotiation take its course.

If the speedo thinks the link is full-duplex, and the link thinks
it’s half-duplex, really bad things will happen.

Any help would be appreciated.
Has the ‘speedo’ driver been used before on an Intel 82551ER? The data

Yep.

David Donohoe wrote:

John Kiernan <> jkiernan@birinc.com> > wrote:

Hello,


We have a custom board (PPC 8245 based) using an Intel 82551ER Ethernet
controller. I’m using QNX 6.3.0 and devn-speedo.so on the target.
(The host is Windows XP)


I have some strange problems going on:


#1. When a host computer and the target board are both plugged into a
switch, they can ping each other with no difficulties. However if one
or the other is plugged in to the ‘network’ (through building routers,
etc…) they can’t ping each other. [although, occasionally this works]


See if the situation is improved after 2) and 3) are addressed.

Doh! Yup.



#2. When both are plugged in through the switch, they ping each other
no problem, but the target’s(QNX) ftp client can not connect to the
host’s(WinXP) ftp server. Target client complains: “Connection timed out”


This would be a symptom of the fact that the mac address you
specified is not a valid station address, it’s a multicast
address. The least significant bit of the first byte must
not be set.

Doh! You are correct. That fixes everything. (That’s what I get for

making up an address)

Thanks for your help!!!


John

John Kiernan <jkiernan@birinc.com> wrote:

Doh! You are correct. That fixes everything. (That’s what I get for
making up an address)

Been there, done that :wink:

Thanks for your help!!!

You’re welcome :slight_smile: