lkml.org 
[lkml]   [1999]   [Jan]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Subjectrunaway SCSI eh thread
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:50    [W:0.039 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site