[787] in linux-scsi channel archive
Bug in scsi.c and sd.c (handling of CHECK_CONDITION)?
daemon@ATHENA.MIT.EDU (D.A.B. Niggemann)
Thu Nov 9 00:46:20 1995
Date: Wed, 8 Nov 1995 17:19:37 +0000 (GMT)
From: "D.A.B. Niggemann" <dabn100@hermes.cam.ac.uk>
To: linux-scsi@vger.rutgers.edu
Hello!
I believe I amy have found a bug/error/irritating absence of feature in
scsi.c and sd.c. This concerns the handling of the following possible error:
a CHECK_CONDITION returned by a scsi disk, because of a low level harware
errror or something like that (say a CRC error). However, the disk
recovers and upon the mid level scsi driver sending out a request sense
message has RECOVERED_ERROR returned to it, with a possible further
syndrome report added in (ASCQ). Now, as far as I can tell the present
code _does_ try to make this error type invisible to the upper layer code
in sd.c. However, it fails in such a way as to
a. Make sd.c report an I/O error. This is more or less reasonable as a
recovered error generally means you are going to have problems here in
the future. However, sd.c doesn't recognize recovered errors (It just
treats it as an unknown error type.
b. As the infomation passed in the driver error variable doesn't include
PRINT_SENSE in this case (is the mid-level code attempting to make this
invisble?) no sense information is printed, just a copy of the driver error
variable, which is, needless to say, a bit hard to interpret!
The last time I actively saw this error was on kernel version 1.2.13 with
the (at that time) latest aic7xxx patches.
I know this error is not caused by the linux aic7xxx driver because I can
provoke the same sort of reaction using the SCSISelect ROM disk
verification routine.
I am going to test whether this error still occurs in 1.3.37 and see
whether I can think of a patch to correct it. However, I have to admit
the nesting of code in scsi_done (esp the fact that it is re-called during
a REQUEST_SENSE) is confusing me a bit ( iam not sure what happens to the
data transferred in previous read phase. Does a CHECK_CONDITION
imply no data was transerred?
System:
486DX2/66, 20MB RAM, 2842VL scsi HA, 2 HD's (very old ca. 1989 Siemens
MegaFile lab series SCSI-II drives 997MB and 640MB), 1 NEC CDR210 CD-ROM
MAXTOR RXT800S WORM drive.
BTW could somebody add the RXT800S revision J to the list of devices that
are broken in that they don't accept LUNS > 0?
the format would be:
{"MAXTOR","RXT-800S","J",BLIST_NOLUN}
Finally, could somebody give a suugestion as to how I could modify the
CD-ROM driver so as to make it return ENODATA to user programs if
1. The device is actually a WORM drive.
2. The device returns a BLANK_CHECK error.
I would be willing to invest some time in the following project:
modifying sr.c to give a sw.c WORM driver.
How soon is it intended that the Linux buffer cache will be modified to
support SCSI block sizes other than 512K, 1024K or 2048K (for CDs only)?
Is anybody working on this?
Thanks for any help,
Dirk.
__________________________________________________________
| / _ \ _ _| __ \ Dirk Niggemann
' / | | | | | Jesus College
. \ __ < | | | Cambridge, CB58BL
_|\_\_| \_\___|____/ dabn100@cam.ac.uk
__________________________________________________________
