On Feb 12, 8:49pm, Daniel Eisenbud wrote:
>
> Eight different SCSI drivers have large switch statements to determine
> the direction in which data will be transferred for a given SCSI
> command. I discovered this when trying to figure out why the MESH
> (powermac SCSI) driver locked up when (and only when) trying to burn a
> CD-R in disk-at-once mode. It turns out that there's a command that's
> not in any of these tables (cdrecord refers to it as send_cue_sheet) and
> it's absence is enough to kill the MESH driver (and apparently also the
> mac53c94 driver.) The other drivers in question may or may not be able
> to recover from the missing item in their tables, but the fact that
> these tables are in the drivers at all implies that they work best if
> the tables are correct.
>
> The attached patch does two things: it creates a new header file called
> scsi_dataout.h, which has a single copy of the switch statement (as a
> static function -- is that all right?) and is included by the relevant
> drivers. I checked that all the drivers had exactly equivalent switch
> statements. The new switch statement is that switch statement with
> SEND_CUE_SHEET (which I've added to include/scsi/scsi.h) added. This
> way if other commands need to be added to the switch statements in the
> future, it will be easy to do it in one central place.
>
> Clearly it is a problem that the mesh and mac53c94 drivers actually lock
> up hard when they get a command that they haven't seen before. When I
> have some time, I will learn more about the SCSI layer and see if I can
> fix this. But in the meantime, this patch prevents the known case that
> locks up, and is a cleanup to boot. Please let me know if there's
> anything I need to do differently to have a chance of this getting added
> to the kernel: I'm rather new to kernel hacking altogether.
Has a direction bit been considered for Linux SCSI infrastructure?
It would be useful to be able to specify this starting at the sg
level on through to the hba layer.
Since the only person who knows for sure the direction of data
transfer is the person writing a user app (in the case of sg), it
seems that it would make sense for the user app to be able to
specify the direction.
We currently support a RAID which uses vendor unique commands to do
device management. We need special versions of drivers that understand
the implied direction of the vendor unique commands. Under Irix, the
ds interface explicitly specifies a direction, so no driver code need
be changed to support this device.
jeremy
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
