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.olt...@nxp.com>
Cc: Tobias Waldekranz <tob...@waldekranz.com>
Signed-off-by: Petr Machata <pe...@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")
--
2.43.0
