[Bug 1924231] Re: Getting "qemu: uncaught target signal 11 (Segmentation fault)" when the installing "libc-bin" which "wget" depends on.

[Peter Maydell]

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 QEMU package...


** Project changed: qemu => qemu (Ubuntu)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1924231

Title:
  Getting "qemu: uncaught target signal 11 (Segmentation fault)" when
  the installing "libc-bin" which "wget" depends on.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1924231/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908063] Re: gdb-multiarch 8.1.1-0ubuntu1 regression: assertion failure or internal error when connecting to QEMU aarch64 gdbstub

[Peter Maydell]

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 various old binaries out of my backups to test
I'm forced to conclude that I was simply misremembering by-hand use of
the gdbstub working and I must not have used it as recently as I'd
thought. So this is a bug, but not a regression.

A possible set of commits for a cherry-picked fix would be
c8ec2f334c3751c28d5f and 4ef0bef68cfc777e59156fce1 (which together
remove the hard-coded limit on register size and thus also the
assertion), but the former is not a completely trivial patch. I haven't
attempted such a cherry-pick to see if it works.

A workaround is to tell QEMU not to emulate SVE (eg with "-cpu
max,sve=off" -- it is the large SVE vector registers which trigger the
problem.


** Summary changed:

- gdb-multiarch 8.1.1-0ubuntu1 regression: assertion failure or internal error 
when connecting to QEMU aarch64 gdbstub
+ gdb-multiarch 8.1.1-0ubuntu1: assertion failure or internal error when 
connecting to QEMU aarch64 gdbstub

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908063

Title:
  gdb-multiarch 8.1.1-0ubuntu1: assertion failure or internal error when
  connecting to QEMU aarch64 gdbstub

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1908063/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908063] Re: gdb-multiarch 8.1.1-0ubuntu1 regression: assertion failure or internal error when connecting to QEMU aarch64 gdbstub

[Peter Maydell]

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, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908063

Title:
  gdb-multiarch 8.1.1-0ubuntu1 regression: assertion failure or internal
  error when connecting to QEMU aarch64 gdbstub

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1908063/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908063] [NEW] gdb-multiarch 8.1.1-0ubuntu1 regression: assertion failure or internal error when connecting to QEMU aarch64 gdbstub

[Peter Maydell]

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 provoke this gdb error.)

Run
 qemu-aarch64 -g 1234 path/to/some/aarch64/binary

In another terminal, start gdb-multiarch. At the (gdb) prompt, type
"target remote :1234". GDB will dump core:

(gdb) target remote :1234
Remote debugging using :1234
Recursive internal problem.
Aborted (core dumped)

You can see a variant of this also in the QEMU test suite with "make -C
your-qemu-build-dir check-tcg", where the error message includes an
assertion failure:

[...]

