Output the relevant time specs before the assertion, in the hopes of
figuring out why this occasionally fails.

Fix the sem_timedwait(3) test.

The recent clock_getres(2) changes made it so that clock_getres(2) returns
the granularity of the active timecounter. This is usually much finer
than that of hardcloc

Fix the sem_timedwait(3) test.

The recent clock_getres(2) changes made it so that clock_getres(2) returns
the granularity of the active timecounter. This is usually much finer
than that of hardclock(9), so we can no longer use clock_getres(2) to
fudge our upper timeout return bound. The test is failing because it
thinks our sem_timedwait(3) call is returning with too much latency.

We can still get the hardclock(9) granularity via the kern.clockrate
sysctl(2), though, so just use that to fudge the upper bound.

While here, we ought to be checking that we return after the requested
absolute timeout, not that we were asleep for a particular interval.

Breakage reported by mpi@.

ok mpi@

show more ...

Fix sem_timedwait regress test. Needs SA_RESTART to block now.

Hug and OK guenther@

There can be resolution-worth of slop in two places, so accept that

Add tests for sem_timedwait()