>> From: Daniel R Risacher <risacher@worldnet.att.net>
>>
>> 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.
Mike> Don't be fooled by the macro; the flags parameter is written
Mike> (not read) by spin_lock_irqsave and then read by
Mike> spin_unlock_irqrestore.
Oh. Of course. Silly me. In that case, the patch I suggested is
almost definitely wrong. Someone with a bigger clue ought to look at
this, but I think it should be something like the following:
--- linux/drivers/scsi/ide-scsi.c.2.1.104-1 Fri May 29 06:12:39 1998
+++ linux/drivers/scsi/ide-scsi.c Sat May 30 22:11:44 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_irq(&io_request_lock);
(void) ide_do_drive_cmd (drive, rq, ide_end);
- spin_lock(&io_request_lock);
+ spin_lock_irq(&io_request_lock);
return 0;
abort:
if (pc) kfree (pc);
-- I wonder if man will walk on the moon in my lifetime? Daniel Risacher magnus@alum.mit.edu- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu