> > 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
Check the 2.0 scsi.c code. It doesn't just return in all SCSI_RESET_SYNC
cases. That's part of the problem. There are three different places that
called SCSI_RESET_SYNC and they did two totally different things and gave the
low level driver no way to know the difference. Therefore, in the 2.0 scsi.c
code, there were checks to avoid re-use of the same command and double
queueing of commands. That's evidently what has been broken, the code itself
for SCSI_RESET_SYNC has always been broken and there was no right way to do
things, any way you did it was guaranteed to be wrong sometime. That's one of
the reasons why the mid-level code has needed re-written for so long.
--
Doug Ledford <dledford@redhat.com>
Opinions expressed are my own, but
they should be everybody's.
-
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/