** Changed in: qemu-linaro
Status: Fix Committed = Fix Released
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/906922
Title:
qemu-arm-static chroots give copious memory errors when setting up
I've committed to qemu-linaro the default-to-R-on-64-bit-hosts patch (so
Steve, you'll want to drop it from the packaging) and also the followup
patch which fixes the bash issues Loic lists. These will both be in
qemu-linaro 2011.03 (due this Thursday!)
** Changed in: qemu-linaro
Status:
Yes, I've seen the bash failures too. They should be fixed by
http://patchwork.ozlabs.org/patch/144476/ which I'm intending to put
into qemu-linaro for next week's release.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
So currently all of the armel PPA buildds that are in auto-mode on
production launchpad are using qemu-arm-static to run their build
chroots.
On staging I saw a dramatic decrease in the number of OOM-type failures
and catastrophic mmap() failures, with a slight uptick in sig11s (on
different
In my case, I'm using qemu-arm-static from precise against an unstable Debian
armel chroot and that used to work fine but now I get:
bash: xmalloc: ../bash/variables.c:1969: cannot allocate 28 bytes (24576 bytes
allocated)
when starting bash; if I run sh (which is dash) I don't have the problem.
On Fri, Mar 09, 2012 at 08:35:44PM -, Loïc Minier wrote:
In my case, I'm using qemu-arm-static from precise against an unstable Debian
armel chroot and that used to work fine but now I get:
bash: xmalloc: ../bash/variables.c:1969: cannot allocate 28 bytes (24576
bytes allocated)
when
I'm not sure. I don't have a feel for whether it has fixed more cases
than it has broken or vice-versa, I'm afraid.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/906922
Title:
qemu-arm-static
This workaround turns out to cause some regressions in other cases, for example:
http://comments.gmane.org/gmane.comp.emulators.qemu/138180
which seems to be because when we use -R (either explicitly or
implicitly because of this patch) we tend to map the guest stack
immediately above the guest
Nick, I think you're certainly exercising qemu-arm-static more than
anyone else at the moment with the autobuilder prototyping. Are you
seeing different regressions now as a result of this patch? Should we
consider reverting this patch until there's a clean upstream solution?
--
You received
On Fri, Mar 02, 2012, Peter Maydell wrote:
This workaround turns out to cause some regressions in other cases, for
example:
http://comments.gmane.org/gmane.comp.emulators.qemu/138180
which seems to be because when we use -R (either explicitly or
implicitly because of this patch) we tend to
This bug was fixed in the package qemu-linaro - 1.0.50-2012.01-0ubuntu4
---
qemu-linaro (1.0.50-2012.01-0ubuntu4) precise; urgency=low
* New patch, 0001_linux-user-reserve-4GB-of-vmem-for-32-on-64, from
http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg01697.html; fixes
** Changed in: qemu-linaro (Ubuntu)
Assignee: (unassigned) = Loïc Minier (lool)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/906922
Title:
qemu-arm-static chroots give copious memory errors
Has anyone here or upstream got a good patch to do this? We need a
workaround as soon as possible, and my initial hacky attempts don't seem
to have worked.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Peter, is there a chance of regressing important and currently working
functionality by setting QEMU_RESERVED_VA=0xf700 as the default in
qemu-linaro in Ubuntu? If not, any reason for not doing it upstream
until a better mmap implementation appears?
--
You received this bug notification
Oh, and also you (probably) don't want to set the environment variable
for running 64 bit guests as I suspect it will unnecessarily restrict
the total amount of RAM that they can use.
Re: doing it upstream: the current status of the discussion is here (plus
followups):
Loic: You don't want to do it on 32 bit platforms, but for 64 bit hosts
I think it should be OK.
The only thing that I can think of that is likely to break is if the
user has a ulimit -v setting which we would now be breaching.
--
You received this bug notification because you are a member of
I don't think there's a good way to put env vars into the binfmt glue; I
think we'd be better off patching it into qemu itself the way Peter says
upstream is considering.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Steve: if this can be worked around with the QEMU_RESERVED_VA
environment variable, then is there any straightforward place to put
this (such as in the binfmt glue) for right now? I wonder if this could
be worked around in the packaged version easily.
--
You received this bug notification
** Attachment added:
buildlog_ubuntu-precise-armel.ant_1.8.2-4build1_FAILEDTOBUILD.txt.gz
https://bugs.launchpad.net/bugs/906922/+attachment/2641337/+files/buildlog_ubuntu-precise-armel.ant_1.8.2-4build1_FAILEDTOBUILD.txt.gz
--
You received this bug notification because you are a member of
Er sorry, of course the buildd was in a precise chroot, not a Hardy one.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/906922
Title:
qemu-arm-static chroots give copious memory errors when setting
Matthias, could this be related to the memory mapping issues previously
identified on ARM that affect Java? If so, can you explain what the
issue is so that we can get this fixed in qemu-linaro?
** Changed in: qemu-linaro (Ubuntu)
Assignee: (unassigned) = Matthias Klose (doko)
** Also
Hmm. So I was going to file another bug about a binutils build on
precise running out of ptys, but on osageorange's oneiric-armel chroot,
it exhausts virtual memory:
g++ -DHAVE_CONFIG_H -I. -I../../gold -I../../gold
-I../../gold/../include -I../../gold/../elfcpp
The same thing happened to me with bzr: precise build using 0.15.91 hit
max open files limit, but oneiric build using 1.0 did the following:
gcc -pthread -fno-strict-aliasing -g -O0 -Wall -Wstrict-prototypes -g
-O2 -fPIC -I/usr/include/python2.7_d -c bzrlib/_dirstate_helpers_pyx.c -o
so this triggers with the first alloc; I don't think that has something
to do with the current 2GB limit
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/906922
Title:
qemu-arm-static chroots give
building the test case from bug 861296:
(oneiric-armel)doko@osageorange:~/tmp$ gcc -g mmap-test.c
(oneiric-armel)doko@osageorange:~/tmp$ ./a.out
Couldn't allocate the heap: 32Mb
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
An untested workaround you could try: arrange to set the environment
variable QEMU_RESERVED_VA=0xf700 so the qemu in the chroot can see
it.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/906922
double-checked that this symptom is the same with both 1.0 and 0.15.91,
so yes, it doesn't seem related to the 2GB limit that affects java
elsewhere - even though the behavior between 1.0 and 0.15.91 is
different for bzr and binutils.
** Changed in: qemu-linaro (Ubuntu)
Assignee: Matthias
Peter, I can confirm that export QEMU_RESERVED_VA=0xf700 fixes this
for Matthias's test case.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/906922
Title:
qemu-arm-static chroots give copious
Right, so this is really down to qemu not being very good at handling
mmap() in the 32-bit-guest-on-64-bit-host case -- it tends to fail
mmap() even when there's more address space available because it hasn't
managed to get the host kernel to allocate it within the 32-bit region
of the address
29 matches
Mail list logo
