This is a really ugly problem that I don't have a solution for. But let me give you a bit of info if you want to do your own digging:
The way I found this is that I was adding NICs to a Linux on the fly. Sometimes this would fail, saying page allocation in syslog. The discussion on this list is here: http://www.mail-archive.com/linux-390%40vm.marist.edu/msg65371.html What I found later is that the NIC driver needs 64k of memory in kernel space. This means the memory needs to be continuous. The kernel keeps memory in structures called slabs, and keeps pools of these. If you do cat /proc/buddyinfo Node 0, zone DMA 9078 10398 3135 838 164 14 0 0 2 Another way to get memory report is to run "echo m > /proc/sysrq-trigger" and look into syslog for a report about kernel memory usage. You will see how many slabs of each order you have. 9078 of order 1 slabs (4kb), 10398 of order 2 slabs (8kb) ... 2 order 9 slabs (1MB). If a slab of lower order is needed it may split a higher order one (e.g. if the kernel wants a 4k slab it may split an 8k slab into two). Lots of kernel allocations and you may run out of the higher order slabs. What worked for me for trigerring this condition was moving a lot of data to the Linux over SCP. There may be other causes. Now the significance of 32k is that this is where Linux stops retrying to rearrange memory to find larger slabs. I don't remember the details, but if you want to investigate look at the kernel sources, namely mm/page_alloc.c and mm/vmscan.c So the bottom line is, anytime you have an operation that needs a large buffer in kernel (chccwdev of a NIC, vmcp with --buffer, DIAG from Linux) it may fail at unexpected times. I have not found a good way to get around this but I will be interested if you find anything. In the case of VMCP what may help is if it allocated a buffer at kernel startup. At the moment it allocates it for every call, see http://lxr.free-electrons.com/source/drivers/s390/char/vmcp.c#L105 Tomas
