odd KSE panic

[Andrew Gallatin]

Andrew Gallatin writes:
 > 
 > The problem happens when exiting.  When main application thread
 > decides to exit, it does an ioctl into the driver to wakeup the
 > sleeping worker thread.  The worker thread thread wakes up, and then
 > exits, then the main thread closes his file descriptor and exits.
 > 
 > The problem I'm seeing is that I get a panic like the following when
 > using KSE.  (A linux binary works fine, ioctls are translated..)
 > 

The problem turned out to be that the worker thread was sleeping in
cv_wait_sig() on a cv which was used elsewhere in the driver.  When I
fixed this, pretty much everything got better.  I still don't
understand exactly what happened.  I have no idea if the worker woke
too early, or if the other place this cv was (mis)used was where the
early wake happened.  (this would be where mx_free() is called).

Anyway, it no longer crashes the machine.   Sorry to have wasted your
time.  

Now to figure out why libthr does pthread_cond_signal() in my scenario
47us faster than libpthread... (ULE, 1 HTT P4 running SMP kernel)

Scenario is that the mainline thread sleeps waiting for a packet
(using pthread_cond_timedwait()) and the worker thread is asleep in
kernel.  When a packet arrives, the worker wakes up, returns from the
ioctl, does a pthread_cond_signal() to wakeup the mainline thread, and
goes back into the kernel to sleep (via an ioctl).  This is the sort
of scenario where I thought KSE would be faster than a 1:1 lib..

Drew