On Thu, Feb 26, 2026 at 02:31:26PM +0100, Andrew Lunn wrote: > > 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.
Seems reasonable. Thanks for the help!
