Messages in this thread | | | From | grant@torque ... | Subject | runaway SCSI eh thread | Date | Fri, 29 Jan 1999 22:34:24 -0500 (EST) |
| |
While attempting to use the new SCSI eh_ routines in a revision of one of my device drivers, I've stumbled onto some behaviour that I can't explain.
In short, the scsi_error_handler() thread turns into a high-priority runaway task.
I'm running a 2.2.1 SMP kernel with full SCSI logging enabled. If any sort of error is triggered by the driver, the error handler thread wakes up, does its thing, and then goes into an infinite loop. The loop logs the following lines over and over:
Error handler waking up scsi_unjam_host: Checking to see if we need to request sense Total of 0+0 commands on 0 devices require eh work scsi_error.c: Waking up host to restart Calling request function to restart things... Error handler sleeping Error handler waking up scsi_unjam_host: Checking to see if we need to request sense Total of 0+0 commands on 0 devices require eh work scsi_error.c: Waking up host to restart Calling request function to restart things... Error handler sleeping [etc ...]
The loop is essentially:
while(1) { printk("Error handler sleeping") down_interruptible(eh_wait) if interrupted die printk("Error handler waking up") scsi_unjam_host() }
And the only places where eh_wait gets an up() log some sort of message - none of which appear here. So, I'm assuming that somehow the semaphore has gone to some hugely positive value and the down's just aren't taking.
Are there any known issues with semaphores that explain this ? I suppose it is possible that I am stomping on the eh_wait semaphore somehow, but that seems an unlikely explanation.
There is one other component to this picture: sometimes (about 50% of the times that I load the scsi modules and my driver) this infinite loop begins immediately after the driver is successfully loaded. Unfortunately, I haven't managed to trigger it while logging was enabled (yet), but I believe the semaphore is triggered by the DID_NO_CONNECT "errors" during the target search.
Has there been a recent change to the semaphore semantics which was not reflected in scsi_error.c ? Or should I be looking deeper for something of mine that is accidently trampling on just the semaphore from afar ?
(I'm using gcc 2.7.2.3).
-------------------------------------------------------------------------- Grant R. Guenther grant@torque.net --------------------------------------------------------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |