Decimal vs hex kernel parameters

[Paul Hopkins]

Hi,

I'm working on a application upgrade on a N4000 server. I sent the software vendor the current kernel parameters. I used kmtune to list the parameters. The vendor sent back some recommended kernel changes and stated,

"In order to avoid panic signal 10 errors, some of the kernel values need to be in dec value not hex. The hex values are known to cause panics"

Has anyone heard of this? Is there a difference between decimal and hex values?

Thanks

Paul

N4000-55, 8cpus, 8Gb memory, 12H autoraid, HP-UX 11i june 2004

[James R. Ferguson]

Hi:

I have not heard this one. A signal-10 is a SIGBUS error which can arise from bad pointers.

Regardless, there is no difference between using decimal or hexadecimal values. I personally use hexadecimal when the parameter's permissible range is expressed in hexadecimal (e.g. 'maxdsiz_64bit' range is 0x40000 to 0x3ffbfffffff), but use decimal when the range is expressed in that base (e.g. 'maxfiles' range is 30-60000). You are free to interconvert.

Regards!

...JRF...

[Paul Hopkins]

I figured the dec & hex values were pretty much interchangeable like you say. I had never heard of a difference between kernel parameters in dec vs hex. Your example of the maxdsiz_64bit parameter was one that the vendor said needed to be entered in decimal. kmtune shows the value in hex.

maxdsiz_64bit 0x40000000 - 0x0000000040000000

If you use sam to look at and/or configure the parameter, it displays the value in decimal.

maxdsiz_64bit 1073741824 1073741824 Static N/A

I was skeptical when I heard this from the vendor. I asked if they had any documentation on this. They haven't come up with anything yet.

Thanks for the reality check.

Paul

[Bill Hassell · Accepted solution]

The kernel tuning values are compiled from the system file and the kernel=builder simply converts whatever is there into an appropriate binary value. The kernel-builder/compiler recognizes octal, hex, decimal and formulae. These are simply symbolic values that will translated into a final binary value for the kernel. My guess is that someone did not compute a hex value correctly and the result was an extremely large number. Unfortunately, many kernel parameters are 8 to 12 numbers and it is really easy to miscount the digit count.

SAM is not helpful because it decodes the entered value into a simple decimal number without any magnitude helpers (like 1,000,000,000 for a billion, or 1.00 billion). You really need a good Octal/Hex calculator to help.

[A. Clay Stephenson]

By the way it behaves, I'm all but positive that kmtune uses the standard library function, strtoul -- which converts a string to an unsigned long value.

#include

unsigned long strtoul(const char *nptr, char **endptr, int base);


The nice feature of this function is that if zero is supplied as the base (radix) for the conversion then strtoul attempts to automatically set the base. If the string begins with '0x' a hexadecimal base is assummed; if the string begins with '0', an octal base is assumed; otherwise, a decimal is assumed. Strtoul works just fine so I rather doubt given valid input in hex or decimal that a problem exists.