Contents of the FYI11081.DOC file
TITLE: Drive Deactivation Troubleshooting Tips
DOCUMENT ID#: FYI.P.11081
PRODUCT VERSION: v3.11
Drive Deactivation Tips and Techniques for NetWare v3.11.
The purpose of this document is to establish what drive deactivation is
and why it occurs. Drive deactivation is when one or more devices
(drives) in the server become unable to communicate with the operating
system (OS). Drive deactivation is caused by an inability of NetWare and
the disk driver to communicate with the device. When the driver cannot
communicate with the drive, it will normally retry several times. If,
after a predetermined number of retries, the driver still cannot
establish a communication link with the drive, the driver tells the OS
that the drive is not responding and the OS then deactivates the device.
Drive deactivation can occur across any of the disk interfaces, such as
IDE, ESDI, or SCSI. Drive deactivation is also not confined to just one
manufacturer. The following list is a "checklist" that Novell suggests
you go through in troubleshooting a drive deactivation problem. In many
cases, you must be very specific with hardware, firmware, and software
revision levels as you work with your third-party Host Bus Adapters
(HBAs) and drive manufacturers in solving your problems. The priority of
the checklist is based on solutions that will cost the least and still
receive the highest priority. For checklist purposes, this discussion
will be restricted to the SCSI interface. All suggestions should be
easily translated for any interface.
1. Verify that termination along the SCSI bus is correct. The first
basic rule to remember is that both ends of the bus must be
terminated. You must be careful that if you have drives in an
internal or external cabinet that you remove the termination from
the individual drives and then just terminate the cabinet
externally. This avoids future headaches; because, as you add more
drives, you do not have to worry about which drive was terminated in
Another problem arises when you use both the internal and external
ports on an HBA. When you do this, you must remove the termination
from the HBA and terminate both ends of the SCSI bus, which will
usually be at the drives themselves unless an external cabinet is
2. Verify that the SCSI IDs are set properly. In all situations, the
HBA will have a SCSI ID of 7. This may be set either through a
hardware setting (jumpers) or through software utilities (such as
EISA CONFIGURATION or REFERENCE).
In PS/2 situations and possibly with HPs, the HBA takes a SCSI ID of
7 and the attached devices start at 6 and work down to 0. In all
other situations, the HBA takes an ID of 7, and the attached devices
start at 0 and work up to 6.
In the PS/2 environment, there are specific things that need to be
Under reference, the "fairness" needs to be turned ON for the
Using the OPTION diskette v1.0 from IBM, the settings for
Fairness are reversed. Normally, fairness is turned ON.
However, if you are using the OPTIONS diskette v1.0, you must
set "Fairness" to OFF. On all other versions of the OPTIONS
diskette, simply set fairness to the normal setting of ON.
3. Verify the disk driver. Verify with your third-party HBA
manufacturer that you are running the latest Novell certified driver
and that it is compatible with the firmware revision level on your
4. Verify the HBA firmware. Verify with your third-party HBA
manufacturer that the version of firmware on your HBA is the correct
version applicable to the version of the disk driver that you are
5. Verify the firmware revision level on the drive. Verify with the
third-party drive manufacturer that you have the proper or latest
version of firmware on your drive.
6. Check and if necessary replace the cabling on the SCSI bus. Reseat
all connectors, then reseat the HBA into the bus. Look for pinched
or broken leads on all connectors and cables.
7. Verify proper wattage of the power supply. Novell had seen many
drive deactivation problems solved by upgrading or replacing a weak
or flaky power supply. Drive deactivation problems seem to be an
ever increasing problem as drives grow larger in capacity yet shrink
in physical size. This smaller size allows more drives to be placed
into the server box itself thus placing a larger demand on the
server's power supply.
8. Examine other devices attached to the SCSI bus. If you have a tape
unit, CD-ROM, or other devices attached to the SCSI bus, ensure you
enable the "disconnect" feature on those devices. This allows the
HBA to issue a command or series of commands to that device and then
disconnect and return to servicing disk requests. If the
"disconnect" feature is not enabled, the SCSI bus must wait for the
device to return with a completion code and by so doing may not be
able to service the drivers requests to "talk" to the drive.
9. Examine other bus mastering boards. If your server has bus
mastering boards, you may need to examine these closely. If a bus
mastering board holds the bus too long, this may prevent the disk
driver from establishing a communication link with the drive.
Sometimes it may be an issue of getting a newer driver for the bus
mastering device or taking drastic steps of replacing or upgrading
the suspected bus mastering device. Experience has shown that this
can happen, but it is rare.
10. Replace the HBA. If the above steps have failed to solve the drive
deactivation problem, then it is time to take drastic action.
Replace the HBA with preferably the same make and model number. If
a different brand or model number is chosen, a reformatting and
repartitioning of the drive may be necessary.
11. If you are still unsuccessful in solving the drive deactivation, it
is time to seriously look at replacing the drive. Experience has
shown that replacing the drive with the same make and model number
may solve the problem; however, in some situations a switch to a
different manufacturer may be necessary. Drive deactivation can
sometimes be very finicky and may require drastic steps to stabilize
the server and eliminate the drive deactivations.