[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Automated report: NetBSD-current/i386 test failure
On 20/09/2020 04:40, Robert Elz wrote:
Date: Sun, 20 Sep 2020 04:02:45 +0100
From: Roy Marples <roy%marples.name@localhost>
| The test case just needed fixing.
That is not uncommon after changes elsewhere.
| The ping to an invalid address caused the ARP entry to enter INCOMPLETE ->
| WAITDELETE state and this hung over into the next test casing this entry
| to take too long to validty resolve.
Why? If a failed ARP (or ND) causes problems for a later request
(incl of the same addr) which should work (that is, any problems at all,
including delays) then I'd consider the implementation broken (not the test).
RFC 7048 expands that consistent failures expontentialy backoff.
Because the server is not reset the backoff may bleed into subsequet tests for
the same address which why this test was sometimes failing.
| The solution is after a deliberate fail
And if it wasn't a deliberate fail? Perhaps being just a fraction of a
second too quick, and attempting a ping (or ssh, or something) just before
the destination becomes reachable (either because it was down, unconfigured,
or the net link between then wasn't functional), and
ATF timings on an emulated environment cannot be that precise.
See PR 43997 for more details.
| to remove the ARP entry for the address
if the user doing this isn't root, and cannot just remove ARP entries?
Maybe I'm misunderstanding the actual scenario, but it seems to me
that things aren't working as well now as they were before (the timing
in the qemu tests hasn't changed recently - not since the nvmm version
started being used - but before the arp implementation change, it used
to work reliably).
By reliably you mean that a successful ARP resoltion lasts for 20 minutes which
we don't have any tests for?
If anything the tests we have are more reliable than before as I have not
adjusted any timings.
Main Index |
Thread Index |