Re: modload: Cannot allocate memory

[jnemeth%victoria.tc.ca@localhost (John Nemeth)]

On Jun 15,  9:49am, Jean-Yves Migeon wrote:
} On 23.01.2011 05:22, Shi Jie Gung wrote:
} > Running NetBSD 5.99.44 (NETBSD_XEN3_DOMU) custom kernel on Debian Unstable, 
Xen 
} > 4.0.
} > 
} > modload failed with every kmod.
} > 
} > hp_netbsd# cd /stand/amd64/5.99.44/modules/hfs
} > hp_netbsd# modload  hfs.kmod                                                
   
} > WARNING: module error: Cannot load kernel object `hfs.kmod' error=12
} > modload: Cannot allocate memory
} > 
} > On another virtualbox machine, modload also failed with Xen Dom0 kernel, 
but 
} > works with standard NetBSD kernel.
} > 
} > I assign 1G ram to netbsd, still the same error.
} 
} IIRC, modules have a custom memory map within kernel, and code is

     Not really.  There is one call to uvm_km_alloc() with module_map
in sys/kern/subr_kobj.c.  However, in
sys/kern/kern_module.c:module_init() if module_map is NULL, then it is
set to kernel_map.  I have no idea why the kernel is throwing ENOMEM.
All the other memory allocations in the module code are bog standard
kmem_[z]alloc() calls.  It's possible that something in MD linking code
(the kernel simply allocates a chunk of memory, reads the file, and
then calls an in-kernel linker to link it) is throwing ENOMEM.

} Still, the way modules are currently loaded makes it impossible to
} distinguish one kernel version to another, as modules should be bound to
} a specific kernel rather than an machine architecture (in this case, x86).

     Modules are mapped to the architecture and the version number.
But, XEN isn't a seperate architecture.

} This leads to problem with Xen, as certain architecture-dependent
} functions (bus access routines, DMA, physical/virtual memory
} translations, ...) differ, and loading a "GENERIC" module in a Xen
} environment will ultimately lead to undefined behavior.

     True enough.  Having XEN mangle various structures/APIs causes all
sorts of problems.  One wonders at times if XEN should be a seperate
ARCH.

}-- End of excerpt from Jean-Yves Migeon