[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |