- Supported operating systems
- Red Hat Enterprise Linux 5, 6
- CentOS 5, 6
- SUSE Linux Enterprise Server 11, 11sp1, 11sp2
- Fedora 17, 18
- openSUSE Linux 11, 12
- Supported architectures
- i386 (with or without "CONFIG_REGPARM")
- x86_64 (AMD64, Intel EM64T)
- Supported adapters
- ATTO ExpressSAS H680
- ATTO ExpressSAS H608
- ATTO ExpressSAS H60F
- ATTO ExpressSAS H6F0
- ATTO ExpressSAS H644
- Installation instructions
NOTE: The kernel header files, make
, and gcc
must be installed. For details on how to do this, click here.
- Unzip and untar the driver files with
tar xfz lnx_drv_esas2hba_XXX.tgz
- Enter the
lnx_drv_esas2hba_XXX
directory and run the install script install.sh
.
- After the driver is installed, it can be loaded automatically if desired.
NOTE:
In Linux kernel 2.6.33 and higher, there is built-in support
for the PMC 8001 chip in a driver named pm8001.ko
.
If present, this driver will load automatically for the ExpressSAS 6Gb HBA
and prevent the esas2hba driver from loading. The driver installation script
will detect the presence of the pm8001 and provide the option to unload that
driver and rename it to prevent this conflict.
Alternatively, the pm8001 driver can be unloaded using
rmmod pm8001
.
To permanently remove the pm8001 driver, you can delete the pm8001 kernel
module. To find the built in driver, use the command
modinfo pm8001
and look for the "filename" field, then remove
that file from the filesystem.
Also, see Recommendations for Fedora to
reconfigure the initrd image.
- Loading the driver
Type the following to manually load the module:
$ modprobe esas2hba
You may receive a warning that the module will taint the kernel.
On SUSE 11, you may also receive an error message about "unsupported" drivers:
$ modprobe esas2hba
FATAL: module '/lib/modules/2.6.27.19-5-default/kernel/drivers/scsi/esas2hba.ko' is unsupported
Use --allow-unsupported or set allow_unsupported_modules to 1 in
/etc/modprobe.d/unsupported-modules
You can fix this problem by loading the driver with modprobe --allow-unsupported esas2hba
or editing the file /etc/modprobe.d/unsupported-modules
as described.
- Advanced - Building the drivers manually
Unzip and untar the driver files:
$ tar xfz lnx_drv_esas2hba_XXX.tgz
NOTE: Make sure there are no spaces in the path in which you extract the archive. The Linux kernel Makefile may fail if the path name contains a space character.
Make and install the modules (must be done as root):
$ cd lnx_drv_esas2hba_XXX.tgz/src
$ make install
NOTE: You need the kernel header files installed to build this driver. If the header files are in a non-standard location, you may need to modify the KDIR variable on the make
command line, eg. make install KDIR=/path/to/kernel
The modules will now be installed and ready to use.
- Advanced - Configuring the driver to load at boot time
On some Linux distributions, the driver may not load automatically when the system is booted. To enable this behavior, try the following suggestions:
Recommended for Red Hat 4 & 5:
Add the following line to /etc/modprobe.conf after installing the driver:
alias scsi_hostadapterX esas2hba
Where X is the next available number.
Recommended for SUSE 10:
Add the following line to /etc/init.d/boot.local:
modprobe esas2hba
Recommended for Fedora:
Fedora distributions may include the
built-in pm8001 driver as part of the
default initrd image. After running the driver install script, or
manually removing the pm8001 driver, you may also need to update the
initrd image using the following command. Consult the Fedora documentation
for complete details of this command.
mkinitrd -f <initrd-image> <kernel-version>
(ex. mkinitrd -f /boot/initramfs-3.6.10-4.fc18.i686.PAE.img 3.6.10-4.fc18.i686.PAE
)
The initrd-image is typically found in the /boot
directory and is named initramfs-<kernel-version>.img
. The kernel-version can be found by running uname -r
.
WARNING:
An incorrect or invalid initrd image can render a system unbootable. Care should be taken when modifying this file.
- Advanced - Optional Module Parameters
The following module parameter is supported by this driver:
- event_log_mask (default 0) Logs error and informative messages to the kernel ring buffer. This value is a bit-mask of message catergories; set to 0xFFFFFFFF to log all possible messages. This feature is mostly for debugging purposes and is not recommended for normal use.
There are also several other parameters available for tweaking. For documentation on these settings, read the file oswrap.c (look for "Module parameter definitions") or the output of the command modinfo esas2hba.ko
.
- Troubleshooting 64-bit driver installation
On certain 64-bit platforms, the driver Makefile may be unable to detect the correct CPU architecture. In this instance, you will see an error similar to the following when attempting to compile the driver:
cc1 : error : CPU you selected does not support x86_64 instruction set
This can be resolved by specifying the correct architecture when running the make command, such as:
$ make install ARCH=x86_64
- Installing kernel source and other necessary packages
This driver requires that the kernel header files, make
, and gcc
be installed on the system.
For SUSE, use the YAST utility's "Software Management" module to install the "kernel-source", "gcc", and "make" packages.
For Red Hat, use the "Add/Remove Applications" utility to install the "Development Tools" packages. For details on installing the kernel source package:
- For Red Hat 4, click here
- For Red Hat 5, click here
Refer to your system documentation for further details.
- Driver Events
The reporting of driver events to the system log is controlled by the event_log_mask
module parameter. event_log_mask is the sum of the event type values for the events
you would like to see.
Event Type |
Value (hexadecimal) |
Description |
Fatal | 0x00000001 | Fatal errors, always reported |
SCSI | 0x00000004 | SCSI command errors |
Protocol | 0x00000008 | SAS protocol errors |
Login | 0x00000010 | Device login/logout events |
Resource | 0x00000040 | Resource usage failures |
Info | 0x00000080 | Informational messages |
In general, only errors that are output for event type 'Fatal' are significant;
all others are mostly for informational or diagnostic purposes.
When turning on event logging, be aware that certain events reported as
errors are expected. For example, a SCSI Check Condition
error will be reported for the first command sent to a device after power on
or a reset condition. Also, certain data underrun errors are expected by the
software and are normal.
All events report the adapter number on which the event occurred. The
adapter number is simply the order in which Linux initialized the adapter
channels and has no relevance to what slot the adapter is in or which channel
of the adapter is being reported.
The following events are classified as 'Fatal' and are always reported.
Event Message |
Description |
More than 3 attempts to recover from PCI errors in the
last minute.
Channel is now inoperative. |
After 3 attempts to recover from PCI errors within a one-
minute period, the driver gives up and renders the adapter
channel inoperative to avoid affecting the operation of
the rest of the system. This error typically indicates
that either the adapter or the slot into which it is
plugged has a serious problem. |
Heartbeat failed. |
The adapter failed to respond with a heartbeat within
the expected time. The driver will attempt to reset
the adapter. This could indicate a hardware failure. |
Configuration parameters not found or corrupt.
Please reflash card. |
This event indicates that the driver could not read the
configuration parameters for the indicated adapter.
Default configuration values will be used. The adapter
needs to have its flash memory rewritten. |
Firmware completed a reset sequence. |
The driver recovered the adapter from a hardware or firmware fault. |
Unknown Event Code.
Code is {Code}.
Least Significant Word is {Info}. |
This event indicates that an unknown event code was
generated by the driver code that the decoder does not
know about. This event should never occur in a released
driver. |
Event Buffer Overflow.
Number of Events Lost is {Count}. |
This event indicates that events occurred faster than the
OS could get them dumped to the event log on disk. This
doesn't happen very often. |
The following events are classified as 'SCSI'.
Event Message |
Description |
SCSI Error.
Error Code {Code}, Sense Key {Key},
Add'l Sense Code {ASC}, Command Code {Cmd},
Path ID {Path}, Target ID {TargetID}, LUN {Lun}. |
An error has been reported by the target device. The
Error Code is usually 0x02 (Check Condition), in which
case the Sense Key and Additional Sense Code displayed
are valid. It is normal for the first command sent to
a SCSI device after power on or reset to report a SCSI
error, in which case the Sense Key would be 0x06 (Unit
Attention) and the Additional Sense Code would be 0x29
(Power-On/Reset). |
SCSI Bus Reset Requested. |
The OS is requesting that a bus reset be performed. This
may happen in cases where a request times out and the
Abort that the driver attempts is not successful. Any
requests outstanding at the time will be completed with
a status of Aborted due to Bus Reset. |
The following events are classified as 'Protocol'.
Event Message |
Description |
IOC Error (Initiator).
IOC Status is {n} {Desc}.
Command Code {Cmd}, Path ID {Path}, Target ID {Targ}, LUN {Lun}
LBA {Logical Block Address}. |
A transport or other error has been detected on an
Initiator mode request. Note that the Logical Block
Address is only valid if the command is a read (0x28)
or write (0x2A). |
The following events are classified as 'Login'.
Event Message |
Description |
Device {SAS Addr} attached to port {#} at {Speed}. |
The indicated SAS device has been attached. |
Device {SAS Addr} removed from port {#}. |
The indicated SAS device has been removed. |
The following events are classified as 'Resource'.
Event Message |
Description |
Resource Failure.
{ResourceType}.
Unavailable Count is {count}. |
The driver encountered a situation where not enough of
the indicated resource is available. The ResourceType
will be one of the following. (The module parameter
controlling the number of each resource is indicated in
parentheses.)
I/O Requests (num_ioreq)
S/G Lists (num_sg_lists, sgl_page_size)
When running out of S/G Lists, nothing bad will happen;
the driver will retry the operation when the resources
become available. |
The following events are classified as 'Info'.
Event Message |
Description |
Bus Reset Request Completed.
Status: {n} ({Desc}). |
This event indicates that a requested Bus Reset has
completed. If there was no error during the reset
procedure, this event will only be reported if the
EVENT_TYPE_INFO bit is set in EventLogMask, otherwise
it will be reported regardless of the EventLogMask. |
- Contact information
You may receive customer service, sales information, and technical support by phone
Monday through Friday, Eastern Standard Time 8:00 am to 6:00 pm, or by fax and
web site 24 hours a day.
ATTO Technology, Inc.
155 CrossPoint Parkway
Amherst, New York 14068
Phone: (716) 691-1999
Fax: (716) 691-9353
www.attotech.com
ATTO Technology can also be reached via e-mail at the following addresses:
Sales Support: sls@attotech.com
Technical Support: techsupp@attotech.com