On Fri, Sep 28, 2007 at 04:15:56PM -0600, Moore, Eric wrote:
> On Tuesday, September 25, 2007 7:38 AM, Matthew Wilcox wrote:
>
> > As I said, it's ambitious. But it'll let us get rid of scsi_pointer
> > and host_scribble entirely.
>
> Are you serious about removing the host_scribble? In fusion we
> currently are hanging our per request message frame pointer there.
Yes. But you snipped the explanation about why we wouldn't need it any
more. You'd not be allocating scsi_cmnds, you'd be allocating a
struct fusion_scsi_cmnd {
struct scsi_cmnd scmd;
... everything currently in host_scribble ...
}
Of course, if you need the message frame pointer to be separated from
the command, you can just do:
struct fusion_scsi_cmnd {
struct scsi_cmnd scmd;
struct message_frame_pointer *host_scribble;
}
Or call it something more useful than host_scribble ;-)
> Its used for two reasons:
>
> (1) Old fibre channel firmware bug. The bug is the same message frame
> completed twice. 1st completion is okay and the scsi_cmd is reallocated
> to some other IO. Meanwhile the driver receives a double completion of
> the same message frame, and the driver attempts to complete the
> reallocated scsi_cmd to some other IO. The sanity check on
> host_scribble avoids this.
>
> (2) error recovery threads decides to complete a scsi_cmd before its
> been returned back by the scsi lld, and the scsi_cmd is reused for some
> other IO. Meanwhile fusion firmware finally decides it wants to
> command the command, then the driver is completing the reallocated
> scsi_cmd that is mapped to some other IO. Again, host_scribble sanity
> check makes sure we finish off the scsi_cmd that its intended for.
--
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours. We can't possibly take such
a retrograde step."
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
