VMS keeps disabling the ethernet port

[Mark Berryman]

I have installed VMS V8.3 on an RX2620 (I do not have -1h1 at this time). I can perform DECnet transactions all day long without issue. However, once a TCP/IP stack has been started and a small amount of traffic has been exchanged, VMS issues the error message:
"%EIA0,
Receive CRC validation failure, device now unusable", the link is shutdown and all network traffic stops. This happens on both ethernet ports and with multiple IP stacks. No CRC errors are logged in the LAN counters and the Ethernet connection works fine when plugged into any other device, including the ILO board. I have also verified that speed and duplex are being negotiated correctly. I'm hoping someone here can explain what is happening or, more importantly, knows a way to tell VMS to stop shutting down the port.

[Ian Miller.]

What patches do you have?

[Hein van den Heuvel]

What's on the other side of the wire?
Can you see the speed/duplex selected?
Maybe the TCP/IP stacks use Jumbo-Frames and that fails?

Hein

[Volker Halle]

Mark,

the most detailled information would be reported by LANCP SHOW DEV/INT EIA0

This error msg does not seem to have been publicly reported before, consider to ask HP what this msg is meant to indicate.

Did this interface work before on this RX2620 ?

Volker.

[Mark Berryman]

The system is up-to-date on all patches.

The connection is only running at 100mb and neither side has jumbo frames enabled. Both sides agree on speed and duplex.

I just obtained this system. The previous owner indicates he never ran an IP stack on it.

I will get a copy of the LANCP output and post it here.

[Volker Halle]

Mark,

here is an answer from an authoritive resource:

'What it means is that the driver is doing a validation of the first 50000 packets for that interface and the calculated CRC is different from the actual CRC. These are packets that passed device validation so no CRC errors are recorded for the device. The CRC error most likely was introduced on each packet during DMA to host memory. The driver is detecting undetected data corruption and turning off the device.

So the device should be replaced.'

IMHO this looks like a hardware problem, if we believe that the driver is coded correctly. This looks like an unusual problem.

Volker.

[Jon Pinkley]

Volker, that seems like a reasonable explanation, but if the same ethernet driver is being used by the DECnet and IP stacks, why doesn't DECnet traffic trigger the same error?

Jon

[Mark Berryman]

That is my question as well. With this information describing what the system is doing, I booted the system and generated DECnet traffic until the counter showed that 50000 CRC validations had been done. Then I started Multinet. So far, everything is working and the Ethernet interface has not been turned off. I also used SCP to copy a large file onto the RX2620 and then used checksum to compare it to the source. Both ends matched which would indicate that packets are not really being corrupted between the ethernet interface and memory. This is looking more like a bug in the CRC validation code in the driver although why it would care about the difference between DECnet packets and IP packets is a mystery unless it has something to do with the framing difference between 802.3 packets (DECnet V5) and Ethernet V2 packets (IP).

[Richard Stockdale · Accepted solution]

The receive CRC check is pretty simple minded - it doesn't matter what type of packet, it just does a CRC calculation of the entire received packet and fails if it doesn't match what was received from the device.

That doesn't mean things won't work as upper layers may be doing checksum calculations and discarding bad packets. Or the corrupted data is in some part of the packet that isn't critical.

As to why DECnet might work and TCP/IP doesn't - it could be the packet size. Or the data in the packet might induce a hardware failure for that packet and not another with a different data pattern. Or the contents of other packets might affect the hardware and cause a bad DMA operation. I'd guess you were just lucky.

As far as running all day long without issue, the test only runs for the first 50000 packets. You could increase this to do the calculation on every packet and see if some DECnet traffic induced the failure.

This check was put into the driver to detect failing AB290A cards and it has been working successfully for several years. I don't think there is a problem with the code.

If you are willing to accept undetected data corruption, you can disable the check using a device-specific function:

$ mc lancp set dev eia/dev=(func="RCRC",value=(low,high))

low,high is a 64 bit number of remaining CRC checks to do, so you could set it to zero and it would do no more checks. The default is value=(50000,0).

- Dick

[Volker Halle]

Mark,

as the CRC checking code in the driver seems to exist for a reason, you might not want to bet your data on 'luck'. If there is some data corruption in the DMA operation between the interface and host memory, all things are possible: caused by certain bit patterns, message length etc.

Volker.