| Since HP-UX 11.0, the HP-UX kernel has had a dynamic component to its nature. There are two parts to this dynamic behavior: Dynamically Loadable Kernel Modules (DLKM) and Dynamically Tunable Kernel Parameters (DTKP). With HP-UX 11i, we have seen a growth in the use of both. 10.1.1 Dynamically Loadable Kernel Modules (DLKM) DLKM allows us to load and unload kernel device drivers and subsystems without requiring a reboot. Come the day when every kernel driver and subsystem is dynamically loadable, we may never need to reboot a system in order to load patch. I said " may never need to reboot" because I can envisage a situation where a device driver managing some low-level IO functionality becomes corrupted. At that time, we might not be able to do anything other than reboot the system in order to clear the resulting system hang. The idea here is that we minimize, as much as possible, the necessity for rebooting our system just to add driver/subsystem functionality. I am going to use a system that has a few DLKM modules installed. The installation of a DLKM is different from the management of a DLKM. The installation is normally taken care of by a swinstall command. After it is installed, a DLKM is ready to be loaded and used. Take an example where we have a (fictitious) widget interface card and associated widgedrv device driver from the Acme Corporation. To use and manage the widget interface card, we need to ensure that the widgedrv driver is installed and loaded. In the following example, I am using a real system and real files, but it is purely for demonstration purposes. I don't think the Acme Corporation sells a widget interface card for HP-UX, yet! Here's a summary of the process: We need to install the widgedrv DLKM device driver. This is normally in the form of a swinstall from the installation CD supplied by the Acme Corporation. If the Acme Corporation does not supply a swinstall -enabled installation CD, we would need to install the widgetdrv driver manually. The process of installing a DLKM can be summarized as follows : -
Load at least three files onto your system: -
A file called system : localizable kernel parameters for this device driver -
A file called master : global default setting for the device driver -
A file called mod.o : relocatable object code; the actual device driver -
Use the kminstall “a widgedrv command to locate the above three files to their appropriate locations:
root@hpeos003[] ll mod.o system master -rw-r--r-- 1 root sys 956 Nov 17 13:20 master -rw-r--r-- 1 root sys 7904 Nov 17 13:20 mod.o -rw-r--r-- 1 root sys 174 Nov 17 13:20 system root@hpeos003[] kminstall -a widgedrv root@hpeos003[]
This will locate the three files to the locations listed in Table 10-1. Table 10-1. DLKM Installation Files | Filename | Target location | | system | /usr/conf/master.d/<driver name > | | master | /stand/system.d/<driver name> | | mod.o | /usr/conf/km.d/<driver name>/mod.o |
root@hpeos003[] ll /stand/system.d/widgedrv -rw-r--r-- 1 root sys 174 Nov 17 13:23 /stand/system.d/widgedrv root@hpeos003[] ll /usr/conf/master.d/widgedrv -rw-r--r-- 1 root sys 956 Nov 17 13:23 /usr/conf/master.d/widgedrv root@hpeos003[] ll /usr/conf/km.d/widgedrv/ total 16 -rw-r--r-- 1 root sys 7904 Nov 17 13:23 mod.o root@hpeos003[]
Compile the kernel module from the installed relocatable object file using the mk_kernel command:
root@hpeos003[] mk_kernel -M widgedrv Generating module: widgedrv... Specified module(s) below is(are) activated successfully. widgedrv root@hpeos003[] ll /stand/dlkm/mod.d total 168 -rw-r--r-- 1 root sys 8528 Oct 31 20:25 krm -rw-r--r-- 1 root sys 67544 Oct 31 20:25 rng -rw-rw-rw- 1 root sys 8648 Nov 17 13:35 widgedrv root@hpeos003[] file /stand/dlkm/mod.d/widgedrv /stand/dlkm/mod.d/widgedrv: ELF-64 relocatable object file - PA-RISC 2.0 (LP 64) root@hpeos003[] root@hpeos003[] kmadmin -s Name ID Status Type ===================================================== krm 1 UNLOADED WSIO rng 2 LOADED WSIO widgedrv 3 UNLOADED WSIO root@hpeos003[]
This is normally the stage at which a swinstall would leave the DLKM, i.e., it's ready to be loaded. Let's assume that we have installed the widget interface card (using OLA/R techniques). Before we can use the widget interface card, i.e., before we run ioscan and insf , we need to ensure that the DLKM is loaded. This is achieved by the kmadmin “L command:
root@hpeos003[] kmadmin -L widgedrv kmadmin: Module widgedrv loaded, ID = 3 root@hpeos003[] kmadmin -s Name ID Status Type ===================================================== krm 1 UNLOADED WSIO rng 2 LOADED WSIO widgedrv 3 LOADED WSIO root@hpeos003[] root@hpeos003[] kmadmin -Q widgedrv Module Name widgedrv Module ID 3 Module Path /stand/dlkm/mod.d/widgedrv Status LOADED Size 61440 Base Address 0xe28000 BSS Size 53248 BSS Base Address 0xe36000 Hold Count 1 Dependent Count 0 Unload Delay 0 seconds Description widgedrv Type WSIO Block Major -1 Character Major 67 Flags a5 root@hpeos003[]
After running ioscan and insf , we could now use our new widget interface card. Sometime later, we find that we need to patch the widgedrv device driver. The point is the interface card hasn't been working well. It keeps dropping widgets all over the network. We have organized with our users that we can unload the driver, which will render the card unusable during this time. We have received new versions of the system , master , and mod.o files from the Acme Corporation. Once unloaded, we can update the driver files, recompile the module, and load it again:
root@hpeos003[] ll system master mod.o -rw-r--r-- 1 root sys 1056 Nov 17 13:49 master -rw-r--r-- 1 root sys 8321 Nov 17 13:49 mod.o -rw-r--r-- 1 root sys 206 Nov 17 13:49 system root@hpeos003[] kmadmin -U widgedrv kmadmin: Module 3 unloaded root@hpeos003[] kmadmin -s Name ID Status Type ===================================================== krm 1 LOADED WSIO rng 2 LOADED WSIO widgedrv 3 UNLOADED WSIO root@hpeos003[] kminstall -u widgedrv root@hpeos003[] mk_kernel -M widgedrv Generating module: widgedrv... Specified module(s) below is(are) activated successfully. widgedrv root@hpeos003[] kmadmin -L widgedrv kmadmin: Module widgedrv loaded, ID = 3 root@hpeos003[] kmadmin -s Name ID Status Type ===================================================== krm 1 UNLOADED WSIO rng 2 LOADED WSIO widgedrv 3 LOADED WSIO root@hpeos003[]
This all happens without a reboot. It should be noted that while unloaded the device was effectively useless. The advantage of DLKM is that we massively improve the overall availability of our system by removing the need to reboot a system in order to update a device drive (load a kernel patch). HP Labs are currently working to ensure that more and more device drivers and subsystems are DLKMs. Currently, more device drivers and subsystems are statically linked than dynamic modules. As time passes , I am sure we will see that situation rectified. 10.1.1.1 STATIC OR DYNAMIC The last part of the DLKM puzzle is to ask a fundamental question regarding the nature of our widgedrv device driver: " Do we need the widgedrv device driver to boot HP-UX? " If the answer to this question is yes , then we need to compile the widgedrv driver into the kernel as a static module using the kmsystem command (-c y = configure yes, -l n = loadable no):
root@hpeos003[stand] cp system system.prev root@hpeos003[stand] kmsystem -c y -l n widgedrv root@hpeos003[stand] mk_kernel Generating module: krm... Generating module: rng... Compiling /stand/build/conf.c... Generating module: widgedrv... Loading the kernel... Generating kernel symbol table... root@hpeos003[stand] root@hpeos003[stand] cp vmunix vmunix.prev root@hpeos003[stand] cp -pr dlkm dlkm.vmunix.prev/ root@hpeos003[stand] kmupdate Kernel update request is scheduled. Default kernel /stand/vmunix will be updated by newly built kernel /stand/build/vmunix_test at next system shutdown or startup time. root@hpeos003[stand]
We are now ready to reboot this system (using shutdown “ry now ) with a static widgedrv device driver. If the answer to the question " Do we need the widgedrv device driver to boot HP-UX? " were no, we would simply add a line to the /etc/loadmods file naming the widgedrv device driver.
root@hpeos003[stand] cat /etc/loadmods rng widgedrv root@hpeos003[stand]
This will ensure that after every reboot, widgedrv is loaded automatically. 10.1.2 Dynamically Tunable Kernel Parameters (DTKP) At present, the number of DTKPs is in a similar state to the number of DLKMs. Currently, there are more statically configured kernel parameters than dynamic ones. When we install HP-UX, the value of kernel parameters is sufficient to run HP-UX. As soon as we install a real-world application, we will commonly need to modify a series of kernel parameters. It's not for me to say which kernel parameters need updating. That's the job of your third-party application suppliers. In some unique situations, HP may suggest adjusting certain kernel parameters. Whoever prompts for a kernel parameter to be changed, we need to understand whether this will involve a reboot of our system. The easiest way to find out whether a parameter is dynamically tunable is to look at the third field of output from the kmtune command. If it says Y, it means the parameter is dynamically tunable:
root@hpeos003[] kmtune awk ' ~/Y/ {print root@hpeos003[] kmtune awk '$3 ~/Y/ {print $0}' core_addshmem_read 0 Y 0 core_addshmem_write 0 Y 0 maxfiles_lim 1024 Y 1024 maxtsiz 0x4000000 Y 0x04000000 maxtsiz_64bit 0x40000000 Y 0x0000000040000000 maxuprc 75 Y 75 msgmax 8192 Y 8192 msgmnb 16384 Y 16384 scsi_max_qdepth 8 Y 8 semmsl 2048 Y 2048 shmmax 0x4000000 Y 0X4000000 shmseg 120 Y 120 root@hpeos003[] }' core_addshmem_read 0 Y 0 core_addshmem_write 0 Y 0 maxfiles_lim 1024 Y 1024 maxtsiz 0x4000000 Y 0x04000000 maxtsiz_64bit 0x40000000 Y 0x0000000040000000 maxuprc 75 Y 75 msgmax 8192 Y 8192 msgmnb 16384 Y 16384 scsi_max_qdepth 8 Y 8 semmsl 2048 Y 2048 shmmax 0x4000000 Y 0X4000000 shmseg 120 Y 120 root@hpeos003[]
If a chosen parameter is not in this list, then changing it will involve a reboot of the system. I have been requested to change a few kernel parameters; some are dynamic, and some aren't. The list of parameters I am going to change are the following:
root@hpeos003[] kmtune -q nproc Parameter Current Dyn Planned Module Version ============================================================================= nproc 2068 - (20+8*MAXUSERS) root@hpeos003[] kmtune -q dbc_max_pct Parameter Current Dyn Planned Module Version ============================================================================= dbc_max_pct 50 - 50 root@hpeos003[] kmtune -q create_fastlinks Parameter Current Dyn Planned Module Version ============================================================================= create_fastlinks 0 - 0 root@hpeos003[] kmtune -q maxuprc Parameter Current Dyn Planned Module Version ============================================================================= maxuprc 75 Y 75 root@hpeos003[]
As you can see, only the last parameter is a DTKP. That's just the way it is. I will change these parameters to the values I have been informed are appropriate for my system:
root@hpeos003[] kmtune -s nproc=5192 root@hpeos003[] kmtune -s dbc_max_pct=20 root@hpeos003[] kmtune -s create_fastlinks=1 root@hpeos003[] kmtune -s maxuprc=1024 root@hpeos003[]
With a single command, I can now dynamically update as many of these parameters as is possible:
root@hpeos003[] kmtune -u WARNING: create_fastlinks cannot be set dynamically. WARNING: dbc_max_pct cannot be set dynamically. The kernel's value of maxuprc has been set to 1024 (0x400). WARNING: nproc cannot be set dynamically. root@hpeos003[] kmtune -d Parameter Current Dyn Planned Module Version ============================================================================= create_fastlinks 0 - 1 dbc_max_pct 50 - 20 nproc 2068 - 5192 root@hpeos003[] root@hpeos003[] kmtune -q maxuprc Parameter Current Dyn Planned Module Version ============================================================================= maxuprc 1024 Y 1024 root@hpeos003[]
As you can see, maxuprc has been dynamically changed while the others will require us to rebuild the kernel and reboot the system in order to effect the change. If there was some mistake with these parameters, I can reset them to the factory defaults with the kmtune “r command.
root@hpeos003[] kmtune -r nproc root@hpeos003[] kmtune -q nproc Parameter Current Dyn Planned Module Version ============================================================================= nproc 2068 - (20+8*MAXUSERS) root@hpeos003[]
I won't go through the process of building a new kernel; you've seen that earlier. Just a reminder to always keep a copy of a backup kernel in case the changes you made here produce a kernel that is not capable of booting. 10.1.3 Monitoring kernel resource with kcweb The kcweb utility is now available for all versions of HP-UX 11i. It is available as a free download from http://software.hp.com. It is a Web-based tool allowing you to monitor and makes changes to your kernel via a web interface. The installation is simplicity itself; it doesn't require a reboot:
root@hpeos003[] swlist -s /tmp/Casey_11.11.depot # Initializing... # Contacting target "hpeos003"... # # Target: hpeos003:/tmp/Casey_11.11.depot # # # Bundle(s): # Casey B.00.03 HP-UX KernelConfig (Kernel Configuration) root@hpeos003[] swinstall -s /tmp/Casey_11.11.depot Casey ======= 11/17/03 16:00:21 GMT BEGIN swinstall SESSION (non-interactive) (jobid=hpeos003-0081) * Session started for user "root@hpeos003". * Beginning Selection ... NOTE: More information may be found in the agent logfile using the command "swjob -a log hpeos003-0081 @ hpeos003:/". ======= 11/17/03 16:00:23 GMT END swinstall SESSION (non-interactive) (jobid=hpeos003-0081) root@hpeos003[]
When we start the kcweb daemon(s), it will start two apache Web server daemons listening on port 1188. The httpd.conf configuration file it uses lives under /opt/webadmin/conf/httpd.conf . root@hpeos003[] kcweb Creating server certificates... Certificates successfully created. Attempting to start server... Server successfully started. Attempting to find an existing browser... SECURITY WARNING: starting a browser in the current environment may open you to security risks. This is the case when the X Server and the browser are on different systems. Since kcweb cannot guarantee a secure browser is available, you may: . Paste the URL https://hpeos003:1188/cgi-bin/kcweb/top.cgi into a browser. . Close any non-local instances of Netscape on 192.168.0.70 and rerun kcweb. . Use kcweb with the "-F" (force) option. There is either one or more instances of Netscape running on 192.168.0.70 that is not local, or Netscape cannot be started in a secure mode because the X Server is not on the same machine as the display variable. root@hpeos003[] This message is displayed because the default behavior of kcweb is to start up the daemon processes and to launch a client Web browser. I am connected from my PC through X-Windows emulation software, and kcweb has detected that I have my DISPLAY variable set. If you want to simply start up the Web server without attempting to start a client browser, use the command kcweb “s startssl . The messages will not stop me from browsing on my local PC. When I do, I will be asked to verify the certificates issued by the kcweb server. When complete, I will presented with a login screen (see Figure 10-1). Figure 10-1. kcweb login screen. 
The interface is intuitive and easy to navigate, as you can imagine. kcweb comes with a bolt-on kernel resource monitor for the EMS subsystem, allowing us to set up alarms to trigger when certain kernel parameters reach certain thresholds. After every reboot, the kcmond daemon is started up to monitor a series of kernel parameters. Being an EMS monitor means that we can integrate resource monitoring into other applications such as the OpenView products and Serviceguard. I particularly like the idea of setting up a Serviceguard resource that monitors a series of critical kernel resources. Should all the resource exceed their threshold, Serviceguard will move an application package to an adoptive node, under the premise that this machine doesn't have enough resources to sustain running this application. Using either the Web interface or via the kcalarm command, I can set up a series of alarms whereby notification is sent to various places (email, SNMP, and so on) whenever a kernel resource breaches a defined threshold. In this way, we can be pre- warned before a particular kernel resource overflows. Figure 10-2 shows a screen where I have logged in and clicked on the nproc kernel parameter: Figure 10-2. Navigating kcweb. 
On the bottom right, you can see a small graph of parameter usage over the last week. You can extract this information from the logfiles maintained by the kcmond daemon in the directory /var/adm/kcmond/ either using the browser or using the kcusage command (you can display hourly, daily, monthly, or yearly data):
root@hpeos003[] kcusage -h nproc Parameter: nproc Setting: 2068 Time Usage % ============================================= Mon 11/17/03 16:20 GMT 153 7.4 Mon 11/17/03 16:25 GMT 57 2.8 Mon 11/17/03 16:30 GMT 57 2.8 Mon 11/17/03 16:35 GMT 57 2.8 Mon 11/17/03 16:40 GMT 57 2.8 Mon 11/17/03 16:45 GMT - - Mon 11/17/03 16:50 GMT 127 6.1 Mon 11/17/03 16:55 GMT 127 6.1 Mon 11/17/03 17:00 GMT 127 6.1 Mon 11/17/03 17:05 GMT 127 6.1 Mon 11/17/03 17:10 GMT 139 6.7 Mon 11/17/03 17:15 GMT 132 6.4 root@hpeos003[]
I won't go through every screen in kcweb because it's all intuitive. The only problem I had was that the kcweb Web server was not started up by default after a reboot and there is no startup script supplied. I think the idea is that the first time you need the Web server is when you actually run the kcweb command from the command line. I would have preferred a startup script that ran the command kcweb “s startssl . This will start the Web server, which will not die (unlike the Web server started by the simple kcweb command) until the system is rebooted or we explicitly kill it with the kcweb “s stop command. There isn't a huge amount of documentation supplied with kcweb because it's straightforward and uncomplicated. There are man pages for the various commands, and the Web interface has a host of online documentation about various kernel parameters and tasks to be performed. | 