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@

0 files changed, 0 insertions, 0 deletions