For as long as I've had my CD-R drive (several months), I've had
intermittent problems with the ide-scsi driver. It would work fine
most of the time, but when numerous IO jobs were running simultaneous
with the ide-scsi driver, the kernel would eventually hang itself
hard. It seemed especially prone to failure when used simultaneously
with the ppa zip drive. (I guess having two *different* emulated SCSI
busses was too much to ask for.)
A few days ago I looked at this problem and noticed that, as of
2.1.104, ide-scsi.c was still using two calls to spin_lock() and
spin_unlock() instead of spin_lock_irqsave() and
spin_lock_irqrestore().
Now, I'm not a full time kernel hacker, and I couldn't find decent
comments anywhere on what the "flags" parameter to spin_lock_irqsave()
really means, but I tried replacing the two suspicious calls and it
seems to have resolved the problems I was observing. I was unnverved
by the fact that in many drivers, (as in this one) the "flags"
parameter to spin_lock_irqsave() seems to be uninitialized.
Someone with more knowledge in this area should evaluate the following
patch for consideration to include in future kernels.
v/r
Daniel Risacher
--- linux/drivers/scsi/ide-scsi.c.2.1.104 Fri May 29 06:12:39 1998
+++ linux/drivers/scsi/ide-scsi.c Fri May 29 06:13:53 1998
@@ -723,6 +723,7 @@
idescsi_scsi_t *scsi;
struct request *rq = NULL;
idescsi_pc_t *pc = NULL;
+ unsigned long flags;
if (!drive) {
printk (KERN_ERR "ide-scsi: drive id %d not present\n", cmd->target);
@@ -770,9 +771,9 @@
rq->buffer = (char *) pc;
rq->bh = idescsi_dma_bh (drive, pc);
rq->cmd = IDESCSI_PC_RQ;
- spin_unlock(&io_request_lock);
+ spin_unlock_irqrestore(&io_request_lock, flags);
(void) ide_do_drive_cmd (drive, rq, ide_end);
- spin_lock(&io_request_lock);
+ spin_lock_irqsave(&io_request_lock, flags);
return 0;
abort:
if (pc) kfree (pc);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu