Linux RHEL 2.1 and 3.0 MegaRAID2 32-bit driver Version 2.10.10.1 Contents 1.0 Supported RAID Controllers 1.1 Compatible Firmware Versions 2.0 Install Instructions 2.1 Downloading and Creating the Driver Disk 2.2 Installing the Driver for the PERC 2.2.1 Updating the Driver Using RPM After OS is Installed 2.2.2 Creating a Megaraid2 Driver Update Disk (DUD) Using DKMS 2.2.3 Installing the Driver Using a Driver Update Disk During OS Installation 2.2.4 Using DKMS to Create and Install a Megaraid2 Driver RPM Package 2.2.5 Updating the Driver Using DKMS After OS is Installed or Updated 2.2.6 Uninstalling the Driver 3.0 Fixes and Enhancements 4.0 Important Information 5.0 Additional Information 6.0 Release History ============================== 1.0 Supported RAID Controllers ============================== This driver supports the following controllers: PERC 4e/Di, 4e/Si, 4e/DC PERC 4/Di, 4/DC, 4/SC PERC 3/QC, 3/DC, 3/DCL, 3/SC 1.1 Compatible Firmware Versions ================================ This device driver is compatible with the following firmware versions: Controller Minimum Recommended Description Firmware Level PERC 3/QC 198Q PERC 3 Quad Channel PERC 3/DC 198Q PERC 3 Dual Channel PERC 3/DCL 198Q PERC 3 Dual Channel Lite PERC 3/SC 198Q PERC 3 Single Channel PERC 4/Di 421Q PERC 4 Integrated on PE 1750 PERC 4/Di 251Q PERC 4 Integrated on PE 2600 PERC 4/SC 351Q PERC 4 Single Channel PERC 4/DC 351Q PERC 4 Dual Channel PERC 4e/Di 521Q PERC 4e Integrated on PE 2800, 2850, 6800, 6850 PERC 4e/Si 521Q PERC 4e Integrated on PE 1850 PERC 4e/DC 521Q PERC 4e Dual Channel ======================== 2.0 Install Instructions ======================== Installation Options -------------------- 1. Install the OS with the assistance of the DSA CD: The Dell Server Assistant CD helps simplify Linux OS installation and ensures a supported Dell storage driver is loaded when installing Red Hat Enterprise Linux. 2. Upgrade the driver after the OS is installed: In many cases, it is possible to install the OS using the PERC driver that shipped with Red Hat Enterprise Linux. Once installation is complete, the driver should be upgraded to the latest PERC driver available on http://support.dell.com. See Section 2.2.1 to upgrade the driver after the OS is installed. 3. Install the driver during OS installation: Not every Red Hat Enterprise Linux kernel ships with drivers that support all Dell PERC controllers. When installing one of these kernels, a Driver Update Disk should be created using the procedure described in Section 2.2.2. This Driver Update Disk is used to load the PERC driver during OS installation as outlined in Section 2.2.3. NOTE: The contents of this driver package may be used as a DUD for kernel versions listed in Section 2.1. For more detailed installation instructions of Red Hat, please refer to the OS installation guide at http://www.dell.com/linux. 2.1 Downloading and Creating the Driver Disk ============================================ The diskette created in this section contains compiled binary drivers and can be used as a Driver Update Disk (DUD) for the following kernels. RHEL 3.0 - 2.4.21-4.EL (uP, smp) RHEL 2.1 U3 - 2.4.9-e.34 (uP, smp and enterprise) NOTE: The kernel versions mentioned above are Dell supported kernels. For all other kernels, the driver can be automatically compiled and installed using the procedure outlined in Section 2.2.1. This operation is done only for the currently running kernel and requires the kernel-source and gcc packages to be installed on the system. 1. On a Linux system: The user will need a formatted 3 1/2 inch floppy diskette for the following procedure. - Download the file perc-2.10.10.1-A11.tar.gz to a temporary directory on your working system. - Extract the file to the floppy disk: Type the following commands from a Linux command shell: mount /dev/fd0 /mnt/floppy tar xvzf (full path to the archive) -C /mnt/floppy (Eg: /tmp/perc-2.10.10.1-A11.tar.gz) umount /mnt/floppy NOTE: The floppy drive in the system may not be enumerated as fd0. For example, a USB floppy drive may have a device name such as /dev/sda. Determine the device name for the floppy drive and substitute fd0 with the proper device name in the command above. NOTE: Winzip does not extract the driver files correctly under Microsoft Windows. 2. On a Windows system: The user will need a formatted 3 1/2 inch floppy diskette for the following procedure. - Download the perc-2.10.10.1-A11.exe file to a temporary directory on your Windows system. 1) Double click on the file to run the executable. 2) Click on the Continue button. This diskette contains the same files as the .tar.gz file above. 2.2 Installing the Driver for the PERC ====================================== 2.2.1 Updating the Driver Using RPM After OS is Installed ========================================================= This procedure installs the megaraid2 and DKMS RPM packages contained in this Dell driver release. If the system is not running one of the supported kernels listed in Section 2.1, kernel source must be installed in order for the driver module to be installed for the running kernel. 1. Create the driver diskette by following the steps in Section 2.1. 2. Type the following commands from a Linux command shell: mount /dev/fd0 /mnt/floppy cd /mnt/floppy source install.sh NOTE: The floppy drive in the system may not be enumerated as fd0. For example, a USB floppy drive may have a device name of /dev/sda. Determine the device name for the floppy drive and substitute fd0 with the proper device name in the command above. 3. Reboot the system for the changes to take effect. NOTE: The megaraid2 module is only installed for the kernel currently running. 2.2.2 Creating a Megaraid2 Driver Update Disk (DUD) Using DKMS ============================================================== Many Red Hat Enterprise Linux kernels support the PERC controllers listed in Section 1.0 of this document. Dell recommends installing the Operating System using the driver that ships with Red Hat Enterprise Linux and then upgrading to the latest Dell driver version after installation is complete. Section 2.2.1 shows how to upgrade the megaraid2 driver after OS installation. If the user wants to install the Dell driver during OS installation, a Driver Update Disk (DUD) must be used. The diskette created in Section 2.1 can be used as a Driver Updated Disk when installing one of the kernel versions listed in that section. To build a Driver Update Disk for other kernels, the following prerequisite packages must be installed: - The megaraid2 and DKMS RPM included in this package (see Section 2.2.1) - Kernel source for the kernel in question - Kernel building tools such as gcc Perform the following procedure to create a Driver Update Disk using DKMS: 1. To create a DUD image for one or multiple kernel versions, first build the driver module for these kernels using the following commands: # dkms build -m megaraid2 -v -k Where is the version of the megaraid2 driver. E.g. v2.10.10.1 Where is the kernel version. E.g. 2.4.21-4.ELBOOT Repeat the DKMS build command for each kernel version to be included on the DUD. NOTE: The user may see informational messages during the build process if a pre-existing module was already built for a particular kernel. 2. Once the driver modules are ready, type the following command in any directory: # dkms mkdriverdisk -d redhat -m megaraid2 -v -k -k Where is the version of the megaraid2 driver. E.g. v2.10.10.1 Where is the kernel version. E.g. 2.4.21-4.ELBOOT This starts the process to create a megaraid2 DUD (Driver Update Disk) image. After the operation is complete, the DUD image is found in the DKMS tree for megaraid2 driver. NOTE: For RHEL2.1 and RHEL3 x86 kernels, a driver compiled against the BOOT kernel needs to be included on the Driver Update Diskette to be used during OS installation. 3. Transfer the contents of the DUD image file to a floppy disk. # dd if=DUD_image_filename of=/dev/fd0 NOTE: The floppy drive in the system may not be enumerated as fd0. For example, a USB floppy drive may have a device name of /dev/sda. Determine the device name for the floppy drive and substitute fd0 with the proper device name in the command above. 2.2.3 Installing the Driver Using a Driver Update Disk During OS Installation ============================================================================= Instructions for Red Hat Enterprise Linux 2.1 --------------------------------------------- 1. Boot normally from the Red Hat installation CD-Rom. 2. Type 'expert noprobe dd' on the boot prompt. 3. At the "Do you have a driver disk" screen, select 'Yes'. 4. At the "Insert your driver disk" screen, insert the driver disk created above and select 'OK' to continue. 5. Select the appropriate choices on the next three prompts. 6. At the "I don't have any special device..." select 'Add Device'. 7. At the "What kind of devices would you like to add", select 'SCSI'. 8. Scroll down and select the "MegaRAID2" driver, and select 'OK'. 9. Select any additional devices in your system manually by selecting 'Add Device' or select 'Done' to proceed. 10. Complete the installation as directed by the install. Instructions for Red Hat Linux 3.0 ---------------------------------- 1. Boot normally from the Red Hat installation CD-Rom. 2. Type 'expert noprobe dd' on the boot prompt. 3. At the "Do you have a driver disk" screen, select Yes. 4. At the "Driver Disk Source" screen, select fd0 (for floppy) 5. At the "Insert Driver Disk" screen, insert the driver disk created above and select OK to continue. 6. At the "Error - No devices of the appropriate type were found..." screen, select "Manually choose". 7. Scroll down and select the "MegaRAID2" driver. 8. Select any additional devices in your system manually. 9. Complete the installation as directed by the install. 2.2.4 Using DKMS to Create and Install a Megaraid2 Driver RPM Package ===================================================================== DKMS can be used to generate a new megaraid2 driver RPM package containing driver binary modules for multiple kernel versions. Once created, the RPM package can be used to upgrade PERC drivers on systems where kernel source is not available. To create the megaraid2 driver RPM package, the following prerequisite packages must be installed: - The megaraid2 RPM included in this package (see Section 2.2.1) - Kernel source for the kernels in question - Kernel building tools such as gcc 1. Add module source into DKMS tree. # dkms add -m megaraid2 -v Where is the version of the megaraid2 driver. E.g. v2.10.10.1 2. Build driver module for all kernel versions to be packaged. # dkms build -m megaraid2 -v -k Where is the version of the megaraid2 driver. E.g. v2.10.10.1 Where is the kernel version. E.g. 2.4.21-4.EL Repeat the DKMS build command for each kernel version to be packaged. Note: If kernel version is not specified on the command line, the driver module will only be built for the current running kernel. NOTE: The user may see informational messages during the build process if a pre- existing module was already built for a particular kernel. 3. Create driver RPM package for all kernel versions to be packaged. # dkms mkrpm -m megaraid2 -v -k -k -k Where is the version of the megaraid2 driver. E.g. v2.10.10.1 Where is the kernel version. E.g. 2.4.21-4.EL 4. Install the RPM package on the designated system: # rpm -Uvh Note: During RPM installation, any kernel on the system that has a matching precompiled module in the RPM will have the driver module installed into the module tree for that kernel. If the RPM does not have a precompiled module for the kernel that is running during RPM installation, the RPM will kick off a module build and install it for that kernel. For non-running kernels that do not have matching precompiled modules in the RPM, the user must perform a DKMS build and install manually. 2.2.5 Updating the Driver Using DKMS After OS is Installed or Updated ===================================================================== NOTE: The DKMS package is necessary to install the driver in the following scenarios: 1. When multiple kernel versions co-exist on the same system and the user wants to install the driver for the non-running kernel versions (assuming the driver RPM package does not contain such driver modules). 2. If the kernel is updated after installing the megaraid2 driver and the user wants to install the megaraid2 driver for the updated kernel. To build the megaraid2 driver for any kernel, the following prerequisite packages must be installed: - The megaraid2 RPM included in this package (see Section 2.2.1) - Kernel source for the kernel in question - Kernel building tools such as gcc 1. Add module source into the DKMS tree. # dkms add -m megaraid2 -v Where is the version of the megaraid2 driver. E.g. v2.10.10.1 2. Build driver module for the kernel to be installed. # dkms build -m megaraid2 -v Where is the version of the megaraid2 driver. E.g. v2.10.10.1 Where is the kernel version. E.g. 2.4.21-4.EL Repeat the DKMS build command for each kernel version to be packaged. NOTE: If a kernel version is not specified on command line, the module will only be built for the current running kernel. 3. Install the driver module. # dkms install -m megaraid2 -v -k Where is the version of the megaraid2 driver. E.g. v2.10.10.1 Where is the kernel version. E.g. 2.4.21-4.EL Note: If kernel version is not specified on command line, the module will only be installed for the current running kernel. 4. Check DKMS status. # dkms status Should show the module is installed in the specific kernel version. 5. Reboot into that kernel for the changes to load the driver module. Refer to the DKMS man page for more information. # man dkms 2.2.6 Uninstalling the Driver ============================= If this driver has been installed using the RPM as described in Section 2.2.1, it can be uninstalled with the following command: # rpm -e megaraid2 If this driver has been installed using DKMS as described in Section 2.2.5, it can be uninstalled with the following command: # dkms uninstall -m megaraid2 -v -k This will uninstall the megaraid2 driver from the specific kernel version. If no kernel version is specified, the current running kernel is assumed. Reboot the system after the completion of the commands for the changes to take effect. ========================== 3.0 Fixes and Enhancements ========================== 1. An issue was corrected to resolve random deletion errors. 2. Fixed tape drive issue: for any Direct CDB command to a physical device, including tape, timeout value set by the driver was 10 minutes. With this value, most commands will return within the timeout. However, for those commands like ERASE or FORMAT, it takes more than an hour depending on capacity of the device and the command could be terminated before it completes. To address this issue, the 'timeout' field in the DCDB command will have NO TIMEOUT value as its timeout on DCDB command. 3. Prevent kernel panic for Test Unit Ready (TUR) commands when installing from SCSI CDROMs. 4. Modify timeout value to prevent kernel watchdog timer expiration. =================== 4.0 Important Notes =================== - This driver update package only contains support for x86 based processors. - A warning message is encountered when a logical disk is configured without a partition. After Linux OS installation or any action that causes system devices to be scanned, the user will see the following warning message right after the login screen: "megaraid: invalid partition on this disk on channel 0" This message will disappear once a partition is created on all logical drives or if the logical drive without a partition is deleted. - A warning message is seen if errata kernel RPMs are installed after installing the megaraid2 driver. The following message is printed: "No module megaraid2 found for kernel x.y.z-p" This message is seen because the /etc/modules.conf file specifies that the megaraid2 driver is to be added to the initial RAM disk (initrd), but the driver is not yet built and installed for the kernel by DKMS. To boot from this kernel, the megaraid2 driver should be built and installed for the kernel as described in Section 2.2.5 and then adding the line: initrd /initrd-x.y.z-p.img to /etc/grub.conf in the stanza for the kernel version installed. - After performing a fresh Linux installation using the driver update, the /etc/modules.conf file may contain unused entries specific to the native 'megaraid' driver that has been replaced by this 'megaraid2' driver update package. 'alias scsi_hostadapter1 megaraid' These entries are created during the operating system installation and may generate error messages during the OS boot process by attempting to load the 'megaraid' driver after 'megaraid2' has already been loaded. To avoid these messages, it is recommended to delete the unused 'megaraid' entries from the etc/modules.conf. - During the fresh Linux installation, the operating system cannot determine drive/device order information based on system BIOS settings. This may lead to undesired drive/device orderings during the install. It is recommended to perform the install with only the target hard drives and storage controller present that the user intends to install to, then later add the additional storage controllers and hard drives to the system once the installation is complete. For an existing RHEL 2.1 installation, the addition of another storage controller may change the boot device ordering and impact the operating systems ability to find the root file system partition. To ensure that the operating system can still properly find the partition, it is recommended that before adding the additional controller to edit the /etc/grub.conf and /etc/fstab to use file system labels instead of the hard-coded device names. (Ex. root=LABEL=/ instead of root=/dev/sda2) This change is not necessary in RHEL 3.0 or later since those installers already utilize file system labels during installation. - After performing a fresh Linux installation using the Driver Update Disk, it is important to update the driver using the RPM after the first boot (See Section 2.2.1 of the Release Notes). During a fresh Linux installation, the Linux operating system places drivers from the update disks in a separate location than the usual location drivers are stored. This may generate error messages during the OS boot process by attempting to load the driver a second time after the driver has already been loaded. It may also prevent the mkinitrd command from completing, indicated by the message "megaraid2.o: binary operator expected." Updating the driver with the RPM stores the driver file in the proper location. - While upgrading driver on RHEL AS 2.1 Update-3, the install script reports the following message: /usr/sbin/dkms: $temp_dir_name: ambiguous redirect . . DKMS: add completed. Loading/Installing pre-built modules for 2.4.9-e.34. Warning! /var/lib/dkms/megaraid2/v2.10.10.1/source already exists. Skipping... The driver is installed correctly. This is an informational message. - If problems are encountered when compiling the driver for non-Red Hat kernels, remove the line listed below from the megaraid2.h file and re-attempt the compile. At the time of the driver release, this syntax was not supported in some non-Red Hat kernels. .vary_io = 1 - A Driver Update Diskette created by the user with DKMS will refer to the Megaraid2 driver as version 2.10.10.0 during the text-mode portion of Linux installation. The actual version, 2.10.10.1, is installed and messaged correctly once OS installation is complete. The incorrect version is only seen when selecting a driver during text-mode installation. ========================== 5.0 Additional Information ========================== dkms-2.0.5-1.noarch.rpm - Dynamic Kernel Module Support utility (DKMS) install.sh - Installation script. license.txt, GPL - License information megaraid2-v2.10.10.1-1dkms.i686.rpm - Megaraid2 binary and source RPM with DKMS support. perc-2.10.10.1-A11.txt - This document README.dkms - Documentation for DKMS =================== 6.0 Release History =================== ### Version 2.10.7 1. Improved driver error handling and memory utilization. 2. Improved driver algorithm when logical drives are deleted out of sequence. ### Version 2.10.6 1. Fixed a minor bug in random deletion of logical drives. 2. Allocate memory at load time for IOCTL commands. ### Version 2.10.3 1. Prevent memory leak while accessing the /proc interface to get information for physical devices on controllers with less than 4 channels. ### Version 2.10.2, 2.10.2.1 1. Ioctl support for x86_64 2. Check for possible failure of register_chrev() for private ioctl interface. 3. Added subsystem vendor id for FSC 4. PCI DMA sync *after* tearing down PCI mapping in mega_free_scb (command completion). 5. Typecast scsi buffer to "struct scatterlist *" for pci_dma_sync_sg, since the buffer is caddr_t 6. Check for controller type before disabling interrupt for IO based controller. 7. 64-bit typecasts for private ioctl interface. 8. Remove bios_param interface. Now we let kernel decide on the geometry. ### Version 2.10.1 1. Fixed a bug where PCI-Express based controllers would not be able to use more than 4GB main memory with 2.10.0 driver. 2. Remove redundant PCI-handle allocation. ### Version 2.10.0 1. Added vendor ids and device ids for PCI-Express controllers, PERC4e/Si, PERC4e/Di, PERC4e/DC 2. Backport some minor changes from 2.6 kernel version of the driver. ### Version 2.00.9a 1. Minor changes which are brought in when syncing with kernel 2.9-test6. 2. Use sizeof(mbox_t) in synchronous routines instead of hard-coded value of 16 bytes. 3. Decouple adapter->host->pci_dev. Replace with adapter->pdev ### Version 2.00.9 1. For extended passthru commands, 64-bit scatter-gather list and 64-bit mailbox address must only be used if the controller supports extended CDBs and 64-bit addressing and the kernel is configured to support memory beyond 4GB. With 2.00.8 and previous drivers, if the controllers supports extended CDBs but the kernel does not support high memory - the driver prepares a 32-bit sg list but the mailbox address is chosen to be 64-bit. This causes FW to incorrectly read 32-bit (8 bytes) sg list as 64-bit (12 bytes) sg list. This would cause IO from non-disk devices to fail. ### Version 2.00.8 1. Make sure the value of number of statuses, completed command id array, and the mailbox status fields are updated in host memory before we read and interpret them. For this to happen - mailbox numstatus and command id array's first element are invalidated. The ISR busy waits until valid values are obtained in these two fields. Now since the status field is between these two fields it is assumed that status values is sane when write to numstatus and completed id array is complete. 2. While returning from the ioctl handler for the SCSI passthru commands a direct access was made to the user address. Now the user structure is copied in before the required field is accessed. 3. Remove redundant volatile casts from pending command counter pend_cmds. ### Version 2.00.7 1. Adapter lock re-definition so that patch for kernels w/o per host lock is less intrusive. 2. While in abort and reset handling, check for non-empty pending list is invalid. The intent is to wait for pending commands in FW to complete, not the pending commands with the driver. ### Version 2.00.6 1. Declare the function prototypes used for "/proc" within the compiler directives #ifdef CONFIG_PROC_FS. Similarly, move global/local variable declarations and code fragments related to /proc within the directives. 2. Initialize host->lock with adapter->lock. 3. Wait for mailbox status to become valid. 4. Right structure is passed to FW for 4-span read configuration command. ### Version 2.00.5 1. Do not use repeated allocations for "pci_dev" for internal allocations. Allocate the handle at load time and set the DMA mask for allocations below 4GB. 2. Remove superfluous definitions, mid-layer /proc entry and synchronous commands. 3. Logical drive numbers were incremented in passthru structure after random-deletion operation! Also, the logical drive deletion command is issued in polled mode because of the racy nature of interrupt based operation. 4. Add support for Intel's subsystem vendor id. ### Version 2.00.4 1. Do not put the completed SCSI commands in a list. Complete them to mid-layer as soon as we have completed them and reclaimed our associated resources. 2. Break ISR functionality in two portions. The lower half serves as interrupt acknowledgment sequence for the firmware. This half can also be called from other places in the driver, e.g., the abort and reset handlers. 3. New abort and reset handling. In these situations, driver allows more time for the firmware to complete outstanding requests instead of failing handlers right-away. ### Version 2.00.3 1. Change the handshake in ISR while acknowledging interrupts. Write the valid interrupt pattern 0x10001234 as soon as it is read from the outdoor register. In existing driver and on certain platform, invalid command ids were being returned. Also, do not wait on status be become 0xFF, since FW can return this status in certain circumstances. Initialize the numstatus field of mailbox to 0xFF so that we can wait on this wait in next interrupt. Firmware does not change its value unless there are some status to be posted. 2. Specify the logical drive number while issuing the RESERVATION_STATUS. 3. Reduce the default mailbox busy wait time from 300us to 10us. This is done to avoid a possible deadlock in FW because of longer bust waits. 4. The max outstanding commands are reduced to 126 because that's the safest value on all FW. 5. Number of sectors per IO are reduced to 128 (64kb), because FW needs resources in special circumstances like check consistency, rebuilds etc. 6. max_commands is no longer a module parameter because of iv. ### Version: 2.00.2 1. Intermediate release with kernel specific code. ### Version: 2.00.1i 1. Make the older IO based controllers work with this driver. ### Version 2.00.1 1. Release host lock before issuing internal command to reset reservations in megaraid_reset() and reacquire after internal command is completed.