SunSolve Internal
| SunSolve Internal |
|
| Infodoc ID | Synopsis | Date | ||
| 14075 | General SCSI FAQ/PSD | 12 Jul 2000 |
| Status | Issued |
| Description | Top |
General SCSI FAQ/PSD
* SCSI Primer
* Which scsi patch do I need for Solaris 2.x?
* What patch fixes "esp0: bad sequence step (0x7) in selection"?
* What are the work arounds for using the DG raid box?
* Was the 2.1GB drive supported in 4.1.3?
* Are there any problems known to SCSI engineering regarding STK 3480
tape devices?
* At what revision was the Open Toolkit command probe-scsi-all added
to
the system PROM's?
* How can I get more bytes of request sense data using auto-request
sense?
* Are there plans to merge esp/sd accounting?
* What kind of problems are encountered porting Solaris 2.3 sparc
target
driver to 2.4 x86? Are there any changes on DDI/DKI for x86? Any
transition documentation exists?
* What is the recommended way to set initiator ids for a
multi-initiator
scsi bus?
* How is the devices directory configured for 4.x? For 5.x?
* What are the advantages of synchronous over asynchronous SCSI? How
can
one tell if a disk is running synchronous or not?
* Can I write a device driver in C++?
* Is there documentation available for the uscsi interface? Can I use
it
targets other than disk/tape/CD-ROM?
* Why do we need scsi_reset_delay set to a high value (e.g. 10000)?
* Why do we always offer only 5MB/sec transfer rate during
negotiation?
* Why do we sometimes not try for synchronous data transfer?
* How can I implement scatter-gather from a non-contiguous set of
descriptors of virtual memory buffers to the raw disk driver?
* What are the SCSI devices supported in Solaris?
* How is data integrity ensured on various components of a SCSI disk?
(memory, controller, disk, etc.)
* Are read/writes on SCSI device files interruptible?
* Do you support SCSI Processor Devices, or just the usual SCSI device
types like Direct-Access Devices (hard disks) and Sequential-Access
Devices (tape drives)?
* What is the version of the C compiler used to create sd,st,esp,isp?
* Are there any problems using C compiler 3.0.1 to compile scsi
drivers?
_______________________________________________________________________________
SCSI Primer
_______________________________________________________________________________
(non-fast) fast fast/wide
================== ===================== =====================
SCSI-1/SCSI-2 SCSI-2 SCSI-2
<= 5MB/sec throughput <= 10MB/sec throughput <= 20 MB/sec
_______________________________________________________________________________
narrow wide
================== =====================
SCSI-1 SCSI-2 (?)
8-bit 16-bit
8 address lines 16 address lines
up to 8 devices, up to 16 devices,
id 0-6 targets, id 0-6 targets,
id 7 initiator id 7 initiator,
id 8-15 targets
50 pin "A" cable 68 pin "P" cable
In multi-initiator systems, the scsi id 6 is usually the second
initiator,
as that has the second highest priority on both the narrow and wide
buses.
_______________________________________________________________________________
Sun Default SCSI id's:
desktops: SS10 and older
0 - second disk drive (on old machines, the main boot disk) on desktop
machines this is "disk3" (OBP)
3 - main boot disk and in OBP, "disk0" and "disk"
servers and desktops SS20 and later:
0 - main boot disk OBP "disk" and "disk0"
both:
4,5 - tape drives
6 - cdrom
7 - initiator id
_______________________________________________________________________________
single-ended differential
================== =====================
SCSI-1/SCSI-2 SCSI-2
superior signal quality
<= 6m total cable length <= 25m total cable length
_______________________________________________________________________________
Any combination of narrow/wide with single-ended/differential
with non-fast/fast is possible.
Fast/wide combo yields up to 20MB/sec throughput.
_______________________________________________________________________________
Sun SBus host adapters
ESP Sport8 FSBE fast, narrow, single-ended
DSBE fast, narrow, differential
ISP Sport16 SWIS fast, wide, single-ended, "intelligent"
DWIS fast, wide, differential, "intelligent"
FAS366 Happy Meal TBD fast, wide, single-ended?,
"semi-intelligent"
_______________________________________________________________________________
* Which scsi patch do I need for 2.x?
o Solaris 2.3
+ 101378-17 or greater (isp, esp, sd)
o Solaris 2.4
+ 102509-04 or greater (esp, isp)
+ 102329-03 (Fidelity point patch for st (fast/wide support.
Needs isp patch above))
+ 102035-01 (main line st - soft error reporting fix)
* What patch fixes "esp0: bad sequence step (0x7) in selection"?
This was fixed in 2.3
* What are the work arounds for using the DG raid box?
DG raid box has multiple logical unit (disks) per target. DG raid
box
firmware seems to be unfair in handling the tagged io requests: it
returns QUEUE FULL for a lun because other luns took away all the
possible queue space (seem to be 100 in total). There may be zero
outstanding commands to the lun, still it reports QFULL status. The
esp
driver does not expect to see queue full on a device with no
commands
outstanding, and hence stops sending further requests to it thereby
leading to hangs.
The following workarounds can be used:
o Disable tag queuing, the problem will go away
o There is a patched version of DG disk firmware; it works
around the
problem by reporting BUSY instead of QFULL; esp/sd drivers
retry
after busy conditions, so this fixes the problem.
o Tune sd_max_throttle in sd driver in such a way that total
number
of requests does not exceed 100 per target (i.e for all lun in
that target). For example, add the following in /etc/system:
set sd:sd_max_throttle=16
For DG raid with 6 luns this will work OK (6*16 = 96 < 100).
We can
set sd_max_throttle=8 to support more luns.
* Was the 2.1GB drive supported in 4.1.3?
Yes, the 2.1GB drive is fully supported in a 4.1.3 system. The 2.9GB
drive is not officially supported, but it seems to work in 4.1.3.
Note
that the filesystems are limited to 2GB size in 4.x. The new 9GB
drive
is not supported and will not work in 4.x systems.
* Are there any problems known to SCSI engineering regarding STK 3480
tape devices?
There were problems with those drives because they were using
implied
and not explicit restore data pointer messages which caused SCSI bus
resets. The patches listed above will have the fixes for Solaris 2.3
and 2.4. No patch is needed for Solaris 2.5 and later.
* At what revision was the Open Toolkit command probe-scsi-all added to
the system PROM's?
The command works on all SPARC 10s and later SPARC 2s. Not supported
until OpenBoot 2.6.
* How can I get more bytes of request sense data using auto-request
sense?
Currently not supported. We may add a new capability for specifying
the
sense length but note that some HBAs have built-in fixed sense
length
(eg. isp).
* Are there plans to merge esp/sd accounting?
The kernel statistics in esp are far more accurate than in sd but
seriously affect performance. There are no plans to support kernel
statistics in HBAs.
* What kind of problems are encountered porting Solaris 2.3 sparc target
driver to 2.4 x86? Are there any changes on DDI/DKI for x86? Any
transition documentation exists ?
Refer to DDK CD-ROM which included the Writing Device Driver guide
and
some sample drivers.
* What is the recommended way to set initiator ids for a multi-initiator
scsi bus?
If a SCSI bus is shared between two hosts, then one of the hosts
need
to change its initiator id from the default value of 7. So, with one
host taking the default of 7, you may set the initiator id on other
host to 6. When the host id is different from 7, you will see a
message
from the esp driver attach function when unix is booted up on a
system.
....
SunOS Release 5.4 Version on494_prealpha8 [UNIX(R) System V Release
4.0]
Copyright (c) 1983-1993, Sun Microsystems, Inc.
esp1:initiator SCSI ID now 6
esp2:initiator SCSI ID now 6
configuring network interfaces: le0.
.....
1. Global change: Using openboot PROM
This is the simplest way of changing the id. You have to be in
the
open boot prom prompt for making this change. The change will
remain intact until another change and will be effective across
system reboots and power on/off.
ok setenv scsi-initiator-id 6 - change it from 7 to 6
ok printenv - This will show you
the list of prom
environment variables
Note:This will set the value to 6 for all the scsi buses in the
system.
2. Specific bus id change using openboot PROM
This is useful in certain cases, for example if you have CDROM
drive at id 6 in the first scsi bus. In this case you may want
the
global setting to be 6 and then override the first bus id with
the
value of 7.
ok show-devs
ok cd /sbus@1,f8000000/esp@0,800000
ok pwd
/sbus@1,f8000000/esp@0,800000
ok " /sbus@1,f8000000/esp@0,800000"
ok select-dev
ok 6 XDRINT " scsi-initiator-id" ATTRIBUTE /* for id 6 */
ok 7 XDRINT " scsi-initiator-id" ATTRIBUTE /* for id 7 */
ok
ok .attributes /* to verify
the settings */
scsi-initiator-id 00000007
device_type scsi
clock-frequency 017d7840
intr 00000003 00000000
reg 00000000 00800000 00000040
name esp
interrupts 00000003
ok
Note: To effect a permanent change of the id for a particular
scsi
port, you may have to put these commands in nvram (see nvedit
and nvstore words).
3. Global change: Using esp/isp.conf file
While booting the kernel, the esp and isp attach routines can
set
the desired initiator ids based on the specification from the
corresponding driver.conf file.
To achieve a global change of initiator id to 6, for example,
you
can include this line in /kernel/drv/esp.conf file
scsi-initiator-id = 6
Note: This change is effective only when unix takes control.
Earlier OBP may have had different settings as given in 1 and
2.
4. Specific bus id change using esp/isp.conf file. You can
override
the value for a particular bus, say for example by adding the
following in esp.conf file:
name="esp" parent="/sbus@1,f8000000"
reg=0x0,0x800000,0x40
scsi-initiator-id=7;
Note: You have to specify the exact path name for parent and
also
the reg details. The property value is effective only when
there
is a unique match. You can obtain this info from "prntconf -v".
5. Recommendation:
Initiator id 6 does not work for SS1000. The cdrom is target 6
and
there are no target switches.
The isp/esp .conf files are not an option. There are
upgrade/install problems with this solution, because the
install/upgrade code will use initiator 7, since it does not
know
to pick up the new .conf files.
So that brings us back to the OBP methods of changing the
initiator id's.
SS1000 - set one machine at 4 and the other at 7.
SS2000 - set one machine at 6 and the other at 7.
move the tape to 4 and the the cdrom to 5
make sure all other disks are between 0-5.
I think it is simpler to set the scsi-initiator-id OBP
environment
variable and not mess with the /devices properties.
* How is the devices directory configured for 4.x? For 5.x?
In 5.x, there are 2 device directories:
o /devices - contain the physical device name found in the device
tree.
o /dev - these are logical devices, actually just links to
physical
devices
The devices in these directories are configured at boot time, when
you
type 'boot -r' at the Open Boot prompt. This will start the
re-creation
of the device tree and the configuration of the /devices and /dev
directories is done automatically.
In 4.x, there is no device trees and the physical devices are
stored in
/dev.
The configuration file /sys/sun4m/conf/GENERIC (or the name of your
kernel configuration file) have to be modified to add the new
device,
and the kernel have to be recompiled. There is no 'boot -r' under
4.x.
* What are the advantages of synchronous over asynchronous SCSI? How can
one tell if a disk is running synchronous or not?
In async scsi, each byte is requested/acknowledged before the next
byte
is transferred. This results in slower transfer rates especially
over
long scsi cables where propagations delays may be significant.
In sync scsi, initiator-target negotiate a data-transfer rate and an
offset between request/ACK. The offset allows several outstanding
REQS
and bytes may be sent before ACKs are received, up to the offset
specified. Hence, this may lead to higher tranfer-rate. Also, fast
scsi
option is also negotiated during synchronous negotiation. Most
drives
these days support synchronous mode.
To find out if the disk is running sync or async (without kadb or a
scsi analyzer), use 'prtconf -v' and look for the properties:
name length <0> -- .
name length <0> -- .
name length <4>
The value of the sync-speed property is the current xfer rate in KB.
If the target is async, there is not sync-speed property.
* Can I write a device driver in C++?
You may be able to, but it isn't supported. For one thing, the
system
header files are not guaranteed to work with both __cplusplus and
_KERNEL set.
Another reason is that unlike C, C++ requires significant runtime
support. Object constructors and destructors... object
initialization... This must come from somewhere and libC isn't
available in the kernel. You can avoid this requirement by avoiding
most uses of objects, but if you do that, why use C++ at all?
* Is there documentation available for the uscsi interface? Can I use it
targets other than disk/tape/CD-ROM?
Yes, look at /usr/include/sys/scsi/impl/uscsi.h for details on
uscsi_cmd struct. There is also a man page on uscsi available upon
request.
A user application can send SCSI commands to a target using the
USCSI
ioctl interface. It is an undocumented and unsupported interface
and it
will probably stay that way -- however, it should not go away in
the near
future, since some of our internal applications also use it.
If, however, the target is not a disk/cdrom, but some robot or other
SCSI target, the sd driver may not recognize that device. In that
case,
I would recommend you to use one of our sample drivers (bst.c/sst.c
-
provided in Driver Writing Kit) and suitably tailor the xx_attach()
routine in that driver to recognize that kind of device.
* Why do we need scsi_reset_delay set to a high value (e.g. 10000)?
The scsi_reset_delay is an option that can be set through
/etc/system,
very much like the more known scsi_options entry:
set scsi_reset_delay=10000
scsi_reset_delay of 10000 ms is required for some crummy old cdroms
that are inaccessible for a long time after a bus reset. Normally
that
is not fatal but when the CDROM is the boot device, it probably is.
* Why do we always offer only 5MB/sec transfer rate during negotiation?
The host adapter negotiates the transfer rate with a target. There
is
the possibility that the target can only do 5MB/s. But it is also
possible that you don't have a scsi host adapter capable of doing
fast
scsi, the FAS based controllers negotiate 10MB/s. The SS5, SS10,
FSBE,
and DSBE have FAS based controllers and support fast scsi.
One less likely factor is that you have scsi_options set to an
incorrect value -- make sure the options sync and fast are set
(0x3f8
enables all scsi options).
* Why do we sometimes not try for synchronous data transfer?
All currently supported host adapters negotiate for synchronous data
transfer. The two most common situations where synchronous data
transfer are not enabled are: during boot time and when the bus is
so
noisy that the SCSI bus only works reliably if we back down to
asynchronous mode.
There are two more remote possibilities: one that the disk doesn't
support synchronous data transfer (very unlikely these days), and
the
other possibility is that scsi_options is set to an incorrect value
(0x3f8 enables all scsi options).
* How can I implement scatter-gather from a non-contiguous set of
descriptors of virtual memory buffers to the raw disk driver?
There are some problems getting the stuff done on Solaris. First it
might be easy on LynxOS. You take the scatter gather list and
'feed' it
into the DMA chip. If the DMA chip supports chaining, you are done.
You
get one interrupt once the whole list is xferred. On Solaris/SPARC
we
have some problems:
1. There is no interface for SCSA/DDI that allows you to pass in
pieces of memory which are discontiguous in the virtual address
range. Something like scsi_init_pkt for uio(9S) structures or
ddi_dma_uio_setup might help.
2. Or SPARC SCSI hbas can deal with memory xfers where the IO
mapping
is contiguous. What we need here is something like the
ddi_dma_nextwin/ddi_dma_nextseg support in the SCSI hba. The
DDI
could send the segment list to the hba and the hba would walk
the
whole list and callback once the whole list is xferred. It
would
be like we handle DMA windows right now but without having the
requirement of having a contiguous I/O mapping.
3. To solve 2, the DDI has to map the scatter-gather list in some
contiguous I/O mapping to express it by a tuple. Now this can
only
be done if the buffers in the scatter-gather list are
page-aligned
and cover a whole page. The first buffer could start anywhere
within a page but must end at a page boundary, all middle
buffers
must start and end at a page boundary, and the last buffer has
to
start at a page boundary but can end anywhere within a page. So
without having the correct layout of the buffers, it's
impossible
to setup just *one* I/O mapping.
To summarize: We need 1. We need also 3. 2 is pretty easy
because
the nextwin/nextseg support is already in the DDI code.
* What are the SCSI devices supported in Solaris?
The answer here is a summary of the SCSI Handbook which provides a
more
detailed answer. The SCSI Handbook has complete matrices of
chips/HBAs/platforms/OS version/devices supported.
Table 1: Chips used in Sun SCSI products
Chips Platforms
-------------------------------------------------------
ESP100, 53C90 SS1, SS1+, IPC
ESP100A, 53C90A SS2, IPX, Sport8
ESP236 Galaxy, SBE
FAS101, MACIO Classic, LX, SS10, SS20, and SS5
FAS236 Galaxy, DSBE, FSBE
ISP1000 DWIS, SWIS
Table 2: Platforms and their motherboard SCSI chips
Platform Chip Transfer Active termination
name rate (MB/s) required?
----------------------------------------------------------------------
1 SE1E (4/e) 53C90 5 no
2 Classic (4/15) MACIO 10 yes
3 SLC (4/20) 53C90A 5 no
4 ELC (4/25) 53C90 5 no
5 LX (4/30) MACIO 10 yes
6 IPC (4/40) 53C90A 5 no
7 IPX (4/50) 53C90A 5 no
8 SS1 (4/60) 53C90 5 no
9 SS1+ (4/65) 53C90A 5 no
10 SS2 (4/75) 53C90A 5 no
11 SS10 (4/80) MACIO 10 yes
12 SS10SX (4/80SX) FAS236 10 yes
13 SparcServer630 FAS236 10 yes
14 SparcServer670 FAS236 10 yes
15 SparcServer690 FAS236 10 yes
16 SS5 MACIO 10 yes
17 SS20 MACIO 10 yes
18 SS1000 FAS236 10 yes
19 SS2000 * no motherboard SCSI
Table 3: Sbus HBA cards and supported platforms
HBA Chip Transfer Platforms
rate (MB/s)
----------------------------------------------------------------------
SSHA (Sport8) 53C90A 5 IPC, IPX, SS1, SS1+, SS2,
Classic, LX, SS10,
SS10SX,
SS5, SS20.
SBE ESP236 5 SS10, SS10SX, SS20,
SparcServer6X0, SS1000.
FSBE FAS236 10 IPC, IPX, SS1, SS1+, SS2,
Classic, LX, SS10,
SS10SX,
SS5, SS20,
SparcServer6X0,
SS1000, SC2000.
DSBE FAS236 10 SS10, SS10SX, SS5, SS20,
SparcServer6X0, SS1000,
SC2000
DWIS ISP1000 20 (wide) SS1000, SC2000
SWIS ISP1000 20 (wide) SS1000
4.x support
o FAS101 on motherboard (early SS10) supported in 4.1.3 and above
o MACIO (FAS101) on motherboard supported in 4.1.4 and above
o FAS236 on motherboard supported in 4.1.2 and above
o SSHA supported in 4.0.3 and above
o SBE supported in 4.1.2 and above
o FSBE and DSBE supported in 4.1.3 and above
o 4.x doesn't support SS1000 and SC2000 servers.
5.x support
o FAS101 on motherboard (early SS10) supported in 2.1 and above
o MACIO (FAS101) on Classic/LX motherboard supported in 2.1 and
above
o MACIO (FAS101) on on all other platforms supported in 2.3 (E2
with
supplement B) and above
o FAS236 on motherboard supported in 2.2 and above
o SSHA supported in 2.0 and above
o SBE supported in 2.0 and above
o FSBE and DSBE supported in 2.0 and above
o DWIS supported in 2.3 and above
o SWIS supported in 2.3 E3 and above
* How is data integrity ensured on various components of a SCSI disk?
(memory, controller, disk, etc.)
First of all, SCSI drivers don't do any data checking while
transferring
data. SCSI hardware provides Parity checking. Here, some type of
ECC is
used to store data on SCSI device and the SCSI bus uses a parity
bit.
However, one can install additional pseudo-drivers like Online
DiskSuite or Veritas RAID software, which will try to make mirrors,
or
encode the ECC into the RAID system. Basically, these software
modules
sit between our SCSI drivers and the OS (which sends io requests)
and
tries to do fault tolerance via diff mechanisms like mirroring or
RAID-5 ... In that case, SCSI drivers get additional requests for
mirrored data or ECC data to be written to disks.
The most valuable aspect is that Sun qualifies SCSI devices to
ensure
that the sequence between the REQ/ACK handshakes meet SCSI
specification requirements.
* Are read/writes on SCSI device files interruptible?
No, the scsi disk and tape operations are not interruptible unlike
the
tty operations. The application (for example tar, dd etc..) would
receive the ^C and other signals and might stop issuing further
read/write requests to scsi drivers.
* Do you support SCSI Processor Devices, or just the usual SCSI device
types like Direct-Access Devices (hard disks) and Sequential-Access
Devices (tape drives)?
Sun scsi drivers include support for direct access devices (disks),
sequential devices (tapes) and CDROM devices. There is no direct
support for processor devices
* What is the version of the C compiler used to create sd,st,esp,isp? Are
there any problems using C compiler 3.0.1 to compile scsi drivers?
SunPro 2.0.1. This is because the later compiler optimizations are
too
aggressive and toss structures/variables that are not used directly
by
the source code, but are used by hardware of the machine.
| Applies To | Hardware |
| Attachments | (none) |
|
Sun Proprietary/Confidential: Internal Use Only
Feedback to SunSolve Team