- Drivers I-o Data Scsi & Raid Devices Download
- Drivers I-o Data Scsi & Raid Devices Usb
- Drivers I-o Data Scsi & Raid Devices List
- Drivers I-o Data Scsi & Raid Devices For Sale
The SCSI device driver writer must be aware of how this routine affects the design of the SCSI device driver. Understanding the tmbuf Structure The tmbuf structure is used for communication between the SCSI device driver and the SCSI adapter device driver for a target-mode received-data buffer.
- SCSI-1 SCSI-2 SCSI-3 WIDE UltraSCSI Advanced SCSI Features multi-threaded I/O, scatter/gather, tagged queuing, disconnect/reconnect, synchronous and asynchronous data transfer Electrical Drivers Single-ended, active, programmable via SCSISelect configuration utility Board Dimensions 6.87' x 3.87' (17.0 cm x 9.5 cm) Operating Characteristics.
- The Solaris DDI/DKI divides the software interface to SCSI devices into two major parts: target drivers and host bus adapter (HBA) drivers. Target refers to a driver for a device on a SCSI bus, such as a disk or a tape drive. Host bus adapter refers to the driver for the SCSI controller on the host machine.
- Each SCSI device must have a unique SCSI ID. Most Seagate SCSI drives come with no jumpers on SCSI ID (SCSI ID = 0). The SCSI host adapter usually uses SCSI ID = 7. If you are installing a drive model ending in LC (uses 80-pin SCA connector), the host normally sets the ID over the I/O interface.
- I/O fencing uses an enhancement to the SCSI specification, known as SCSI-3 persistent reservations, (SCSI-3 PR or just PR). SCSI-3 PR is designed to resolve the issues of using SCSI reservations in a modern clustered SAN environment.
| Last modified: 8 February 1999. |
These programming notes cover the following topics:
SCSI Miniport Drivers
NT 5 SCSI miniports are either run as legacy drivers or as PnP drivers. A PnP miniport must have a HwScsiStopAdaptor routine and have a PnPInterface entry in the registry.Initialisation happens different, ie in PnP manner.
Miniport called by the system port driver to process SCSI Request Blocks (SRBs). These are translated by NT into Command Descriptor Blocks (CDBs). Non-SCSI drivers can fit into this scheme and pretend to be SCSI device.
A miniport has a DriverEntry and various HwScsi... routines. Various other call-backs used. Called by port driver.
A driver has a device extension for each HBA. Also has a luextension for each logical unit. Can specify the size of SrbExtensions.
DriverEntry initialises an HW_INITIALIZATION_DATA structure with pointers to its routines. It then calls ScsiPortInitialize for each bus it might be attached to.
In legacy drivers, ScsiPortInitialize calls back the driver’s HwScsiFindAdapter routine. HwScsiFindAdapter sees if its hardware is present on the given bus and gets access to it. It allocates a DMA buffer if appropriate.
HwScsiInitialize is then called for each found HBA. This sets any registers and enables interrupts.
HwScsiStartIo called to process SRBs. The miniport driver owns the request and must complete it. The miniport calls ScsiPortNotification with notification codes. For each SRB, a miniport usually issues a CompleteRequest notification and then a NextRequest or NextLuRequest notification.
Most SRBs are SRB_FUNCTION_EXECUTE_SCSI.
A miniport can say that it is busy and ask that the SRB be queued again for processing later.
To perform DMA, call ScsiPortIoMapTransfer. When the DMA controller is ready, the miniport’s HwScsiDmaStarted routine is called to set up the HBA for the DMA transfer. Call ScsiPortFlushDma to flush any cached data from DMA controllers.
The HwScsiInterrupt routine is to service a HBA interrupt. Note that normally there is no deferred procedure call. So service the interrupt and call ScsiPortNotification to complete the request and start the next one.
Some HwScsiInterrupt routines might need to run for a long time, eg more than 50 microseconds if doing polling programmed I/O. This is best handled by scheduling a DPC call-back using ScsiPortNotificationCallEnableInterrupts with a HwScsiEnableInterruptsCallback routine. HwScsiEnableInterruptsCallback can carry on interacting with the HBA safe from its own interrupts, although all other system interrupts are enabled. After completing the request, as per usual, it makes a ScsiPortNotificationCallDisableInterrupts with a HwScsiDisableInterruptsCallback routine; this should reenable interrupts from the HBA.
HwScsiResetBus is called to reset a bus. ScsiPortCompleteRequest can be used instead to complete all relevant requests after a bus or device reset.
A timer routine might be used to poll the HBA. To set up a one-shot timer, make a ScsiPortNotificationRequestTimer call with a HwScsiTimer routine and the required interval. The port driver ensures that HwScsiTimer does not run at the same time as a HwScsiInterrupt.
HwScsiStopAdaptor is called when the HBA is about to be stopped or removed. Disable all interrupts and release all resources.
Use ScsiPortLogError to report errors.
Use ScsiPortStallExecution to wait for small time intervals. Never delay for more than 1 millisecond in any miniport routine.
Miniport drivers of HBAs that are initialised in x86 real mode and that are sensitive to x86-specific processor mode transitions must have a HwScsiAdapterState routine.
The use can set values which disable certain features of an HBA: synchronous transfers, bus-disconnect operations, tagged queuing and internal queuing. How?
SRBs have:
The PathId value
This identifies the SCSI bus on which the device is attached. It is a required value in SRBs.
The TargetId value
This identifies the TID of the controller or device. It is a required value in SRBs.
The Lun value
CDB
SCSI Class Drivers
Write a SCSI class driver if you have a totally new type of device. A SCSI class driver uses the SCSI port driver. It calls port driver with Device I/O Control IRPs.A SCSI driver is a standard driver, ie it processes IRPs, creates devices, etc. It maps IRPs to SRBs, limiting the size of transfers for underlying HBAs.
DriverEntry
The DriverEntry routine layers itself over the SCSI port driver and typically has GetInquiryData, ClaimDevice and GetCapabilities routines.The generic port driver is found using a IoGetDeviceObjectPointer call. Note that this is not an HBA device object.
GetInquiryData uses IOCTL_SCSI_GET_INQUIRY_DATA to get a SCSI_ADAPTER_BUS_INFO structure filled by the port driver. ClaimDevices makes the appropriate physical, logical or virtual devices. It makes a port driver IOCTL_SCSI_EXECUTE_NONE call with an SRB_FUNCTION_CLAIM_DEVICE SRB. It should store the returned pointer to the port driver’s HBA specific device. The driver should use this device pointer to issue all subsequent requests to this device via the port driver.
A GetCapabilities routine then issues a IOCTL_SCSI_GET_CAPABILITIES to get a IO_SCSI_CAPABILITIES structure filled. This reveals various details of the HBA, such as the number of bytes that it can transfer in one operation.
Unload
The unload routine must make an SRB_FUNCTION_RELEASE_DEVICE SRB call to release the device.Don’t forget to dereference the generic port driver handle.
Dispatch routines
A class driver’s IRP_MJ_CREATE and IRP_MJ_CLOSE handlers usually just return TRUE.
Don’t forget to handle IRP_MJ_SHUTDOWN and IRP_MJ_FLUSH_BUFFERS if you buffer data internally.
You can pass IRP_MJ_INTERNAL_DEVICE_CONTROL and IOCTL_SCSI_PASS_THROUGH requests through to the port driver as long as you set up the PathId, TargetId and Lun fields in the SRB and set the minor function code to IRP_MN_SCSI_CLASS.
Usually class drivers do not have internal queues as the port driver has queues for each LU.
To process read and write requests, have a BuildSRV routine to set up an IRP with an appropriate SRB containing a CDB. The IRP has a IRP_MJ_SCSI function code (actually the same as IRP_MJ_INTERNAL_DEVICE_CONTROL) and Parameters.Scsi.Srb points to the SRB. Allocate nonpaged memory for the SRB either using ExAllocatePool or use lookaside lists.
For request-sense information requests or where retries might be needed, set an IRP completion routine.
Most class drivers need to have a SplitTransferRequest to ensure that read and write requests do not exceed the underlying HBA capabilities. SplitTransferRequest registers an completion routine for each driver-allocated IRP it sends down to the port driver. The completion routine maintains a count of completed partial transfer requests in the original IRP and protects the count with a spin lock.
The completion routine should translate error codes into NTSTATUS values. It should release the SRB memory if appropriate.
If the port driver freezes an LU’s queue following an error, the completion routine calls a ReleaseQueue routine. It should determine the cause of the error and release the queue. Alternatively, if the device media has changed, ReleaseQueue might also clear the queue of any stacked up requests. Use auto-sense requests or SRBs with a SRB_FLAGS_BYPASS_FROZEN_QUEUE flag if you need to bypass a frozen queue. The release or flush IRP must be allocated with from NonPagedPoolMustSucceed memory - this is one of the few times such memory can be requested.
Drivers I-o Data Scsi & Raid Devices Download
The port driver can handle time-outs requests for the class driver.
SCSI Filter Drivers
Rather than write a whole new SCSI class driver for your slightly weird device, you can write a SCSI Filter Device (SFD) which layers itself over a system SCSI driver.A filter driver does any special handling of existing IRPs or implementing new IRP_MJ_DEVICE_CONTROL requests.
An SFD must support all the requests that its underlying class driver supports. Usually it just passes these straight through to the underlying driver. If appropriate, it can set a completion routine to do any post-processing.
An SFD can use IoGetConfigurationInformation to find how many devices to intercept. Otherwise grovelling around in the registry might be necessary. It then attaches to the underlying device and sees if it is one that it supports. If not, it should detach itself from the device.
SCSI Tape Miniclass Drivers
To support a new tape device or family of tape devices, write a device-specific tape miniclass driver that calls the system-supplied tape class driver. See the DDK for full details.Changer Drivers
Changer drivers control jukebox type devices, ie with interchangeable media.A changer has transporters for moving media from storage slots to data transfer elements. It may also have an import/export element where media can be physically changed, and a door to access all media.
Write a changer miniclass driver to interface with the system changer class driver. It reports the above changer characteristics to the class driver.
See the DDK for full details of the required interface. It ought to support Plug and Play and Power Management requests as well.
User applications need to call the user-mode NT Media Services (NTMS) to change media.
| Document revision date: 30 March 2001 |
OpenVMS I/O User's Reference Manual
| Previous | Contents | Index |
7.4 Error Processing
Shadow set recovery and repair are handled by volume processing, which replaces mount verification for shadow sets. Membership failure decisions are made by the VAX hosts. Device errors that result in inaccessibility of physical member units first utilize the class driver's connection walking algorithm. If that fails, a local decision is made on the shadow set membership. The rules are:
- If some, but not all, members of the set are accessible, then the local node sequentially adjusts the membership and notifies the other hosts.
- If no members are accessible, no modifications to the set membership are made.
There are two types of volume processing: active and passive. Active volume processing handles error processing on a local node. Triggered by a failed I/O operation, active volume processing also controls mount verification functions, member removal, and failover. Passive volume processing is triggered by lock messages or by a cluster event. Passive volume processing revalidates shadow set membership, ensures that the shadow set reflects changes made outside the shadow set, and handles the following functions:
- Member additions from other nodes
- Member removals from other nodes
- A new node mounting the shadow set
- A node dismounting the shadow set
- A system crash on a node that has the shadow set mounted
For more information, refer to the Volume Shadowing for OpenVMS manual.
Chapter 8
Using the OpenVMS Generic SCSI Class Driver
This chapter describes the use of the OpenVMS Generic Small Computer System Interface (SCSI) class driver.
8.1 Overview of SCSI
The American National Standard for information systems---Small Computer System Interface--2 (SCSI--2) specification defines mechanical, electrical, and functional requirements for connecting small computers to a wide variety of intelligent devices, such as rigid disks, flexible disks, magnetic tape devices, printers, optical disks, and scanners. It specifies standard electrical bus signals, timing, and protocol, as well as a standard packet interface for sending commands to devices on the SCSI bus.
Certain OpenVMS systems employ the SCSI bus as an I/O bus. For these systems, Compaq offers SCSI-compliant disk and tape drives, such as the RZ55 300 MB read/write disk, the RRD40 600 MB compact disk, and the TZK50 95 MB streaming tape drive. The operating system also allows devices including disk drives, tape drives, and scanners, supplied by sources other than Compaq, to be connected to the SCSI bus of such a system.
SCSI has been widely adopted by manufacturers for a variety of peripheral devices. However, because the ANSI SCSI standard is broad in scope, not all devices that implement its specifications can fully interrelate on the bus. Compaq fully supports SCSI-compliant equipment sold or supplied by Compaq. Proper operation of products not sold or supplied by Compaq cannot be assured.
For more information, refer to the following documents:
- American National Standard for Information Systems---Small Computer System Interface---2 (SCSI--2) specification (X3T9.2/86--109)
Copies of this document may be purchased from: Global Engineering Documents, 2805 McGaw, Irvine, California 92714, United States; or (800) 854-7179 or (714) 261-1455. Please refer to document X3.131--198X. - American National Standard for Information Systems---Small Computer System Interface specification (X3.131--1986)
Copies of this document may be obtained from: American National Standards Institute, Inc., 1430 Broadway, New York, New York, 10018. This document is now known as the SCSI--1 standard.
Compaq publishes two additional documents to help third-party vendors prepare SCSI peripherals and peripheral software for use with DIGITAL workstations.
- The Small Computer System Interface: An Overview (EK--SCSISOV--001) provides a general description of the DIGITAL SCSI third-party support program.
- The Small Computer System Interface: A Developer's Guide (EK--SCSIS--SP--001) presents the details of implementation of SCSI within DIGITAL operating systems.
8.2 OpenVMS SCSI Class/Port Architecture
The operating system employs a class/port driver architecture to communicate with devices on the SCSI bus. The class/port design allows the responsibilities for communication between the operating system and the device to be cleanly divided between two separate driver modules (see Figure 8-1).
Figure 8-1 OpenVMS SCSI Class/Port Interface
The SCSI port driver transmits and receives SCSI commands and data. It knows the details of transmitting data from the local processor's SCSI port hardware across the SCSI bus. Although it understands SCSI bus phases, protocol, and timing, it has no knowledge of which SCSI commands the device supports, what status messages it returns, or the format of the packets in which this information is delivered. Strictly speaking, the port driver is a communications path. When directed by a SCSI class driver, the port driver forwards commands and data from the class driver onto the SCSI bus to the device. On any given OpenVMS system, a single SCSI port driver handles bus-level communications for all SCSI class drivers that may exist on the system.
The SCSI class driver acts as an interface between the user and the SCSI port, translating an I/O function as specified in a user's $QIO request to a SCSI command targeted to a device on the SCSI bus. Although the class driver knows about SCSI command descriptor buffers, status codes, and data, it has no knowledge of underlying bus protocols or hardware, command transmission, bus phases, timing, or messages. A single class driver can run on any given OpenVMS system, in conjunction with the SCSI port driver that supports that system. The operating system supplies a standard SCSI disk class driver and a standard SCSI tape class driver to support its disk and tape SCSI devices.
8.3 Overview of the OpenVMS Generic SCSI Class Driver
The OpenVMS generic SCSI class driver provides a mechanism by which an application program can control a SCSI device, supplied by a source other than Compaq, that cannot be controlled by the standard OpenVMS disk and tape class drivers. By means of a Queue I/O Request ($QIO) system service call, a program can pass to the generic SCSI class driver a preformatted SCSI command descriptor block. The generic SCSI class driver, in conjunction with the standard OpenVMS SCSI port driver, delivers this SCSI command to the device, manages any transfer of data from the device to a user buffer, and returns SCSI status to the application.
In effect, an application using the generic SCSI class driver implements details of device control usually managed within device driver code. The programmer of such an application must understand which SCSI commands the device supports and which SCSI status values the device returns. The programmer must also be aware of the device's timeout requirements, data transfer capabilities, and command retry behavior.
The application program sets up the characteristics of the connection the generic SCSI class driver uses when delivering commands to, exchanging data with, and receiving status from the device. The program associates each I/O operation the device can perform with a specific SCSI command. When it receives a request for a particular operation, the application program creates the specific command descriptor block that, when passed to the device, causes it to perform that operation.
The application initiates all transactions to the SCSI device by means of a $QIO call to the generic SCSI class driver, supplying the address and length of the SCSI command descriptor block, plus the parameters of any data transfer operation, in the call. When the transaction completes and the application program regains control, it interprets the returned status value, processes any returned data, and services any failure. To avoid conflicts with other applications accessing the same device, an application may need to explicitly allocate the device.
Because the generic SCSI class driver has no knowledge of specific device errors, it neither logs device errors nor implements error recovery. An application using the driver must manage device-specific errors itself. To service an error returned on a single transaction, the application must issue additional $QIO requests and initiate further transactions to the device. If more precise or more efficient error recovery is required for a device, the developer should consider writing a third-party SCSI class driver, as described in the OpenVMS VAX Device Support Manual (available on the Documentation CD-ROM). A third-party SCSI class driver can log errors associated with device activity by using the method described in the OpenVMS VAX Device Support Manual (available on the Documentation CD-ROM).
A third-party class driver is the only means of supporting devices that themselves generate transactions on the SCSI bus, such as notification of a device selection event to the host processor. Refer to the description of asynchronous event notification (AEN) in the OpenVMS VAX Device Support Manual (available on the Documentation CD-ROM).
Figure 8-2 shows the flow of a $QIO request through the generic SCSI class driver and the port driver.
Figure 8-2 Generic SCSI Class Driver Flow
When direct access to a target device on the SCSI bus is required, the generic SCSI class driver is loaded for that device, as described in Section 8.6. An application program using the generic class driver performs the following tasks to issue a command to the target device:
- Calls the Assign I/O Channel ($ASSIGN) system service to assign a channel to the generic SCSI class driver, and to allocate the device for the application's exclusive use.
- Formats a SCSI command descriptor block.
- Formats any data to be transferred to the device.
- Calls the Queue I/O Request ($QIO) system service to request the generic SCSI class driver to send the SCSI command descriptor block to the port driver.
- Upon completion of the I/O request, interprets the SCSI status byte and any data returned from the target device.
These operations are described in following sections.
8.4 Accessing the OpenVMS Generic SCSI Class Driver
Interactive commands and procedure calls can use the OpenVMS generic SCSI class driver to access devices on the SCSI bus. However, it is unlikely that a user application would access a device on the SCSI bus by directly using the $QIO interface of the generic SCSI class driver. First of all, any user process directly using the $QIO interface would require DIAGNOSE and PHY_IO or LOG_IO privileges. Under normal circumstances, it would be a system security risk to grant DIAGNOSE and PHY_IO or LOG_IO privileges to many system users. Secondly, it would be cumbersome for end users of the device to identify, format, and issue SCSI commands to the device. Rather, it would be more efficient to develop an interface that hides these details.
A utility program, installed with the DIAGNOSE and PHY_IO or LOG_IO privileges, can provide nonprivileged users with a command-line interface to a SCSI device. The utility translates interactive commands provided by the user into the appropriate set of SCSI commands and sends them to the device using the $QIO interface provided by the generic SCSI class driver. The utility checks user commands to ensure that only valid SCSI commands are sent to the device. Refer to the OpenVMS System Manager's Manual and the OpenVMS System Management Utilities Reference Manual for information about installing images with privileges.
A privileged shareable image can provide system applications with a procedure interface to a SCSI device. The image contains a set of procedures that translate operations specified by the caller into the appropriate set of SCSI commands. The SCSI commands are sent to the device through the $QIO interface of the generic SCSI class driver. The privileged shareable image checks its caller's parameters to ensure that only valid SCSI commands are sent to the device. Refer to the OpenVMS Programming Concepts Manual for information about creating shareable images.
8.5 SCSI Port Features Under Application Control
The standard OpenVMS SCSI port driver provides mechanisms by which the generic SCSI class driver can control the nature of data transfers and command transmission across the SCSI bus. An application uses the $QIO interface to tailor these mechanisms to the specific device it supports. Among the features under application program control are the following:
- Data transfer mode
- Disconnection and reselection
- Command retry
- Command timeouts
The following sections discuss these features.
8.5.1 Setting the Data Transfer Mode
The SCSI bus defines two data transfer modes, asynchronous and synchronous. In asynchronous mode, for each REQ from a target there is an ACK from the host prior to the next REQ from the target. Synchronous mode allows higher data transfer rates by allowing a pipelined data transfer mechanism where, for short bursts (defined by the REQ-ACK offset), the target can pipeline data to an initiator without waiting for the initiator to respond.
Whether or not a port or a target device allows synchronous data transfers, it is harmless for the program to set up the connection to use such transfers. If synchronous mode is not supported, the port driver automatically uses asynchronous mode.
For example, to use synchronous mode in a transfer, a programmer using the generic SCSI class driver must ensure that both the SCSI port and the SCSI device involved in the transfer support synchronous mode. The SCSI port of the VAXstation 3520/3540 system allows both synchronous and asynchronous transfers, whereas that of OpenVMS 3100 systems supports only asynchronous transfers.
Drivers I-o Data Scsi & Raid Devices Usb
To set up a connection to use synchronous data transfer mode, a program using the generic SCSI class driver sets the syn bit in the flags field of the generic SCSI descriptor, the address of which is passed to the driver in the p1 argument to the $QIO request.
8.5.2 Enabling Disconnection and Reselection
The ANSI SCSI specification defines a disconnection facility that allows a target device to yield ownership of the SCSI bus while seeking or performing other time-consuming operations. When a target disconnects from the SCSI bus, it sends a sequence of messages to the initiator that cause it to save the state of the I/O transfer in progress. Once this is done, the target releases the SCSI bus. When the target is ready to complete the operation, it reselects the initiator and sends to it another sequence of messages. This sequence uniquely identifies the target and allows the initiator to restore the context of the suspended I/O operation.
Whether disconnection should be enabled or disabled on a given connection depends on the nature and capabilities of the device involved in the transfer, as well as on the configuration of the system. In configurations where there is a slow device present on the SCSI bus, enabling disconnection on connections that transfer data to the device can increase bus throughput. By contrast, systems where most of the I/O activity is directed towards a single device for long intervals can benefit from disabling disconnection. By disabling disconnection when there is no contention on the SCSI bus, port drivers can increase throughput and decrease the processor overhead for each I/O request.
By default, the OpenVMS class/port interface disables the disconnect facility on a connection. To enable disconnection, an application program using the generic SCSI class driver sets the dis bit of the flags field of the generic SCSI descriptor, the address of which is passed to the driver in the p1 argument to the $QIO call.
8.5.3 Disabling Command Retry
The SCSI port driver implements a command retry mechanism, which is enabled on a given connection by default.
When the command retry mechanism is enabled, the port driver retries up to three times any I/O operation that fails during the COMMAND, Message, Data, or STATUS phases. For instance, if the port driver detects a parity error during the Data phase, it aborts the I/O operation, logs an error, and retries the I/O operation. It repeats this sequence twice more, if necessary. If the I/O operation completes successfully during a retry attempt, the port driver returns success status to the class driver. However, if all retry attempts fail, the port driver returns failure status to the class driver.
An application may need to disable the command retry mechanism under certain circumstances. For example, repeated execution of a command on a sequential device may produce different results than are intended by a single command request. A tape drive could perform a partial write and then repeat the write without resetting the tape position.
An application program using the generic SCSI class driver can disable the command retry mechanism by setting the dpr bit of the flags field of the generic SCSI descriptor, the address of which is passed to the driver in the p1 argument to the $QIO request.
8.5.4 Setting Command Timeouts
The SCSI port driver implements several timeout mechanisms, some governed by the ANSI SCSI specification and others required by OpenVMS. The timeouts required by OpenVMS include the following:| Timeout | Description |
|---|---|
| Phase change timeout | Maximum number of seconds for a target to change the SCSI bus phase or complete a data transfer. (This value is also known as the DMA timeout.) Upon sending the last command byte, the port driver waits this many seconds for the target to change the bus phase lines and assert REQ (indicating a new phase). Or, if the target enters the DATA IN or DATA OUT phase, the transfer must be completed within this interval. |
| Disconnect timeout | Maximum number of seconds, from the time the initiator receives the DISCONNECT message, for a target to reselect the initiator so that it can proceed with the disconnected I/O transfer. |
An application program using the generic SCSI class driver is responsible for maintaining both of these timeout values. It has the following options:
- Accepting a connection's default value. The default value for both timeouts is 20 seconds.
- Altering the connection's default value. To modify the default values, the class driver specifies nonzero values for the phase change timeout and disconnect timeout fields of the generic SCSI descriptor, the address of which is passed to the driver in the p1 argument to the $QIO system service call.
8.6 Configuring a Device Using the Generic Class Driver
On VAX systems, the System Generation utility (SYSGEN) loads the generic SCSI class driver into system virtual memory, creates additional data structures for the device unit, and calls the driver's controller initialization routine and unit initialization routine. SYSGEN automatically loads and autoconfigures the SCSI port driver at system initialization. As part of autoconfiguration, SYSGEN polls each device on each SCSI bus. If the device identifies itself as a direct-access device, direct-access CD-ROM device, or flexible disk device, SYSGEN automatically loads the disk class driver (DKDRIVER). If the device identifies itself as a sequential-access device, SYSGEN automatically loads the tape class driver (MKDRIVER). If the autoconfiguration facility does not recognize the type of the SCSI device, it does not load a driver.
If a third-party-supplied SCSI device requires that the generic class driver be loaded, it must be configured by an explicit SYSGEN CONNECT command, as follows:
On Alpha systems, SYSMAN performs the same functions that SYSGEN performs on VAX systems. If a third-party-supplied SCSI device requires that the generic class driver be loaded, the device must be configured by an explicit SYSMAN CONNECT command, as follows:
On VAX and Alpha systems, GK is the device mnemonic for the generic SCSI class driver (GKDRIVER); p represents the SCSI port ID (for instance, the controller ID A or B); d represents the SCSI device ID (a digit from 0 to 7); 0 signifies the digit zero; and u represents the SCSI logical unit number (a digit from 0 to 7).
Drivers I-o Data Scsi & Raid Devices List
Multiple devices residing on any SCSI bus in the system can share GKDRIVER as a class driver, as long as a CONNECT command is issued for each target device that requires the driver.
Drivers I-o Data Scsi & Raid Devices For Sale
Because just one connection can exist through the SCSI port driver to each target, the generic class driver cannot be used for a target if a different SCSI class driver is already connected to that target. For example, if the SCSI disk class driver has a connection to device ID 2 on the SCSI bus identified by SCSI port ID B (DKB200), the generic class driver cannot be used to communicate with this disk. An attempt to connect GKDRIVER for this target results in GKB200 being placed off line.
8.6.1 Disabling the Autoconfiguration of a SCSI Device (VAX Only)
On VAX systems, in special cases you may need to prevent the autoconfiguration facility from loading the disk or tape class driver for a device with a specific port ID and device ID. This would be the case if a SCSI device, supplied by a source other than Compaq, should identify itself as either a random-access or sequential-access device and were to be controlled by the generic SCSI class driver.
To disable the loading of a disk or tape driver for any given device ID, OpenVMS defines the special system parameter SCSI_NOAUTO.
The SCSI_NOAUTO system parameter, as shown in Figure 8-3, stores a bit mask of 32 bits in which the low-order byte corresponds to the first SCSI bus (PKA0), the second byte corresponds to the second SCSI bus (PKB0), and so on. For each SCSI bus, setting the low-order bit inhibits automatic configuration of the device with SCSI device ID 0; setting the second low-order bit inhibits automatic configuration of the device with SCSI device ID 1, and so forth. For instance, the value 0000200016 would prevent the device with SCSI ID 5 on the bus identified by SCSI port ID B from being configured. By default, all of the bits in the mask are cleared, allowing all devices to be configured.
Figure 8-3 SCSI_NOAUTO System Parameter
| Previous | Next | Contents | Index |
| privacy and legal statement | ||
| 6136PRO_027.HTML | ||