When rx-pktsNtoM reports a range that involves very low-valued range, such as 0-64, the calculated length of the packet will be -4, because FCS is subtracted from the value. mausezahn then confuses the value for an option and bails out. As a result, the test dumps many mausezahn error messages.
Instead, cap the value at 0. mausezahn will use an appropriate minimum packet length.
Cc: Vladimir Oltean vladimir.oltean@nxp.com Cc: Tobias Waldekranz tobias@waldekranz.com Signed-off-by: Petr Machata petrm@nvidia.com --- tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh | 1 + 1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh b/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh index e2a1c10d3503..8f60c1685ad4 100755 --- a/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh +++ b/tools/testing/selftests/drivers/net/hw/ethtool_rmon.sh @@ -44,6 +44,7 @@ bucket_test() # Mausezahn does not include FCS bytes in its length - but the # histogram counters do len=$((len - ETH_FCS_LEN)) + len=$((len > 0 ? len : 0))
before=$(ethtool --json -S $iface --groups rmon | \ jq -r ".[0].rmon["${set}-pktsNtoM"][$bucket].val")