|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] rootfs as RAMDisk + Hypervisor: Cannot allocate memory
>>> On 07.10.10 at 13:21, Robyn Bachofer <r.bachofer@xxxxxxxxxxxxxx> wrote:
> [hostname ~]# modprobe iscsi_tcp
> Warning: at mm/vmalloc.c:108 vmap_page_range_noflush+0x22/0x2e2()
> Hardware name: IBM eServer BladeCenter HS21 -[7995A1G]-
> Pid: 2344, comm: modprobe Tainted: C W 2.6.32.23-pvops #2
> Call Trace:
> [<ffffffffxxxxxxxx>] ? warn_slowpath_common
> [<ffffffffxxxxxxxx>] ? vmap_page_range_noflush
> [<ffffffffxxxxxxxx>] ? map_vm_area
> [<ffffffffxxxxxxxx>] ? __vmalloc_area_node
> [<ffffffffxxxxxxxx>] ? load_module
> [<ffffffffxxxxxxxx>] ? do_page_fault
> [<ffffffffxxxxxxxx>] ? sys_init_module
> [<ffffffffxxxxxxxx>] ? sys_call_fastpath
> ---[ end trace xxxxxxxx ]---
> FATAL: Error inserting iscsi_tcp
> (/lib/modules/2.6.32.23-pvops/kernel/driver/scsi/iscsi_tcp.ko): Cannot
> allocate memory
Can you match this to a source line? Namely, if it maps to
if (WARN_ON(!pte_none(*pte)))
in vmap_pte_range(), it would suggest there's some page table
cleanup missing after the initrd is no longer needed at its original
location (with the sizes you provided its quite certain that it runs
into the virtual address range used for modules). For native,
there's no mapping of the initrd following the kernel image (and
honestly I don't know why Xen specifies it as being mapped
there - if you had one of about 2G in size, Xen would refuse to
load your Dom0 altogether; perhaps time for another ELF note
indicating that the kernel can do without the initrd being
mapped into virtual space), so Xen kernels need to clean up
the left over page table entries, and apparently the pv-ops
code didn't inherit the respective XenoLinux bits.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|