Changed kernel parms not activated

[Mark van Hassel]

Hello,

We've changed some kernel parms on a RP8400 running HPUX 11.i but after the reboot the changes are not activated. SAM shows the old values and kmtune shows the old value as current and the new as planned. We've tried rebooting the system again, changed parameters and rebooted again, but to no avail. Another thing we notice is that 'lanscan' does not give any output.
Anyone experienced this before ?

Any help is appreciated,

Thanks.

[Pete Randall]

Mark,

I hate to even ask, but did you re-build the kernel?

Pete

[Mark van Hassel]

That's okay. I (SAM) did rebuilt the kernel. A strings of /stand/vmunix even show the correct new kernel parameters.

[T G Manikandan]

If lanscan does not show any output how about

#lanscan /stand/vmunix.prev

Probably the lanscan is waiting for the activation of changes of the kernel.

[Balaji N]

Just a thought.

After changes, did u compile the kernel? A query.

Also, see if there is a new kernel, system file in /stand directory and one .prev file as well.

Sorry if u have already checked them.

Regards
Balaji

[Pete Randall]

Mark,

How about patches? Searching on just "lanscan" turned up these:
PHNE_26774
PHNE_25338
PHCO_22958

Pete

[Mark van Hassel]

Thanks for the responses.
Not output from lanscan /stand/vmunix.prev. Kernel was compiled before reboot. It looks as if the correct vmunix file is there (hence the correct parameters that show from strings /stand/vmunix)but it is not activated.

[Jean-Louis Phelix]

Hello,

Did you check your autoboot file ? Try :

lifcp /dev/rdsk/cxtydz:AUTO -

just to see if you really boot on /stand/vmunix.

Regards,

Jean-Louis.

[Telia BackOffice]

Stop the boot process.

main -> bo pri
IPL y/n : y

IPL > hpux /stand/vmunix

BR,
Jannik

[T G Manikandan]

I would recommened a kernel build from the command line.

/usr/lbin/sysadm/system_prep -s /stand/build/system
vi /stand/build/system
Edit the changes
/usr/sbin/mk_kernel -s /stand/build/system
mv /stand/build/system /stand/system
kmupdate /stand/build/vmunix_test
shutdown -r


Revert

[Pete Randall]

Since a strings /stand/vmunix shows the changes, I doubt that a manually built kernel will be of any help. It really sounds like you're not booting the kernel you think you are, like Jean-Louis was suggesting.

The only other thing I can think of is the kernel parameters you were changing. What parameters were they and what values were you changing them from/to?

Pete

[Mark van Hassel]

licp shows 'hpux -lq'.

Patches are installed except PHNE_26774 but that is an APA patch and we're not running APA on this system.

I will check if I can reboot the system again today.
The changes paramters are:

maxfiles -> 1536
nflocks -> 1200
ninode -> 16384
nproc -> 5120
max_mem_window ->7

[Pete Randall]

Mark,

The changed parameters look reasonable enough. I'm not sure about max_mem_window, though. I looked at it in SAM, but there's no min/max info given for it. You're probably reasonably certain that 7 is a valid value, right?

Pete

[Joaquin Gil de Vergara]

what kernel parameters do you change? static or dinamic?

if you compile a kernel and defer the reboot until you run kmupdate you must move the /stand/build/system.SAM to /stand/system. If not, you have old /stand/system and dinamic parameters will not be applied

[Joaquin Gil de Vergara]

lanscan

see /etc/mnttab. Probably is corrupt

remove ir and run a mount -a to recreate

try now to run lanscan

[Mark van Hassel]

The maximum number of memory windows is 8192, so that should not be a problem either.

[Mark van Hassel]

We've performed T.G.'s procedure and executed 'hpux /stand/vmunix' from ISL but it did not solve the issue.
It's escalated to Hp's Wtec.

[Michael Tully]

Hi Mark,

One thing I would like to suggest to you is definitely look at the latest firmware for this unit. There is a little nasty fix in it pertaining to system reboots. We had a problem a while ago where the system refused to boot. Might worth be looking at.

Cheers
Michael

[Clemens van Everdingen]

Hi,

How do you see that the new parms are not activated ?

Because it looks like you booted from a correct /stand/vmunix.

C.

[Mark van Hassel]

We will look into the formware issue, thanks.

In SAM we still see the old values, kmtune shows the old values as 'current' and the new values as 'planned'. The last and best check is that we cannot create more than 4 memory windows (the old kernel value).

[Clemens van Everdingen]

Hi,

Sorry misread your answer.

Could you try to read the parms with this command:

adb -k /stand/vmunix
nproc?D #displays value of nproc in kernel
nkthread?D #display value of nkthread in kernel
$q

You could do this for all wanted parms.

C.

[Jean-Louis Phelix]

Hello,

I would be curious about the answer to Clemens' question ... I think that your kernel really has the old values.

from kmtune :

Current: current value from running kernel
Planned: planned value from system file

So it only means that your /stand/system has new values and your /stand/vmunix old values ...

If you used SAM to regen the kernel, you should really look at the log file to see if something was wrong during the regen. Then, if it's OK, try to regen the kernel manually (perhaps you have a pure SAM problem ...) using TG's procedure.

Regards,

Jean-Louis.

[Mark van Hassel]

The adb queries show the new values (same as strings /stand/vmunix as mentioned earlier). We compiled a new kernel both using SAM and the command line but to no avail.

[Clemens van Everdingen]

Hi,

How much memory does your system have ?

max_mem_window Enables/configures number of Memory Windows in system
Minimum: 0
Maximum: memory limited
Default: 0

Could it be the memory is to limited for the new value ?

C.

[Mark van Hassel]

Hi,

The problem is solved !
A few weeks ago we've done an Ignite recovery test. After the test vg00 was re-mirrored except for /dev/vg00/lvol1 which held the old kernel and is the primary boot disk !
We've remirrorred vg00 and everything is ok now.

Thanks for your help and responses.

Mark