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.

In 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.

ASGAUR