using "adb" to look at kernel parameters

[Joseph Belesi]

I have two HP-UX 10.20 D370 servers and I'm using "adb" to look at kernel parameters. The only difference between the 2 systems is that one has 3GB of physical memory and the other has 1GB of physical memory.

On the machine with 1GB, I invoke "adb" as follows:

echo "$e" | adb -k /stand/vmunix /dev/kmem

The output provides everything I need. On the machine with 3GB, the "-k" option yields no output. I must invoke "adb" as follows:

echo "$e" | adb /stand/vmunix /dev/kmem

Anyone have an idea why the "-k" option doesn't work in this scenario?

Thanks in advance...

[federico_3]

i always use adb like the following:

echo kernel_param/D | adb -k /stand/vmunix /dev/kmem

-k tells ADB that the object and core files are kernel files so ADB can perform the appropriate memory mapping.

To know all the kernel parameters sending them in a file:
# adb -k -w /stand/vmunix /dev/kmem > /tmp/file_ker_par
$e
$q
#


federico

[Stefan Farrelly]

If you run the following command on both your boxes;

/usr/contrib/bin/q4pxdb -s status /stand/vmunix
/stand/vmunix ready for debugging

Does it return the same for both of them ? ie. that the kernel has been preprocessed for debugging (adb) ?

If not you can preprocess it with this command;

/usr/cq4pxdb /stand/vmunix

[Joseph Belesi]

Thanks for the info.

On both machines, "q4pxdb -s status /stand/vmunix" I get the following:

crt0 out of date
/stand/vmunix hasn't been preprocessed

I guess I'm looking for why adb's "-k" option is doesn't work for the machine with 3GB of memory. Could 3GB of memory be too much to perform virtual-to-physical address translation?
Thanks...

[Stefan Farrelly]

Ive got servers ranging from 32Mb to over 3GB and the same command works on all of them;

echo bufpages/D | adb -k /stand/vmunix /dev/kmem

- all with the -k option, so size of memory is not an issue. On your server it isnt working on is the kernel in sync with /stand/vmunix ? Try it pointing to vmunx.prev

Is you server with 3GB running 10.20 ? If so there are issues with individual processes adressing > 2.75Gb of memory which could be your problem, all ours are 11.0