INTEGRITY CHECKING NOTES:
-------------------------

Prototype code to implement integrity checking as 
specified in the SCSI Standards Committee T10/98-235r3 document.

Limitations: 
------------
The 'basic' and 'enhanced' tests have been implemented.  
The 'margining' tests are vendor specific and have not 
been implemented.


Kernel Modifications:
---------------------
hosts.h: The SCSI data structure Scsi_Device had one bit added, 
check_integrity.  This bit must be set if integrity checking is
to occur.

scsi.h:  The SCSI data structure Scsi_Cmnd had three negotiation
flags (ic_nego, ic_nego_width, ic_nego_speed) and two progress 
flags (ic_in_progress, ic_complete). 

scsi.c:  The function scan_scsis_single will perform integrity
checking if the check_integrity flag is set and the target lun is 0.


Driver Modifications:
---------------------
A specialized negotiation was added that is invoked only during
integrity checking.  This function utilizes the negotiation flags
to specify the message.  Additional code was added to save the 
negotiated values once the integrity check was complete.  All future
negotiations are restricted to the performance levels achieved during
the integrity check routine.

Integrity checking can be enabled by selecting the experimental
option (kernel) and enabling the driver option.
To over-ride, on module load:
    #insmod sym53c8xx sym53c8xx="buschk:4"
with lilo boot setup
     lilo: linux root=/dev/hda2 sym53c8xx=buschk:4


Needs:
------
Due to our limited hardware selection - we need help in identifying
devices that behave badly and verifying that the proposed changes
do not create other, unanticipated results.

If you have any problems with this code OR if you have a device
that behaves badly, send an email to pam.delaney@lsil.com

Known Badly Behaving Devices
  Micropolis 4345NV Drives - drive completely locks up when a 
                  read buffer follows a write buffer. A power
                  cycle is required to clear the device.

Known Devices with Minor Problems
 Quantum (9.1WLS, 4.5 WLS, 4.5 WSE) If the initiator ID > 7, 
      first command after a reserve results in a reservation problem.

These devices have not shown any problems with my testing:
 Conner CP30450
 HP  C2247, SureStore Dat40
 Quantum Ultra III 18GB
 Seagate ST39173LC, ST32171W, ST34501W
 Wester Digital Enterprise
 Epson Expression636


More Information:
-----------------

The basic test consists of negotiating to narrow and 
asyn and performing two Inquiry commands.  
Next, negotiate to the maximum width/speed
and perform another Inquiry.  The code is designed to issue
one negotiation per command (though this is compatible with
PPR negotiation too). If the resulting data compares,
the test passes.  If there is a miscompare, the process is 
repeated once.  On a second miscompare, bus width and/or speed
are reduced and the process is repeated.   The loop continues
until a successful comparison or async/narrow transmission 
characteristics are received.

The enhanced test validates the I/O path by using the targets
internal buffer.  This test consists of a Reserve and a 
read buffer capacity call.  If the read buffer command fails or
if the buffer size is zero, the device is released. Otherwise,
a series of four stress tests are written to, and read back from,
the internal buffer, and the results compared.  
Miscompares and bus resets (triggered by a timeout) 
result in reducing the bus performance. The test completes 
with a read capacity and an extended read (2kbytes)

**CD-ROMS will fail the read buffer test if the device is empty.**


Just for Fun:

If you are interested in watching the test sequence and are
running the driver as a module, configure syslog.conf to allow
messages to a console (i.e. uncomment the kern.* line),
open a console window (xconsole &)
and enter #echo "scsi log scan 7" >/proc/scsi/scsi
to enable much of the debugging information.  
To get message out/in information use the command line option
	debug:0x200  
and rebuild the module.


Thanks in Advance!