Bug 20016

The threads library is terminating because setitimer is being
called with a negative number of microseconds.  This is occuring
because timeout function is taking so long that all of the
timecounter elements are used.

This is occuring because the system call gettimeofday is returning
a negative number of microseconds to _thread_kern_sched() in
/usr/src/lib/libc_r_g/uthread/uthread_kern.c

This is occuring because the microtime() function called
by the system call gettimeofday in
/usr/src/sys/kern/kern_clock.c is returning a negative number
of microseconds.

This is occurring because the inline function tco_delta()
is returning the a negative time.

This is occurring because the timecounter structure used
by microtime and given to tco_delta is being modified
while tco_delta is using it.

Specifically tcl_delta() is calling tc->tc_get_timecount(tc)
and is storing the value in a register.

A timer interrupt occurs at this point which then calls
a timeout function which does not mask off
timer interrupts but which processes for a period of time
long enough so that the original timecounter element used
by microtime is reused.

At this point sync_other_counter() resets tc->tc_offset_count
and tc_delta returns a very large number.

static __inline unsigned 
tco_delta(struct timecounter *tc)
{

        return ((tc->tc_get_timecount(tc) - tc->tc_offset_count) &
            tc->tc_counter_mask);
}

Fix: 

Add to the kernel configuration file:

options         "NTIMECOUNTER=100"

This would allow for timeout functions of up to 1000 milli seconds.

The comments in LINT while they may be correct should be more
specific.
How-To-Repeat: It is difficult to reproduce the problem.

I think if you start up a timeout function which
spins for 100 ms and then call gettimeofday()
you may get lucky.