Online Expert Day - HPE Data Storage - Live Now
April 24/25 - Online Expert Day - HPE Data Storage - Live Now
Read more
System Administration
cancel
Showing results for 
Search instead for 
Did you mean: 

panic: kalloc: out of kernel virtual space

Bob Manocchia
Regular Advisor

panic: kalloc: out of kernel virtual space

I have an rx4640 running HPUX 11.23> I tried loading some fiber channel drivers and a couple of patches. When I rebooted I received the following error:

panic: kalloc: out of kernel virtual space.

I googled it and it refers to Dynamic Loable Kernel Modules but all the references were for HPUX 11.11
Are there any patches for HPYX 11.23.
Thanks
2 REPLIES
Don Morris_1
Honored Contributor

Re: panic: kalloc: out of kernel virtual space

Normally this is fragmentation, but that shouldn't kick in at boot -- so the sysmap64 tunable may not have any effect here.

Can you post your console/syslog and then boot with hpux vmunix -v and include the output? I'd like to have a clearer idea of where you're at to try to figure out where the kernel virtual address space went here.
Don Morris_1
Honored Contributor

Re: panic: kalloc: out of kernel virtual space

Other thoughts:

1) Being 11.23, getting out of this situation to resolve it is probably best done by booting a backup or last_install configuration (hpux backup from the EFI). If the kernel was good before the patch change, this should have that good kernel.

2) Since it is pretty unlikely that the kernel fragmented the virtual address space during boot -- the most likely cause of exhaustion is someone doing some bad math [or getting overlarge values] and requesting simply more memory than the system has virtually. By default on 11.23, the kernel uses 64Gb or 3 x RAM, whichever is larger. You don't say how big your system is -- so you'll have to fill in which that is.

If one of the things you did (or the patches did) was to set a kernel tunable much, much higher (I'm thinking of some of the IPCs like the SysV SEM tunables -- they can really cause some big allocations when too high because they multiply against each other) -- then this may be an allocation that's just way too big for your box. In which case, you could boot the backup, lower the tunable -- and reboot with the patches in place.

If the problem is in one of the patches you installed generated a bad allocation -- you'll have to back out the patch. Hence why I'd like the stack trace and verbose output to get some idea of where this allocation is coming from so we can cross-check with the patches you installed.