ncr53c8xx.txt

linux 内核源代码

10.6 SCSI BUS checking boot option.

When this option is set to a non-zero value, the driver checks SCSI lines 
logic state, 100 micro-seconds after having asserted the SCSI RESET line.
The driver just reads SCSI lines and checks all lines read FALSE except RESET.
Since SCSI devices shall release the BUS at most 800 nano-seconds after SCSI 
RESET has been asserted, any signal to TRUE may indicate a SCSI BUS problem.
Unfortunately, the following common SCSI BUS problems are not detected:
- Only 1 terminator installed.
- Misplaced terminators.
- Bad quality terminators.
On the other hand, either bad cabling, broken devices, not conformant 
devices, ... may cause a SCSI signal to be wrong when te driver reads it.

10.7 IMMEDIATE ARBITRATION boot option

This option is only supported by the SYM53C8XX driver (not by the NCR53C8XX).

SYMBIOS 53C8XX chips are able to arbitrate for the SCSI BUS as soon as they 
have detected an expected disconnection (BUS FREE PHASE). For this process 
to be started, bit 1 of SCNTL1 IO register must be set when the chip is 
connected to the SCSI BUS.

When this feature has been enabled for the current connection, the chip has 
every chance to win arbitration if only devices with lower priority are 
competing for the SCSI BUS. By the way, when the chip is using SCSI id 7, 
then it will for sure win the next SCSI BUS arbitration.

Since, there is no way to know what devices are trying to arbitrate for the 
BUS, using this feature can be extremely unfair. So, you are not advised
to enable it, or at most enable this feature for the case the chip lost 
the previous arbitration (boot option 'iarb:1').

This feature has the following advantages:

a) Allow the initiator with ID 7 to win arbitration when it wants so.
b) Overlap at least 4 micro-seconds of arbitration time with the execution 
   of SCRIPTS that deal with the end of the current connection and that 
   starts the next job.

Hmmm... But (a) may just prevent other devices from reselecting the initiator, 
and delay data transfers or status/completions, and (b) may just waste 
SCSI BUS bandwidth if the SCRIPTS execution lasts more than 4 micro-seconds.

The use of IARB needs the SCSI_NCR_IARB_SUPPORT option to have been defined 
at compile time and the 'iarb' boot option to have been set to a non zero 
value at boot time. It is not that useful for real work, but can be used 
to stress SCSI devices or for some applications that can gain advantage of 
it. By the way, if you experience badnesses like 'unexpected disconnections', 
'bad reselections', etc... when using IARB on heavy IO load, you should not 
be surprised, because force-feeding anything and blocking its arse at the 
same time cannot work for a long time. :-))


11. Some constants and flags of the ncr53c8xx.h header file

Some of these are defined from the configuration parameters.  To
change other "defines", you must edit the header file.  Do that only
if you know what you are doing.

SCSI_NCR_SETUP_SPECIAL_FEATURES	(default: defined)
	If defined, the driver will enable some special features according  
	to chip and revision id.
        For 810A, 860, 825A, 875 and 895 scsi chips, this option enables 
	support of features that reduce load of PCI bus and memory accesses 
	during  scsi transfer processing: burst op-code fetch, read multiple, 
        read line, prefetch, cache line, write and invalidate, 
        burst 128 (875 only), large dma fifo (875 only), offset 16 (875 only).
	Can be changed by the following boot setup command:
		ncr53c8xx=specf:n

SCSI_NCR_IOMAPPED		(default: not defined)
	If defined, normal I/O is forced.

SCSI_NCR_SHARE_IRQ		(default: defined)
	If defined, request shared IRQ.
	
SCSI_NCR_MAX_TAGS		(default: 8)
	Maximum number of simultaneous tagged commands to a device.
	Can be changed by "settags <target> <maxtags>"

SCSI_NCR_SETUP_DEFAULT_SYNC     (default: 50)
	Transfer period factor the driver will use at boot time for synchronous 
	negotiation. 0 means asynchronous.
	Can be changed by "setsync <target> <period factor>"

SCSI_NCR_SETUP_DEFAULT_TAGS     (default: 8)
	Default number of simultaneous tagged commands to a device.
	< 1 means tagged command queuing disabled at start-up.

SCSI_NCR_ALWAYS_SIMPLE_TAG	(default: defined)
	Use SIMPLE TAG for read and write commands.
	Can be changed by "setorder <ordered|simple|default>"

SCSI_NCR_SETUP_DISCONNECTION	(default: defined)
	If defined, targets are allowed to disconnect.

SCSI_NCR_SETUP_FORCE_SYNC_NEGO	(default: not defined)
	If defined, synchronous negotiation is tried for all SCSI-2 devices.
	Can be changed by "setsync <target> <period>"

SCSI_NCR_SETUP_MASTER_PARITY	(default: defined)
	If defined, master parity checking is enabled.

SCSI_NCR_SETUP_MASTER_PARITY	(default: defined)
	If defined, SCSI parity checking is enabled.

SCSI_NCR_PROFILE_SUPPORT	(default: not defined)
	If defined, profiling information is gathered.

SCSI_NCR_MAX_SCATTER		(default: 128)
	Scatter list size of the driver ccb.

SCSI_NCR_MAX_TARGET		(default: 16)
	Max number of targets per host.

SCSI_NCR_MAX_HOST		(default: 2)
	Max number of host controllers.

SCSI_NCR_SETTLE_TIME		(default: 2)
	Number of seconds the driver will wait after reset.

SCSI_NCR_TIMEOUT_ALERT		(default: 3)
	If a pending command will time out after this amount of seconds,
	an ordered tag is used for the next command.
	Avoids timeouts for unordered tagged commands.

SCSI_NCR_CAN_QUEUE		(default: 7*SCSI_NCR_MAX_TAGS)
	Max number of commands that can be queued to a host.

SCSI_NCR_CMD_PER_LUN		(default: SCSI_NCR_MAX_TAGS)
	Max number of commands queued to a host for a device.

SCSI_NCR_SG_TABLESIZE		(default: SCSI_NCR_MAX_SCATTER-1)
	Max size of the Linux scatter/gather list.

SCSI_NCR_MAX_LUN	(default: 8)
	Max number of LUNs per target.


12. Installation

This driver is part of the linux kernel distribution.
Driver files are located in the sub-directory "drivers/scsi" of the 
kernel source tree.

Driver files:

	README.ncr53c8xx	: this file
	ChangeLog.ncr53c8xx	: change log
	ncr53c8xx.h		: definitions
	ncr53c8xx.c		: the driver code

New driver versions are made available separately in order to allow testing 
changes and new features prior to including them into the linux kernel 
distribution. The following URL provides information on latest available 
patches: 

      ftp://ftp.tux.org/pub/people/gerard-roudier/README


13. Architecture dependent features.

<Not yet written>


14. Known problems

14.1 Tagged commands with Iomega Jaz device

I have not tried this device, however it has been reported to me the
following: This device is capable of Tagged command queuing. However
while spinning up, it rejects Tagged commands. This behaviour is
conforms to 6.8.2 of SCSI-2 specifications. The current behaviour of
the driver in that situation is not satisfying. So do not enable
Tagged command queuing for devices that are able to spin down.  The
other problem that may appear is timeouts. The only way to avoid
timeouts seems to edit linux/drivers/scsi/sd.c and to increase the
current timeout values.

14.2 Device names change when another controller is added.

When you add a new NCR53C8XX chip based controller to a system that already 
has one or more controllers of this family, it may happen that the order 
the driver registers them to the kernel causes problems due to device 
name changes.
When at least one controller uses NvRAM, SDMS BIOS version 4 allows you to 
define the order the BIOS will scan the scsi boards. The driver attaches 
controllers according to BIOS information if NvRAM detect option is set.

If your controllers do not have NvRAM, you can:

- Ask the driver to probe chip ids in reverse order from the boot command
  line: ncr53c8xx=revprob:y
- Make appropriate changes in the fstab.
- Use the 'scsidev' tool from Eric Youngdale.

14.3 Using only 8 bit devices with a WIDE SCSI controller.

When only 8 bit NARROW devices are connected to a 16 bit WIDE SCSI controller, 
you must ensure that lines of the wide part of the SCSI BUS are pulled-up.
This can be achieved by ENABLING the WIDE TERMINATOR portion of the SCSI 
controller card.
The TYAN 1365 documentation revision 1.2 is not correct about such settings.
(page 10, figure 3.3).

14.4 Possible data corruption during a Memory Write and Invalidate

This problem is described in SYMBIOS DEL 397, Part Number 69-039241, ITEM 4.

In some complex situations, 53C875 chips revision <= 3 may start a PCI 
Write and Invalidate Command at a not cache-line-aligned 4 DWORDS boundary.
This is only possible when Cache Line Size is 8 DWORDS or greater.
Pentium systems use a 8 DWORDS cache line size and so are concerned by 
this chip bug, unlike i486 systems that use a 4 DWORDS cache line size.

When this situation occurs, the chip may complete the Write and Invalidate 
command after having only filled part of the last cache line involved in 
the transfer, leaving to data corruption the remainder of this cache line.

Not using Write And Invalidate obviously gets rid of this chip bug, and so 
it is now the default setting of the driver.
However, for people like me who want to enable this feature, I have added 
part of a work-around suggested by SYMBIOS. This work-around resets the 
addressing logic when the DATA IN phase is entered and so prevents the bug 
from being triggered for the first SCSI MOVE of the phase. This work-around 
should be enough according to the following:

The only driver internal data structure that is greater than 8 DWORDS  and 
that is moved by the SCRIPTS processor is the 'CCB header' that contains 
the context of the SCSI transfer. This data structure is aligned on 8 DWORDS 
boundary (Pentium Cache Line Size), and so is immune to this chip bug, at 
least on Pentium systems.
But the conditions of this bug can be met when a SCSI read command is 
performed using a buffer that is 4 DWORDS but not cache-line aligned.
This cannot happen under Linux when scatter/gather lists are used since 
they only refer to system buffers that are well aligned. So, a work around 
may only be needed under Linux when a scatter/gather list is not used and 
when the SCSI DATA IN phase is reentered after a phase mismatch.

14.5 IRQ sharing problems

When an IRQ is shared by devices that are handled by different drivers, it 
may happen that one driver complains about the request of the IRQ having 
failed. Inder Linux-2.0, this may be due to one driver having requested the 
IRQ using the IRQF_DISABLED flag but some other having requested the same IRQ
without this flag. Under both Linux-2.0 and linux-2.2, this may be caused by 
one driver not having requested the IRQ with the IRQF_SHARED flag.

By default, the ncr53c8xx and sym53c8xx drivers request IRQs with both the 
IRQF_DISABLED and the IRQF_SHARED flag under Linux-2.0 and with only the IRQF_SHARED
flag under Linux-2.2.

Under Linux-2.0, you can disable use of IRQF_DISABLED flag from the boot
command line by using the following option:

     ncr53c8xx=irqm:0x20   (for the generic ncr53c8xx driver)
     sym53c8xx=irqm:0x20   (for the sym53c8xx driver)

If this does not fix the problem, then you may want to check how all other 
drivers are requesting the IRQ and report the problem. Note that if at least 
a single driver does not request the IRQ with the IRQF_SHARED flag (share IRQ),
then the request of the IRQ obviously will not succeed for all the drivers.

15. SCSI problem troubleshooting

15.1 Problem tracking

Most SCSI problems are due to a non conformant SCSI bus or to buggy
devices.  If unfortunately you have SCSI problems, you can check the
following things:

- SCSI bus cables
- terminations at both end of the SCSI chain
- linux syslog messages (some of them may help you)

If you do not find the source of problems, you can configure the
driver with no features enabled.

- only asynchronous data transfers
- tagged commands disabled
- disconnections not allowed

Now, if your SCSI bus is ok, your system have every chance to work
with this safe configuration but performances will not be optimal.

If it still fails, then you can send your problem description to
appropriate mailing lists or news-groups.  Send me a copy in order to
be sure I will receive it.  Obviously, a bug in the driver code is
possible.

     My email address: Gerard Roudier <[e-mail]>

Allowing disconnections is important if you use several devices on
your SCSI bus but often causes problems with buggy devices.
Synchronous data transfers increases throughput of fast devices like
hard disks.  Good SCSI hard disks with a large cache gain advantage of
tagged commands queuing.

Try to enable one feature at a time with control commands.  For example:

- echo "setsync all 25" >/proc/scsi/ncr53c8xx/0
  Will enable fast synchronous data transfer negotiation for all targets.

- echo "setflag 3" >/proc/scsi/ncr53c8xx/0
  Will reset flags (no_disc) for target 3, and so will allow it to disconnect 
  the SCSI Bus.

- echo "settags 3 8" >/proc/scsi/ncr53c8xx/0
  Will enable tagged command queuing for target 3 if that device supports it.

Once you have found the device and the feature that cause problems, just 
disable that feature for that device.

15.2 Understanding hardware error reports

When the driver detects an unexpected error condition, it may display a 
message of the following pattern.

sym53c876-0:1: ERROR (0:48) (1-21-65) (f/95) @ (script 7c0:19000000).
sym53c876-0: script cmd = 19000000
sym53c876-0: regdump: da 10 80 95 47 0f 01 07 75 01 81 21 80 01 09 00.

Some fields in such a message may help you understand the cause of the 
problem, as follows:

sym53c876-0:1: ERROR (0:48) (1-21-65) (f/95) @ (script 7c0:19000000).
............A.........B.C....D.E..F....G.H.......I.....J...K.......

Field A : target number.
  SCSI ID of the device the controller was talking with at the moment the