| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] rootfs as RAMDisk + Hypervisor: Cannot allocate memory
>>> On 08.10.10 at 09:38, Robyn Bachofer <r.bachofer@xxxxxxxxxxxxxx> wrote:
> Hello Jan,
>
> that's a good guess.
> I found your pasted line in mm/vmalloc.c, line 108.
> What can i do? A workaround is to change from ramdisk to nfs, but this is
> not fine.
> Or a way to "fix" this problem?
Since you posted to xen-devel (and not xen-users) I supposed you
would be able to do some work here. That's why I outlined potential
fixes (and the page table cleanup one shouldn't be more than a
couple of lines). If that's not the case, you'll need to talk someone
into doing this work for you.
Oh, actually I just thought of a possible workaround: Likely your
initrd is over 500Mb in size only in uncompressed form. If in
compressed form it's well below that size, you could either change
the compression type to anything but gzip (so that GrUB won't try
to expand it) or use "modulenounzip" instead of "module" in
grub.conf for specifying the initrd.
Jan
> 2010/10/7 Jan Beulich <JBeulich@xxxxxxxxxx>
>
>> >>> 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
|
|
|
| |
|
Home