Re: kern/39173: random processes get stuck in "D" state

[Brett Lymn <blymn%internode.on.net@localhost>]

After I released the modified if_iwn.c driver I had been trying to fix
others had the same issues.  Another person pointed out that I had made
the wireless commands synchronous instead of asynchronous by default -
this results in the iwn driver doing a tsleep waiting for the firmware
command to complete.  Due to the lack of locking, I think what was
happening was another thread was manipulating the ring buffers while
the first thread was waiting for the firmware to finish which, I think
caused random memory corruption.  By making the firmware command routines
run asynchronously (no tsleeps) then the window for the problem to occur
is much reduced and my machine is far more stable.  Really, the proper fix
is to apply locking around the manipulation of critical data structures.
Mind you, a quick check of a few other wireless drivers show the same
lack of locking which is a bit of a worry.

-- 
Brett Lymn