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.
(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.
The 'qemu' binary (which is for x86 and kvm) is not always the same version as
the one used for ARM user-mode emulation (and in particular it is in a
different package for newer Ubuntu releases). What is the output of:
qemu-arm-static -h | grep version
?
--
You received this bug notification
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.
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
I've analysed this segfault. The problem is that we're not correctly
taking account of the IT state on entry to a Thumb translation block if
we're retranslating it for cpu_restore_state().
The offending TB here is:
0x0003dc00: movle r2, #0
0x0003dc02: ldrr1, [pc, #644] (0x3de88)
I have a patchset which fixes this bug, which I need to do a bit more
cleanup and testing with before I post it to the list.
** Changed in: qemu
Status: New = In Progress
--
You received this bug notification because you are a member of Ubuntu
Server Team, which is subscribed to
I've now posted this patchset; it comes in 7 parts:
http://patchwork.ozlabs.org/patch/77887/
http://patchwork.ozlabs.org/patch/77882/
http://patchwork.ozlabs.org/patch/77884/
http://patchwork.ozlabs.org/patch/77885/
http://patchwork.ozlabs.org/patch/77888/
http://patchwork.ozlabs.org/patch/77881/
Suggested patch sent upstream: http://patchwork.ozlabs.org/patch/83964/
I'll put this in qemu-linaro 2011.03 one way or another.
** Changed in: qemu-linaro
Status: New = In Progress
** Changed in: qemu-linaro
Importance: Undecided = Medium
** Changed in: qemu-linaro
Milestone:
Moving back to qemu-kvm as specific to that package.
** Package changed: qemu-linaro (Ubuntu) = qemu-kvm (Ubuntu)
--
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/584480
Title:
Moving back to qemu-kvm as specific to that package.
** Package changed: qemu-linaro (Ubuntu) = qemu-kvm (Ubuntu)
--
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/579227
Title:
** Changed in: qemu-linaro
Status: In Progress = Fix Committed
--
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/721801
Title:
llseek bug in amd64 host
--
Ubuntu-server-bugs
** Changed in: qemu-linaro
Status: Fix Committed = Fix Released
--
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/721801
Title:
llseek bug in amd64 host
--
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
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
On 7 May 2014 15:34, Paul Jimenez 1317...@bugs.launchpad.net wrote:
Bug description:
Using the latest version of qemu-user-static from trusty, 2.0.0+dfsg-
2ubuntu1.
Reported to qemu and patch submitted long ago by the guy who wrote
http://www.devttys0.com/2011/12/qemu-vs-sstrip/
On 7 May 2014 15:48, Peter Maydell 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
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
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
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
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:
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
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.
** 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)
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
#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
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
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
28 matches
Mail list logo
