Fix fs_test:cleanup__mount_point__busy
The first call to kyua_fs_cleanup in this test was supposed to fail as
it is exercising an error path. But the check was reversed, expecting
no error. Fix this obvious mistake.
Sometime this tests passes (after all, it's exercising a race condition) and
when it does it's reported as a failure. By giving the test a few chances
to expose the problem, we prevent this noisy signal. When the race is really
addressed, this will start failing consistently as expected.
The offending tests are these:
- t_filter_exec: f26, f27.
- t_filter_parse: i17.
- t_nat_exec: n12.
These tests are confirmed to fail in NetBSD/current under amd64, i386 and
sparc as reported by the continuous testing systems.
This test was failing on my machine when run natively but not causing any
problems when run within qemu, and the failure was "mkdir: No space left
on device".
My understanding of the issue is that this test overflowed the temporary
disk image due to its high rate of file churn and the lfs_cleanerd not
being able to keep up. Note that this test is capped by time, not number
of operations, so this is why the problem does not show up in a slow
emulated system.
To fix this, just bump the test file system image limit a little bit.
(I tried increasing the frequency at which lfs_cleanerd does its thing,
but it wasn't enough.)
If mount_tmpfs fails, show what the stderr output of the command was instead
of failing without details.
While doing this, remove the stupidity to deal with the optional arguments
to the test_mount routine.
collect this document.
It's not clear that src/doc is the best place to manage this
information; a "NetBSD-7" file may or may not be forthcoming
shortly.
The *_host_{setup,data}_[tr]x routines already split transfers into < mps
units, so there no reason to do it in *_setup_{ctrl,data}_chain. Fix
short_pkt handling in the process.
This gives urtwn a fighting change to Tx large packets.
This is wrong. The zfs tests already use rump so they should not require
root. However, I've already spent much more time than I wanted trying to
figure out why that's the case without much luck. If you can find why,
just remove this hack.
Add periodic clock synchronization to vmt(4) so that the guest clock
remains synchronized even when the host is suspended (which is a very
typical situation in a laptop).
Do this by default once per minute, but provide a sysctl to tune this
value (machdep.vmt0.clock_sync.period).
Sent to tech-kern@ for review and addressed a couple of issues.
rmind