 | |
Testing the Driver Update DisketteTesting Solaris Installation With Driver Update DiskettesThe Solaris (Intel Platform Edition) Device Configuration Assistant boot diskette is used perform a Solaris installation and upgrade, along with bootable Solaris media that resides on a CD-ROM or in a network installation area known as a netinstall image (see the add_install_client(1M) man page for more information). Testing the bootable device driver on the Driver Update (DU) diskette consists of supplying the driver's DU diskette to the boot subsystem at the initial boot menu (via the F4_Driver Upate menu choice) and then verifying that all supported devices are recognized properly and can be selected to install Solaris from and/or install Solaris to, depending on the capabilities of the device.Solaris HBA (Host Bus Adapter) drivers can generally be used to install Solaris from, when Solaris installable media is provided in a CD-ROM. Solaris HBA realmode drivers should be able to boot from the CD-ROM and from all hard drives (provided Solaris is already installed on a hard drive). Solaris network drivers are used to install Solaris from, when a Solaris netinstall server is providing install media via the network. Solaris realmode network drivers can boot from these remote NFSTM mounted file systems. The typical installation process begins with inserting the Configuration Assistant boot diskette into a system's diskette drive and rebooting the system. At the initial Configuration Assistant boot menu, select the F4_Driver Update menu choice to read in iteratively all DU diskettes to be tested. At the conclusion of DU diskette processing, the Configuration Assistant presents a list of device drivers loaded from the DU diskette that have been associated with device hardware attached to the system (for detailed documentation on each step, see the Configuration Assistant online help). Stepping through the Configuration Assistant menus, information concerning DU-supported adapters and devices are displayed, and this information can be used to confirm that the bootable device driver has loaded properly from the DU diskette. Finally, a list of bootable devices to choose from is presented. In general, new bootable device drivers should be tested to confirm first that the realmode driver is able to boot from all supported devices (from configured netinstall areas for network realmode drivers, and from CD-ROM boot media and installed hard drives for HBA realmode drivers). For example, to test the xyzuraid bootable device driver DU diskette, first place a Solaris bootable CD-ROM in a CD-ROM drive that is attached to the xyzuraid device hardware and then boot the system with the Configuration Assistant diskette. Next, select the Configuration Assistant F4_Driver Update menu choice and step through the menus to process the xyzuraid DU diskette. At the conclusion of DU diskette processing, reinsert the Configuration Assistant boot diskette to continue the boot process until a list of bootable devices is presented. At this point, the CD-ROM drive attached to the xyzuraid device should appear as one of the bootable devices from which you can select to boot Solaris (Intel Platform Edition). Enabling Debugging With the Configuration Assistant Boot DisketteOccasionally there might be problems with the newly developed realmode driver, the driver.itu(4) file, and so on, and this may require debugging of the Configuration Assistant boot sequence. The bootconf.exe boot program provides a -d debug flag that simplifies the debugging process by displaying information while the driver.itu(4) file is processed, and also during the entire Solaris (Intel Platform Edition) boot sequence. To enable DU debugging, add the -d0x80000400 flag to the /solaris/bootenv.rc file on the Configuration Assistant diskette. For example, this line:setprop confflags "-F"would be changed to: setprop confflags "-F -d0x80000400"to print verbose information on each stage of the Configuration Assistant boot sequence related to DU diskette processing. (Note that the eeprom(1m) command may also be used to edit this property, as well as the Device Configuration Assistant menu system, can be used to edit property values). The following experimental debugging options are available; however, note that the Configuration Assistant boot diskette and bootconf.exe are private interfaces and that these experimental debugging variables may not be avaiable in all releases). #define D_BEF_PRINT 0x00000001UL /* BEF printf's */The various white papers on realmode drivers and related sample source and man pages available at the Driver Developer Site provide additional information on how to debug realmode device drivers. Common DU Diskette ErrorsRealmode Driver From DU Diskette Is Not LoadedIf the realmode driver either has not loaded or has not recognized any hardware devices to support, ensure that all device IDs for hardware supported by the realmode device driver have been specified (see the devicedb(4), driver.itu(4) and add_drv(1M) man pages for more information on associating device hardware with realmode and Solaris device drivers). For example, in the xyzuraid pkg_drv(1M) example given previously, the -i '"pci1234,5678"' alias was supplied to associate the xyzuraid driver with self-identifying hardware with this vendor information. This generated the devicedb(4) entrypci1234,5678 pci1234,5678 msd pci xyzuraid.bef "xyzuraid: IHV-supplied Device Driver Kernel Module"whose purpose is to associate the device hardware with the xyzuraid.bef realmode driver. This information is also encoded in the xyzuraid.itu driver.itu(4) file that is used by the Configuration Assistant boot diskette during DU diskette processing: dev_type=msdEnsure that all aliases have been provided to pkg_drv(1M) so that proper devicedb(4) and add_drv(1M) driver aliases are created. Also, verify carefully any manually added entries. Note that for the Solaris OS on x86 Platforms, entries might need to be added to both the devicedb(4) file and the /etc/driver_aliases file. Also be certain that the dev_type entry, and other devicedb entries, are properly set. The pkg_drv(1m) utility may not be able to access enough information, to properly identify the type of a driver, meaning that the driver.itu(4) file will require manual editing. A realmode driver must be of type "msd" or "net" to be bootable. Configuration Assistant Diskette Reports Errors Parsing the DU DisketteCarefully note the parsing errors that are reported, and turn on the D_ITU Configuration Assistant diskette debugging flag to obtain further information on the type of error.The driver.itu(4) file parser provided by the Configuration Assistant boot diskette is unforgiving, so you might need to simplify this file carefully to avoid parsing errors. In particular, do not nest braces and other constructs, and do not use quotes and white spaces in ways other than those described in the driver.itu(4) man page. Solaris Boot Sequence Hangs Prior to First Installation MenuThere are a variety of possible causes for the Solaris boot sequence to hang somewhere before the first installation menu appears on the screen. Methods of debugging include enabling of the Configuration Assistant boot diskette and kernel debugging, using debugging printf statements in the realmode and Solaris device drivers, and using the kadb(1M) kernel debugger to breakpoint the device driver in question. Analyzers and packet capturing utilities like snoop(1M) can also be used to discern the progress of a Solaris boot sequence.To obtain the maximum amount of debugging information, turn on all debugging flags for the Configuration Assistant boot diskette, in the /solaris/bootenvr.c file: setprop confflags="-F -d0x8fffffff"Next, instrument the realmode driver with printf statements. Another useful strategy is to set red zone checks around realmode driver data structures and stack. As the realmode driver runs prior to UnixR protections that are in force, it may corrupt itself or another portion of the boot subsystem unless care is taken. When the initial Solaris boot(1M) prompt is reached, the kadb(1M) debugger may be loaded, by first typing b kadb -dand selecting a Unix (typically kernel/UNIX) and then typing enter. At the initial kadb prompt, you can turn on debugging of dynamic kernel module loading by setting the moddebug variable: moddebug/W 80000000With Solaris 7 (Intel Platform Edition), you can also set deferred breakpoints in future loadable modules (such as the new bootable Solaris device driver). For example, for the xyzuraid driver, you might type xyzuraid#xyzuraid_probe:bto insert a breakpoint in the xyzuraid_probe() routine. Then, to continue execution in kadb, type: :c Solaris Install Boot Sequence Appears to Work, But No Driver In Root File SystemFirst, ensure that the DU diskette was processed during an install or upgrade boot sequence, using the Configuration Assistant boot diskette. Specifically, the DU boot sequence is not currently supported if the system is booted from a hard drive.The Solaris package or patch that places the new bootable device driver onto the installation or upgrade root is installed only at the conclusion of the Solaris install or upgrade sequence. So, be sure you are prompted again for the DU diskette at the end of the Solaris install or upgrade process and that the package, patch, or both are properly installed. If the DU diskette is not re-processed at the end of the sequence or if the package fails to install properly, the driver and associated components will not be applied to the installed or upgraded root file system. Note that the DU diskette can be debugged independently from the Solaris install process by applying the Solaris package, patch, or both manually, using the pkgadd(1M) or patchadd(1M) command, or by using the interactive option of the install.sh script on the DU diskette. Again, using the xyzuraid example, the following commands can be used to test the installation sequence of the DU diskette: # volcheck
[Previous | Contents | Next][Return to Driver Tools]Solaris OS on x86 Platforms: Third-Party Packaging Tools (A White Paper) | |||
|
Oracle is reviewing the Sun product roadmap and will provide guidance to customers in accordance with Oracle's standard product communication policies. Any resulting features and timing of release of such features as determined by Oracle's review of roadmaps, are at the sole discretion of Oracle. All product roadmap information, whether communicated by Sun Microsystems or by Oracle, does not represent a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. It is intended for information purposes only, and may not be incorporated into any contract.
| ||||||||||||
Print-friendly Version
