Copyright 1994, Drew Eckhardt Commercial redistribution is allowed and encouraged, provided that the author is notified of any such distributions and given opportunity to to provide a more up-to-date version. Failure to comply with this will result in the author refusing to answer questions which are answered in newer versions, and publically denouncing your distribution as a grave disservice to the Linux community. Noncommercial redistributions of a verbatim copy in any medium physical or electronic are permitted without express permission of the author. Translations are similarly permitted without express permission if they includes a notice on who translated it. Short quotes may be used without prior consent by the author. Derivative work and partial distributions of the SCSI-HOWTO must include either a verbatim copy of this file or make a verbatim copy of this file available. If the latter is the case, a pointer to the verbatim copy must be stated at a clearly visible place. In short, we wish to promote dissemination of this information through as many channels as possible. However, we do wish to retain copyright on the HOWTO documents, to be notified of any plans to redistribute the HOWTOs to insure that outdated versions don't spread too far, and for ALL the information provided in the HOWTOS to be disseminated. If you have questions, please contact Matt Welsh, the Linux HOWTO coordinator, at mdw@sunsite.unc.edu, or +1 607 256 7372. IMPORTANT : BUG REPORTS WHICH FAIL TO FOLLOW THE PROCEDURE OUTLINED IN SECTION 2 WILL BE IGNORED. This HOWTO covers the Linux SCSI subsystem, as implemented in Linux kernel revision 1.1.38 and newer alpha code. Earlier revisions of the SCSI code are _unsupported_, and may differ significantly in terms of the drivers implemented, performance, and options available. For additional information, you may wish to join the SCSI channel of the Linux activists list - mail to linux-activists-request@joker.cs.hut.fi with the line X-MN-Admin: join SCSI in the header. I'm aware that this document isn't the most user-friendly, and that there may be inaccuracies and oversights. If you have constructive comments on how to rectify the situation you're free to mail me about it. Table of contents Section 1 Common Problems Section 1.1 General Flakiness Section 1.2 The kernel command line Section 1.3 A SCSI device shows up at all possible IDs Section 1.4 A SCSI device shows up at all possible LUNs Section 1.5 You get sense errors when you know the devices are error free Section 1.6 A kernel configured with networking does not work. Section 1.7 Device detected, but unable to access. Section 1.8 Sometimes the scsi subsystem locks up completely. Section 1.9 Configuring and building the kernel Section 2 Reporting Bugs Section 3 Hosts Section 3.1 Supported and Unsupported Hardware Section 3.2 Common Problems Section 3.3 Adaptec 152x, 151x, Sound Blaster 16 SCSI, SCSI Pro, Gigabyte, and other AIC 6260/6360 based products (Standard) Section 3.4 Adaptec 154x, AMI FastDisk VLB, Buslogic, DTC 329x (Standard) Section 3.5 Adaptec 174x (Standard) Section 3.6 Adaptec 274x (pre-ALPHA) Section 3.7 Allways IN2000 (ALPHA) Section 3.8 DPT (ALPHA) Section 3.9 Future Domain 16x0 with TMC-1800, TMC-18C30, or TMC-18C50 chip (Standard) Section 3.10 Generic NCR5380 / T130B (Standard) Section 3.11 NCR53c810 (Standard) Section 3.12 Seagate ST0x/Future Domain TMC-8xx/TMC-9xx (Standard) Section 3.13 PAS16 (Standard) Section 3.14 Trantor T128/T128F/T228 (Standard) Section 3.15 Ultrastor 14f, 24f, 34f (Standard) Section 3.16 Western Digital 7000 (Standard) Section 4 Disks Section 4.1 Supported and Unsupported Hardware Section 4.2 Common Problems Section 4.3 Device Files Section 4.4 Partitioning Section 4.5 Disk Geometry Section 5 CD ROMs Section 5.1 Supported and Unsupported Hardware Section 5.2 Common Problems Section 5.3 Device Files Section 6 Tapes Section 6.1 Supported and Unsupported Hardware Section 6.2 Common Problems Section 6.3 Device Files Section 7 Generic Section 7.1 Supported and Unsupported Hardware Section 7.2 Common Problems Section 7.3 Device Files Section 8 Buyers Guide Section 1 : Common Problems This section lists some of the common problems that people have. If there is not anything here that answers your questions, you should also consult the sections for your host adapter and the devices in that are giving you problems. Section 1.1 : General Flakiness If you experience random errors, the most likely causes are cabling and termination problems. Some products, such as those built arround the newer NCR chips, feature digital filtering, active signal negation, and aren't very sensitive to cabling problems. Others, such as the Adaptec 154xC, 154xCF, and 274x, are _extremely_ sensitive and may fail with cables that work with other systems. I reiterate : some host adapters are _extremely_ sensitive to cabling and termination problems and therefore, cabling and termination should be the first things checked when there are problems. To minimize your problems, you should use cables which 1. Claim SCSI-II compliance 2. Have a characteristic impedance of 132 ohms 3. All come from the same source to avoid impedance mismatches 4. Come from a reputable vendor such as Amphenol who Termination power should be provided by _all_ devices on the SCSI bus, through a diode to prevent current backflow, so that sufficient power is available at the ends of the cable where it is needed. To prevent damage if the bus is shorted, TERMPWR should be driven through a fuse or other current limiting device. If multiple devices, external cables, or FAST SCSI 2 are used, active or forced perfect termination should be used on both ends of the SCSI bus. See the Comp.Periphs.Scsi FAQ (available on tsx-11 in pub/linux/ALPHA/scsi) for more information about active termination. Section 1.2 : The kernel command line Other parts of the documentation refer to a "kernel command line". The kernel command line is a set of options you may specify from either the LILO : prompt after an immage name, or in the append field in your LILO configuration file (typically /etc/lilo/config). Boot your system with LILO, and hit one of the alt, control, or shift keys when it first comes up to get a prompt. LILO should respond with : At this prompt, you can select a kernel image to boot, or list them with ?. Ie :? ramdisk floppy harddisk To boot that kernel with the command line options you have selected, simply enter the name followed by a white space delimited list of options, terminating with a return. Options take the form of variable=valuelist Where valuelist may be a single value or comma delimited list of values with no whitespace. With the exception of root device, individual values are numbers, and may be specified in either decimal or hexadecimal. Ie, to boot linux with an Adaptec 1520 clone not recognized at bootup, you might type Ie, to boot linux with an Adaptec 1520 clone not recognized at bootup, you might type :floppy aha152x=0x340,11,7,1 If you don't care to type all of this at boot time, it is also possible to use the LILO configuration file "append" option with LILO .13 and newer. Section 1.3 : A SCSI device shows up at all possible IDs If this is the case, you have strapped the device at the same address as the controller (typically, 7, although some boards use other addresses). Please change the jumper settings. Section 1.4 : A SCSI device shows up at all possible LUNs The device has buggy firmware. There is a list of buggy devices in the kernel sources in drivers/scsi/scsi.c in the variable blacklist. Try adding the device to the list and see if this helps. Section 1.5 : You get sense errors when you know the devices are error free Sometimes this is caused by bad cables or impropper termination. Your SCSI bus must be terminated at both ends (using external terminators, or onboard terminators on the host adapter or devices) and not in the middle. The SCSI-2 specification recommends active termination at both ends of the cable. For SCSI configurations with just one device and a short cable, you can probably get away with passive termination, but if you start having SCSI reliability problems when you start adding more devices or using a longer cable then you should try active termination. See the Comp.Periphs.Scsi FAQ (available on tsx-11 in pub/linux/ALPHA/scsi) for more information about active termination. Section 1.6 : A kernel configured with networking does not work. The auto-probe routines for many of the network drivers are not passive, and will interfere with operation with some of the SCSI drivers. Section 1.7 : Device detected, but unable to access. A SCSI device is detected by the kernel, but you are unable to access it - ie mkfs /dev/sdc, tar xvf /dev/rst2, etc fails. You don't have a special file in /dev for the device. Unix devices are identified as either block or character (block devices go through the buffer cache, character devices do not) devices, a major number (ie which driver is used - block major 8 corresponds to SCSI disks) and a minor number (ie which unit is being accessed through a given driver - ie character major 4, minor 0 is the first virtual console, minor 1 the next, etc). However, accessing devices through this separate namespace would break the unix/Linux metaphor of "everything is a file," so character and block device special files are created under /dev. This lets you access the raw third SCSI disk device as /dev/sdc, the first serial port as /dev/ttyS0, etc. The preferred method for creating a file is using the MAKDEV script - cd /dev and run MAKEDEV (as root) for the devices you want to create - ie ./MAKEDEV sdc wildcards "should" work - ie ./MAKEDEV sd\* "should" create entries for all SCSI disk devices (doing this should create /dev/sda through /dev/sdp, with fifteen partition entries for each) ./MAKEDEV sdc\* "should" create entries for /dev/sdc and all fifteen permissible partitions on /dev/sdc, etc. I say "should" because this is the standard unix behavior - the MAKEDEV script in your installation may not conform to this behavior, or may have restricted the number of devices it will create. If MAKEDEV won't do the right magic for you, you'll have to create the device entries by hand with the mknod command. The block/character type, major, and minor numbers are specified for the various SCSI devices in Subsection 3 : Device Files in the appropriate section. Take those numbers, and use (as root) mknod /dev/device b|c major minor ie - mknod /dev/sdc b 8 32 mknod /dev/rst0 c 9 0 Section 1.8 : SCSI System Lockups This could be one of a number of things. Also see the section for your specific host adapter for possible further solutions. There are cases where the lockups seem to occur when multiple devices are in use at the same time. In this case, you can try contacting the manufacturer of the devices and see if firmware upgrades are available which would correct the problem. If possible, try a different scsi cable, or try on another system. This can also be caused by bad blocks on disks, or by bad handling of DMA by the motherboard (for host adapters that do DMA). There are probably many other possible conditions that could lead to this type of event. Sometimes these problems occur when there are multiple devices in use on the bus at the same time. In this case, if your host adapter driver supports more than one outstanding command on the bus at one time, try reducing this to 1 and see if this helps. If you have tape drives or slow cdrom drives on the bus, this might not be a practical solution. Section 1.9 : Configuring and building the kernel Unused SCSI drivers eat up valuable memory, aggravating memory shortage problems on small systems because kernel memory is unpagable. So, you will want to build a kernel tuned for your system, with only the drivers you need installed. cd to /usr/src/linux If you are using a root device other than the current one, or something other than 80x25 VGA, and you are writing a boot floppy, you should edit the makefile, and make sure the ROOT_DEV = and SVGA_MODE = lines are the way you want them. If you've installed any patches, you may wish to guarantee that all files are rebuilt. If this is the case, you should type make mrproper Irregardless of weather you ran make mrproper, type make config and answer the configuration questions. Then run make depend and finally make Once the build completes, you may wish to update the lilo configuration, or write a boot floppy. A boot floppy may be made by running make zdisk Section 2 : Reporting Bugs The Linux SCSI developers don't necessarily maintain old revisions of the code due to space constraints. So, if you are not running the latest publically released Linux kernel (note that many of the Linux distributions, such as MCC, SLS, Yggdrasil, etc. often lag one or more revisions behind this) chances are we will be unable to solve your problem. So, before reporting a bug, please check to see if it exists with the latest publically available kernel. If after upgrading, and reading this document thoroughly, you still believe that you have a bug, please mail a bug report to the SCSI channel of the mailing list where it will be seen by many of the people who've contributed to the Linux SCSI drivers. In your bug report, please provide as much information as possible regarding your hardware configuration, and the exact text of all of the messages that Linux prints when it boots and when the error condition occurs. Failure to provide the exact text of any and all messages may result in misdiagnosis of your problem. The bottom line is that if we can't reproduce your bug, and you can't point at us what's broken, it won't get fixed. Assuming you don't yet have Linux up and running, a good way to provide the information we need would be to perform the following procedure : Format a floppy diskette under DOS. Note that if you have a distribution which mounts the root diskette off of floppy rather than RAM drive, you'll have to format a diskette readable in the drive not being used to mount root. Boot Linux, and login as root mkdir /tmp/dos Insert the diskette in a drive not being used to mount root, and mount it. Ie mount -t msdos /dev/fd0 /tmp/dos or mount -t msdos /dev/fd1 /tmp/dos Insure that the /proc filesystem is mounted. grep proc /etc/mtab If the /proc filesystem is not mounted, mount it mkdir /proc chmod 755 /proc mount -t proc /proc /proc Copy the kernel revision and messages into a log file cat /proc/version > /tmp/dos/log cat /proc/kmsg >> /tmp/dos/log Type CNTRL-C after a second or two. Unmount the DOS floppy umount /tmp/dos And shutdown Linux shutdown Reboot into DOS, and using your favorite communications software include the log file in your trouble mail. Section 3 : Hosts This section gives specific information about the various host adapters that are supported in some way or another under linux. Section 3.1 : Supported and Unsupported Hardware Drivers in the distribution kernel : Adaptec 152x, Adaptec 154x (including clones from Bustek and DTC 329x boards), Adaptec 174x, Future Domain 850, 885, 950, and other boards in that series (but not the 880 board unless you make the appropriate patch), Future Domain 16x0 with TMC-1800 or TMC-18C50 chip, PAS16 SCSI ports, Seagate ST0x, Trantor T128 boards, Ultrastor 14F, 24F, and 34F, and Western Digital 7000. Alpha drivers : Adaptec 2742 DPT Richoh GSI-8 Many of the ALPHA drivers are available via anonymous FTP from tsx-11.mit.edu:/pub/linux/ALPHA/scsi Drivers that are being developed, but aren't publically available yet, and modifications needed to make existing drivers compatable with other boards : Announcements WILL be made when drivers are available for public alpha testing. Until then, please don't use up the developers' valuable time with mail asking for release dates, etc. Adaptec 2842, 2940, various AIC 7770/7870 implementations An Adaptec 2742 driver for the EISA AIC-7770 board has been developed, and with some modifications (perhaps limited to detection) should support these boards. NCR53c8x0/7x0 A NCR53c810 drviver has been developed, and with modifications ranging from minor to severe should support these chips NCR53c815 - detection changes NCR53c820, NCR53c825 - detection changes, possible initialization changes, ultimately support for WDTR messages. NCR53c720 - detection changes, initializaion changes, modification of the assembler to use the 720's register mapping NCR53c710 - detection changes, initialization changes, modification of assembler, modification of the NCR code to use fatal interrupts or GPIO generated non fatal interrupts for command completion, elimination of add with carry instructions through DSA alignment modification. NCR53c700, NCR53c700-66 - detection changes, initialization changes, modification of NCR code to not use DSA, modification of Linux code to handle context switches. NCR53c9x family Qlogic Trantor T130B / generic NCR53c400 using pseudo DMA The Trantor T130B uses an NCR53c400 chip, essentially a more integrated, low-performance ISA SCSI solution adding a pair of 128 byte buffers and on-chip "pseudo-DMA" hardware to a NCR5380 ASIC core Kevin's patches to support the on-chip buffers and interrupts on the board work, and an effort to integrate them into an ALPHA kernel is being made. SCSI hosts that will not work : All parallel->SCSI adapters, Rancho SCSI boards, and Grass Roots SCSI boards. SCSI hosts that will NEVER work : Non Adaptec compatable DTC boards (including the 3270 and 3280). Aquiring programming information requires a non-disclosure agreement with DTC. This means that it would be impossible to distribute a Linux driver if one were written, since complying with the NDA would mean distributing no source, in violation of the GPL, and complying with the GPL would mean distributing source, in violation of the NDA. If you want to run Linux on an unsupported piece of hardware, your options are to either write a driver yourself (Eric Youngdale and I are usually willing to answer technical questions concerning the Linux SCSI drivers) or to commision a driver. Section 3.2 : Common Problems Section 3.2.1 : SCSI timeouts Make sure interrupts are enabled correctly, and there are no IRQ, DMA, or address conflicts with other boards. Section 3.2.2 : Failure of autoprobe routines on boards that rely on BIOS for autoprobe. If your SCSI adapter is one of the following : Adaptec 152x, Adaptec 151x, Adaptec AIC-6260, Adaptec AIC-6360, Future Domain 1680, Future Domain TMC-950, Future Domain TMC-8xx, Trantor T128, Trantor T128F, Trantor T228F, Seagate ST01, Seagate ST02, or a Western Digital 7000 and it is not detected on bootup, ie you get a scsi : 0 hosts message or a scsi%d : type message is not printed for each supported SCSI adapter installed in the system, you may have a problem with the autoprobe routine not knowing about your board. Autodetection will fail for drivers using the BIOS for autodetection if the BIOS is disabled. Double check that your BIOS is enabled, and not conflicting with any other peripherial BIOSes. Autodetection will also fail if the board's "signature" and/or BIOS address don't match known ones. If the BIOS is installed, please use DOS and DEBUG to find a signature that will detect your board - Ie, if your board lives at 0xc8000, under DOS do debug d c800:0 q and send a message to the SCSI channel of the mailing list with the ASCII message, with the length and offset from the base address (ie, 0xc8000). Note that the EXACT text is required, and you should provide both the hex and ASCII portions of the text. If no BIOS is installed, and you are using an Adaptec 152x, Trantor T128, or Seagate driver, you can use command line or compile time overrides to force detection. Please consult the appropriate subsection for your SCSI board as well as Section 1.1 : Section 3.2.3 : Failure of boards using memory mapped I/O (This include the Trantor T128 and Seagate boards, but not the Adaptec, Generic NCR5380, PAS16, and Ultrastor drivers) This is often caused when the memory mapped I/O ports are incorrectly cached. You should have the board's address space marked as uncachable in the XCMOS settings. If this is not possible, you will have to disable cache entirely. Section 3.2.4 : Failure of bootable kernels for a ALPHA drivers This You get resulting in a "kernel panic : cannot mount root device" message, or it does not work with your Linux distribution. You'll need to edit the binary image of the kernel (before or after writing it out to disk), and modify a few two byte fields (little endian) to gurantee that it will work on your system. 1. default swap device at offset 502, this should be set to 0 2. ram disk size at offset 504, this should be set to the size of the boot floppy in K - ie, 5.25" = 1200, 3.5" = 1440. This means the bytes are 3.5" : 0xA0 0x05 5.25" : 0xB0 0x04 3. root device offset at 508, this should be 0, ie the boot device. dd or rawrite the file to a disk. Insert the disk in the first floppy drive, wait until it prompts you to insert the root disk, and insert the root floppy from your distribution. Section 3.2.5 : Installing a device driver not included with the distribution kernel You need to start with the version of the kernel used by the driver author. This revision may be alluded to in the documentation included with the driver. Various recent kernel revisions can be found at nic.funet.fi:/pub/OS/Linux/PEOPLE/Linus as linux-version.tar.gz They are also mirrored at tsx-11.mit.edu and various other sites. cd to /usr/src. Remove your old Linux sources, if you want to keep a backup copy of them mv linux linux-old Untar the archive gunzip < linux-0.99.12.tar.gz | tar xvfp - Apply the patches. The patches will be relative to some directory in the filesystem. By examining the output file lines in the patch file (grep for ^---), you can tell where this is - ie patches with these lines --- ./kernel/blk_drv/scsi/Makefile --- ./config.in Wed Sep 1 16:19:33 1993 would have the files relative to /usr/src/linux. Untar the driver sources at an appropriate place - you can type tar tfv patches.tar to get a listing, and move files as necessary (The SCSI driver files should live in /usr/src/linux/kernel/drivers/scsi) Either cd to the directory they are relative to and type patch -p0 < patch_file or tell patch to strip off leading path components. Ie, if the files started with --- linux-new/kernel/blk_drv/scsi/Makefile and you wanted to apply them while in /usr/src/linux, you could cd to /usr/src/linux and type patch -p1 < patches to strip off the "linux-new" component. After you have applied the patches, look for any patch rejects, which will be the name of the rejected file with a # suffix appended. find /usr/src/linux/ -name "*#" -print If any of these exist, look at them. In some cases, the differences will be in RCS identifiers and will be harmless, in other cases, you'll have to manually apply important parts. Documentation on diffs files and patch is beyond the scope of this document. See also Section 1.8 : Configuring and building the kernel 3.2.6 : Installing a driver that has no patches In some cases, a driver author may not offer patches with the .c and .h files which comprise his driver, or the patches may be against an older revision of the kernel and not go in cleanly. 1. Copy the .c and .h files into /usr/src/linux/drivers/scsi 2. Add the configuration option Edit /usr/src/linux/config.in, and add a line in the * * SCSI low-level drivers * section, add a boolean configuration variable for your driver. Ie, bool 'Allways IN2000 SCSI support' CONFIG_SCSI_IN2000 y 3. Add the makefile entries Edit /usr/src/linux/drivers/scsi/Makefile, and add an entry like ifdef CONFIG_SCSI_IN2000 SCSI_OBS := $(SCSI_OBJS) in2000.o SCSI_SRCS := $(SCSI_SRCS) in2000.c endif before the scsi.a: $(SCSI_OBJS) line in the makefile, where the .c file is the .c file you copied in, and the .o file is the basename of the .c file with a .o suffixed. 4. Add the entry points Edit /usr/src/linux/drivers/scsi/hosts.c, and add a #inlclude for the header file, conditional on the CONFIG_SCSI preprocessor define you added to the configuration file. Ie, after #ifdef CONFIG_SCSI_GENERIC_NCR5380 #include "g_NCR5380.h" #endif you might add #ifdef CONFIG_SCSI_IN2000 #include "in2000.h" #endif You will also need to add the Scsi_Host_Template entry into the scsi_hosts[] array. Take a look into the .h file, and you should find a #define that looks something like this : #define IN2000 {"Always IN2000", in2000_detect, \ in2000_info, in2000_command, \ in2000_queuecommand, \ in2000_abort, \ in2000_reset, \ NULL, \ in2000_biosparam, \ 1, 7, IN2000_SG, 1, 0, 0} the name of the preprocessor define, and add it into the scsi_hosts[] array, conditional on definition of the preprocessor symbol you used in the configuration file. Ie, after #ifdef CONFIG_SCSI_GENERIC_NCR5380 GENERIC_NCR5380, #endif you might add #ifdef CONFIG_SCSI_IN2000 IN2000, #endif See also Section 1.8 : Configuring and building the kernel Section 3.3 : Adaptec 152x, 151x, Sound Blaster 16 SCSI, SCSI Pro, Gigabyte, and other AIC 6260/6360 based products (Standard) Supported Configurations : BIOS addresses : 0xd8000, 0xdc000, 0xd0000, 0xd4000, 0xc8000, 0xcc000, 0xe0000, 0xe4000. Ports : 0x140, 0x340 IRQs : 9, 10, 11, 12 DMA is not used IO : port mapped Autoprobe : Works with many boards with an installed BIOS. All other boards, including the Adaptec 1510, and Sound Blaster16 SCSI must use a kernel command line or compile time override. Autoprobe Override : Compile time : Define PORTBASE, IRQ, SCSI_ID, RECONNECT as appropriate, see Defines kernel command line : aha152x=,,, Usually, SCSI-ID will be 7 and RECONNECT non-zero. To force detection at 0x340, IRQ 11, at SCSI-ID 7, allowing disconnect/reconnect, you would use the following command line option : aha152x=0x340,11,7,1 Antiquity Problems, fix by upgrading : 1. The driver fails with VLB boards. There was a timing problem in kernels older than revision 1.0.5. Defines : AUTOCONF : use configuration the controller reports (only 152x) IRQ : override interrupt channel (9,10,11 or 12) (default 11) SCSI_ID : override scsiid of AIC-6260 (0-7) (default 7) RECONNECT : override target dis-/reconnection/multiple outstanding command - set to non-zero to enable, zero to disable. DONT_SNARF : Don't register ports (pl12 and below) SKIP_BIOSTEST : Don't test for BIOS signature (AHA-1510 or disabled BIOS) PORTBASE : Force port base. Don't try to probe Section 3.4 : Adaptec 154x, AMI FastDisk VLB, Buslogic, DTC 329x (Standard) Supported Configurations : Ports : 0x330 and 0x334 IRQs : 9, 10, 11, 12, 14, 15 DMA channels : 5, 6, 7 IO : port mapped, bus master Autoprobe : works with all supported configurations, does not require an installed BIOS. Autoprobe override : none Note: Buslogic makes a series of boards that are software compatible with the Adaptec 1542, and these come in ISA, VLB and EISA flavors. Antiquity Problems, fix by upgrading : 1. Linux kernel revisions prior to .99.10 don't support the 'C' revision. 2. Linux kernel revisions prior to .99.14k don't support the 'C' revision options for - BIOS support for the extended mapping for disks > 1G - BIOS support for > 2 drives - BIOS support for autoscanning the SCSI bus 3. Linux kernel revisions prior to .99.15e don't support the 'C' with the BIOS support for > 2 drives turned on and the BIOS support for the extended mapping for disks > 1G turned off. 4. Linux kernel revisions prior to .99.14u don't support the 'CF' revisions of the board. 5. Linux kernel revisions prior to 1.0.5 have a race condition when multiple devices are accessed at the same time. Common problems : 1. There are unexpected errors with a 154xC or 154xCF board, Early examples of the 154xC boards have a high slew rate on one of the SCSI signals, which results in signal reflections when cables with the wrong impedance are used. Newer boards aren't much better, and also suffer from extreme cabling and termination sensitivity. See also Common Problems #2 and #3 and Section 1 : Common Problems, Subsection 1.1 : General Flakiness 2. There are unexpected errors with a 154xC or 154x with both internal and external devices connected. This is probably a termination problem. In order to use the software option to disable host adapter termination, you must turn switch 1 off. See also Common Problems #1 and #3 and Section 1 : Common Problems, Subsection 1.1 : General Flakiness 3. The SCSI subsystem locks up completely. There are cases where the lockups seem to occur when multiple devices are in use at the same time. In this case, you can try contacting the manufacturer of the devices and see if firmware upgrades are available which would correct the problem. As a last resort, you can go into aha1542.h and change AHA1542_MAILBOX to 1. This will effectively limit you to one outstanding command on the scsi bus at one time, and may help the situation. If you have tape drives or slow cdrom drives on the bus, this might not be a practical solution. See also Common Problems #1 and #2 and Section 1.1 : Common Problems : General Flakiness Section 1.8 : Common Problems : SCSI Lockups 4. An "Interrupt received, but no mail" message is printed on bootup and your SCSI devices are not detected. Disable the BIOS options to support the extended mapping for disks > 1G, support for > 2 drives, and for autoscanning the bus. Or, upgrade to Linux .99.14k or newer. Section 3.5 : Adaptec 174x Supported Configurations : Slots : 1-8 Ports : EISA board, not applicable IRQs : 9, 10, 11, 12, 14, 15 DMA Channels : EISA board, not applicable IO : port mapped, bus master Autoprobe : works with all supported configurations Autoprobe override : none Note: This board has been discontinued by Adaptec. Common Problems : 1. If the Adaptec 1740 driver prints the message "aha1740: Board detected, but EBCNTRL = %x, so disabled it." your board was disabled because it was not running in enhanced mode. Boards running in standard 1542 mode are not supported. Section 3.6 : Adaptec 274x (Pre-ALPHA) available via anonymous FTP from ftp.cpsc.ucalgary.ca /pub/systems/linux/aha274x. Supported Configurations : Slots : 1-12 Ports : EISA board, not applicable IRQs : ALL DMA Channels : EISA board, not applicable IO : port mapped, bus master BIOS MUST be enabled Section 3.7 : Allways IN2000 (ALPHA) ALPHA available via ftp tsx-11.mit.edu/pub/linux/ALPHA/SCSI/in2000 driver is in2000.tar.z, bootable kernel zImage Ports : 0x100, 0x110, 0x200, 0x220 IRQs : 10, 11, 14, 15 DMA is not used IO : port mapped Autoprobe : BIOS not required Autoprobe override : none Common Problems : 1. There are known problems in systems with IDE drives and with swapping. Section 3.8 : DPT ALPHA available via ftp ftp.ibp.fr in directory /pub/linux/ALPHA/scsi Section 3.9 : Future Domain 16x0 with TMC-1800, TMC-18C30, TMC-18C50, or TMC-36C70 chip Supported Configurations : BIOSs : 2.0, 3.0, 3.2, 3.4 BIOS Addresses : 0xc8000, 0xca000, 0xce000, 0xde000 Ports : 0x140, 0x150, 0x160, 0x170 IRQs : 3, 5, 10, 11, 12, 14, 15 DMA is not used IO : port mapped Autoprobe : works with all supported configurations, requires installed BIOS Autoprobe Override : none Antiquity Problems, fix by upgrading : 1. Old versions do not support the TMC-18C50 chip, and will fail with newer boards. 2. Old versions will not have the most current BIOS signatures for autodetection. 3. Versions prior to the one included in Linux 1.0.9 and 1.1.6 don't support the new SCSI chip or 3.4 BIOS. Section 3.10 : Generic NCR5380 / T130B Supported and Unsupported Configurations : Ports : all IRQs : all DMA channels - DMA is not used IO : port mapped Autoprobe : none Autoprobe Override : Compile time : Define GENERIC_NCR5380_OVERRIDE to be an array of tupples with port, irq, dma, board type - ie #define GENERIC_NCR5380_OVERRIDE {{0x330, 5, DMA_NONE, BOARD_NCR5380}} for a NCR5380 board at port 330, IRQ 5. #define GENERIC_NCR5380_OVERRIDE {{0x350, 5, DMA_NONE, BOARD_NCR53C400}} for a T130B at port 0x350. Older versions of the code eliminate the BOARD_* entry. The symbolic IRQs IRQ_NONE and IRQ_AUTO may be used. kernel command line : ncr5380=port,irq ncr5380=port,irq,dma ncr53c400=port,irq 255 may be used for no irq, 254 for irq autoprobe. Common Problems : 1. Using the T130B board with the old (pre public release 6) generic NCR5380 driver which doesn't support the ncr53c400 command line option. The NCR5380 compatable registers are offset eight from the base address. So, if your address is 0x350, use ncr53480=0x358,254 on the kernel command line. Antiquity problems, fix by upgrading : 1. The kernel locks up during disk access with T130B or other NCR53c400 boards Pre-public release 6 versions of the Generic NCR5380 driver didn't support interrupts on these boards. Upgrade. Notes : the generic driver doesn't support DMA yet, and pseudo-DMA isn't supported in the generic driver. Section 3.11 : NCR53c810 (Standard) Supported and Unsupported Configurations : Base addresses : ALL IRQs : ALL DMA channels : PCI, not applicable IO : port mapped, busmastering Autoprobe : requires PCI BIOS, uses PCI BIOS routines to search for devices and read configuration space The driver uses the pre-programmed values in some registers for initialization, so a BIOS must be installed. Antiquity Problems, fix by upgrading : 1. Older versions of Linux had a problem with swapping See Section 4.2.7 : Disks : System Hangs When Swapping Common Problems : 1. Many people have encountered problems where the chip worked fine under DOS, but failed under Linux with a timeout on test 1 due to a lost interrupt. This is often due to a mismatch between the IRQ hardware jumper for a slot or mainboard device and the value set in the CMOS setup. It may also be due to PCI INTB, INTC, or INTD being selected on a PCI board in a system which only supports PCI INTA. Finally, PCI should be using level-sensitive rather than edge triggered interrupts. Check that your board is jumpered for level-sensitive, and if that fails try edge-triggered because your system may be broken. This problem is especially common with Viglen some Viglen motherboards, where the mainboard IRQ jumper settings are NOT as documented in the manual. I've been told that what claims to be IRQ5 is really IRQ9, your mileage will vary. 2. Lockups occur when using an S3928P, X11, and the NCR chip at the same time. There are hardware bugs in at least some S3928P chip. Don't do this. 3. You get a message on boot up indicating that the I/O mapping was disabled because base address 0 bits 0..1 indicated a non I/O mapping This is due to a BIOS bug in some machines which results in dword reads of configuration regsisters returning the high and low 16 bit words swapped. 4. Some systems have problems if PCI write posting, or CPU-> PCI buffering are enabled. If you have problems, disable these options. 5. Some systems with the NCR SDMS software in an onboard BIOS ROM and in the system BIOS are unable to boot DOS. Disabling the image in one place should rectify this problem. 6. Some systems have hideous, broken, BIOS chips. Don't make any bug reports until you've made sure you have the newest ROM from your vendor. - Intel P90 boards require revision 1.00.04.AX1 Section 3.12 : Seagate ST0x/Future Domain TMC-8xx/TMC-9xx Supported and Unsupported Configurations : Base addresses : 0xc8000, 0xca000, 0xcc000, 0xce000, 0xdc000, 0xde000 IRQs : 3, 5 DMA channels : DMA is not used IO : memory mapped Autoprobe : probes for address only, IRQ is assumed to be 5, requires installed BIOS. Autoprobe Override : Compile time : Define OVERRIDE to be the base address, CONTROLLER to FD or SEAGATE as appropriate, and IRQ to the IRQ. kernel command line : st0x=address,irq or tmc8xx=address,irq (only works for .99.13b and newer) Antiquity Problems, fix by upgrading : 1. Versions prior to the one in the Linux .99.12 kernel had a problem handshaking with some slow devices, where This is what happens when you write data out to the bus 1. Write byte to data register, data register is asserted to bus 2. time_remaining = 12us 3. wait while time_remaining > 0 and REQ is not asserted 4. if time_remaining > 0, assert ACK 5. wait while time remaining > 0 and REQ is asserted 6. deassert ACK The problem was encountered in slow devices that do the command processing as they read the command, where the REQ/ACK handshake takes over 12us - REQ didn't go false when the driver expected it to, so the driver ended up sending multiple bytes of data for each REQ pulse. 2. With Linux .99.12, a bug was introduced when I fixed the arbitration code, resulting in failed selections on some systems. This was fixed in .99.13. A Common Problems : 1. There are command timeouts when Linux attempts to read the partition table or do other disk access. The board ships with the defaults set up for MSDOS, ie interrupts are disabled. To jumper the board for interrupts, on the Seagate use jumper W3 (ST01) or JP3 (ST02) and short pins F-G to select IRQ 5. 2. The driver can't handle some devices, particularly cheap SCSI tapes and CDROMs. The Seagate ties the SCSI bus REQ/ACK handshaking into the PC bus IO CHANNEL READY and (optionally) 0WS signals. Unfortunately, it doesn't tell you when the watchdog timer runs out, and you have no way of knowing for certain that REQ went low, and may end up seeing one REQ pulse as multiple REQ pulses. Dealing with this means using a tight loop to look for REQ to go low, with a timeout incase you don't catch the transition due to an interrupt, etc. This results in a performance decrease, so it would be undesireable to apply this to all SCSI devices. Instead, it is selected on a per-device basis with the "borken" field for the given SCSI device in the scsi_devices array. If you run into problems, you should try adding your device to the list of devices for which borken is not reset to zero (currently, only the TENEX CDROM drives). 3. A future domain board (specific examples include the 840,841, 880, and 881) doesn't work. A few of the Future domain boards use the Seagate register mapping, and have the MSG and CD bits of the status register flipped. You should edit seagate.h, swapping the definitions for STAT_MSG and STAT_CD, and recompile the kernel with CONTROLLER defined to SEAGATE and an appropriate IRQ and OVERRIDE specified. 4. When attempting to fdisk your drive, you get error messages indicating that the HDIO_REQ or HDIO_GETGEO ioctl failed, or You must set heads sectors and cylinders. You can do this from the extra functions menu. See Section 4.4 : Disks : Partitioning 5. After manually specifying the drive geometry, subsequent attempts to read the partition table result in partition boundary not on a cylinder boundary, physical and logical boundaries don't match, etc. error messages. See Section 4.4 : Disks : Partitioning 6. Some systems which worked prior to .99.13 fail with newer versions of Linux. Older versions of Linux assigned the CONTROL and DATA registers in an order different than that outlined in the Seagate documentation, which broke on some systems. Newer versions make the assignment in the correct way, but this breaks other systems. The code in seagate.c looks like this now : cli(); DATA = (unsigned char) ((1 << target) | (controller_type == SEAGATE ? 0x80 : 0x40)); CONTROL = BASE_CMD | CMD_DRVR_ENABLE | CMD_SEL | (reselect ? CMD_ATTN : 0); sti(); Changing this to cli(); CONTROL = BASE_CMD | CMD_DRVR_ENABLE | CMD_SEL | (reselect ? CMD_ATTN : 0); DATA = (unsigned char) ((1 << target) | (controller_type == SEAGATE ? 0x80 : 0x40)); sti() may fix your problem. Defines : FAST or FAST32 will use blind transfers where possible ARBITRATE will cause the host adapter to arbitrate for the bus for better SCSI-II compatability, rather than just waiting for BUS FREE and then doing its thing. Should let us do one command per Lun when I integrate my reorganization changes into the distribution sources. SLOW_HANDSHAKE will allow compatability with broken devices that don't handshake fast enough (ie, some CD ROM's) for the Seagate code. SLOW_RATE=x, x some number will let you specify a default transfer rate if handshaking isn't working correctly. Section 3.13 : PAS16 SCSI Supported and Unsupported Configurations : Ports : 0x388, 0x384, 0x38x, 0x288 IRQs : 10, 12, 14, 15 IMPORTANT : IRQ MUST be different from the IRQ used for the sound portion of the board. DMA is not used for the SCSI portion of the board IO : port mapped Autoprobe : does not require BIOS Autoprobe Override : Compile time : Define PAS16_OVERRIDE to be an array of port, irq tupples. Ie #define PAS16_OVERRIDE {{0x388, 10}} for a board at port 0x388, IRQ 10. kernel command line : pas16=port,irq Defines : AUTOSENSE - if defined, REQUEST SENSE will be performed automatically for commands that return with a CHECK CONDITION status. PSEUDO_DMA - enables PSEUDO-DMA hardware, should give a 3-4X performance increase compared to polled I/O. PARITY - enable parity checking. Not supported SCSI2 - enable support for SCSI-II tagged queueing. Untested UNSAFE - leave interrupts enabled during pseudo-DMA transfers. You only really want to use this if you're having a problem with dropped characters during high speed communications, and even then, you're going to be better off twiddling with transfersize. USLEEP - enable support for devices that don't disconnect. Untested. Common problems : 1. Command timeouts, aborts, etc. You should install the NCR5380 patches that I posted to the net some time ago, which should be integrated into some future alpha release. These patches fix a race condition in earlier NCR5380 driver cores, as well as fixing support for multiple devices on NCR5380 based boards. If that fails, you should disable the PSEUDO_DMA option by changing the #define PSEUDO_DMA line in drivers/scsi/pas16.c to #undef PSEUDO_DMA. Note that the later should be considered a last resort, because there will be a severe performance degradation. Section 3.14 : Trantor T128/T128F/T228 Supported and Unsupported Configurations : Base addresses : 0xcc000, 00xc8000, 0xdc000, 0xd8000 IRQs : none, 3, 5, 7 (all boards) 10, 12, 14, 15 (T128F only) DMA is not used. IO : memory mapped Autoprobe : works for all supported configurations, requires installed BIOS. Autoprobe Override : Compile time : Define T128_OVERRIDE to be an array of address, irq tupples. Ie #define T128_OVERRIDE {{0xcc000, 5}} for a board at address 0xcc000, IRQ 5. The symbolic IRQs IRQ_NONE and IRQ_AUTO may be used. kernel command line : t128=address,irq -1 may be used for no irq, -2 for irq autoprobe. Defines : AUTOSENSE - if defined, REQUEST SENSE will be performed automatically for commands that return with a CHECK CONDITION status. PSEUDO_DMA - enables PSEUDO-DMA hardware, should give a 3-4X performance increase compared to polled I/O. PARITY - enable parity checking. Not supported SCSI2 - enable support for SCSI-II tagged queueing. Untested UNSAFE - leave interrupts enabled during pseudo-DMA transfers. You only really want to use this if you're having a problem with dropped characters during high speed communications, and even then, you're going to be better off twiddling with transfersize. USLEEP - enable support for devices that don't disconnect. Untested. Common Problems : 1. Command timeouts, aborts, etc. You should install the NCR5380 patches that I posted to the net some time ago, which should be integrated into some future alpha release. These patches fix a race condition in earlier NCR5380 driver cores, as well as fixing support for multiple devices on NCR5380 based boards. If that fails, you should disable the PSEUDO_DMA option by changing the #define PSEUDO_DMA line in drivers/scsi/pas16.c to #undef PSEUDO_DMA. Note that the later should be considered a last resort, because there will be a severe performance degradation. Section 3.15 : Ultrastor 14f (ISA), 24f (EISA), 34f (VLB) Ports : 0x130, 0x140, 0x210, 0x230, 0x240, 0x310, 0x330, 0x340 IRQs : 10, 11, 14, 15 DMA channels : 5, 6, 7 IO : port mapped, bus master Autoprobe : does not work for boards at port 0x310, BIOS not required. Autoprobe override : compile time only, define PORT_OVERRIDE Common Problems : 1. The address 0x310 is not supported by the autoprobe code, and may cause conflicts if networking is enabled. Please use a different address. 2. Using an Ultrastor at address 0x330 may cause the system to hang when the sound drivers are autoprobing. Please use a different address. 3. Various other drivers do unsafe probes at various addresses, if you are having problems with detection or the system is hanging at boot time, please try a different address. 0x340 is recommended as an address that is known to work. 4. Linux detects no SCSI devices, but detects your SCSI hard disk on an Ultrastor SCSI board as a normal hard disk, and the hard disk driver refuses to support it. Note that when this occurs, you will probably also get a message hd.c: ST-506 interface disk with more than 16 heads detected, probably due to non-standard sector translation. Giving up. (disk %d: cyl=%d, sect=63, head=64) If this is the case, you are running the Ultrastor board in WD1003 emulation mode. You have 1. Switch the ultrastor into native mode. This is the recommended action, since the SCSI driver can be significantly faster than the IDE driver, especially with the clustered read/write patches installed. Some users have sustained in excess of 2M/sec through the file system using these patches. Note that this will be necessary if you wish to use any non- hard disk, or more than two hard disk devices on the Ultrastor. 2. Use the kernel command line switch hd=cylinders,heads,sectors to override the default setting to bootstrap yourself, keeping number of cylinders <= 2048, number of heads <= 16, and number of sectors <= 255 such that cylinders * heads * sectors is the same for both mappings. You'll also have to manually specify the disk geometry when running fdisk under Linux. Failure to do so will result in incorrect partition entries being written, which will work correctly with Linux but fail under MSDOS which looks at the cylinder/head/sector entries in the table. Once Linux is up, you can avoid the inconvience of having to boot by hand by recompiling the kernel with an appropriately defined HD_TYPE macro in include/linux/config.h. Section 3.16 : Western Digital 7000 Supported Configurations : BIOS Addresses : 0xce000 Ports : 0x350 IRQs : 15 DMA Channels : 6 IO : port mapped, bus master Autoprobe : requires installed BIOS Common Problems : 1. There are several revisisions of the chip and firmware. Supposedly, revision 3 boards do not work, revision 5 boards do, chips with no suffix do not work, chips with an 'A' suffix do. 2. The board supports a few BIOS addresses which aren't on the list of supported addresses. If you run into this situation, please use one of the supported addresses and submit a bug report as outlined in Section 2, "Bug Reports" Section 4 : Disks This section gives information that is specific to disk drives. Section 4.1 : Supported and Unsupported Hardware All direct access SCSI devices with a block size of 256, 512, or 1024 bytes should work. Other block sizes will not work (Note that this can often be fixed by changing the block and/or sector sizes using the MODE SELECT SCSI command) Sector size refers to the number of data bytes allocated per sector on a device, ie CDROMs use a 2048 byte sector size. Block size refers to the size of the logical blocks used to interface with the device. Although this is usually identical to sector size, some devices map multiple smaller physical sectors (ie, 256 bytes in the case of 55M Syquest drives) to larger logical blocks or vice versa (ie, 512 byte blocks on SUN compatable CDROM drives). Removeable media devices, including Bernoulis, flopticals, and MO drives work. Section 4.2 : Common Problems Section 4.2.1 : Cylinder > 1024 message. When partitioning, you get a warning message about "cylinder > 1024" or you are unable to boot from a partition including a logical cylinder past logical cylinder 1024. This is a BIOS limitation. See Section 4.4 Disk Geometry and Partitioning for an explanation. Section 4.2.2 : You are unable to partition "/dev/hd*" /dev/hd* aren't SCSI devices, /dev/sd* are. See Section 4.3, Device files, and Section 4.4, Disk Geometry and Partitioning for the correct device names and partitioning procedure. Section 4.2.3 : Unable to eject media from a removeable media drive. Linux attempts to lock the drive door when a piece of media is mounted to prevent filesystem corruption due to an inadvertant media change. Please unmount your disks before ejecting them. Section 4.2.4 : Unable to boot using LILO from a SCSI disk In some cases, the SCSI driver and BIOS will disagree over the correct BIOS mapping to use, and will result in LILO hanging after 'LI' at boot time and/or other problems. To workarround this, you'll have to determine your BIOS geometry mapping used under DOS, and make an entry for your disk in /etc/lilo/disktab. Alternatively, you may be able to use the "linear" configuration file option. Section 4.2.5 : Fdisk responds with You must set heads sectors and cylinders. You can do this from the extra functions menu. and disk geometry is not 'remembered' when fdisk is rerun. See Section 4.4 : Partitioning Section 4.2.6 : Only one drive is detected on a bridge board with multiple drives connected. Linux won't search LUNs past zero on SCSI devices which predate ANSI SCSI revision 1. If you wish devices on alternate LUNs to be recognized, you will have to modify drivers/scsi/scsi.c:scan_scsis(). Section 4.2.7 : System hangs when swapping We think this has been fixed, try upgrading to 1.1.38. Section 4.3 : Device Files SCSI disks use block device major 8, and there are no "raw" devices ala BSD. 16 minor numbers are allocated to each SCSI disk, with minor % 16 == 0 being the whole disk, minors 1 <= (minor % 16) <= 4 the four primary partitions, minors 5 <= (minor % 16) <= 15 any extended partitions. Due to constraints imposed by Linux's use of a sixteen bit dev_t with only eight bits allocated to the minor number, the SCSI disk minor numbers are assigned dynamically starting with the lowest SCSI HOST/ID/LUN. Ie, a configuration may work out like this (with one host adapter) Device Target, Lun SCSI disk 84M Seagate 0 0 /dev/sda SCSI->SMD bridge disk 0 3 0 /dev/sdb SCSI->SMD bridge disk 1 3 1 /dev/sdc Wangtek tape 4 0 none 213M Maxtor 6 0 /dev/sdd Etc. The standard naming convention is /dev/sd{letter} for the entire disk device ((minor % 16) == 0) /dev/sd{letter}{partition} for the partitions on that device (1 <= (minor % 16) <= 15) Ie /dev/sda block device major 8 minor 0 /dev/sda1 block device major 8 minor 1 /dev/sda2 block device major 8 minor 2 /dev/sdb block device major 8 minor 16 etc. Section 4.4 : Partitioning You can partition your SCSI disks using the partitioning program of your choice, under DOS, OS/2, Linux or any other operating system supporting the standard partitioning scheme. The correct way to run the Linux fdisk program is by specifying the device on the command line. Ie, to partition the first SCSI disk, fdisk /dev/sda If you don't explicitly specify the device, the partitioning program may default to /dev/hda, which isn't a SCSI disk. In some cases, fdisk will respond with You must set heads sectors and cylinders. You can do this from the extra functions menu. Command (m for help): and/or give a message to the effect that the HDIO_REQ or HDIO_GETGEO ioctl failed. In these cases, you must manually specify the disk geometry as outlined in Subsection 4.5 : Disk Geometry when running fdisk, and also in /etc/disktab if you wish to boot kernels off that disk with LILO. If you have manually specified the disk geometry, subsequent attempts to run fdisk will give the same error message. This is normal, since PCs don't store the disk geometry information in the partition table. In and of itself, will cause _NO PROBLEMS_, and you will have no problems accessing partitions you created on the drive with Linux. Some vendors' poor installation code will choke on this, in which case you should contact your vendor and insist that they fix the code. In some cases, you will get a warning message about a partition ending past cylinder 1024. If you create one of these partitions, you will be unable to boot Linux kernels off of that partition using LILO. Note, however, that this restriction does not preclude the creation of a root partition partially or entirely above the 1024 cylinder mark, since it is possible to create a small /boot partition below the 1024 cylinder mark or to boot kernels off existing partitions. Section 4.5 : Disk Geometry Under Linux, each disk is viewed as the SCSI host adapter sees it : N blocks, numbered from 0 to N-1, all error free, where as DOS/BIOS predate intelligent disks and apply an arbitrary head / cylinder / sector mapping to this linear addressing. This can pose a problem when you partition the drives under Linux, since there is no portable way to get DOS/BIOS's idea of the mapped geometry. In most cases, a HDIO_GETGEO ioctl() can be implemented to return this mapping. Unfortunately, when the vendor (ie Seagate) has chosen a perverse, non-standard, and undocumented mapping, this is not possible and geometry must be manually specified If manual specification of the is required, you have one of several options : 1. If you don't care about using DOS, or booting kernels from the drive with LILO, create a translation such that heads * cylinders * sectors * 512 < size of your drive in bytes (a megabyte is defined as 2^20 bytes). 1 <= heads <= 256 1 <= cylinders <= 1024 1 <= sectors <= 63 2. Use the BIOS mapping. In some cases, this will mean reconfiguring the disk so that it is at SCSI ID 0, and disabling the second IDE drive (if you have one). You can either use a program like NU, or you can use the following program : begin 664 dparam.com MBAZ``##_B+^!`+N!`(H'0SP@=/D\,'5:@#]X=`6`/UAU4(!_`3AU2H!_`P!U M1(I7`H#J,(#Z`7L6N]T!,=*Y M"@#W\8#",$N(%PG`=>^)VK0)S2'#=7-A9V4Z(&1P87)A;2`P>#@P#0H@("!O L or mt setblk 0 to get variable block length support. Note that these mt flags are NOT supported under the GNU version of mt which is included with some Linux distributions. Instead, you must use the BSD derrived Linux SCSI mt command. Source should be available from tsx-11.mit.edu:/pub/linux/ALPHA/scsi Section 6.2.5 : "No such device" error message. All attempts to access the tape result in a "No such device" or similar error message. Check the type of your tape device - it MUST be a character device with major and minor numbers matching those specified in subsection C, Device Files. Section 6.2.6 : Tape reads at a given density work, writes fail Many tape drives support reading at lower densities for compatability with older harware, but will not write at those same densities. This is especially the case with QIC drives, which will read old 60M tapes but only write new 120, 150, 250, and 525M formats. Section 6.3 : Device Files SCSI tapes use character device major 9. Due to constraints imposed by Linux's use of a sixteen bit dev_t with only eight bits allocated to the minor number, the SCSI tape minor numbers are assigned dynamically starting with the lowest SCSI HOST/ID/LUN. Rewinding devices are numbered from 0 - with the first SCSI tape, /dev/rst0 being c 9 0, the second /dev/rst1 c 9 1, etc. Non-rewinding devices have the high bit set in the minor number, ie /dev/nrst0 is c 9 128. The standard naming convention is /dev/nrst{digit} for non-rewinding devices /dev/rst{digit} for rewinding devices Section 7 : Generic This information gives information that is specific to the generic scsi driver. Section 7.1 : Supported Hardware The Generic SCSI device driver provides an interface for sending SCSI commands to all SCSI devices - disks, tapes, CDROMs, media changer robots, etc. Everything electrically compatable with your SCSI board should work. Section 7.2 : Common Problems None :-). Section 7.3 : Device Files SCSI generic devices use character major 21. Due to constraints imposed by Linux's use of a 16 bit dev_t, minor numbers are dynamically assigned from 0, one per device, with /dev/sg0 corresponding to the lowest numerical target/lun on the first SCSI board. Section 8 : Buyers Guide A frequent question is: "Linux supports quite a number of different boards, so which scsi host adapter should I get." The answer depends upon how much performance you expect or need, motherboard, and the scsi peripherals that you plan on attaching to your machine. The biggest factor affecting performance (in terms of throughput and interactive response time during SCSI I/O) is going to be the transfer type used. Transfer type Description / Performance / Recomendedations Pure A pure polled I/O board will use the CPU to handle Polled all of the SCSI processing, including the REQ/ACK handshaking. Even a fast CPU will be slower handling the REQ/ACK handshake sequence than a simple finite state machine, resulting in peak transfer rates of about 150K/sec on a fast machine, perhaps 60K/sec on a slow machine (through the filesystem). The driver also must sit in a tight loop as long as the SCSI bus is busy, resulting in near 100% CPU utilitization and extremely poor responsiveness during SCSI/IO. Slow CDROMs which don't disconnect/reconnect will kill interactive performance with these boards. Not recommended. Interlocked Boards using interlocked polled I/O are essentially Polled the same as pure polled I/O boards, only the SCSI REQ/ACK handshaking signals are interlocked with the PC bus handshaking signals. All SCSI processing beyond the handshaking is handled by the CPU. Peak transfer rates of 500-600K/sec through the filesystem are possible on these boards. As with pure polled I/O boards, the driver must sit in a tight loop as long as the SCSI bus is busy, resulting in CPU utilization dependant on the transfer rates of the devices, and when they disconnect/reconnect. CPU utilization may vary between 25% for single speed CDs which handle disconnect/reconnect properly to 100% for faster drives or broken CD ROMs which fail to disconnect/reconnect. On my 486-66, with a T128, I use 90% of my CPU time to sustain a throughput of 547K/sec on a drive with a headrate of 1080K/sec with a T128 board. Sometimes acceptable for slow tapes and CDROMs when low cost is essential. FIFO Boards using FIFO polled I/O put a small (typically 8K) Polled buffer between the CPU and the SCSI bus, and often implement some amount of intelligence. The net effect is that the CPU is only tied up when it is transfering data at top speed to the FIFO and when it's handling the rest of the interrupt processing for FIFO empty conditions, disconnect/reconnect, etc. Peak transfer rates should be sufficient to handle most SCSI devices, and have been measured at up to 4M/sec using raw SCSI commands to read 64K blocks on a fast Seagate Barcuda with an Adaptec 1520. CPU utilization is dependant on the transfer rates of the devices, with faster devices generating more interrupts per unit time which require more CPU processing time. Although CPU usage may be high (perhaps 75%) with fast devices, the system usually remains usable. These boards will provide excellent interactive performance with broken devices which don't disconnect/reconnect (typically cheap CDROM drives) Recommended for persons on a budget. Slave Drivers for boards using slave DMA program the PC's DMA DMA controller for a channel when they do a data transfer, and return control to the CPU. Peak transfer rates are usually handicapped by the poor DMA controller used on PCs, with one such 8-bit board having problems going faster than 140-150K/sec with one mainboard. CPU utilization is very reasonable, slightly less than what is seen with FIFO polled I/O boards. These boards are very tollerant of broken devices which don't disconnect/reconnect (typically cheap CSG limitDROM drives). Acceptable for slow CDROM drives, tapes, etc. Busmastering These boards are intelligent. Drivers DMA for these boards throw a SCSI command, the destination target and lun, and where the data should end up in a structure, and tell the board "Hey, I have a command for you." The driver returns control to various running programs, and eventually the SCSI board gets back and says that it's done. Since the intelligence is in the host adapter firmware and not the driver, drivers for these boards typically support more features - synchronous transfers, tagged queing, etc. With the clustered read/write patches, peak transfer rates through the file system approach 100% of head rate writing, 75% reading. CPU utilization is minimal, irregardless of I/O load, with a measured 5% CPU usage while accessing a double speed CDROM on an Adaptec 1540 and 20% while sustaining a 1.2M/sec transfer rate on a SCSI disk. Recommended in all cases where money is not extremely tight, the main board is not broken (some broken main boards do not work with bus masters), and applications where time to data is more important than throughput are not being run (bus master overhead may hit 3-4ms per command). The second most important driver/hardware feature with respect to performance is support for scatter/gather I/O. The overhead of executing a SCSI command is significant - on the order of milliseconds. Intelligent bus masters like the Adaptec 1540 may take 3-4ms to process a SCSI command before the target even sees it. On unbuffered devices, this overhead is allways enough to slip a revolution, resulting in a transfer rate of about 60K/sec (assuming a 3600RPM drive) per block transfered at a time. So, to maximize performance, it is necessary to minimize the number of SCSI commands needed to transfer a given amount of data by transfering more data per command. Due to the design of the Linux buffer cache, contiguous disk blocks are not contiguous in memory. With the clustered read/write patches, 4K worth of buffers are contiguous. So, the maximum amount of data which can be transfered per SCSI command is going to be 1K * # of scatter/gather regions without the clustered read/write patches, 4K * # of regions with. Experimentally, we've determined that 64K is a reasonable a55mount to transfer with a single SCSI command - meaning 64 scatter/gather buffers without clustered read/write patches, 16 without. With the change from 16K to 64K transfers, we saw an improvement from 50% of headreate, through the filesystem, reading and writing, to 75% and 100% respectively using an Adaptec 1540 series board. Bus type is the next thing to consider, with choices including ISA, EISA, VESA, and PCI. Marketing types often spout of absurd bandwidth numbers based on burst transfer rates and fiction, which isn't very useful. Instead, I've chosen to state "real-world" numbers based on measured performance with various peripherials. Bus Bandwidth, description, ISA Bandwidth is slightly better than 5M/sec for busmastering devices. With an ISA bus, arbitration for busmasters is performed by the venerable 8237 third party DMA controller, resulting in relatively high bus aquisition times. Interrupt drivers are tri-state and edge triggered, meaning interrupts cannot be shared. Generally, ISA is unbuffered, meaning the host/memory bus is tied up whenever a transfer is occuring. No mechanism is provided to prevent bus-hogging. VESA Bandwidth is about 30M/sec. Some VESA systems run the bus out of spec, rendering them incompatable with some boards, so this should be taken into consideration before purchasing hardware without a return guarantee. Generally, VESA is unbuffered, meaning meaning the host/memory bus is tied up whenever a transfer is occuring. EISA Bandwidth is about 30M/sec, with busmastering operations generally being faster than VESA. Some EISA systems buffer the bus, allowing burst transfers to the faster host/memory bus and minimizing impact on CPU performance. EISA interrupt drivers may be either tri-state edge-triggered or open collector level-active, allowing interrupt sharing with drivers that support it. Since EISA allocates a separate address space for each board, it is usually less prone to resource conflicts than ISA or VESA. PCI Bandwidth is about 60M/sec. Most PCI systems implement write posting buffers on the host bridge, allowing speed mismatches on either side to have a minimum impact on bus/CPU performance. PCI interrupt drivers are open collector level-active, allowing interrupt sharing with drivers that support it. Mechanisms are provided to prevent bus hogging, and for both master and slave to suspend a bus-mastering operation. Since PCI provides a plug-n-play mechanism with writeable configuration registers on every board, in a separate address space, a propperly implemented PCI system is plug-and play. PCI is extremely strict as to trace length, loading, mechanical specifications, etc. and ultimately should be more reliable than VESA or ISA. In summary, PCI is the best PC bus, although it does have its dark side. PCI is still in its infancy, and although most manufacturers have ironed out the problems, there is still stock of older, buggy PCI hardware and broken main BIOSes. For this reason, I _strongly_ recommend a return guarantee on the hardware. While the latest PCI mainboards are truly plug-and-play, older PCI boards may require the user to set options with both jumpers and in software (ie, interrupt assignments). Although many users have resolved their PCI problems, it has taken time and for this reason I cannot recommend a PCI purchase if having the system operational is extremely time critical. For many slower SCSI devices, such as disks with head rates arround 2M/sec or less, CDROMs, and tapes, there will be little difference in throughputs with the different PC bus interfaces. For faster contemporary SCSI drives (Typical high end multi-gigabyte drives have a head rate of 4-5M/sec, and at least one company is currently ALPHA testing a parallel head unit with a 14M/sec head rate), throughput will often be significantly better with controllers on faster busses, with one user noting a 2.5 fold performance improvement when going from an Adaptec 1542 ISA board to a NCR53c810 PCI board. With the exception of situations where PCI write-posting or a similar write-buffering mechanism is being used, when one of the busses in your system is busy, all of the busses will be unaccessable. So, although bus saturation may not be interfering with SCSI performance, it may have a negative effect on interactive performance. Ie, if you have a 4M/sec SCSI disk under ISA, you'll have lost 80% of your bandwidth, and in an ISA/VESA system would only be able to bitblt at 6M/sec. In most cases, a similar impact on processing jobs in the background would also be felt. Note that having over 16M of memory does not preclude using an ISA busmastering SCSI board. Unlike various broken operating systems, Linux will double buffer when using a DMA with an ISA controller and a transfer is ultimately destined for an area above 16M. Performance on these transfers only suffers by about 1.5%, ie not noticably. Finally, the price difference between bus masters offered with the different bus interfaces is often minimal. With all that in mind, based on your priorities you will have certain bus preferences Stability, time critical installations, EISA ISA VESA PCI and poor return policies Performance, and typical hobbiest PCI EISA VESA ISA installations As I pointed out earlier, bus mastering versus other transfer modes is going to have a bigger impact on total system performance, and should be considered more important than bus type when purchasing a SCSI controller. If will you have multiple devices on your SCSI bus, you may want to see whether the host adapter/driver that you are considering supports more than one outstanding command at one time. This is very important if you are mixing devices of different speeds, like a tape drive and a disk drive. If the linux driver only supports one outstanding command, you may be locked out of your disk drive while a tape in the tape drive is rewinding, for example. With two disk drives, the problem will not be as noticeable, allthough throughput would approach the average of the two transfer rates rather than the sum of the two transfer rates. Driver feature comparison (supported chips are listed in parenthesis) Driver Simultaneous SG > 1 Transfer mode Commands limit Boards total/LUN aha152x FIFO(8k) Polled 1s/1s 255s (AIC6260, AIC6360) aha1542 Busmastering DMA 8s/1s 16 Y aha1740 Busmastering DMA 32s 16 aha274x Busmastering DMA 4s/1s 1 Y buslogic Busmastering DMA Y 64s, 8196h fdomain FIFO(8k) Polled 1s 64s (TMC1800, TMC18c30, TMC18c50) in2000* FIFO(2k) Polled 1s 255s g_NCR5380 Pure Polled 16s/2s 255s Y (NCR5380, NCR53c80, NCR5381, NCR53c400) gsi8* Slave DMA 16s/2s 255s (NCR5380) PAS16 Pure Polled 16s/2s 255s Y (NCR5380) or Interlocked Polled (fails on some systems!) seagate Interlocked Polled 1s 255s N wd7000 Busmastering DMA 8s 1 t128 Interlocked Polled 16s 255s Y (NCR5380) ultrastor Busmastering DMA Y 53c7,8xx Busmastering DMA 1s/1s 255s Y (NCR53c810) Notes : 1. drivers flagged with an '*' are not included with the distribution kernel, and binary boot images may be unavailable. 2. numbers suffixed with an 's' are arbitrary limits set in software which may be changed with a compile time define. 3. hardware limits are indicated by an 'h' suffix, and may differ from the software limits currently imposed by the Linux drivers. 4. unsuffixed numbers may indicate either hard or soft limits. Board comparison : Board Driver Bus Price Notes Adaptec AIC-6260 aha152x ISA chip, not board Adaptec AIC-6360 aha152x VLB chip, not board (Used in most VESA/ISA multi-IO boards with SCSI, Zenon mainboards) Adaptec 1520 aha152x ISA Adaptec 1522 aha152x ISA $80 1520 w/FDC Adaptec 1510 aha152x ISA 1520 w/out boot ROM, won't autoprobe. Adaptec 1540C aha1542 ISA Adaptec 1542C aha1542 ISA 1540C w/FDC Adaptec 1540CF aha1542 ISA FAST SCSI-II Adaptec 1542CF aha1542 ISA $200 1540CF w/FDC Adaptec 1740 aha1740 EISA discontinued Adaptec 1742 aha1740 EISA discontinued, 1740 w/FDC Adaptec 2740 aha274x EISA Adaptec 2742 aha274x EISA Allways IN2000 in2000 ISA Buslogic 445S aha1542, VLB $250 FAST SCSI-II, active buslogic termination, w/FDC Buslogic 747S aha1542, EISA FAST SCSI-II, active buslogic termination, w/FDC Buslogic 946S buslogic PCI FAST SCSI-II, activte termination. DTC 3290 aha1542 EISA Although it should work, due to documentation release polcies, DTC hardware is unsupported DTC 3292 aha1542 EISA 3290 w/FDC Future Domain 1680 fdomain ISA FDC Future Domain 3260 fdomain PCI NCR53c810 (boards sold 53c7,8xx PCI $70 chip, not board. Boards by FIC, Chaintech, (board) don't include Nextor, Gigabyte, etc. BIOS, although most Mainboards with chip by non-NCR equipped main AMI, ASUS, J-Bond, boards have the SDMS etc. Common in DEC BIOS PCI systems) Pro Audio Spectrum 16 pas16 ISA Sound board w/SCSI Seagate ST01 seagate ISA $20 BIOS only works with some drives Seagate ST02 seagate ISA $40 ST01 w/FDC Sound Blaster 16 SCSI aha152x ISA Sound board w/SCSI Western Digital 7000 wd7000 ISA w/FDC Trantor T128 t128 ISA Trantor T128F t128 ISA T128 w/FDC and support for high IRQs Trantor T130B g_NCR5380 ISA Ultrastor 14F ultrastor ISA w/FDC Ultrastor 24F ultrastor EISA w/FDC Ultrastor 34F ultrastor VLB Notes : 1. Trantor was recently purchased by Adaptec, and some products are being sold under the Adaptec name. 2. Ultrastor recently filed for Chapter 11 Bankruptcy, so technical support is non-existant at this time. 3. Various Buslogic boards other than the 545S, 445S, 747S, and 946S _should_ work, although to my knowledge have not been tried. 4. The $70 price for the busmastering NCR53c810 boards is not a typo, includes the standard ASPI/CAM driver package for DOS, OS/2 and Windows (32 bit access), and other drivers are available for free download. If you can't find one at that price, try Technoland at 1-800-292-4500 or 1-408-992-0888 if you live in California. 5. Adaptec's recent SCSI chips show an unusual sensitivity to cabling and termination problems. For this reason, I cannot recommend the Adaptec 154x C and CF revisions or the 274x series. Note that the reliability problems do NOT apply to the older 154x B revision boards, 174x A revision boards, or to my knowledge AIC-6360/AIC-6260 based boards. Also, the quality of their technical support has slipped markedly, with long delays becoming more common, and their employees being ignorant (suggesting there were non-disclosure policies affecting certain literature when there were none), and hostile (ie, refusing to pass questions on to some one else when they couldn't answer them). If users desire handholding, or wish to make a political statement, they should take this point into consideration. Otherwise, the Adaptec 152x/1510 are nicer than the other ISA boards in the same price range, and there are some excellent deals on used and surplus 154x B revision boards and 1742 boards which IMHO outweigh the support problems. Most ISA, EISA, and VESA users will probably be served best by a Buslogic board, due to its performance, features such as active termination, and Adaptec 1540 compatability. There are a number of models available with EISA, ISA, PCI, and VESA local bus interfaces, in single ended and differential, and 8/16 bit SCSI bus widths. People with PCI systems should seriously consider NCR53c810 based boards. These are bus mastering SCSI controllers, available in Q1 for about $70 (ie, cheaper than the Adaptec 1520) with larger quantities being cheaper (I've seen $62 in Q20). In addition to being the cheapest PCI SCSI boards, the NCR boards were also benchmarked as faster than the Adaptec 2940 and Buslogic BT-946, and demonstrate excellent performance under Linux (up to 4M/sec through the file system ) inspite of the performance optomizations being disabled in the current driver. The disadvantages of these boards versus the Buslogics are that they aren't Adaptec 1540 compatable, don't come with active termination, and to my knowledge are only supported under DOS+Windows, OS/2, Windows NT, SCO, NeXTstep, and Free BSD. Currently, the driver is somewhat limited, but appears quite stable (We've moved several gigabytes of data to NCR based devices with no problems), surprisingly fast (I've seen 4M/sec through the filesystem) and will rapidly become more featureful. People wanting non-PCI SCSI on a limited budget will probably be happiest finding a surplus or used Adaptec 154x B revision or 174x A revision, or an Adaptec 1520 clone of some sort (about $80) if they want new. These boards offer reasonable throughput and interactive performance at a modest price. EOF