[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] rootfs as RAMDisk + Hypervisor: Cannot allocate memory


  • To: Jan Beulich <JBeulich@xxxxxxxxxx>
  • From: Robyn Bachofer <r.bachofer@xxxxxxxxxxxxxx>
  • Date: Fri, 8 Oct 2010 09:38:32 +0200
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Fri, 08 Oct 2010 00:39:24 -0700
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ngPGopDXoKXQkjqdE6vX+U9Z+k/53VehqXNAz2nbjg6N5y+r1I2QOgaeZgTzqS8ld5 ZIyppdg67VLjL+VrmxVSFQ60jy5zRtw/v0k9tpf+Fcj4KFVra7PaXYHrvst8IuwmjucS peEQVCMX3Cq503uGCMJXtApS3gQsrNIighD30=
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>

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?

Robyn


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




--
Robyn Bachofer

Pearl-S.-Buck-Str. 12
D-73037 Göppingen
Telefon: +49 (0) 7161 4018708
Mobil: +49 (0) 176 49230082
E-Mail: r.bachofer@xxxxxxxxxxxxxx
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.