> I had the same problem: there it a bug/incompatiblity between the ncr53c8xx
> & the scsi handler:
> (read the thread "Oops after scsi-reset (ncr53c8xx)" in linux-kernel).
>
> Could you please remove the following lines from drivers/scsi/ncr53c8xx.c:
> function ncr_reset_bus(), lines 5458-5459.
>
> if (!found && sync_reset && !retrieve_from_waiting_list(0, np, cmd)) {
> /* cmd->result = ScsiResult(DID_RESET, 0); <<<<<<<these 2 lines!
> ncr_queue_done_cmd(np, cmd); <<<<<<<<<<<<< */
> }
>
> That fixed the problem on my machine. Please send me an email if this fixed
> your problem!
> Please note that I've not checked any side effects, but the resulting driver
> runs without any problems.
>
> Explanation: scsi_old_done() sees that some devices do not respond to
> request sense, and calls scsi_reset(SCpnt, SCSI_RESET_SYNCHRONOUS). This
> function assumes that the Scsi_cmnd->scsi_done() is NOT called, but the
> ncr53c8xx calls this function, and some time later the system crashes
> because the same command is processed twice. (see the warning in
> scsi_obsolete.c, function scsi_old_done())
Your explain what happens, but I think it is scsi_obsolete.c that broke
the previous behaviour of scsi.c. The ncr53c8xx driver is fine with
respect to what the SCSI_RESET_SYNCHRONOUS flag is supposed to expect from
low level drivers, in my opinion.
The SCSI_RESET_SYNCHRONOUS flag tells low level drivers to call the done()
routine even if the command is not actually queued to it.
So, scsi_obsolete.c is wrong when trying to REDO this command but should
just return, IMO, as this was coded in 2.0 kernel/scsi.c
> > If none of the above actions are taken, the drive in question
> > will hang. If more than one of the above actions are taken by
> > scsi_done, then unpredictable behavior will result.
Indeed.
Regards,
Gerard.
-
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/