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.)
Daniel,
Does that driver take any account of Scsi_Cmnd::sc_data_direction_flag?
All upper level drivers (including sg) in the lk 2.4 series set
the corresponding Scsi_Request::sr_data_direction_flag .
In the case of sg in lk 2.4, it supports 2 interfaces:
- In the newer one (not yet used by cdrecord) the data
direction flag is given explicitly. [There could be
PCI bus problems if the app gets the direction wrong].
- In the older interface the internal data direction flag
is deduced from the sizes of the data buffers given.
There is a slight ambiguity when the write (to device)
buffer and the read (from device) buffer are both
given; a read from device data direction flag is assumed.
[BTW The SCSI_IOCTL_SEND_COMMAND ioctl() makes a similar
deduction.]
If cdrecord is sending a vendor specific command that
writes data to the device, but sets the read buffer
up as well and thus tricks the above logic, then we get
cdrecord changed. Cdrecord has a library called libscg
that interfaces to many OSes and the generic structures
within libscg have a data direction flag.
> 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.
Data direction tables shouldn't be needed in lk 2.4 .
Doug Gilbert
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to [EMAIL PROTECTED]
