134164f8d3
The Am1771 driver will sometimes do the following: - Some thread-> NdisScheduleWorkItem(some work) - Worker thread -> do some work, KeWaitForSingleObject(some event) - Some other thread -> NdisScheduleWorkItem(some other work) When the second call to NdisScheduleWorkItem() occurs, the NDIS worker thread (in our case ndis taskqueue) is suspended in KeWaitForSingleObject() and waiting for an event to be signaled. This is different from when the worker thread is idle and waiting on NdisScheduleWorkItem() to send it more jobs. However, the ndis_sched() function in kern_ndis.c always calls kthread_resume() when queueing a new job. Normally this would be ok, but here this causes KeWaitForSingleObject() to return prematurely, which is not what we want. To fix this, the NDIS threads created by kern_ndis.c maintain a state variable to indicate whether they are running (scanning the job list and executing jobs) or sleeping (blocked on kthread_suspend() in ndis_runq()), and ndis_sched() will only call kthread_resume() if the thread is in the sleeping state. Note that we can't just check to see if the thread is on the run queue: in both cases, the thread is sleeping, but it's sleeping for different reasons. This stops the Am1771 driver from emitting various "NDIS ERROR" messages and fixes some cases where it crashes. |
||
|---|---|---|
| .. | ||
| freebsd32 | ||
| ia32 | ||
| linprocfs | ||
| linux | ||
| ndis | ||
| netbsd | ||
| pecoff | ||
| svr4 | ||