timeout 60  
/home/petmay01/linaro/qemu-from-laptop/qemu/tests/guest-debug/run-test.py --gdb 
/usr/bin/gdb-multiarch --qemu 
/home/petmay01/linaro/qemu-from-laptop/qemu/build/aarch64-linux/qemu-aarch64 
--qargs "" --bin sha1 --test 
/home/petmay01/linaro/qemu-from-laptop/qemu/tests/tcg/multiarch/gdbstub/sha1.py 
>  run-gdbstub-sha1.out
/build/gdb-veKdC1/gdb-8.1.1/gdb/regcache.c:122: internal-error: void* 
init_regcache_descr(gdbarch*): Assertion `MAX_REGISTER_SIZE >= 
descr->sizeof_register[i]' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

This is a bug, please report it.  For instructions, see:
.

Aborted (core dumped)
/home/petmay01/linaro/qemu-from-laptop/qemu/tests/tcg/multiarch/Makefile.target:51:
 recipe for target 'run-gdbstub-sha1' failed

** Affects: gdb (Ubuntu)
 Importance: Undecided
 Status: New

** Affects: gdb (Ubuntu Bionic)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908063

Title:
  gdb-multiarch 8.1.1-0ubuntu1 regression: assertion failure or internal
  error when connecting to QEMU aarch64 gdbstub

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1908063/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1163034] Re: linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code)

[Peter Maydell]

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 configure check code)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1163034/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Qemu-devel] [Bug 1793183] [NEW] apt source --compile qemu-system-x86 fails on last ubuntu 18.04.1

[Peter Maydell]

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)
> ^~~~
> In file included from /usr/include/x86_64-linux-gnu/bits/mman-linux.h:115:0,
>  from /usr/include/x86_64-linux-gnu/bits/mman.h:45,
>  from /usr/include/x86_64-linux-gnu/sys/mman.h:41,
>  from /tmp/qemu-2.10+dfsg/include/sysemu/os-posix.h:29,
>  from /tmp/qemu-2.10+dfsg/include/qemu/osdep.h:104,
>  from /tmp/qemu-2.10+dfsg/util/memfd.c:28:
> /usr/include/x86_64-linux-gnu/bits/mman-shared.h:46:5: note: previous 
> declaration of ‘memfd_create’ was here
>  int memfd_create (const char *__name, unsigned int __flags) __THROW;
>  ^~~~
> /tmp/qemu-2.10+dfsg/rules.mak:66: recipe for target 'util/memfd.o' failed

This is fixed in upstream QEMU in commit 75e5b70e6b5dcc, which is in
QEMU 2.12.0. If Ubuntu are interested in fixing this they can backport
that to the QEMU they are shipping, or alternatively move forward to 2.12.

thanks
-- PMM

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1793183

Title:
  apt source --compile qemu-system-x86 fails on last ubuntu 18.04.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/qemu/+bug/1793183/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

>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 instructions if necessary".

LP: #1764555 was closed because it was "bug submitter was still running
the old QEMU version and didn't realise it".

-- 
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 about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1740219] Re: static linux-user ARM emulation has several-second startup time

[Peter Maydell]

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/1740219

Title:
  static linux-user ARM emulation has several-second startup time

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1740219/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1749393] Re: [PATCH] linux-user: Allocate extra space for brk in PIE executable

[Peter Maydell]

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 bug suggests 128M gap for x86_64, but that's
> somewhat irrelevant to the given i686 test case.  There's certainly nothing
> in the referenced kernel patch that does any more than we had been doing
> without this patch.

I think the 128MB is enforced by mmap_base() in arch/x86/mm/mmap.c:
since x86-64 sots HAVE_ARCH_UNMAPPED_AREA_TOPDOWN, mmap_base is the
highest address in memory where mmap is permitted, and mmap_base()
enforces that it goes at least 128MB below the bottom of the stack
(accounting for rlimit stack size requirements also). Since
binfmt_elf() loads ELF segments via mmap this means that they won't
go too close to the stack. (The commit a87938b2e246 ensures the
gap is honoured by using the full binary size when it does the first
mapping so that mmap picks an address that is sufficiently before the
end of the mmap region for everything to fit.)
The kernel also uses ELF_ET_DYN_BASE to ensure that PIE programs
themselves get loaded clear of the ELF interpreter, which we
don't have any equivalent of (so you can see that different values
of -R result in either the interpreter or the executable getting
loaded at lower addresses.)

PS: do you know what the intention of the
if (reserved_va) {
mmap_next_start = reserved_va;
}
code in linux-user/main.c is? It seems a bit odd to say "ok,
we have reserved a big region. we will start trying to mmap
outside it.", especially when that region covers the full
4G that the guest can access...

thanks
-- PMM

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1749393

Title:
  sbrk() not working under qemu-user with a PIE-compiled binary?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1749393/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1749393] Re: sbrk() not working under qemu-user with a PIE-compiled binary?

[Peter Maydell]

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
reserved section, which is typically right at the top of the guest's
address space. This means that for a PIE executable we'll try to load it
at a very high address, which then means there's no space above the data
section for the brk segment.

Secondly, for the no-reserved-region case (-R 0, or 64-on-64), we still
fail, but this time because we've chosen to mmap the dynamic interpreter
at an address just above the executable. Again, no space to expand the
data segment and brk fails.

Linux kernel commit a87938b2e246b81 message says something about there
being a guaranteed 128MB "gap" between data segment and stack on x86-64
which we're obviously not honourin; presumbably there's similar
requirements for other archs. (As an aside, is bash really happy with
only having perhaps 128MB of allocatable memory? Otherwise it really
ought to use mmap rather than brk for its allocator.)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1749393

Title:
  sbrk() not working under qemu-user with a PIE-compiled binary?

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1749393/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1163034] Re: linux-user mode can't handle guest setting a very small RLIMIT_AS (hangs running gnutls28, coreutils configure check code)

[Peter Maydell]

** 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 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 configure check code)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1163034/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1726394] Re: Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address)

[Peter Maydell]

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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1726394

Title:
  Passes through prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, address)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1726394/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

[Peter Maydell]

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 Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1350435

Title:
  tcg.c:1693: tcg fatal error

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-buildd/+bug/1350435/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1077116] Re: automoc4 segfaults when building in an armhf pbuilder on an amd64 host

[Peter Maydell]

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 2.10).


** 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/1077116

Title:
  automoc4 segfaults when building in an armhf pbuilder on an amd64 host

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1077116/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1319100] Re: qemu-arm-static bug in signal handling causes mono and java to hang

[Peter Maydell]

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 java to hang

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1319100/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1615021] Re: Unable to network boot Ubuntu 16.04 installer normally on Briggs

[Peter Maydell]

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 systemd about the presence of ttyAMA0 until after
systemd's 1m30 timeout has expired and it gives up, reporting "Timed out
waiting for device dev-ttyAMA0.device". (This happens most of the time
on an emulated QEMU CPU and at least occasionally on one running with
single-vcpu KVM, probably dependent on speed of the host hardware.)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1615021

Title:
  Unable to network boot Ubuntu 16.04 installer normally on Briggs

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1615021/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1042388] Re: qemu: Unsupported syscall: 257 (timer_create)

[Peter Maydell]

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 patch:

http://patchwork.ozlabs.org/patch/665274/

I think this should tie up the last loose end in this bug report so once
it gets into master we can close it.

-- 
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:
  qemu: Unsupported syscall: 257 (timer_create)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1042388/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1062220] Re: qemu-system-arm crashed with SIGABRT in cpu_abort()

[Peter Maydell]

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 ROM at 0x0800
This usually means one of the following happened:

(1) You told QEMU to execute a kernel for the wrong machine type, and it 
crashed on startup (eg trying to run a raspberry pi kernel on a versatilepb 
QEMU machine)
(2) You didn't give QEMU a kernel or BIOS filename at all, and QEMU executed a 
ROM full of no-op instructions until it fell off the end
(3) Your guest kernel has a bug and crashed by jumping off into nowhere

This is almost always one of the first two, so check your command line and that 
you are using the right type of kernel for this machine.
If you think option (3) is likely then you can try debugging your guest with 
the -d debug options; in particular -d guest_errors will cause the log to 
include a dump of the guest register state at this point.

Execution cannot continue; stopping here.

==

So I'm going to mark this bug as fix-committed, at least for upstream
QEMU.


** 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/1062220

Title:
  qemu-system-arm crashed with SIGABRT in cpu_abort()

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1062220/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 hangs with qemu-arm-static

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 intel) hosts, but it will only be fixed
for 32-bit intel hosts by commit 3e904d6ade7 (which also fixes this for
aarch64, arm, ppc64 and s390x hosts).

If you are using a 32-bit x86 host that would explain the failure-vs-
success that you report in comment #56. I suspect from looking at the
qemu binaries that were in your test case tarball that you are using
32-bit.

-- 
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 about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 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 about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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.net/bugs/955379

Title:
  cmake hangs with qemu-arm-static

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1285363] Re: qemu-aarch64-static segfaults

[Peter Maydell]

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 you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1285363

Title:
  qemu-aarch64-static segfaults

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1285363/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1319100] Re: qemu-arm-static bug in signal handling causes mono and java to hang

[Peter Maydell]

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://bugs.launchpad.net/bugs/1319100

Title:
  qemu-arm-static bug in signal handling causes mono and java to hang

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1319100/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 => 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/955379

Title:
  cmake hangs with qemu-arm-static

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 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 about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 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 about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/955379

Title:
  cmake hangs with qemu-arm-static

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1543185] Re: Malformed query causing timeouts due to ignored upstream queries

[Peter Maydell]

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
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1543185

Title:
  Malformed query causing timeouts due to ignored upstream queries

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1543185/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1543185] Re: Malformed query causing timeouts due to ignored upstream queries

[Peter Maydell]

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   Mon, 08 Feb 2016 15:46:48 +

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to dnsmasq in Ubuntu.
https://bugs.launchpad.net/bugs/1543185

Title:
  Malformed query causing timeouts due to ignored upstream queries

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1543185/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1543185] Re: Malformed query causing timeouts due to ignored upstream queries

[Peter Maydell]

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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1543185

Title:
  Malformed query causing timeouts due to ignored upstream queries

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1543185/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1543185] Re: Malformed query causing timeouts due to ignored upstream queries

[Peter Maydell]

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   Mon, 08 Feb 2016 15:46:48 +

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1543185

Title:
  Malformed query causing timeouts due to ignored upstream queries

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dnsmasq/+bug/1543185/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1535307] Re: running 'rr' make check causes kernel "hard LOCKUP"

[Peter Maydell]

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 impossible, since the set_flags() 
function in arch/x86/kernel/ptrace.c sanitizes eflags if set via ptrace. The 
issue fixed by 29722cd4ef66 is that setting r11 in some situations would bypass 
the sanitizing.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1535307

Title:
  running 'rr' make check causes kernel "hard LOCKUP"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1535307/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1535307] Re: running 'rr' make check causes kernel "hard LOCKUP"

[Peter Maydell]

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 member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1535307

Title:
  running 'rr' make check causes kernel "hard LOCKUP"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1535307/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1535307] Re: running 'rr' make check causes kernel "hard LOCKUP"

[Peter Maydell]

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 the test suite to deadlock the kernel is
https://github.com/mozilla/rr/commit/36ac389649e3e84caa46d64487813c018857f831
which is an R11-related change.

rr upstream have now committed
https://github.com/mozilla/rr/commit/11e67a66a2218effb9381b9ac86a2085b0f5d5d1
which is essentially working around this kernel bug. However, since
"unprivileged user can deadlock the kernel" is a local-user DoS exploit
I think the fix is still worth backporting.

I haven't attempted to analyze the kernel change to determine why the
kernel was crashing before or if you could do something more interesting
than just crash it by setting r11 to something other than 0 in the
userspace code.


** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1535307

Title:
  running 'rr' make check causes kernel "hard LOCKUP"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1535307/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1535307] Re: running 'rr' make check causes kernel "hard LOCKUP"

[Peter Maydell]

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.
https://bugs.launchpad.net/bugs/1535307

Title:
  running 'rr' make check causes kernel "hard LOCKUP"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1535307/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1535307] Re: running 'rr' make check causes kernel "hard LOCKUP"

[Peter Maydell]

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 kernel.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1535307

Title:
  running 'rr' make check causes kernel "hard LOCKUP"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1535307/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1535307] Re: running 'rr' make check causes kernel "hard LOCKUP"

[Peter Maydell]

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] [ cut here 
]
Jan 21 18:00:08 e104462 kernel: [  171.577005] WARNING: CPU: 6 PID: 14136 at 
/home/kernel/COD/linux/kernel/signal.c:2072 get_signal+0x597/0x600()
Jan 21 18:00:08 e104462 kernel: [  171.577006] Modules linked in: rfcomm bnep 
bluetooth nfsd auth_rpcgss nfs_acl nfs binfmt_misc lockd grace sunrpc fscache 
drbg ansi_cprng snd_hda_codec_hdmi intel_rapl x86_pkg_temp_thermal 
intel_powerclamp coretemp kvm_intel kvm dm_crypt irqbypass crct10dif_pclmul 
crc32_pclmul aesni_intel aes_x86_64 lrw snd_hda_codec_realtek 
snd_hda_codec_generic gf128mul glue_helper ablk_helper snd_hda_intel cryptd 
snd_hda_codec snd_hda_core snd_hwdep input_leds pl2303 snd_pcm usbserial 
snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device snd_timer 
snd 8250_fintek soundcore mei_me mei shpchp ie31200_edac lpc_ich ppdev 
edac_core serio_raw mac_hid parport_pc lp parport hid_generic usbhid hid uas 
usb_storage nouveau mxm_wmi i2c_algo_bit ttm drm_kms_helper syscopyarea 
sysfillrect sysimgblt fb_sys_fops e1000e drm ahci psmouse libahci ptp pps_core 
wmi fjes video
Jan 21 18:00:08 e104462 kernel: [  171.577037] CPU: 6 PID: 14136 Comm: 
block-z8iSdZiRK Not tainted 4.4.0-040400-generic #201601101930
Jan 21 18:00:08 e104462 kernel: [  171.577038] Hardware name: LENOVO 
32281S1/MAHOBAY, BIOS 9SKT71AUS 07/02/2013
Jan 21 18:00:08 e104462 kernel: [  171.577039]   
a495bf0f 88040afdbd20 813c8d94
Jan 21 18:00:08 e104462 kernel: [  171.577040]   
88040afdbd58 8107dba2 
Jan 21 18:00:08 e104462 kernel: [  171.577042]  88040afdbe38 
8000 88040afdbf58 880405d58000
Jan 21 18:00:08 e104462 kernel: [  171.577043] Call Trace:
Jan 21 18:00:08 e104462 kernel: [  171.577046]  [] 
dump_stack+0x44/0x60
Jan 21 18:00:08 e104462 kernel: [  171.577049]  [] 
warn_slowpath_common+0x82/0xc0
Jan 21 18:00:08 e104462 kernel: [  171.577050]  [] 
warn_slowpath_null+0x1a/0x20
Jan 21 18:00:08 e104462 kernel: [  171.577051]  [] 
get_signal+0x597/0x600
Jan 21 18:00:08 e104462 kernel: [  171.577053]  [] 
do_signal+0x37/0x6f0
Jan 21 18:00:08 e104462 kernel: [  171.577055]  [] ? 
schedule+0x35/0x80
Jan 21 18:00:08 e104462 kernel: [  171.577057]  [] ? 
do_exit+0x736/0xab0
Jan 21 18:00:08 e104462 kernel: [  171.577058]  [] ? 
__switch_to_xtra+0xe2/0x1b0
Jan 21 18:00:08 e104462 kernel: [  171.577061]  [] 
exit_to_usermode_loop+0x8c/0xd0
Jan 21 18:00:08 e104462 kernel: [  171.577062]  [] 
syscall_return_slowpath+0x4e/0x60
Jan 21 18:00:08 e104462 kernel: [  171.577064]  [] 
int_ret_from_sys_call+0x25/0x8f
Jan 21 18:00:08 e104462 kernel: [  171.577065] ---[ end trace 1c1af43c0c2249f3 
]---

but it seems to be a completely different thing from the lockup back
traces seen with the 3.13 kernel.

(2) rr complains:
1134: [FATAL 
/home/petmay01/src/rr/src/Monkeypatcher.cc:660:patch_after_exec_arch()
 errno: 0 'Success'] 
1134:  -> Failed to monkeypatch vdso: your __kernel_vsyscall() wasn't 
recognized.
1134: Syscall buffering is now effectively disabled.  If you're OK with
1134: running rr without syscallbuf, then run the recorder passing the
1134: --no-syscall-buffer arg.
1134: If you're *not* OK with that, file an issue.

which indicates that it's not happy with running under a 4.4 kernel in
some way, and the code being run won't be the same as it was under the
3.13 kernel. (I filed https://github.com/mozilla/rr/issues/1627 against
rr about that.)


** Tags added: kernel-fixed-upstream

** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1535307

Title:
  running 'rr' make check causes kernel "hard LOCKUP"

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1535307/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1535307] [NEW] running 'rr' make check causes kernel "hard LOCKUP"

[Peter Maydell]

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 https://github.com/mozilla/rr/issues/1614 (which includes
information about a Debian Jessie kernel crash initially and also the
Ubuntu crash later on in the same report), but since crashing the kernel
is a kernel bug I'm reporting that part here.

kern.log reports:

Jan 18 12:33:12 e104462 kernel: [  367.805326] [ cut here 
]
Jan 18 12:33:12 e104462 kernel: [  367.805333] WARNING: CPU: 2 PID: 4294 at 
/build/linux-_xRakU/linux-3.13.0/kernel/watchdog.c:245 
watchdog_overflow_callback+0x
9c/0xd0()
Jan 18 12:33:12 e104462 kernel: [  367.805334] Watchdog detected hard LOCKUP on 
cpu 2
Jan 18 12:33:12 e104462 kernel: [  367.805335] Modules linked in: pci_stub 
vboxpci(OX) vboxnetadp(OX) vboxnetflt(OX) vboxdrv(OX) bnep rfcomm bluetooth 
nfsd auth_rpcgss nfs_acl binfmt_misc nfs lockd sunrpc fscache dm_crypt 
snd_hda_codec_hdmi intel_rapl snd_hda_codec_realtek x86_pkg_temp_thermal 
intel_powerclamp coretemp kvm_intel snd_hda_intel snd_hda_codec kvm pl2303 
usbserial snd_hwdep snd_pcm crct10dif_pclmul crc32_pclmul snd_page_alloc 
snd_seq_midi snd_seq_midi_event snd_rawmidi aesni_intel aes_x86_64 lrw snd_seq 
gf128mul glue_helper ablk_helper cryptd snd_seq_device serio_raw snd_timer 
lpc_ich snd soundcore mei_me mei shpchp mac_hid parport_pc ppdev lp parport 
hid_generic usbhid hid usb_storage nouveau mxm_wmi i2c_algo_bit ttm 
drm_kms_helper e1000e psmouse ahci drm ptp libahci pps_core video wmi
Jan 18 12:33:12 e104462 kernel: [  367.805365] CPU: 2 PID: 4294 Comm: 
rr:async_signal Tainted: G   OX 3.13.0-74-generic #118-Ubuntu
Jan 18 12:33:12 e104462 kernel: [  367.805366] Hardware name: LENOVO 
32281S1/MAHOBAY, BIOS 9SKT71AUS 07/02/2013
Jan 18 12:33:12 e104462 kernel: [  367.805367]  0009 
8804033abc78 81724b70 8804033abcc0
Jan 18 12:33:12 e104462 kernel: [  367.805369]  8804033abcb0 
810678bd 880407798000 
Jan 18 12:33:12 e104462 kernel: [  367.805370]  8804033abde0 
 8804033abf58 8804033abd10
Jan 18 12:33:12 e104462 kernel: [  367.805372] Call Trace:
Jan 18 12:33:12 e104462 kernel: [  367.805376]  [] 
dump_stack+0x45/0x56
Jan 18 12:33:12 e104462 kernel: [  367.805379]  [] 
warn_slowpath_common+0x7d/0xa0
Jan 18 12:33:12 e104462 kernel: [  367.805380]  [] 
warn_slowpath_fmt+0x4c/0x50
Jan 18 12:33:12 e104462 kernel: [  367.805382]  [] ? 
restart_watchdog_hrtimer+0x50/0x50
Jan 18 12:33:12 e104462 kernel: [  367.805384]  [] 
watchdog_overflow_callback+0x9c/0xd0
Jan 18 12:33:12 e104462 kernel: [  367.805386]  [] 
__perf_event_overflow+0x8e/0x250
Jan 18 12:33:12 e104462 kernel: [  367.805389]  [] ? 
x86_perf_event_set_period+0xe8/0x150
Jan 18 12:33:12 e104462 kernel: [  367.805390]  [] 
perf_event_overflow+0x14/0x20
Jan 18 12:33:12 e104462 kernel: [  367.805392]  [] 
intel_pmu_handle_irq+0x1ed/0x3f0
Jan 18 12:33:12 e104462 kernel: [  367.805395]  [] 
perf_event_nmi_handler+0x2b/0x50
Jan 18 12:33:12 e104462 kernel: [  367.805397]  [] 
nmi_handle.isra.2+0x88/0x180
Jan 18 12:33:12 e104462 kernel: [  367.805399]  [] 
do_nmi+0x1c9/0x3e0
Jan 18 12:33:12 e104462 kernel: [  367.805400]  [] 
nmi+0x5a/0xbf
Jan 18 12:33:12 e104462 kernel: [  367.805402] ---[ end trace 1511edbd209fafac 
]---

followed a little later by

Jan 18 12:33:33 e104462 kernel: [  392.175012] BUG: soft lockup - CPU#1 stuck 
for 23s! [condvar_stress-:3380]
Jan 18 12:33:33 e104462 kernel: [  392.175014] Modules linked in: pci_stub 
vboxpci(OX) vboxnetadp(OX) vboxnetflt(OX) vboxdrv(OX) bnep rfcomm bluetooth 
nfsd auth_rpcgss nfs_acl binfmt_misc nfs lockd sunrpc fscache dm_crypt 
snd_hda_codec_hdmi intel_rapl snd_hda_codec_realtek x86_pkg_temp_thermal 
intel_powerclamp coretemp kvm_intel snd_hda_intel snd_hda_codec kvm pl2303 
usbserial snd_hwdep snd_pcm crct10dif_pclmul crc32_pclmul snd_page_alloc 
snd_seq_midi snd_seq_midi_event snd_rawmidi aesni_intel aes_x86_64 lrw snd_seq 
gf128mul glue_helper ablk_helper cryptd snd_seq_device serio_raw snd_timer 
lpc_ich snd soundcore mei_me mei shpchp mac_hid parport_pc ppdev lp parport 
hid_generic usbhid hid usb_storage nouveau mxm_wmi i2c_algo_bit ttm 
drm_kms_helper e1000e psmouse ahci drm ptp libahci pps_core video wmi
Jan 18 12:33:33 e104462 kernel: [  392.175054] CPU: 1 PID: 3380 Comm: 
condvar_stress- Tainted: GW  OX 3.13.0-74-generic #118-Ubuntu
Jan 18 12:33:33 e104462 kernel: [  392.175055] Hardware name: LENOVO 
32281S1/MAHOBAY, BIOS 9SKT71AUS 07/02/2013
Jan 18 12:33:33 e104462 kernel: [  392.175056] task: 880401c4b000 ti: 
8804067ca000 task.ti: 8804067ca000
Jan 18 12:33:33 e104462 kernel: [  392.175057] RIP: 0010:[]  
[] smp_call_function_many+0x26e/0x2d0
Jan 18 12:33:33 e104462 

[Bug 1062220] Re: qemu-system-arm crashed with SIGABRT in cpu_abort()

[Peter Maydell]

#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
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1062220

Title:
  qemu-system-arm crashed with SIGABRT in cpu_abort()

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1062220/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1062220] Re: qemu-system-arm crashed with SIGABRT in cpu_abort()

[Peter Maydell]

#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.
https://bugs.launchpad.net/bugs/1062220

Title:
  qemu-system-arm crashed with SIGABRT in cpu_abort()

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1062220/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/955379

Title:
  cmake hangs with qemu-arm-static

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1463172] Re: destination arm board hangs after migration from x86 source

[Peter Maydell]

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
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1463172

Title:
  destination arm board hangs after migration from x86 source

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1463172/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1463172] Re: destination arm board hangs after migration from x86 source

[Peter Maydell]

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 source

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1463172/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1478035] [NEW] pkg-config --static --libs gnutls includes an option that gcc doesn't recognize (-R)

[Peter Maydell]

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 the way that pkg-
config says you are supposed to be able to.

It seems likely to me that this -R option is an error and should be
removed.

(The pkg-config output for a non-static build is fine.)

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: libgnutls-dev 2.12.23-12ubuntu2.2
ProcVersionSignature: Ubuntu 3.13.0-44.73-generic 3.13.11-ckt12
Uname: Linux 3.13.0-44-generic x86_64
ApportVersion: 2.14.1-0ubuntu3.11
Architecture: amd64
Date: Fri Jul 24 15:49:47 2015
InstallationDate: Installed on 2014-05-22 (428 days ago)
InstallationMedia: Ubuntu 14.04 LTS Trusty Tahr - Release amd64 (20140417)
SourcePackage: gnutls26
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: gnutls26 (Ubuntu)
 Importance: Undecided
 Status: New


** Tags: amd64 apport-bug trusty

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1478035

Title:
  pkg-config --static --libs gnutls includes an option that gcc
  doesn't recognize (-R)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnutls26/+bug/1478035/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1349277] Re: AArch64 emulation ignores SPSel=0 when taking (or returning from) an exception at EL1 or greater

[Peter Maydell]

** Changed in: qemu
   Status: New = Fix Committed

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1349277

Title:
  AArch64 emulation ignores SPSel=0 when taking (or returning from) an
  exception at EL1 or greater

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1349277/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1349277] Re: AArch64 emulation ignores SPSel=0 when taking (or returning from) an exception at EL1 or greater

[Peter Maydell]

** 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 at EL1 or greater

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1349277/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Qemu-devel] [Bug 1042388] Re: qemu: Unsupported syscall: 257 (timer_create)

[Peter Maydell]

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
 and I have not figured out how to handle that yet.

Didn't we discuss this on the list a while back? You're confusing
the libc API with the kernel syscall API here -- the kernel definitely
does not take a pointer to a function to call here. (The timer_create
manpage explicitly says that the SIGEV_THREAD functionality
is implemented in the C library, not the kernel.) You can see
this if you strace it:

clone(child_stack=0xb76e5494,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0xb76e5bd8, {entry_number:6, base_addr:0xb76e5b70,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1},
child_tidptr=0xb76e5bd8) = 12666
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0xb76d324c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
timer_create(CLOCK_REALTIME, {0x984b098, 32, SIGEV_THREAD_ID,
{12666}}, {0x1}) = 0
timer_settime(0x1, 0, {it_interval={0, 0}, it_value={0, 5000}}, NULL) = 0

Under the hood libc is creating a new thread with clone, and
what the timer_create() syscall gets passed is a struct including
the thread ID to be sent a signal when the timer expires (here
that's 12666).

So all you need to do is support SIGEV_THREAD_ID,
which I think doesn't require much more than copying
across the thread ID struct field.

(On the other hand that does mean that all programs which
use SIGEV_THREAD are by definition multithreaded, which
puts them into this isn't supported territory because of our
well known and longstanding threading issues.)

-- PMM

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1042388

Title:
  qemu: Unsupported syscall: 257 (timer_create)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1042388/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1042388] Re: qemu: Unsupported syscall: 257 (timer_create)

[Peter Maydell]

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
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1042388

Title:
  qemu: Unsupported syscall: 257 (timer_create)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1042388/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

Re: [Qemu-devel] [Bug 1042388] Re: qemu: Unsupported syscall: 257 (timer_create)

[Peter Maydell]

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
 and I have not figured out how to handle that yet.

Didn't we discuss this on the list a while back? You're confusing
the libc API with the kernel syscall API here -- the kernel definitely
does not take a pointer to a function to call here. (The timer_create
manpage explicitly says that the SIGEV_THREAD functionality
is implemented in the C library, not the kernel.) You can see
this if you strace it:

clone(child_stack=0xb76e5494,
flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID,
parent_tidptr=0xb76e5bd8, {entry_number:6, base_addr:0xb76e5b70,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0,
limit_in_pages:1, seg_not_present:0, useable:1},
child_tidptr=0xb76e5bd8) = 12666
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
futex(0xb76d324c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
timer_create(CLOCK_REALTIME, {0x984b098, 32, SIGEV_THREAD_ID,
{12666}}, {0x1}) = 0
timer_settime(0x1, 0, {it_interval={0, 0}, it_value={0, 5000}}, NULL) = 0

Under the hood libc is creating a new thread with clone, and
what the timer_create() syscall gets passed is a struct including
the thread ID to be sent a signal when the timer expires (here
that's 12666).

So all you need to do is support SIGEV_THREAD_ID,
which I think doesn't require much more than copying
across the thread ID struct field.

(On the other hand that does mean that all programs which
use SIGEV_THREAD are by definition multithreaded, which
puts them into this isn't supported territory because of our
well known and longstanding threading issues.)

-- PMM

-- 
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:
  qemu: Unsupported syscall: 257 (timer_create)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1042388/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1042388] Re: qemu: Unsupported syscall: 257 (timer_create)

[Peter Maydell]

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:
  qemu: Unsupported syscall: 257 (timer_create)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1042388/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

[Peter Maydell]

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 remove any motivation anybody might have had for
fixing things properly).

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1350435

Title:
  tcg.c:1693: tcg fatal error

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-buildd/+bug/1350435/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

[Peter Maydell]

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
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1350435

Title:
  tcg.c:1693: tcg fatal error

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-buildd/+bug/1350435/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

[Peter Maydell]

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 remove any motivation anybody might have had for
fixing things properly).

-- 
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: tcg fatal error

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-buildd/+bug/1350435/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

[Peter Maydell]

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: tcg fatal error

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-buildd/+bug/1350435/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

[Peter Maydell]

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 because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1350435

Title:
  tcg.c:1693: tcg fatal error

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-buildd/+bug/1350435/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1350435] Re: tcg.c:1693: tcg fatal error

[Peter Maydell]

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 because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1350435

Title:
  tcg.c:1693: tcg fatal error

To manage notifications about this bug go to:
https://bugs.launchpad.net/launchpad-buildd/+bug/1350435/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/955379

Title:
  cmake hangs with qemu-arm-static

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 help here. You'd have to use signalfd(),
which of course is much less portable.)

-- 
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 about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/955379

Title:
  cmake hangs with qemu-arm-static

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Qemu-devel] [Bug 1317090] Re: qemu fails on ELF files with no section headers

[Peter Maydell]

On 9 May 2014 09:14, Riku Voipio riku.voi...@iki.fi 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 back the original email
 address to fix up the signed-off-by line with, so we can
 credit the fix to Craig properly.)

 Can you resend the patch with your Signed-Off-By: ?

Seems a bit unnecessary to force a resend -- the original
has the signoff, it's just the mailing list archive has mangled
it, so we can just restore it...

thanks
-- PMM

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1317090

Title:
  qemu fails on ELF files with no section headers

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1317090/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

Re: [Qemu-devel] [Bug 1317090] Re: qemu fails on ELF files with no section headers

[Peter Maydell]

On 9 May 2014 09:14, Riku Voipio riku.voi...@iki.fi 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 back the original email
 address to fix up the signed-off-by line with, so we can
 credit the fix to Craig properly.)

 Can you resend the patch with your Signed-Off-By: ?

Seems a bit unnecessary to force a resend -- the original
has the signoff, it's just the mailing list archive has mangled
it, so we can just restore it...

thanks
-- PMM

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317090

Title:
  qemu fails on ELF files with no section headers

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1317090/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Qemu-devel] [Bug 1317090] Re: qemu fails on ELF files with no section headers

[Peter Maydell]

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/
   but apparently dropped on the floor - at least, I can't find it in any qemu 
 bug tracker anywhere.  It's now keeping me from running openwrt binaries 
 under qemu-arm-static (because the openwrt guys strip section headers to save 
 space on their teeny embedded boxes).  It's a one-line patch, reproduced here:

   --- qemu/linux-user/elfload.c   2011-12-02 15:16:07.637541215 -0500
   +++ qemu-patched/linux-user/elfload.c   2011-12-02 15:27:24.061522798 -0500
   @@ -1068,7 +1068,6 @@ static bool elf_check_ehdr(struct elfhdr
return (elf_check_arch(ehdr-e_machine)
 ehdr-e_ehsize == sizeof(struct elfhdr)
 ehdr-e_phentsize == sizeof(struct elf_phdr)
   - ehdr-e_shentsize == sizeof(struct elf_shdr)
 (ehdr-e_type == ET_EXEC || ehdr-e_type == ET_DYN));
}

Yeah; the equivalent kernel code:
http://lxr.linux.no/#linux+v3.14.3/fs/binfmt_elf.c#L595
doesn't check the section header size, and nor should QEMU.

thanks
-- PMM

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1317090

Title:
  qemu fails on ELF files with no section headers

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1317090/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

Re: [Qemu-devel] [Bug 1317090] Re: qemu fails on ELF files with no section headers

[Peter Maydell]

On 7 May 2014 15:48, Peter Maydell peter.mayd...@linaro.org 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 patch submitted long ago by the guy who wrote 
 http://www.devttys0.com/2011/12/qemu-vs-sstrip/
   but apparently dropped on the floor - at least, I can't find it in any 
 qemu bug tracker anywhere.  It's now keeping me from running openwrt 
 binaries under qemu-arm-static (because the openwrt guys strip section 
 headers to save space on their teeny embedded boxes).  It's a one-line 
 patch, reproduced here:

   --- qemu/linux-user/elfload.c   2011-12-02 15:16:07.637541215 -0500
   +++ qemu-patched/linux-user/elfload.c   2011-12-02 15:27:24.061522798 -0500
   @@ -1068,7 +1068,6 @@ static bool elf_check_ehdr(struct elfhdr
return (elf_check_arch(ehdr-e_machine)
 ehdr-e_ehsize == sizeof(struct elfhdr)
 ehdr-e_phentsize == sizeof(struct elf_phdr)
   - ehdr-e_shentsize == sizeof(struct elf_shdr)
 (ehdr-e_type == ET_EXEC || ehdr-e_type == ET_DYN));
}

 Yeah; the equivalent kernel code:
 http://lxr.linux.no/#linux+v3.14.3/fs/binfmt_elf.c#L595
 doesn't check the section header size, and nor should QEMU.

Original 2011 patch:
http://lists.gnu.org/archive/html/qemu-trivial/2011-12/msg00025.html

(hitting the 'reply' button gets us back the original email
address to fix up the signed-off-by line with, so we can
credit the fix to Craig properly.)

thanks
-- PMM

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1317090

Title:
  qemu fails on ELF files with no section headers

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1317090/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

Re: [Qemu-devel] [Bug 1317090] Re: qemu fails on ELF files with no section headers

[Peter Maydell]

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/
   but apparently dropped on the floor - at least, I can't find it in any qemu 
 bug tracker anywhere.  It's now keeping me from running openwrt binaries 
 under qemu-arm-static (because the openwrt guys strip section headers to save 
 space on their teeny embedded boxes).  It's a one-line patch, reproduced here:

   --- qemu/linux-user/elfload.c   2011-12-02 15:16:07.637541215 -0500
   +++ qemu-patched/linux-user/elfload.c   2011-12-02 15:27:24.061522798 -0500
   @@ -1068,7 +1068,6 @@ static bool elf_check_ehdr(struct elfhdr
return (elf_check_arch(ehdr-e_machine)
 ehdr-e_ehsize == sizeof(struct elfhdr)
 ehdr-e_phentsize == sizeof(struct elf_phdr)
   - ehdr-e_shentsize == sizeof(struct elf_shdr)
 (ehdr-e_type == ET_EXEC || ehdr-e_type == ET_DYN));
}

Yeah; the equivalent kernel code:
http://lxr.linux.no/#linux+v3.14.3/fs/binfmt_elf.c#L595
doesn't check the section header size, and nor should QEMU.

thanks
-- PMM

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317090

Title:
  qemu fails on ELF files with no section headers

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1317090/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Qemu-devel] [Bug 1317090] Re: qemu fails on ELF files with no section headers

[Peter Maydell]

On 7 May 2014 15:48, Peter Maydell peter.mayd...@linaro.org 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 patch submitted long ago by the guy who wrote 
 http://www.devttys0.com/2011/12/qemu-vs-sstrip/
   but apparently dropped on the floor - at least, I can't find it in any 
 qemu bug tracker anywhere.  It's now keeping me from running openwrt 
 binaries under qemu-arm-static (because the openwrt guys strip section 
 headers to save space on their teeny embedded boxes).  It's a one-line 
 patch, reproduced here:

   --- qemu/linux-user/elfload.c   2011-12-02 15:16:07.637541215 -0500
   +++ qemu-patched/linux-user/elfload.c   2011-12-02 15:27:24.061522798 -0500
   @@ -1068,7 +1068,6 @@ static bool elf_check_ehdr(struct elfhdr
return (elf_check_arch(ehdr-e_machine)
 ehdr-e_ehsize == sizeof(struct elfhdr)
 ehdr-e_phentsize == sizeof(struct elf_phdr)
   - ehdr-e_shentsize == sizeof(struct elf_shdr)
 (ehdr-e_type == ET_EXEC || ehdr-e_type == ET_DYN));
}

 Yeah; the equivalent kernel code:
 http://lxr.linux.no/#linux+v3.14.3/fs/binfmt_elf.c#L595
 doesn't check the section header size, and nor should QEMU.

Original 2011 patch:
http://lists.gnu.org/archive/html/qemu-trivial/2011-12/msg00025.html

(hitting the 'reply' button gets us back the original email
address to fix up the signed-off-by line with, so we can
credit the fix to Craig properly.)

thanks
-- PMM

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1317090

Title:
  qemu fails on ELF files with no section headers

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1317090/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1285363] Re: qemu-aarch64-static segfaults

[Peter Maydell]

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 that's true for all targets. It probably just happens more
often on the aarch64 target than others you've tested because aarch64
has a signal-return trampoline on the stack frame, so we'll often see
that page get translated and thrown away again. (Other targets with a
trampoline include sparc, cris, openrisc and ppc.)

PS: the comment this is not required for qemu to work just means that
QEMU will work fine whether we tell the guest a lie about what's going
on with SIGSEGV in one way (saying it's blocked) or the other (saying
it's not blocked).

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1285363

Title:
  qemu-aarch64-static segfaults

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1285363/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1285363] Re: qemu-aarch64-static segfaults

[Peter Maydell]

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 that's true for all targets. It probably just happens more
often on the aarch64 target than others you've tested because aarch64
has a signal-return trampoline on the stack frame, so we'll often see
that page get translated and thrown away again. (Other targets with a
trampoline include sparc, cris, openrisc and ppc.)

PS: the comment this is not required for qemu to work just means that
QEMU will work fine whether we tell the guest a lie about what's going
on with SIGSEGV in one way (saying it's blocked) or the other (saying
it's not blocked).

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1285363

Title:
  qemu-aarch64-static segfaults

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1285363/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1285505] Re: [ppa 2.0~git-20140225] SIGABRT with -virtfs

[Peter Maydell]

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 are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1285505

Title:
  [ppa 2.0~git-20140225] SIGABRT with -virtfs

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1285505/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1285505] Re: [ppa 2.0~git-20140225] SIGABRT with -virtfs

[Peter Maydell]

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 are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1285505

Title:
  [ppa 2.0~git-20140225] SIGABRT with -virtfs

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1285505/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1256546] Re: qemu-s390x-static: segmentation fault entering chroot

[Peter Maydell]

Does this patch fix this issue?
http://patchwork.ozlabs.org/patch/309529/

-- 
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1256546

Title:
  qemu-s390x-static: segmentation fault entering chroot

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1256546/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1256546] Re: qemu-s390x-static: segmentation fault entering chroot

[Peter Maydell]

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 manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1256546/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1254672] Re: ps segfaults with qemu-arm-static

[Peter Maydell]

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 file in /proc isn't right). The next stage would be to
debug where exactly ps is crashing (attaching a debugger to the qemu
gdbstub is probably easiest, or good old printfs...)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1254672

Title:
  ps segfaults with qemu-arm-static

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1254672/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1246990] Re: [qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11 (Segmentation fault) - core dumped

[Peter Maydell]

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
Server Team, which is subscribed to qemu in Ubuntu.
https://bugs.launchpad.net/bugs/1246990

Title:
  [qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11
  (Segmentation fault) - core dumped

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1246990/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 1246990] Re: [qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11 (Segmentation fault) - core dumped

[Peter Maydell]

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/1246990

Title:
  [qemu-x86-64-linux-user 1.6.1] qemu: uncaught target signal 11
  (Segmentation fault) - core dumped

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1246990/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1163034] Re: linux-user mode can't handle guest setting RLIMIT_AS (hangs running gnutls28 configure check code)

[Peter Maydell]

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.
https://bugs.launchpad.net/bugs/1163034

Title:
  linux-user mode can't handle guest setting RLIMIT_AS (hangs running
  gnutls28 configure check code)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1163034/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1163034] Re: linux-user mode can't handle guest setting RLIMIT_AS (hangs running gnutls28 configure check code)

[Peter Maydell]

** 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
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1163034

Title:
  linux-user mode can't handle guest setting RLIMIT_AS (hangs running
  gnutls28 configure check code)

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1163034/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1163034] Re: gnutls28 fails to build from source in armhf

[Peter Maydell]

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 work on QEMU because we just pass the
rlimit syscall through to the host, and end up limiting not just the
guest program but also QEMU itself.  QEMU doesn't expect its own
allocations to fail and typically dies in confusing ways as a result.
(Sometimes we do check allocations and call abort(), which then under
linux-user doesn't work properly because we treat the resulting signal
as if it were caused by the guest and not by QEMU's own code; IIRC we
end up hanging in that situation.) In this particular instance we
segfault in tb_alloc_page() because it doesn't check that
page_find_alloc() didn't return NULL.

[Confirmed by running qemu-arm under gdb.]

Fixing this would require us to implement the address space rlimits
entirely in QEMU by keeping track of how much memory we've handed the
guest so we can fail mmap() etc. That is probably relatively speaking
fairly tractable, though it's not a five minute job.

Unsupported syscall bugs are usually easy fixes, incidentally (though
occasionally they are nasty); also often QEMU will warn but things will
continue OK because the guest libc/userspace supports fallback code for
when a native kernel hasn't yet implemented the new syscall.

-- 
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:
  gnutls28 fails to build from source in armhf

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1163034/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1157066] Re: qemu-keymaps lacks en_us. REGRESSION: VMs do not boot out of Virtual Machine Manager any more

[Peter Maydell]

 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 a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1157066

Title:
  qemu-keymaps lacks en_us.  REGRESSION: VMs do not boot out of Virtual
  Machine Manager any more

To manage notifications about this bug go to:
https://bugs.launchpad.net/linaro-ubuntu/+bug/1157066/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1129571] Re: libreoffice armhf FTBFS

[Peter Maydell]

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/bugs/1129571

Title:
  libreoffice armhf FTBFS

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1129571/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1129571] Re: libreoffice armhf FTBFS

[Peter Maydell]

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 handler won't be able to run until the syscall returns, which it
never does].

-- 
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 armhf FTBFS

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1129571/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1129571] Re: libreoffice armhf FTBFS

[Peter Maydell]

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 armhf FTBFS

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1129571/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1129571] Re: libreoffice armhf FTBFS

[Peter Maydell]

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 particular case will be fixed by it.

-- 
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 armhf FTBFS

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1129571/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1129571] Re: libreoffice armhf FTBFS

[Peter Maydell]

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/Contribute/SubmitAPatch. A couple of remarks about this 
patch specifically:
 * it's going to need a signed-off-by: line
 * it's fixing two different bugs (the actual futex bug and the strace error) 
and they will need to be in two different patches
 * you don't need to treat FUTEX_WAIT and _WAIT_BITSET separately, you can just 
always pass val3 to sys_futex in both cases (if the op is not FUTEX_WAIT_BITSET 
the kernel will just ignore the extra parameter)

Optional but nice: try the futex related bits of the LTP
(http://wiki.qemu.org/Testing/LTP) and see if more of them pass now (or
at least that we don't regress).

-- 
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 armhf FTBFS

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1129571/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1129571] Re: libreoffice armhf FTBFS

[Peter Maydell]

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 think we've fixed anything in this area, it's an easy thing to
try...)

However I would not be too optimistic -- Java is typically heavily
threaded, and QEMU user-mode has a number of known problems with
handling multithreaded guests. It's possible this will turn out to be a
fairly easy fix, but it's equally possible it will just be another
manifestation of problems like LP:668799.

-- 
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 armhf FTBFS

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1129571/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1129571] Re: libreoffice armhf FTBFS

[Peter Maydell]

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:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/parser.jar:/build/buildd/libreoffice-3.5.7/solver/unx
lngr.pro/bin/xt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/unoil.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/ridl.jar:/build/buildd/libreoffice-3.5.7/
solver/unxlngr.pro/bin/jurt.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/xmlsearch.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/LuceneHelpWrapper.jar:/bu
ild/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/HelpIndexerTool.jar:/build/buildd/libreoffice-3.5.7/solver/unxlngr.pro/bin/lucene-core-2.3.jar:/build/buildd/libreoffice-3.5.7/so
lver/unxlngr.pro/bin/lucene-analyzers-2.3.jar 
com.sun.star.help.HelpIndexerTool -lang cs -mod swriter -zipdir 
../../unxlngr.pro/misc/ziptmpswriter_cs -o ../../unxlngr.pro/bin/swrit
er_cs.zip.unxlngr.pro
dmake:  Error code 132, while making '../../unxlngr.pro/bin/swriter_cs.zip'


Interestingly, this happens after we've successfully run exactly the same Java 
command to produce swriter_foo.zip for various other values of 'foo' (different 
locales/languages?) My suspicion is that (a) maybe we're running out of address 
space? (b) this is going to be really painful to track down because it's 
obviously dependent on the data input to the tool. Does the build reproducibly 
fail on exactly the same bit every time?

Serge: that also looks like it's probably some issue with running Java
under QEMU, but it doesn't seem to be the same thing at all as the
LibreOffice errors in the build log...

-- 
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 armhf FTBFS

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1129571/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 571432] Re: qemu-system-arm crashed with SIGSEGV in subpage_register()

[Peter Maydell]

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
Server Team, which is subscribed to qemu-kvm in Ubuntu.
https://bugs.launchpad.net/bugs/571432

Title:
  qemu-system-arm crashed with SIGSEGV in subpage_register()

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/571432/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 393430] Re: kvm: use PulseAudio instead of ALSA

[Peter Maydell]

(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
Server Team, which is subscribed to kvm in Ubuntu.
https://bugs.launchpad.net/bugs/393430

Title:
  kvm: use PulseAudio instead of ALSA

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/393430/+subscriptions

-- 
Ubuntu-server-bugs mailing list
Ubuntu-server-bugs@lists.ubuntu.com
Modify settings or unsubscribe at: 
https://lists.ubuntu.com/mailman/listinfo/ubuntu-server-bugs

[Bug 571432] Re: qemu-system-arm crashed with SIGSEGV in subpage_register()

[Peter Maydell]

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/571432

Title:
  qemu-system-arm crashed with SIGSEGV in subpage_register()

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/571432/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 393430] Re: kvm: use PulseAudio instead of ALSA

[Peter Maydell]

(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/393430

Title:
  kvm: use PulseAudio instead of ALSA

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/393430/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1062220] Re: qemu-system-arm crashed with SIGABRT in cpu_abort()

[Peter Maydell]

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 further.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1062220

Title:
  qemu-system-arm crashed with SIGABRT in cpu_abort()

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1062220/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 hangs with qemu-arm-static

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Qemu-devel] [Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 immediately. If there is a signal pending in the QEMU signal
queue (because the host kernel just delivered it to us) then there
will always be a window between the point where you say ok, queue
is empty and actually doing the host syscall, where a signal could
be delivered and put in the queue. You cannot fix this bug in the way
you are trying to: you must handle this case by longjumping out of
the signal handler. I've already sketched the correct design for
fixing this.

[to anybody in the peanut gallery who is thinking about pselect()
now: yes, you could perhaps hack something up with that, but it would
still be a big patch with a bunch of corner cases to review, and
it would only fix this bug for this particular syscall, not in
general.]

-- PMM

-- 
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 about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Qemu-devel] [Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

On 3 December 2012 21:20, Alexander Graf ag...@suse.de 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 syscall we're blocking in in this
case is select(), which is a syscall which will exit when a
signal arrives anyway. That is, I think we're really hitting
the race condition of the signal arriving while we're in QEMU's
C code, rather than the stuck-in-blocking-syscall of the boehm
GC case.

-- PMM

-- 
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 about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

** 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-static

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Qemu-devel] [Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 think about this. Thank you for great analysis
 :)

 Apparently have to dig into qemu's code to understand this better, but
 first thought was that do you think it would be possible to add some
 crude hack bit in qemu's signal handler which we could 'almost
 atomically' check prior to entering system poll/select/read/whatnot ?
 This bit would tell there are user signals queued and handlers should be
 executed first.. ?

Nope, it's still not going to be non-racy that way (and it would still
be a pretty invasive change so it doesn't really make it easier either
I think).

-- PMM

-- 
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 about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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/bugs/955379

Title:
  cmake hangs with qemu-arm-static

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 that 
the SIGCHLD is coming in just before syscall.c executes the poll syscall, so 
that qemu queues the signal for delivery to the guest (but never actually 
delivers it) and then enters a poll syscall that won't return (because the 
SIGCHLD has already arrived). If so, fixing this would require the significant 
redesign sketched out here:
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/955379

Title:
  cmake hangs with qemu-arm-static

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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 process using a select call to block until data are 
ready.  Two of the pipes are stdout and stderr for the child.  The third is a 
special pipe populated by a signal handler to indicate that a child has 
terminated.  This is used in conjunction with the timeout on the select call to 
implement a timeout for program even when it closes stdout and stderr and at 
the same time avoiding races.

So (assuming no timeout set up) we can get the following race:
 * spawn child process
 * parent gets to point of making select() syscall
 * this takes the parent process into qemu's linux-user/main.c code
 * child process exits
 * host kernel sends SIGCHLD to parent
 * qemu's signal handler queues this SIGCHLD and does a cpu_exit, which will 
make the parent take the signal at the next basic block
 * parent code (still inside main.c or syscall.c) does the actual host select() 
syscall
 * 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

Fixing this bug will indeed require the significant rework I referred to
in comment #14, I'm afraid. Don't hold your breath...

-- 
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 about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Re: [Qemu-devel] [Bug 955379] Re: cmake hangs with qemu-arm-static

[Peter Maydell]

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
 one.

Yeah, 100M repro case tarball is manageable.

-- PMM

-- 
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 about this bug go to:
https://bugs.launchpad.net/qemu/+bug/955379/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs