15. SCSI problem troubleshooting
15.1 Problem tracking
15.2 Understanding hardware error reports
-16. Synchonous transfer negotiation tables
+16. Synchronous transfer negotiation tables
16.1 Synchronous timings for 53C875 and 53C860 Ultra-SCSI controllers
16.2 Synchronous timings for fast SCSI-2 53C8XX controllers
17. Serial NVRAM support (by Richard Waltham)
It is now available as a bundle of 2 drivers:
- ncr53c8xx generic driver that supports all the SYM53C8XX family including
- the ealiest 810 rev. 1, the latest 896 (2 channel LVD SCSI controller) and
+ the earliest 810 rev. 1, the latest 896 (2 channel LVD SCSI controller) and
the new 895A (1 channel LVD SCSI controller).
- sym53c8xx enhanced driver (a.k.a. 896 drivers) that drops support of oldest
- chips in order to gain advantage of new features, as LOAD/STORE intructions
+ chips in order to gain advantage of new features, as LOAD/STORE instructions
available since the 810A and hardware phase mismatch available with the
896 and the 895A.
ftp://ftp.symbios.com/
-Usefull SCSI tools written by Eric Youngdale are available at tsx-11:
+Useful SCSI tools written by Eric Youngdale are available at tsx-11:
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsiinfo-X.Y.tar.gz
ftp://tsx-11.mit.edu/pub/linux/ALPHA/scsi/scsidev-X.Y.tar.gz
The 896 and the 895A allows handling of the phase mismatch context from
SCRIPTS (avoids the phase mismatch interrupt that stops the SCSI processor
until the C code has saved the context of the transfer).
-Implementing this without using LOAD/STORE instructions would be painfull
-and I did'nt even want to try it.
+Implementing this without using LOAD/STORE instructions would be painful
+and I didn't even want to try it.
The 896 chip supports 64 bit PCI transactions and addressing, while the
895A supports 32 bit PCI transactions and 64 bit addressing.
In order to really gain advantage of this feature, devices must have
a reasonable cache size (No miracle is to be expected for a low-end
hard disk with 128 KB or less).
-Some kown SCSI devices do not properly support tagged command queuing.
+Some known SCSI devices do not properly support tagged command queuing.
Generally, firmware revisions that fix this kind of problems are available
at respective vendor web/ftp sites.
All I can say is that the hard disks I use on my machines behave well with
support by the driver of this feature at linux start-up and enable
this feature after boot-up only for devices that support it safely.
-CONFIG_SCSI_NCR53C8XX_PROFILE_SUPPORT (default answer: n)
- This option must be set for profiling information to be gathered
- and printed out through the proc file system. This features may
- impact performances.
-
CONFIG_SCSI_NCR53C8XX_IOMAPPED (default answer: n)
Answer "y" if you suspect your mother board to not allow memory mapped I/O.
May slow down performance a little. This option is required by
A boot setup command for the ncr53c8xx (sym53c8xx) driver begins with the
driver name "ncr53c8xx="(sym53c8xx). The kernel syntax parser then expects
-an optionnal list of integers separated with comma followed by an optional
-list of comma-separated strings. Example of boot setup command under lilo
+an optional list of integers separated with comma followed by an optional
+list of comma-separated strings. Example of boot setup command under lilo
prompt:
lilo: linux root=/dev/hda2 ncr53c8xx=tags:4,sync:10,debug:0x200
Some scsi boards use a 875 (ultra wide) and only supply narrow connectors.
If you have connected a wide device with a 50 pins to 68 pins cable
converter, any accepted wide negotiation will break further data transfers.
- In such a case, using "wide:0" in the bootup command will be helpfull.
+ In such a case, using "wide:0" in the bootup command will be helpful.
10.2.14 Differential mode
diff:0 never set up diff mode
irqm:0 always open drain
irqm:1 same as initial settings (assumed BIOS settings)
irqm:2 always totem pole
- irqm:0x10 driver will not use SA_SHIRQ flag when requesting irq
- irqm:0x20 driver will not use SA_INTERRUPT flag when requesting irq
+ irqm:0x10 driver will not use IRQF_SHARED flag when requesting irq
+ irqm:0x20 driver will not use IRQF_DISABLED flag when requesting irq
(Bits 0x10 and 0x20 can be combined with hardware irq mode option)
ncr53c8xx=safe:y,mpar:y
ncr53c8xx=safe:y
-My personnal system works flawlessly with the following equivalent setup:
+My personal system works flawlessly with the following equivalent setup:
ncr53c8xx=mpar:y,spar:y,disc:y,specf:1,fsn:n,ultra:2,fsn:n,revprob:n,verb:1\
tags:32,sync:12,debug:0,burst:7,led:1,wide:1,settle:2,diff:0,irqm:0
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 SA_INTERRUPT flag but some other having requested the same IRQ
+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 SA_SHIRQ flag.
+one driver not having requested the IRQ with the IRQF_SHARED flag.
By default, the ncr53c8xx and sym53c8xx drivers request IRQs with both the
-SA_INTERRUPT and the SA_SHIRQ flag under Linux-2.0 and with only the SA_SHIRQ
+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 SA_INTERRUPT flag from the boot
+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)
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 SA_SHIRQ flag (share IRQ),
+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 infortunately you have SCSI problems, you can check the
+devices. If unfortunately you have SCSI problems, you can check the
following things:
- SCSI bus cables
You are not required to decode and understand them, unless you want to help
maintain the driver code.
-16. Synchonous transfer negotiation tables
+16. Synchronous transfer negotiation tables
Tables below have been created by calling the routine the driver uses
for synchronisation negotiation timing calculation and chip setting.
git://ftp.safe.ca / safe / jmp / linux-2.6 / blobdiff