Messages in this thread |  | | | Date | Sun, 4 Jul 1999 10:39:04 +0200 (MET DST) | | From | Gerard Roudier <> | | Subject | Re: Kernel OOPS on 2.2.10 SCSI related, SCSI extensions |
| |
On Sat, 3 Jul 1999, Douglas Gilbert wrote:
> Gerard Roudier wrote:
> > But the "actual bytes transferred" does not make > > sense in SCSI due to the MODIFY DATA POINTER message. So does not make > > sense the calculation of any residual based on some DMA counter for the > > same reason. Even if the MODIFY DATA POINTER is rarely supported and/or > > used, we must consider it. > > > > You only need to be aware of the amount of data that has been transferred > > for some situations involving tape devices (stream devices). For these > > situations there are flags and REQUEST SENSE data that allow to deal with > > them gracefully. > > If a transfer count is good enough for CAM-3 it should > be good enough for us. [I prefer an absolute count > (defaulting to 0 for low level drivers that don't > support it) while the rest of the world prefers a > residual count. I will go with the majority on this > point.]
And if the majority is loose, such a "moutons de Panurge" bahaviour makes you as loose as the majority.
Just think about a device that uses MODIFY DATA POINTER message and let me know how you will calculate your residual/actual data counter and how the application will understand about the counter value when the transfer is partial.
No need to consider MDP, btw: a device is perfectly allowed to RESTORE the previously saved DATA POINTER and then to complete the command, even if it is stupid. Let me know how the majority will calculate the residual in such a _legal_ (but stupid) behaviour of the device.
What about intelligent controllers that donnot provide this information?
As an example, such a stupid "moutons de Panurge" behaviour led most SCSI device drivers to _wrongly_ associate the CmdQueue flag to the target. The CmdQueue bit must be associated to the logical unit that is the _real_ device.
> vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv > CAM-3 Working draft, rev 3 16-Mar-98 > page 144 section 11.8.1 in > typedef struct ccb_scsiio3 { > ... > CAM_I32 cam_resid; > ... > } CCB_SCSIIO3; > > - cam_resid > The data residual length member contains the difference > in twos complement form of the number of data bytes > transferred by the HA for the SCSI command compared > with the number of bytes requested by the CCB cam_dxfer_len > member. ... > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Both Doug Ledford (aic7xxx) and Bob Frey (advansys) have > indicated that they can provide this number. On the
So can provide this number the aic7xxx of FreeBSD and the aha(1542) device driver of FreeBSD, it seems. So, very probably associate the CmdQueue to the target all the drivers that have been mentionned.
It is not the majority, as far as I can tell, unless you consider that that Adaptec stuff and guys represents the majority.
> application side, Joerg Schilling (cdrecord), Monty > (cdparanoia) and David Mostang (sane) would like to > know this number.
AFAIK, the MDP is still in the SCSI specs. Even if the MDP has been used, we can calculate such a number, but it can only indicate if the transfer has been complete or partial (kind of error checking). It must not be used for anything else, unless the application ckecked that the MDP is not enabled for this device, and made sure that the involved SCSI device driver is smart enough not to be confused by a SCSI device that changed the data pointer by a restore just before completing the IO.
By the way, the CAM3 method is basically some reformulation of some DEC access method. It can be wrong or just loose in some places and some non-sense may have been missed by the SCSI committee.
Gérard.
- 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/
|  |