sverre@lars.Seri.GOV (Sverre Froyen) (05/07/91)
For its entire life (or at least since 1.5h came out) my pc532 has reported a scsi error on the first access to each of my disk drives. Since subsequent accesses are error free, I have just ignored this problem until now. With the arrival of my scsi floppy drive, however, it appears I need to find a solution. The floppy drive does not recover but gives an endless stream of error messages, sense key = 5, code = 24, which translates into "Illegal field in command descriptor block". This is the same error that I get (once) from my two hard drives. Since this appears to be a general problem of initialization I am hoping that someone else have run into this and perhaps even solved it. For the record, the commands I use to initialize the floppy drive are mode select (0x15) format unit (0x04) rezero unit (0x01) and I have run the exact same commands from the ROM monitor of my ICM3216 without any problems. For the hard disks I use the standard initialization commands in scsi_hi.c. Sverre -- Sverre Froyen sverre@seri.gov, sunpeaks!seri!sverre
phil@cs.wwu.edu (Phil Nelson) (05/08/91)
From: sverre@lars.Seri.GOV (Sverre Froyen) For its entire life (or at least since 1.5h came out) my pc532 has reported a scsi error on the first access to each of my disk drives. Since subsequent accesses are error free, I have just ignored this problem until now. With the arrival of my scsi floppy drive, however, it appears I need to find a solution. The floppy drive does not recover but gives an endless stream of error messages, sense key = 5, code = 24, which translates into "Illegal field in command descriptor block". This is the same error that I get (once) from my two hard drives. Since this appears to be a general problem of initialization I am hoping that someone else have run into this and perhaps even solved it. Yes, others have run into the problem and also have ignored it. After getting my 150Mb tape drive I tried to solve the problem. Here is the problem as I SEE IT. After issuing the reset command (I think that was the command.) the driver just goes into a timing loop. After the timing loop, it exits and the read or write continues. Some devices take longer to reset. After doing one read/write try with an error, the device is ready and no errors occur after that. Once a disk is initialized, it is not initialized again. Other devices take much longer (Tape Drive, floppy) and the read/write tries several times to read/write before giving up and trying to initialize the disk again, which of course was the reason it was not ready! A fix that might work is making the initialization loop real long. I didn't find a number large enough for my tape but gave up trying because I had to make major mods and I thought I'd wait for Des Young to finish his work on a completly different SCSI driver. The best fix would have the initialization routine wait until the device is not busy and then return. That would be fast for fast devices and slow for slow devices. --Phil
des@musashi.wpd.sgi.com (Des Young) (05/08/91)
Hi, you should not use format unit (0x04) just to initialize the floppy drive. This will instead try to format the floppy diskette ! mode select, rezero unit should suffice. Des. P.S. check your mode select parameters, that is where an illegal field would most likely occur. Or, a non-zero "init" byte in the format instruction
sverre@lars.Seri.GOV (Sverre Froyen) (05/08/91)
Thanks to Bruce, Phil, and Des I now understand the floppy problem. Here is the scoop. > you should not use format unit (0x04) just to initialize the floppy >drive. This will instead try to format the floppy diskette ! >Des. I used the format because I believed (incorrectly) that the monitor "raw" command was broken and I needed to get a floopy formatted. It turns out that formatting takes too long and the Minix scsi driver gives a watchdog timeout. Once I took the format command out of my initialization sequence I was back to the single 5/24 error that I also get from my hard drives. In other words I have a working floppy drive. The next step is to dig a hole through the ioctl mess in the kernel in order to get other scsi commands to the drive. I suspect that the watchdog timeout problem will continue to be a problem too. Is there a solution to the latter besides increasing the timeout length. (Formatting hard drives can take tens of minutes). Sverre
news@bungi.com.mu.edu (05/08/91)
Attached is appendix F from the SCSI-2 specification which addresses
power on initialization in general. I believe the body of the spec
contains additional initialization info specific to each scsi device
class.
I (and I assume the reset of the group) look forward to hearing
how you make out with the scsi-floppy -- good luck.
best regards,
johnc
--------------- Appendix F, SCSI-2 ----------------
F. Power On Protocols - Recommended Initialization Procedure
This appendix describes the normal mechanisms for obtaining the information
required for system initialization from SCSI-2 devices as well as all SCSI
devices meeting conformance level 2 as defined in Appendix E of SCSI-1. This
procedure documents the steps required to obtain this information and to
achieve the desired initial states in the attached devices.
F.1. System Initialization
The following list of information is assumed necessary and sufficient for
normal system initialization:
1) A list of each installed and powered on SCSI device for each SCSI
address. SCSI devices that are not power-on are treated as not
installed, assuming that the terminators are powered from a source other
than the power-off SCSI devices.
2) A list of the installed logical units for each SCSI device. Power-off or
failing logical units may not be completely identifiable.
3) The device type for each available logical unit.
4) The manufacturer and model for each available logical unit. (This
information may not be available for SCSI-1 devices)
5) The critical device type information for each available logical unit.
This information varies depending on the device type.
6) Extended functionality of SCSI devices such as target role capability in
devices that are principally initiators, AEN capability, etc.
The following states are established for each attached logical unit that has
power available and is not failing:
1) The ready state for each available logical unit, including any required
medium initialization, but not formatting.
2) All error conditions associated with the starting process are cleared.
3) All UNIT ATTENTION conditions are cleared.
4) All data transfer parameters are established.
5) All pertinent system tuning parameters are established where known. Note
that these may be modified dynamically to improve the performance
characteristics of the system.
The following procedures show the sequences necessary to implement a system
that initializes itself with a minimum of information available at power-on.
In reality many systems are not as generalized, and have considerable
information available about the configuration at power-on. In those cases,
the sequence steps that would have been necessary to obtain information about
the configuration may be skipped or ignored.
F.2. General Procedure for Initializing Devices
The system should execute the following steps to perform initialization.
Some of the steps are detailed in subsequent paragraphs. Note that the text
represents a primitive pseudo-code that can be converted to the appropriate
software object code by those who implement device drivers.
F.2.1. General Procedure Executed by Initiators
Initiator Activities:
Power On: It is assumed that each SCSI device, as it is powered on, performs
appropriate internal reset operations and internal test operations. Once
powered on, initiators that have target capability should be prepared to
respond to a selection within a system-specific time.
Reset: At power-on time, it is likely that an SCSI device has caused errors
to the ongoing activities on the SCSI bus. A bus reset should be generated to
notify attached devices that any activities that may have been occurring
should be restarted.
Find Devices: Each SCSI address other than the initiator's SCSI address
should be tested to determine if an SCSI device responds. If an SCSI device
responds, an INQUIRY command to logical unit 0 should be executed. The
information obtained indicates the device type, manufacturer, and model of the
attached logical unit 0 if the response data format field is one or two. If
the response data format field is zero, only the device type field is valid.
In addition, the version of the command set supported by the device is
indicated by the ANSI-approved version field.
Find logical units: Each possible logical unit number on the attached
targets should be tested for existence using an INQUIRY command. Those found
with a non-zero peripheral qualifier in the INQUIRY data should not be
included in the list of available logical units. Each available logical unit
should be added to the host configuration information, identifying the
associated logical unit number, device type, manufacturer, and model.
Verify State: The verify state test (see F.2.3) should be made to clear
any outstanding errors, capture and clear UNIT ATTENTION conditions, and
determine the state of readiness of the available logical units. The logical
units should be identified as ready, not ready, or failing by this test.
Device Initialization: The device undergoes a device-dependent
initialization process. This process is described for direct-access devices,
sequential-access devices, and processor devices. Other device initialization
procedures are not described since they tend to be similar to one of these
initialization procedures. The initialization process takes into account the
state of the device as identified during the verify state test.
Device On-line: The successful completion of the device initialization
process allows the device-table entry to be fully enabled. The device joins
the system with all key parameters identified and initialized. The device
state is known and may be presented to the system operator.
F.2.2. Procedure Executed by Temporary Initiators
A temporary initiator typically performs initiator operations only under the
direction of a host processor. Such operations may include read and write
commands associated with management of a COPY command. Other possible
operations include issuing a SEND command associated with asynchronous event
notification. As such, temporary initiators need not completely perform the
last two steps defined above. Since all commands are managed by a host
processor, temporary initiators normally need not recover information about
the media density, the sparing algorithms, or other detailed information that
may be required only by a host processor.
F.2.3. Verify State Test
The verify state test uses the following steps to identify any outstanding
errors, clear any UNIT ATTENTION conditions, and determine the readiness of
the devices. The verify state test should be executed against each available
logical unit.
TEST UNIT READY (1)
|
|
________________|______________
| GOOD | CHECK CONDITION
| |
exit: LOGICAL UNIT READY |
REQUEST SENSE (2)
_______________|
|
|
TEST UNIT READY (3)
|
|
______________|_______________
| GOOD | CHECK CONDITION
| |
exit: LOGICAL UNIT READY |
REQUEST SENSE (4)
|
_______________|
|
|
TEST UNIT READY (5)
|
|
_____________|_______________
| GOOD | CHECK CONDITION
| |
exit: LOGICAL UNIT READY |
_______________|
|
|
REQUEST SENSE (6)
|
|
_____________|_______________
| NOT READY | OTHER CHECK
| |
exit: LOGICAL UNIT NOT READY exit: LOGICAL UNIT FAILED
Figure F-1: Verify State Test
TEST UNIT READY (1):
This TEST UNIT READY command is used to determine if any outstanding CHECK
CONDITION or UNIT ATTENTION condition exists. If not, the device is indicated
to be ready.
REQUEST SENSE (2):
This REQUEST SENSE command is used to clear the outstanding CHECK CONDITION.
Most SCSI-2 logical units return UNIT ATTENTION sense key in this sense
information.
TEST UNIT READY (3):
This TEST UNIT READY command is used to see if the UNIT ATTENTION condition
or other error was successfully cleared. In some special cases, another error
may have been nested with the UNIT ATTENTION and this TEST UNIT READY command
may also return CHECK CONDITION status.
REQUEST SENSE (4):
This REQUEST SENSE command is used to determine which error or exception was
associated with the CHECK CONDITION status returned by the TEST UNIT READY (3)
command. In addition, this REQUEST SENSE command is used to clear the
outstanding CHECK CONDITION. This may be a NOT READY sense key or another
unexpected error.
TEST UNIT READY (5):
This TEST UNIT READY command is used to see if all outstanding CHECK
CONDITION statuses have finally been cleared. If so, the logical unit is
identified as ready.
REQUEST SENSE (6):
This REQUEST SENSE command is used to determine why there is a persistent
CHECK CONDITION status. If the sense key is NOT READY, the logical unit is
identified as not ready. If the sense key indicates some other failure, the
logical unit is identified as failing and the sense key is logged in the
appropriate area.
IMPLEMENTORS NOTE: Commands that receive BUSY or RESERVATION CONFLICT
status should be re-issued until some other status is received.
F.3. Direct-Access Device Initialization Procedure
The device-dependent initialization process for a direct-access device may
be divided into three independent activities. The first activity enables the
minimum logical function required for execution of READ commands on the boot
device. The second activity is performed on all direct-access devices,
including the boot device. It establishes all required initial parameters and
operating conditions. The third activity is performed on direct-access
devices that have never been formatted or initialized. This activity is
normally performed by an initialization utility program.
F.3.1. Boot Device Initialization Procedure
It is assumed that the boot program and boot device have been prepared in
such a manner that proper block lengths, data file contents, and logical
addresses have been implemented by both the boot device and the boot program.
The boot program prepares the boot device for operation in the following
manner:
Verify Ready: The state of the device as determined by the verify state
test (see F.2.3) is examined. If the test indicates that the required drive
has failed, the boot device initialization is not performed and appropriate
error indications are presented.
Start Device: A START STOP UNIT command should be issued with the start bit
set to one. The Immed bit should be set to zero in order to guarantee that
the returned status reflects the completion of the device start operation. A
disconnect operation is likely to occur since the start process may take a
considerable period of time. If system-controlled power sequencing of the
peripheral devices is required, it is done by managing the timing relationship
of the START STOP UNIT commands to different logical units.
If GOOD status is returned, the next step should be started. If CHECK
CONDITION status is returned, a REQUEST SENSE command is issued to determine
what error condition was detected. If an ILLEGAL REQUEST sense key is found,
the START STOP UNIT command was not supported by the target or peripheral
device and the next step should be started. If any other error is detected
(BUSY status is not an error), the boot device initialization should be
terminated and appropriate error indications should be presented.
Verify Ready / Spinning: A verify state test should be performed. If the
device is ready, the next step should be started. If the device is not ready
or failing, the boot device initialization should be terminated and
appropriate error indications should be presented.
Boot: The boot READ commands can now be started on the boot device. It is
assumed that the information read includes the programs that are required to
continue the system initialization and bring-up process, including the
necessary programs and device drivers to perform the other system
initialization procedures.
F.3.2. General Direct-Access Device Initialization Procedure
A general direct-access device initialization procedure is defined below.
The initialization procedure should be executed for each attached logical unit
that has been identified as a direct-access device. Execution of this
procedure may be overlapped from one logical unit to another. If the
initiator supports only a limited range of devices, parts of this procedure
may be skipped or simplified.
Verify Ready: The state of the device as determined by the verify state
test (see F.2.3) should be examined. If the device has failed, the general
direct-access device initialization should not be performed and appropriate
error indications should be presented.
Start Device: A START STOP UNIT command should be issued with the start bit
set to one. If GOOD status is returned, the next step should be started. If
CHECK CONDITION status is returned, a REQUEST SENSE command should be issued
to determine what error condition was detected. If an ILLEGAL REQUEST sense
key is found, the START STOP UNIT command was not supported by the device and
the next step should be started. If any other error is detected (BUSY status
is not an error), the general direct-access device initialization procedure
should be terminated on this logical unit and appropriate error indications
should be presented.
Verify Ready / Spinning: A verify state test (see F.2.3) should be
performed. If the device is ready, the next step should be started. If the
device is not ready or failing, the general direct-access device
initialization should be terminated for this logical unit and appropriate
error indications should be presented.
Determine Parameters: If the ANSI-approved version field of the previously
executed INQUIRY command was 0 or 1, the MODE SENSE information, if any, may
be vendor specific and this function should be skipped unless required by the
vendor specific initialization protocols.
If the ANSI-approved version field is 2, optional MODE SENSE information is
by this standard. In this case, a MODE SENSE command should be executed with
the page control field set to request current values and the page code field
set to request all pages. A record should be made of the current values.
If a CHECK CONDITION status is returned to the MODE SENSE command, then a
REQUEST SENSE command should be issued. If the sense key is ILLEGAL REQUEST,
then the target does not support the MODE commands. In this case, the
initiator should skip to the determine capacity step.
A second MODE SENSE command should be executed with the page control field
set to request changeable values and the page code field set to request all
pages. A record should be made of the changeable values.
Any errors that occur during the two MODE SENSE commands should be recorded
and the initialization for the failing logical unit should be terminated.
Set Parameters: If the ANSI-approved version field is 0 or 1, the
initialization operation may be vendor specific and may be executed according
to the vendor's rules for the peripheral device. The system is assumed to
have some other source of information concerning these requirements or it may
skip this step, accepting the target's default parameters.
If the ANSI-approved version field is 2, the optional MODE SELECT command is
defined by this standard. The actual requirements for the parameters are
characteristic of the particular system and should be known to the system.
The current values and the changeable values obtained from the previous MODE
SENSE commands should be examined to see if the system's requirements are
satisfied and if the parameters can be modified. If all values are correct,
the remainder of this step may be skipped. If modifications need to be made
to the changeable values, a MODE SELECT command should be issued to modify the
appropriate pages. This may include modifying error recovery parameters or
performance tuning parameters. Most geometry parameters should not be
modified during general direct-access device initialization.
Determine Capacity: The capacity and block size of the logical unit are
determined by issuing a READ CAPACITY command. The information is stored for
access by the system device drivers.
The direct-access device is now fully initialized and all required
information has been made available to the system. When all available non-
failing devices have been initialized, the system initialization is considered
complete.
F.3.3. Direct-Access Device Medium Initialization Procedure
The following initialization procedure is not part of normal power-up system
initialization. It is assumed to be performed after completion of the general
system initialization process but uses only the INQUIRY data information
obtained during that process. It is performed to initialize the device medium
and is normally performed only by an initialization utility program.
Determine Format Requirement: The requirement to perform a format operation
is normally generated by an operator who has just installed a new device known
to require formatting. It may also be generated by recognition that the
device has information that is no longer valid and should be totally erased.
It may also be generated by changes in system requirements, including
different block sizes. Finally, reformatting may also be required to
restructure the defect management.
The general direct-access device initialization procedure may have
identified the device as failing because of the inability of the device to
recover the READ CAPACITY parameters. The device is assumed to have been
started during the general direct-access device initialization procedure. The
verify state test should be executed again. The device should be ready
according to that test. If the logical unit is not ready or failing, the
direct-access device medium initialization procedure should be terminated and
appropriate error indications should be presented.
If it was determined in the general direct-access device initialization
procedure that the target does not support the MODE commands, then the
initiator should either proceed to the perform format operation step or it
should perform the determine format parameters and set format parameters steps
in the vendor-specified manner.
Determine Format Parameters: If the ANSI-approved version field is 0 or 1,
the direct-access device medium initialization procedure may be vendor
specific and should be executed according to the vendor's rules for the
peripheral device. The system is assumed to have some other source of
information concerning these requirements or to be willing to accept the
target's default format.
If the ANSI-approved version field is 2, a MODE SENSE command should be
issued with the page control field set to current values and the page code
field set to return all pages. A MODE SENSE command should be issued again
with the page control field set to changeable values and the page code field
set to return all pages. The information returned by the two MODE SENSE
commands indicates what values should be provided by the system to complete
the format parameters. If either of these MODE SENSE operations does not
complete normally, the media initialization operation should be terminated and
appropriate error indications should be presented.
Set Format Parameters: If the ANSI-approved version field is 0 or 1, the
format requirements may be vendor specific and the appropriate commands should
be known to the initialization utility or it should be willing to accept the
target's default format. Those format preparation commands, if any, should be
executed at this time.
If the ANSI-approved version field is 2 and the target supports the MODE
commands, the logical unit should be prepared for medium formatting by
executing a MODE SELECT command. The necessary formatting parameters are
selected to meet the system requirements and are placed into the changeable
value locations. The MODE SELECT command is then issued. If the command
fails, the media initialization procedure should be terminated and
appropriate error indications should be presented. If the command succeeds,
the next step should be performed.
Perform Format Operation: After the appropriate format parameters are
established, the FORMAT command should be executed. The FORMAT parameters
depend on the system requirements and the device capabilities. These
parameters should be made easily variable in the operating system architecture
so that modifications can be performed when system or device requirements
change. An error may be returned if improper format parameters are selected.
If the FORMAT command fails, the media initialization procedure should be
terminated and appropriate error indications should be presented. If the
command succeeds, the device is fully operational and the next step should be
performed.
Set Parameters: If the ANSI-approved version field is 0 or 1 or if the
target does not support the MODE commands, the initialization operation may be
vendor specific and may be executed according to the vendor's rules for the
peripheral device. The system is assumed to have some other source of
information concerning these requirements or it may skip this step, accepting
the target's default parameters.
If the ANSI-approved version field is 2, the optional MODE SELECT command is
defined by this standard. The actual requirements for the parameters are
characteristic of the particular system and should be known to the system.
The current values and the parameters established by the MODE SELECT and
FORMAT commands should be examined to determine if the system requirements are
satisfied and if the parameters should be modified. If all values are
correct, the remainder of this step may be skipped. If modifications need to
be made to the changeable values, a MODE SELECT command should be issued to
modify the appropriate pages. This may include modifying error recovery
parameters or performance tuning parameters. Most geometry parameters were
established by the storing of parameters during the MODE SELECT and FORMAT
commands and should not be modified.
Determine Capacity: The capacity and block size of the logical unit should
be determined by issuing a READ CAPACITY command. The information should be
stored for access by the system device drivers.
Upon completion of this procedure the device should be initialized and
prepared to partake in system-oriented activities. Other system
initialization operations may also be required, including the establishment of
system volume labels, tables of contents, and other structures.
F.4. Sequential Access Device Initialization Procedure
The initialization process for a sequential-access device may be divided
into two independent activities. The first activity establishes all required
initial parameters and operating conditions for the identified devices. The
second activity performs any required medium initialization for the available
logical units.
F.4.1. General Sequential-Access Device Initialization
A general sequential-access device initialization procedure is defined
below. The initialization procedure should be executed for each attached
logical unit that has been identified as a sequential-access device.
Execution of this procedure may be overlapped from one logical unit to
another. If initiator supports only a limited range of devices, parts of this
procedure may be skipped or simplified.
Verify Ready: The state of the device as determined by the verify state
test (see F.2.3) should be examined. If the device has failed, the general
direct-access device initialization should not be performed and appropriate
error indications should be presented.
Start Device: A LOAD UNLOAD command should be issued with the load bit set
one. If GOOD status is returned, the next step should be started. If CHECK
CONDITION status is returned, a REQUEST SENSE command should be issued to
determine what error condition was detected. If an ILLEGAL REQUEST sense key
is found, the LOAD UNLOAD command was not supported by the device and the next
step should be started. If any other error is detected, the device
initialization procedure should be terminated on this logical unit and
appropriate error indications should be presented.
Verify Ready / Loaded: If necessary, a verify state test (see F.2.3) should
be performed. If the device and medium are ready, the next step should be
started. If a NOT READY sense key is reported, manually loading the medium or
activating a switch mechanism may be required to establish the ready state for
the device. If any other error is detected, the device initialization
procedure should be terminated and the appropriate error indications should be
presented.
Determine Parameters: A READ BLOCK LIMITS command should be issued to
determine the range of block sizes supported by the device. Following this
command, a MODE SENSE command should be issued to determine additional
operating parameters of the device. If the ANSI-approved version field of the
previously executed INQUIRY command is 0 or 1, any MODE SENSE data following
the header and block descriptor is vendor specific. If the ANSI-approved
version field is 2, additional pages of MODE SENSE data may be available as
defined in this standard. In this case, a MODE SENSE command should be issued
with the page code field set to return all pages. If any unrecovered errors
are detected during execution of the READ BLOCK LIMITS or MODE SENSE commands,
the device initialization process should be terminated and the appropriate
error indications should be presented.
Set Parameters: Specific system requirements may require that certain
operating parameters be changed from the values reported in the previously
executed MODE SENSE command. If changes are required, a MODE SELECT command
should be issued to modify the appropriate parameters. This may include error
recovery parameters, performance tuning parameters, or other basic operating
parameters. If any unrecovered error occurs during this step, the device
initialization process should be terminated and the appropriate error
indications should be presented. If no change is required or no unrecovered
error occurs, the general sequential-access device initialization procedure is
complete.
F.5. Asynchronous Event Notification Initialization Procedure
A target using asynchronous event notification, must first execute an
initialization procedure. This initialization procedure allows the target
device to determine which SCSI devices are capable and willing to receive an
asynchronous event notification. Parameters that affect asynchronous event
notification within the target device is specified in the control mode page.
The initialization procedure is performed at power-on (after waiting the
recommended 10 seconds for all devices to be able to respond and waiting the
time specified in the control mode page). It may also be performed following
a reset condition, or when a target becomes aware of another SCSI device, or
following the issuance of the control mode page or prior to a device issuing
an asynchronous event notification.
The target device that uses asynchronous event notification must determine
which devices on the bus are capable of receiving an asynchronous event
notification. This is done by the target device becoming a temporary
initiator and selecting each SCSI device. If the SCSI device responds to
selection, the verify state test (see F.2.3) is performed. If the verify
state test fails, then the SCSI device does not support asynchronous event
notification. If the verify state test succeeds then an INQUIRY command is
issued to logical unit zero. The peripheral qualifier field in the INQUIRY
data is examined to determine if the SCSI device is a processor device type
and then the AENC bit is examined. An AENC bit of zero indicates that
asynchronous event notification is not supported by the SCSI device. An AENC
bit of one, indicates that asynchronous event notification is supported by the
SCSI device.
Disabling of asynchronous event notification can be done by using a vendor-
specific hardware mechanism (e.g., switch or jumper), or by issuing control
mode pages to devices that support saved parameters.
. end of Appendix F
--
John Connin: manatee Orlando, Florida
UUCP: {uunet,ge-dab,ucf-cs}!tarpit!tous!manatee!johnc