kernel panic when raising maxswapchunks in 11.11

[likid0]

Hy,

I wanted to add more swap to one of my boxes, so i raised the maxswapchunks value, and i get the following panic:

panic:kalloc: out of kernell virtual space

i'll give you some info on the server:

its hp-ux 11

diehard:/# kmtune | grep sw
maxswapchunks 3584 - 3584
swapmem_on 1 - 1
swchunk 4096 - 4096

i raised the value from 3584 to 9000, to get the 36 gigs of ram that i need,but after compiling the new kernel and a reboot i get the panic, i have done the same in other servers and it has worked ok.

any idea why it can happen?


Thnx

[Bill Hassell]

> its hp-ux 11

Not useful. Here are the versions of HP-UX:

11.00 11.11 11.23 11.31

Each one very different with 11.00 obsolete and unsupported. The documented limit id 16384 so 9000 is well below that limit. Reboot to the old kernel and change maxswapchunks to 4000. If this still panics your system, the problem is likely unrelated to maxswapchunks and you'll need to save the crash dump for analysis.

[Wim Rombauts]

Have you changed parameter nsysmap ?

Read following link : http://docs.hp.com/en/B3921-90010/nsysmap.5.html

The exact error is specified there.

[AwadheshPandey]

http://docs.hp.com/en/5965-4641/ch01s09.html

[likid0]

Hy bill, sorry its 11.11

and the machine is working ok, i booted from the old kernel, changed it to 4000 and gave it a reboot, and it goes fine

thnx

[likid0]

Win, I saw that doc before, but i compared the nsysmap from other machines and its the same, in the other servers maxswapchunks has even 11000 value

[Wim Rombauts]

If you still have the time to reboot again, maybe it's worth a try to increase nsysmap on this system and try again ?
Maybe something that is overlooked on only this server causes a higher usage of the kernel sysmap.
No way to be sure, but if you are stuck because you can't use the swap you need, it looks like worth a try.

[whiteknight]

Daniel,

Usually we do not want to increase maxswapchuck unless you are increasing more swap space and syslog recommended the value to increase the maxswapchunks.

Here is the formula
Max Swap Space = maxswapchunks * 1024 * swchunk


WK
please assign points

[Don Morris_1 · Accepted solution]

I can't see how maxswapchunks increases should be causing increased sysmap fragmentation [the allocations made when building the swap tables are not the tiny size that is more typical for fragmentation and are contiguous... it just doesn't seem that likely that the increase will split that many entries at that point in the boot sequence].

I'm very curious -- is there any chance you modified any _other_ tunables at the same time (and picked up a restored value when you rebuilt)? Were there any console messages about tunables out of range in the panic boot? (And if you have the console log for the panic boot, I wouldn't mind seeing it -- though I'm not positive it will have anything meaningful either).

With a 64-bit kernel and 36Gb of RAM [which implies the 64-bit kernel], there should have been over 90Gb of virtual address space for the kernel... I'm very suspicious that we'd suddenly exhaust that..

Also, is this a nPar? Normal box? vPar?

[likid0]

I was raising the value of maxswapchunks because more ram was added some time ago to the machine and I needed more swap.

Its and Npar, in a superdome.

I was Only changing that value, kmtune -d , only showed the raise of maxswapchunks


I haven't got the full panic console log, i can tell you, is that it only got to the stage when it loads the kernel and then came the panic.

The prob is that it is a production machine and i only had a 5 hour window so i couldnt try different options


Thnx for the help

[likid0]

After sending the dump to HP, and some info, they have told me i need to patches:

PHKL_29890 and PHKL_29889


I will tell you when i get the chance to stop the servers if it works.


thnx