[1214] in linux-scsi channel archive
Re: NCR 53c825 (53c8xx vs. 53c7,8xx)
daemon@ATHENA.MIT.EDU (Gerard Roudier)
Fri Jan 3 11:46:52 1997
Date: Fri, 3 Jan 1997 17:33:27 +0000 (GMT)
From: Gerard Roudier <groudier@club-internet.fr>
To: Dirk Foersterling <dirk@informatik.uni-frankfurt.de>
cc: Linux SCSI <linux-scsi@vger.rutgers.edu>, Stefan Esser <se@FreeBSD.org>
In-Reply-To: <Mutt.19970103160436.dirk@infinity.milliByte.de>
On Fri, 3 Jan 1997, Dirk Foersterling wrote:
> Hi, SCSI Linuxers.
>
> Just curiosity:
>
> I have an NCR 53C825 based hostadapter, and with the 53c8xx driver I get
> the following messages short after starting to use the scanner:
>
[ init messages removed ...]
> Jan 3 13:38:44 infinity kernel: ncr53c825-0-<target 6, lun 0>: extraneous data discarded.
> Jan 3 13:38:44 infinity kernel: ncr53c825-0-<target 6, lun 0>: COMMAND FAILED (9 0) @0137a810.
> Jan 3 13:38:58 infinity kernel: ncr53c825-0: restart (ncr dead ?).
>
> Then, I used the other driver (ncr53c7,8xx) and the result was:
>
[ init messages removed ...]
>
> [scan did function properly]
I am interested in the opcode that cause problem.
(Config "verbose scsi messages" will probably print it to the syslog)
I think I guess what's wrong.
Obviously, application programs known the direction of data transfer.
However, the scsi upper and middle-driver do not send this information
to low-level drivers under Linux.
(I never used the sg driver, but I think is does not require the direction
of transfer prior to queuing the command to the low-level driver).
The fact, that the expected direction of transfer is not passed to the low
level drivers is, in my opinion, an design flaw of the linux scsi sub-system.
It is probably too late to change that and we probably must live with the
risk that brain-deaded devices may send data to the host when we expect
data to be sent to the device.
This driver has been ported from FreeBSD. Under FreeBSD, the expected
direction of transfer is passed to low-level drivers.
A recipe exists to deduce a scsi command length from the opcode.
I did not find an equivalent formula to deduce the transfer direction
from the opcode and very probably such a formula does not exist.
So, there is a routine in the ported driver that tries to guess the
expected transfer direction.
This guess is probably not enough or perhaps have errors, or "scan" uses
some proprietary commands for your scanner.
I know that I have to change something in the driver in order to allow
both possible directions for "unknown" command.
That is possible, since the target informs the driver of data direction
with MSG C/D I/O signals.
If this change was easy (for me) I probably had done it already. But it is
not and I will ask Stefan Esser, author of the original driver, about such a
change.
Regards, Gerard.
