DOCUMENT ID:  1227-01

SYNOPSIS:     Setting scsi_options in /etc/system
OS:           Solaris/SunOS
PLATFORM:     Sparc
OS VERSION:   2.x
TECH AREA:    OS
PRODUCT:      Kernel, Config
KEYWORDS:     scsi_options /etc/system

DESCRIPTION:
Setting scsi_options in /etc/system

SOLUTION:
The scsi_options variable in the Solaris 2.x kernel can be configured to enable or disable particular capabilities.  This can be achieved by setting the scsi_options in the /etc/system file.  The default scsi_options variable allows the widest range of capabilities that the SCSI host adapter can provide to be supported.

The default scsi_options value on Solaris 2.x works for both 5MB and 10MB devices.  The driver will negotiate with each device to determine if it is 10MB transfer capable or not.  If they are 10MB devices, 10MB transfer will be used.  If not, 5MB transfer will be used.

If a particular capability is needed to be enabled or disabled the following definitions can be used:

/*
 * SCSI subsystem options - global word of options are available
 *
 * bits 0-2 are reserved for debugging/informational level
 * bit  3 reserved for a global disconnect/reconnect switch
 * bit  4 reserved for a global linked command capability switch
 * bit  5 reserved for a global synchronous SCSI capability switch
 *
 * the rest of the bits are reserved for future use
 *
 */

#define SCSI_DEBUG_TGT  0x1     /* debug statements in target drivers */
#define SCSI_DEBUG_LIB  0x2     /* debug statements in library */
#define SCSI_DEBUG_HA   0x4     /* debug statements in host adapters */

#define SCSI_OPTIONS_DR         0x8     /* Global disconnect/reconnect  */
#define SCSI_OPTIONS_LINK       0x10    /* Global linked commands */
#define SCSI_OPTIONS_SYNC       0x20    /* Global synchronous xfer capability */

#define SCSI_OPTIONS_PARITY     0x40    /* Global parity support */
#define SCSI_OPTIONS_TAG        0x80    /*   "    tagged command support */
#define SCSI_OPTIONS_FAST       0x100   /*   "    FAST scsi support */
#define SCSI_OPTIONS_WIDE       0x200   /*   "    WIDE scsi support */

For example a line in /etc/system that read:

        set scsi_options=0x3f8

means that the default options would be to allow WIDE SCSI, FAST SCSI, tagged commands, global parity, synchronous transfer, linked commands and global disconnect/reconnect, i.e.  all currently supported options.

DATE APPROVED: 10/23/97

Copyright (c) 1997 Sun Microsystems, Inc.

Subject: Solaris 2 Frequently Asked Questions (FAQ) 1.68
From: Casper.Dik@Holland.Sun.COM
Date: 1999/03/15
Newsgroups: comp.unix.solaris
Archive-name: Solaris2/FAQ
Version: 1.68
Last-Modified: 1999/03/15 16:45:43
Maintained-by: Casper Dik <Casper.Dik@Holland.Sun.COM>

The following is a list of questions that are frequently asked about Solaris 2.x and later.  Where the FAQ mentions "Solaris 2.x", it really refers to Solaris 2.x, Solaris 7 and later.

3.31) I have all kinds of problems with SCSI disks/RAIDs under Solaris 2.x    They worked fine under SunOS 4.x.

For a quick fix, append this line to /etc/system and reboot:

set scsi_options & ~0x80

This turns off Tagged Command Queuing, a SCSI feature that is improperly implemented in many older drives and can cause problems between Suns and some RAID implementations (for a special note on    RAID, see the end of this question)

NOTE: this will seriously degrade performance on disks that do properly support tagged command queuing.  Setting the SCSI options per broken target is therefor the preferred solution.

IIn Solaris 2.4 and later you can set those options per SCSI bus.  See isp(7) and esp(7).

For some disks, all you need to do is decrease the maximum number of queued commands:

set sd:sd_max_throttle=10

In later Solaris releases you can specify scsi_options per (broken) target or per SCSI bus.  See esp(7d), isp(7d), from which this example /kernel/drv/esp.conf file is derived:

name="esp" parent="/iommu@f,e0000000/sbus@f,e0001000/espdma@f,400000"  reg=0xf,0x800000,0x40
target1-scsi-options=0x58
scsi-options=0x178;

Certain hardware RAIDs support a number of different LUNs (logical disks) but share a common set of I/O buffers between them.  This can cause SCSI QFULL conditions on devices without any commands    queued.  Since the algorithm is to retry the command when a previous command is completed, Solaris doesn't handle this situation very well.

The workaround is to decrease sd_max_throttle such that there's always at least 1 slot available for each LUN.  E.g., if you have 3 LUNs and your RAID supports upto 64 outstanding commands,   sd_max_throttle must be at most 31.  (Any two LUNs can get 31 requests and you still have two slots over for number 3)

Decreasing sd_max_throttle was seen to improve performance due to better load balancing among LUNs on some hardware RAIDs.