This is the bug tracker for upstream QEMU. If you'd like to request
Ubuntu to backport some fix into their packages of QEMU, you'll need to
file it against the Ubuntu QEMU package bug tracker. Since those bugs
are also tracked in Launchpad, I'll try re-componenting this bug report
to the Ubuntu QEM
It looks like the reason QEMU's test suite passed was that the older
Ubuntu gdb didn't have a fix for LP:1901026 (support remote connection
over UNIX domain socket), so the test suite would simply skip the
offending test and never get as far as falling over the assertion
failure. After pulling vari
Further testing with the old gdb-8.1-0ubuntu3 package shows that this
isn't a regression since then, as that version fails too. I must have
been misled by the apt history.log somehow; sorry for the confusion
there.
--
You received this bug notification because you are a member of Ubuntu
Bugs, whi
Public bug reported:
This bug is a regression introduced in 8.1.1-0ubuntu1 for Bionic -- the
previous 8.1-0ubuntu3.2 gdb works fine with QEMU's gdbstub.
Reproduce:
Get the sources for QEMU 5.2.0, and build the aarch64-linux-user target. (It
looks like Bionic's QEMU is old enough that it doesn't
This bug is still valid, yes.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1163034
Title:
linux-user mode can't handle guest setting a very small RLIMIT_AS
(hangs running gnutls28, coreutils conf
On 18 September 2018 at 10:24, Dmitry Isaykin wrote:
> Public bug reported:
>
> Error log:
>
> /tmp/qemu-2.10+dfsg/util/memfd.c:40:12: error: static declaration of
> ‘memfd_create’ follows non-static declaration
> static int memfd_create(const char *name, unsigned int flags)
> ^~
>From upstream QEMU's point of view the status of this bug is "it's an
old bug report that tended to accumulate 'this seems like it's the same
as my bug' extra comments; we have fixed the underlying cause of the
original bug, so leave this one closed and file new ones with proper
reproducer instru
We don't generally mark bugs 'fix released' until the final (non-rc)
release is made.
** Changed in: qemu
Status: Fix Released => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/17
On 16 March 2018 at 10:34, Richard Henderson
wrote:
> Limit this to 16M; there does not appear to be any special
> support for this in the kernel itself, at least for i686.
>
> Fixes: https://bugs.launchpad.net/bugs/1749393
> Signed-off-by: Richard Henderson
> ---
>
> Commentary in the launchpad
There seem to be two parts to this. Firstly, with a big reserved-region,
which is the default for 32-bit-guest-on-64-bit-host, this code in
main.c:
if (reserved_va) {
mmap_next_start = reserved_va;
}
says to start trying for the next mmap address at the top of the
rese
** Summary changed:
- linux-user mode can't handle guest setting RLIMIT_AS (hangs running gnutls28
configure check code)
+ linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs
running gnutls28, coreutils configure check code)
** Tags added: linux-user
--
You received this
v2 of the patch (https://lists.gnu.org/archive/html/qemu-
devel/2017-11/msg01199.html) has been accepted upstream, though it isn't
in master yet.
** Tags added: linux-user
** Changed in: qemu
Status: New => In Progress
--
You received this bug notification because you are a member of Ub
We think we've fixed our linux-user threading issues, so if there are
still problems as of qemu-2.11 or later, please raise a fresh bug report
with repro instructions.
** Changed in: qemu
Status: Confirmed => Fix Committed
--
You received this bug notification because you are a member of
I was able to reproduce this failure with QEMU 2.5, and the code runs OK
under QEMU current master, so I think this is fixed by the
threading/signal handling bugfixes we've done between then and now. I'm
going to close this as will-be-fixed-in-2.11 (though it's quite possible
it's already fixed in
Yes it did.
** Changed in: qemu
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/1319100
Title:
qemu-arm-static bug in signal handling causes mono and jav
Just a note that the udev rules change from comment 6 seems to be
necessary to reliably get an image booted under QEMU to bring up a getty
on the serial console. What seems to happen without it is that udevd
spends all its time running copies of 'readlink', and it doesn't get
around to telling syst
I finally got round to looking into why the test case from comment #27
worked on x86-64 guests and i386-guest-on-i386-host but not on arm-
on-x86-64. This turns out to be a wrong structure definition which meant
we weren't handling the 32-bit-guest-on-64-bit-host combinations
correctly. I've sent a
In the upcoming QEMU 2.7 we've removed the abort() call in this code
path, and instead will print an error message which hopefully is clearer
at suggesting to users where they've gone wrong rather than implying
that this is a QEMU bug:
==
qemu-system-arm: Trying to execute code outside RAM or
OK, so the behaviour you saw is expected since we didn't fix 32-bit
hosts until a bit later; but they should both be fixed now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hang
Thanks for that test case; unfortunately it works fine for me (both with
current git master and with commit b66e10e4c9ae7384).
Can you tell me what host machine you're running this on, and in
particular whether it is 32 bit or 64 bit? Commit b66e10e4c9ae7384 will
fix this hang for x86-64 (64-bit i
Please provide exact reproduction instructions -- I need enough
information that I can completely replicate your setup and what you're
doing: exactly how you've set up any chroot or whatever other guest
setup you have, what cmake command you're running, and so on.
--
You received this bug notific
Please can you (a) double check that you're definitely running the
correct new QEMU and (b) provide exact reproduction instructions so I
can investigate the hang.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.n
We've now overhauled the signal handling code in upstream QEMU, and it
has its own implementation of the basic idea in the patch from comment 1
(which is "don't let the guest block SIGSEGV").
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because y
Recent changes to QEMU's handling of signals fix this hang trying to run
mono under QEMU; they should be out in QEMU 2.7.
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https:/
I'm going to mark this bug as 'fix committed', because changes which
should fix both the cmake and the git hang are now in QEMU git master.
If people have test cases for things which still fail on current git
master, please open fresh bugs for them.
** Changed in: qemu
Status: Confirmed =>
Thanks for that report of a hang running git. I've been able to identify and
fix the bug (it is a different problem to the issue that was causing cmake to
hang) and have sent a patch:
http://patchwork.ozlabs.org/patch/631708/
That fix will hopefully make it into QEMU 2.7.
--
You received this b
I was hoping for a "run this command" level of reproducer :-)
Alternatively, if anybody's conveniently able to build and test a new QEMU with
whatever was failing for them, you can try the git branch
https://git.linaro.org/people/peter.maydell/qemu-arm.git sigrace-fixes
--
You received this bug
Does anybody have a reliable reproduce case for this bug? I have some
patches I'd like to test which I think should fix it, but I cannot get
the test case attached in comment #10 to hang at all, even without the
fixes.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
Ah, it looks like Colin did just cherry pick the fix for this bug; from
the backport .deb's changelog:
+dnsmasq (2.68-1ubuntu0.1ppa1) trusty; urgency=medium
+
+ * Cherry-pick from 2.73:
+- Correctly sanitise DNS header bits in answer when recreating query for
+ retry.
+
+ -- Colin Watson
This post to the dnsmasq-discuss list:
http://lists.thekelleys.org.uk/pipermail/dnsmasq-
discuss/2015q2/009575.html suggests that the bug has been fixed in a
later version of dnsmasq and should be fairly easy to backport.
--
You received this bug notification because you are a member of Ubuntu
B
I wrote: "PS: it's possible that that commit doesn't actually fix the
underlying kernel crash, it just means that rr isn't triggering it any more,
and that if you modified EFLAGS via the ptrace interface rather than r11 you'd
get the crash back again."
but looking at the kernel I think that is i
PS: it's possible that that commit doesn't actually fix the underlying
kernel crash, it just means that rr isn't triggering it any more, and
that if you modified EFLAGS via the ptrace interface rather than r11
you'd get the crash back again.
--
You received this bug notification because you are a
I've now completed the kernel git bisect. git bisect says the commit
which fixed this issue is 29722cd4ef666705b2eda1c3ba44435488e509eb
("x86/asm/entry/64: Save R11 into pt_regs->flags on SYSCALL64
fastpath").
This fits in with the discovery on the rr side that the rr commit which
started causing
I retried with a workaround for the rr bug I described in "caveat (2)"
and the kernel still does not lockup, so I am now confident that this
bug is not present in the upstream kernel.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
htt
I tested with linux-headers-4.4.0-040400 / linux-
headers-4.4.0-040400-generic / linux-image-4.4.0-040400-generic
4.4.0-040400.201601101930. The kernel lockups did *not* reproduce.
Two caveats:
(1) I did get this kernel warning in the log:
Jan 21 18:00:08 e104462 kernel: [ 171.577000] --
No, I don't think this was associated with a kernel upgrade, though it's
hard to say for certain as I hadn't run the test suite in some months. I
suspect it's more that rr's test suite got more complex and included
some stress tests that reveal pre-existing kernel bugs.
I will test the upstream ke
Public bug reported:
Running the 'rr' make check on Ubuntu Trusty causes the machine to
become unusable because the kernel crashes. (rr build-and-make-check
instructions: https://github.com/mozilla/rr/wiki/Building-And-
Installing)
This is 3.13.0-74-generic #118-Ubuntu for x86_64.
This is rr bug
#10: if that's your entire command line then that's expected behaviour,
and is saying "we just executed a pile of zeros and fell off the end of
RAM". You need to supply a kernel to run.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
h
Recent patchseries which I think ought to be a proper fix for this bug:
https://lists.gnu.org/archive/html/qemu-devel/2015-09/msg01388.html
It does need some more work to address review comments but it's sound in
principle.
--
You received this bug notification because you are a member of Ubuntu
I think it is in theory supposed to work, but possibly in practice it
doesn't...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1463172
Title:
destination arm board hangs after migration from x86 sou
Public bug reported:
The output of "pkg-config --static --libs gnutls" is the following:
-R/usr/lib/x86_64-linux-gnu -lgnutls -lgcrypt -lgpg-error -ltasn1 -lz
-lp11-kit
However, gcc doesn't understand the "-R" option, so you can't pass the
pkg-config output as a set of gcc command line options t
** Changed in: qemu
Status: New => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1349277
Title:
AArch64 emulation ignores SPSel=0 when taking (or returning from) an
exception
Patch which seems to at least make the test case work (tested with
i386-on-i386 linux-user): http://patchwork.ozlabs.org/patch/378769/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1042388
Title:
qe
On 9 August 2014 07:15, Erik de Castro Lopo <1042...@bugs.launchpad.net> wrote:
> Unfortunately the test case @pittit submitted is far harder to support
> than the original test case. In this case the timer_create() syscall
> gets passed pointers to functions and data in the target's address space
Well, it won't make anything any worse, so it's your call based on how
much it actually improves your failure rate I guess.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1350435
Title:
tcg.c:1693: t
I think it's likely to happen eventually; it depends rather on the
balance between this and other work priorities (at least if it's going
to be Linaro doing the work). Regardless, I'm not taking hacky
workarounds like this into mainline (hacks are hard to get out once you
let them in, and they remo
That patch is not in mainline because it's an appalling hack. If we care
about multi-threaded guests we need to fix them properly, not paper over
the issues by constraining multiple threads to one CPU in the hopes the
race conditions don't bite us so often.
--
You received this bug notification b
Most rececnt qemu-devel discussion and a promising looking approach (ie it
would work whereas my idea linked from comment #14 would not):
http://lists.gnu.org/archive/html/qemu-devel/2014-02/msg04569.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is sub
What cmake is doing is an entirely legitimate and well-recognized Unix
idiom for converting signals into effects on filedescriptors for
select(), and there's no reason for them to change it. This is
absolutely a bug in QEMU, it's just one that's not easy for us to fix.
(Using socketpair would not h
No; this is a a complicated issue to fix that basically requires a
significant restructuring of the linux-user code. Nobody's done that yet
and as far as I know nobody's said they plan to do so either.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
On 9 May 2014 09:14, Riku Voipio wrote:
> Hi Craig,
>
> On Wed, May 07, 2014 at 03:53:38PM +0100, Peter Maydell wrote:
>> Original 2011 patch:
>> http://lists.gnu.org/archive/html/qemu-trivial/2011-12/msg00025.html
>
>> (hitting the 'reply' button gets us b
On 7 May 2014 15:34, Paul Jimenez <1317...@bugs.launchpad.net> wrote:
> Bug description:
> Using the latest version of qemu-user-static from trusty, 2.0.0+dfsg-
> 2ubuntu1.
>
> Reported to qemu and patch submitted long ago by the guy who wrote
> http://www.devttys0.com/2011/12/qemu-vs-sstrip
On 7 May 2014 15:48, Peter Maydell wrote:
> On 7 May 2014 15:34, Paul Jimenez <1317...@bugs.launchpad.net> wrote:
>> Bug description:
>> Using the latest version of qemu-user-static from trusty, 2.0.0+dfsg-
>> 2ubuntu1.
>>
>> Reported to qemu and
Doing this only for aarch64 targets seems like a bad idea to me -- this
isn't an aarch64 specific issue. QEMU needs SIGSEGV to go to its own
handler (so we can unprotect pages we've marked as read-only in order to
catch guest writes to them so we can throw away invalidated translated
code), and tha
Actually, the interesting bit of the stack trace starts just below where
you cut it off, because object_initialize_with_type() is just asserting
that it wasn't called with a NULL pointer, so what we really want to
know is what the caller was...
--
You received this bug notification because you ar
Does this patch fix this issue?
http://patchwork.ozlabs.org/patch/309529/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1256546
Title:
qemu-s390x-static: segmentation fault entering chroot
To manag
I suspect this is a NULL pointer access that happens in procps where it
isn't handling an error path that it's not expecting somehow (either a
syscall we're not implementing, or perhaps something like /proc not
being mounted in your chroot environment, or something about qemu's
emulation of some fi
The backtrace indicates that this is a multithreaded application. These
won't work reliably under qemu-user : they tend to crash, as you have
found.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/124699
Regarding bug 1042388, those are the posix timer syscalls, and I guess
they've just been around long enough that apt expects them to exist.
Anyway, we should just implement them in QEMU.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Summary changed:
- gnutls28 fails to build from source in armhf
+ linux-user mode can't handle guest setting RLIMIT_AS (hangs running gnutls28
configure check code)
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
B
Actually, assuming the guest ARM glibc doesn't have the printf() bug the
code is testing for, we shouldn't take the SIGSEGV anyway, so that's a
red herring. The actual problem here is the setrlimit().
The conftest.c test case works by using rlimit to limit the address
space. This generally doesn't
> Of course, qemu-keymaps coming from linaro may not be a problem if it
would include the en_us map :)
It does include en_us, it's just putting all the keymaps in a different
directory to the one qemu is looking for (/qemu-linaro/ vs /qemu/)
--
You received this bug notification because you are
Well, you can try, but I don't think it is very likely to help. The
patch is a hacky workaround for select() in particular, not for the
entire class of hangs.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/b
cmake bug: LP:955379.
sketch of how to fix signal races:
http://lists.gnu.org/archive/html/qemu-devel/2011-12/msg00384.html
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1129571
Title:
libreoffice
John: it would be interesting to try to determine whether that hang has
the same root cause as the cmake and boehm-gc hangs, ie the thing that
is supposed to post the futex is a signal handler whose signal comes in
either just before or during the syscall [either way, the emulated code
for the hand
John: you might also like to try with this patchset applied:
http://lists.nongnu.org/archive/html/qemu-devel/2013-02/msg04207.html
as that fixes one category of races. There are still other races that can cause
segfaults and other problems (as the cover letter describes) but it's possible
this pa
Thanks for the patch. John, since you're going to be doing more QEMU work in
future I'd encourage you to go through the process of submitting it to
upstream's mailing list and shepherding it through the patch review process.
Upstream's patch submission guidelines are here:
http://wiki.qemu.org
The actual command from the build log:
/usr/lib/jvm/java-6-openjdk-armhf/bin/java -cp
".:../../unxlngr.pro/class:/usr/lib/jvm/java-6-openjdk-armhf/jre/lib/rt.jar:.:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin
/jaxp.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/juh.jar:/bu
Well, the first step would be to provide a reasonably tractable set of
reproduce instructions (at minimum, something like "do this to set up a
chroot, then in the chroot run this command and watch it SIGILL".) Also
checking it still repros on 1.4.0 (just released) would be nice (though
I don't thin
(ancient distro packaging bug so never valid for QEMU upstream itself;
marking Invalid there)
** Changed in: qemu
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/39
Closing as invalid for QEMU because it's an Incomplete bug against an
ancient QEMU version.
** Changed in: qemu
Status: Incomplete => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/5714
qemu-system-arm -M versatilepb -kernel u-boot.bin
[...]
Trying to execute code outside RAM or ROM
This almost always means that you tried to execute a guest binary which
wasn't for the VersatilePB. Without more info about exactly what this
u-boot.bin file was this bug report can't progress any fur
On 4 December 2012 11:21, Janne Karhunen <955...@bugs.launchpad.net> wrote:
> And what would break if we make poll timeout instantly in case there are
> signals pending and restart the given syscall after handlers run?
If there are signals pending in the host kernel poll will *already*
return imme
Yes. You can never shut the window completely trying to do it that way,
which is why you need fix the problem properly instead.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hang
On 3 December 2012 21:20, Alexander Graf wrote:
> Could you please try and see if this patch makes a difference?
>
> http://repo.or.cz/w/qemu/agraf.git/patch/489924aa0115dc6cfcd4e91b0747da4ff8425d1f
I think the answer will turn out to be "no" (though it's worth
testing anyway), because the syscal
** Changed in: qemu
Status: New => Confirmed
** Changed in: qemu-linaro
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with qemu-arm-
On 1 December 2012 10:29, Janne Karhunen <955...@bugs.launchpad.net> wrote:
>> this blocks forever, because the thing that would wake it up is the
> signal handler writing to the pipe we're selecting on, but we will never
> run the signal handler until select exits
>
> Duh, makes sense, have to thi
Actually I just managed to interact with a hung qemu under a debugger
sufficiently to confirm what is happening here.
CMake's code for running child processes (in kwsys/ProcessUNIX.c) does this:
"On UNIX, a child process is forked to exec the program. Three output pipes
are read by the parent pr
I'll take the bigger usecase, please. It's pretty hard to debug race
conditions that don't manifest often enough to let you do useful
logging.
>From the time or two I caught it hanging, it looks like qemu is sleeping in
>poll, and there's a zombie child process. I wonder if what's happening is th
That test case seems to have very weak reproducibility -- I think I saw
a hang perhaps once in 30+ runs. That's not really usable for debugging,
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/
On 28 November 2012 08:42, Janne Karhunen <955...@bugs.launchpad.net> wrote:
> Peter, I have qemu chrootable test case under which you could fire one
> command to hit the bug reliably. Only issue is, are you willing to take
> a peek at 100M extractable tarball? If not, I'll try to create a smaller
On 25 November 2012 20:40, Tim Penhey wrote:
> Peter, if you try to run the cmake file for lp:unity you should hit it.
I'm afraid that's way too little detail. Assume I know nothing about
launchpad, cmake or unity, and give me a set of instructions I
can run on a machine which isn't necessarily r
If you can provide a simple straightforward reproduce case that would be
useful.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/955379
Title:
cmake hangs with qemu-arm-static
To manage notifications
http://lists.gnu.org/archive/html/qemu-devel/2012-05/msg03012.html is my
current proposed long-term upstream-acceptable approach to TrustZone
handling.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/104
This bug doesn't seem to have any reproduction instructions, and at
least some of the command lines seem to be asking for 512MB of RAM on a
versatilepb model, which isn't supported and will crash the guest
unhelpfully. I'm marking it 'incomplete' for QEMU...
** Changed in: qemu
Status: New
** 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/928432
Title:
spice backend fails to build on i386 with -Werror
To manage notif
** 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/956799
Title:
qemu: Unsupported syscall: 336
To manage notifications about this
I've committed the fix for missing ppoll on the basis that it is the bug
you've reported. I suspect it's not the bug you actually care about --
if the sigill still persists please file a new bug report, preferably
with a reasonably easy to reproduce test case...
** Changed in: qemu-linaro
Mil
** Changed in: qemu-linaro
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/696794
Title:
eglibc lacks getcontext() on ARM
To manage notifications about this bug go to:
h
This time for sure!
** Changed in: qemu-linaro
Status: Triaged => Fix Committed
** Changed in: qemu-linaro
Milestone: None => 2012.04
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/928432
ppoll implementation:
http://patchwork.ozlabs.org/patch/147225/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/956799
Title:
qemu: Unsupported syscall: 336
To manage notifications about this bug go
...although glibc should fall back to its own implementation if there's
no ppoll syscall so probably the underlying crash is some other issue.
It would be useful if you could manage to extract the actual failing
binary as a manageable test/repro case...
--
You received this bug notification becau
Hmm, this may be as easy as changing the line in linux-user/arm/syscall_nr.h
that reads
/* 336 for ppoll */
to say
#define TARGET_NR_ppoll 336
instead...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubu
Oops. My test of this was on a 32 bit oneiric system, where configure now
disables spice completely. Retested and reproduced on a precise-i386 chroot,
and sent a patch upstream:
http://patchwork.ozlabs.org/patch/147207/
--
You received this bug notification because you are a member of Ubuntu
Bu
** 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/928432
Title:
spice backend fails to build on i386 with -Werror
To manage notif
** 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
** 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/928555
Title:
qemu-linaro FTBFS on arm because of deprecated gthread calls
To m
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: N
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.
https://bugs.l
Upstream says that apparently Spice does work on 32 bit hosts now (the
FAQ is out of date). I've put the necessary compilation warning fixes
into qemu-linaro pending them being committed upstream.
Steve: this means you'll want to unwind the 'don't build qemu-kvm-spice
on i386' change in the packag
1 - 100 of 235 matches
Mail list logo
