Troubleshooting SCSI Devices

Many common problems with SCSI devices are quite easy to solve. Finding the cause of the problem is often the most difficult step. It’s usually helpful to read the diagnostic message that the operating system displays when it boots or attempts to use a SCSI device.

The following are the most common problems encountered with SCSI devices, their probable causes, and possible solutions:

SCSI devices show up at all possible SCSI IDs—You have configured the device with the same SCSI address as the controller, which is typically set at SCSI ID 7. Change the jumper settings to another SCSI ID.

A SCSI device shows up with all possible LUNs—The device probably has bad firmware. The file /usr/src/linux/drivers/scsi/scsi.c contains a list of bad devices under the variable blacklist. You can try adding the device to this list and see if it affects the behavior. If not, contact the device manufacturer.

Your SCSI system times out—Make sure the controller card’s interrupts are enabled correctly and that there are no IRQ, DMA, or address conflicts with other boards in your system.

You get “sense errors” from error-free devices—This is usually caused by either bad cables or improper termination on the chain. Make sure the SCSI chain is terminated at both ends using external or onboard terminators. Don’t terminate in the middle of the chain because this can also cause problems. You can probably use passive termination, but for long chains with several devices, try active termination for better behavior.

The tape drive is not recognized at boot time—Try booting with a tape in the drive.

A networking kernel does not work with new SCSI devices—The autoprobe routines for many network drivers are not passive and can interfere with some SCSI drivers. Try to disable the network portions to identify the guilty program, and then reconfigure it.

A SCSI device is detected, but the system is unable to access it—You probably don’t have a device file for the device. Device drivers should be in /dev and configured with the proper type (block or character) and unique major and minor device numbers. Run mkdev for the device.

The SCSI controller card fails when it uses memory-mapped I/O—This problem is common with Trantor T128 and Seagate boards and is caused when the memory-mapped I/O ports are incorrectly cached. You should have the board’s address space marked as uncacheable in the XCMOS settings. If you can’t mark them as such, disable the cache and see whether the board functions properly.

Your system fails to find the SCSI devices and you get messages such as scsi : 0 hosts or scsi%d : type: when the system boots—The autoprobe routines on the controller cards rely on the system BIOS autoprobe and can’t boot properly. This is particularly prevalent with these SCSI adapters: 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, and Western Digital 7000. Check that your BIOS is enabled and not conflicting with any other peripheral BIOSs (such as on some adapter cards). If the BIOS is properly enabled, find the board’s “signature” by running DOS’ DEBUG command to check whether the board is responding. For example, use the DEBUG command d=c800:0 to see whether the board replies with an acknowledgment (assuming you have set the controller card to use address 0xc8000; if not, replace the DEBUG command with the proper address). If the card doesn’t respond, check the address settings.

Sometimes the SCSI system locks up completely—There are many possible reasons, including a problem with the host adapter. Check the host adapter with any diagnostics that came with the board. Try a different SCSI cable to see whether that is the problem. If the lockups seem to occur when multiple devices are in use at the same time, there is probably a firmware problem. Contact the manufacturer to see whether upgrades are available that would correct the problem. Finally, check the disk drives to ensure that there are no bad blocks that could affect the device files, buffers, or swap space.

Summary

SCSI has a reputation for being difficult to work with, but in fact, it is one of the easiest and most versatile systems available. After you get used to the nomenclature, SCSI offers many useful features to the Linux user. Indeed, most veteran UNIX people prefer working with SCSI because it is easy to use with the UNIX kernel and the same applies to Linux. From here, you may want to learn more about the following topics:

Shell programming and how you can use it to make your experience with bash more powerful is discussed in Chapter 14, “Shell Programming.”

Setting up an Internet server with your Linux system is discussed in Chapter 47, “Setting up an Internet Site.”

Using source code control systems to maintain previous versions of your files is discussed in Chapter 56, “Source Code Control.”