I am back with a bit more information. The counters which were not
checked in this version can be grouped in two categories:

- Error counters such as:

	u64 FrameCheckSequenceErrors;
	u64 AlignmentErrors;
	u64 FramesLostDueToIntMACXmitError;
	u64 CarrierSenseErrors;
	u64 FramesLostDueToIntMACRcvError;
	u64 InRangeLengthErrors;
	u64 OutOfRangeLengthField;
	u64 FrameTooLongErrors;
	u64 FramesAbortedDueToXSColls;

  I did extend the selftest with these ones so that we check them
  against zero. I ran the test hundreds of times and I did not see any
  problems.

Great.

- Collision related counters (not really errors):

	u64 SingleCollisionFrames;
	u64 MultipleCollisionFrames;
	u64 FramesWithDeferredXmissions;
	u64 LateCollisions;
	u64 FramesWithExcessiveDeferral;

  With these I don't know what to do. Theoretically, they could be
  non-zero in half-duplex circumstances which means that checking for
  zero would not be entirely accurate.

How about, fail the test if any are greater than 1% of the number of
packets transmitted/received? My _guess_ is, if you have 1% packet
loss, networking is not going to be happy anyway. It probably means
you have one end doing Half duplex and the other Full. That is a
typical configuration error you see causing collisions. Not that i've
actually seen this for maybe a decade!

Failing the test, with a comment about checking duplex configuration,
seems sensible.

     Andrew