Sunday September 23, 2007 Running recent Nevada builds on a VIA EPIA system
At home I use a VIA EPIA system to serve NFS for my other systems. Since I didn't want another noisy system near my desk, I chose a fanless 600 MHz VIA C3 motherboard. This system has been happily running Nevada (and Solaris 10 before that) for quite some time. As it was running an ancient build (snv_48), I decided to upgrade it to some more recent bits.
While trying to install build 71 some weeks ago, I ran into 6591195 segvn_init() may return before checking HAT_SHARED_REGIONS support where the system paniced with the message "No shared region support on x86 ". Luckily the fix for that went into snv_72, so when snv_73 became available I had another go. This time the system got a little further before it fell over:
init(1M) exited on fatal signal 9: restarting automatically init(1M) exited on fatal signal 9: restarting automatically init(1M) exited on fatal signal 9: restarting automatically
Some searching turned up 6572151 snv boot failure since snv_66 which is a dup of 6332924 snv_24 /usr/ccs/bin/as adds new HWCAP tags to previously untagged object. The problem is that libc.so is now built with HWCAP tags that specify that SSE is required while it is not required per se (if SSE is available it will be used, otherwise it will not be used).
However, since the tag says that SSE is required, a system without SSE support will no longer work. The first consumer of libc.so after boot is /sbin/init. It will fail because libc.so requires SSE, die a horrible death and get restarted (and restarted, and restarted, ...). Running isainfo on my EPIA system shows that it indeed does not have the SSE capability:
$ isainfo -v
32-bit i386 applications
ahf mmx cx8 tsc fpu
CR 6332924 is currently in the 'Fix in progress' state so there is no build which includes the fix yet. There is a workaround though: elfedit(1). As the name suggests elfedit can be used to edit ELF files, and that is what I did. By removing the SSE HWCAP tag from libc.so, I was able the get my EPIA to work with build 73.
Here is what I did to make it work: since we obviously can't easily update libc.so on the DVD, I used LiveUpgrade to create a second boot environment for build 73:
# lucreate -c nv_48 -n nv_73 -m /:/dev/dsk/c0d0s3:ufs # luupgrade -n nv_73 -u -s /mnt # DVD mounted on /mnt
Next, I mounted the build 73 BE to access the build 73 copy of /lib/libc.so
# lumount -n nv_73
elfedit is available from snv_75 onwards so I copied libc.so to another system running a recent nightly build to remove the SSE tag:
$ file /tmp/libc.so /tmp/libc.so: ELF 32-bit LSB dynamic lib 80386 Version 1 [SSE CX8 FPU], dynami cally linked, not stripped, no debugging information available $ elfedit -e 'cap:hw1 -and -cmp sse' /tmp/libc.so $ file /tmp/libc.so /tmp/libc.so: ELF 32-bit LSB dynamic lib 80386 Version 1 [CX8 FPU], dynamicall y linked, not stripped, no debugging information available
I copied the modified libc.so back and activated the nv_73 boot environment:
# luumount nv_73 # luactivate nv_73 # init 6
Success!
(Ali Bahrami, I owe you a beer!)
opensolaris
( Sep 23 2007, 03:33:25 PM CEST )
Permalink
Comments [1]
Wednesday September 12, 2007 Resource control observability using kstats
One of the things I sometimes miss when using resource controls, is a simple way to see what the current usage of a particular resource control by a project or zone is. While finding out the limit for the rctl is no problem (for that we haveprctl(1)), getting the actual usage requires work and implementation knowledge.
For instance, we could get the amount of System V shared memory used by a project using ipcs -Jam and some parsing of its output. Or fire up mdb(1) and lookup the value for kpd_shmmax in the project's kproject_t struct. And, if we wanted to get the usage of another resource control (say the number of lwps), we'd need to use another tool (prstat -LJc) or know that the number of lwps is kept in the kpj_nlwps member. Hardly usable for more than the occasional peek. Plus that relying on kernel implementation details such as these structure members is highly inadvisable as they may change in the future (they probably won't, but they are not stable interfaces so don't rely on them).
The addition of the swap and locked memory resource controls by PSARC 2006/598 Swap resource control; locked memory RM introduced a number of kstats for observability:
caps:{zoneid}:swapresv_zone_{zoneid}caps:{zoneid}:lockedmem_zone_{zoneid}caps:{zoneid}:lockedmem_project_{projid}
These kstats have a 'value' statistic for the current limit and a 'usage' statistic that holds the current usage:
$ kstat -c zone_caps -n swapresv_zone_0
module: caps instance: 0
name: swapresv_zone_0 class: zone_caps
crtime 0
snaptime 102512.50351337
usage 532168704
value 18446744073709551615
zonename global
Exposing these values as kstats gives us exactly what is needed, a simple, well defined method to get the limit and usage for a resource control.
To satisfy my curiosity and to see what changes would be needed, I spent some evenings creating a prototype that adds kstats for all project.* and zone.* resource controls. The following extra kstats are available in the prototype:
caps:{projid}:contracts_project_{projid}caps:{projid}:msgids_project_{projid}caps:{zoneid}:msgids_zone_{zoneid}caps:{projid}:nlwps_project_{projid}caps:{zoneid}:nlwps_zone_{zoneid}caps:{projid}:ntasks_project_{projid}caps:{projid}:semids_project_{projid}caps:{zoneid}:semids_zone_{zoneid}caps:{projid}:shmids_project_{projid}caps:{zoneid}:shmids_zone_{zoneid}caps:{projid}:shmmem_project_{projid}caps:{zoneid}:shmmem_zone_{zoneid}
Getting a list of the current usage of all resource controls is now as simple as typing:
$ kstat -p caps:::usage caps:0:contracts_project_0:usage 33 caps:0:contracts_project_1:usage 2 caps:0:contracts_project_101:usage 0 caps:0:cryptomem_project_0:usage 0 ... caps:5:nlwps_project_0:usage 108 caps:5:nlwps_zone_5:usage 108 caps:5:ntasks_project_0:usage 15 caps:5:semids_project_0:usage 0 caps:5:semids_zone_5:usage 0 caps:5:shmids_project_0:usage 1 caps:5:shmids_zone_5:usage 1 caps:5:shmmem_project_0:usage 172032 caps:5:shmmem_zone_5:usage 172032 caps:5:swapresv_zone_5:usage 95178752
And now that we have the numbers as kstats, we can use any tool to massage the numbers into a form that suits us. The screenshot below is from a hacked up version of one of the JKstat demo programs and shows a graph of the number of LWPs in all projects and zones during boot and shutdown of a Zone.
T: OpenSolaris Solaris ( Sep 12 2007, 09:29:14 PM CEST ) Permalink Comments [3]