On Tue, Dec 15, 2020 at 09:07:19AM +0100, Gerd Hoffmann wrote:
> > > +if (using_spice) {
> > > +/*
> > > + * When using spice allow the spice audio driver being picked
> > > + * as default.
> > > + *
> > > + * Temporary hack. Using audio devices without
On Wed, Sep 16, 2020 at 2:42 AM Gerd Hoffmann wrote:
>
> Handle the spice special case in audio_init instead.
>
> With the qemu_spice_audio_init() symbol dependency being
> gone we can build spiceaudio as module.
>
> Signed-off-by: Gerd Hoffmann
> ---
> include/ui/qemu-spice.h | 1 -
>
** Changed in: kunpeng920/ubuntu-18.04-hwe
Status: Triaged => Fix Committed
** Changed in: kunpeng920/ubuntu-18.04
Status: Triaged => Fix Committed
** Changed in: kunpeng920
Status: Triaged => Fix Committed
--
You received this bug notification because you are a member of
Verified w/ over 500 successful iterations on a m6g.metal instance, and
over 300 in an armhf chroot on the same.
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
You received this bug notification because you are a
I ran the new PPA build (1:2.11+dfsg-1ubuntu7.29~ppa01) on both a
ThunderX2 system and a Hi1620 system overnight, and both survived (6574
& 12919 iterations, respectively).
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
Ike's backport in
https://launchpad.net/~ikepanhc/+archive/ubuntu/lp1805256 tests well for
me on Cavium Sabre. One minor note is that the function
in_aio_context_home_thread() is being called in aio-win32.c, but that
function didn't exist in 2.11. We probably want to change that to
On Wed, May 6, 2020 at 1:20 PM Philippe Mathieu-Daudé
<1805...@bugs.launchpad.net> wrote:
>
> Isn't this fixed by commit 5710a3e09f9?
See comment #43. The discussions hence are about testing/integration
of that fix.
-dann
--
You received this bug notification because you are a member of
** Description changed:
[Impact]
* QEMU locking primitives might face a race condition in QEMU Async I/O
bottom halves scheduling. This leads to a dead lock making either QEMU
or one of its tools to hang indefinitely.
[Test Case]
* qemu-img convert -f qcow2 -O qcow2
fyi, I backported that fix also to focal/groovy and eoan, and with those
builds. On my test systems the hang reliable occurs within 20
iterations. After the fix, they have survived > 500 iterations thus far.
I'll leave running overnight just to be sure.
--
You received this bug notification
fyi, what I tested in Comment #35 was upstream QEMU (@ aceeaa69d2) with
a port of the patch in Comment #34 applied. I've attached that patch
here. While it did avoid the issue in my testing, I agree with Rafael's
Comment #36 that it does not appear to address the root cause (as I
understand it),
I tested the patch in Comment #34, and it was able to pass 500
iterations.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
qemu-img hangs on rcu_call_ready_event logic in Aarch64 when
** Changed in: kunpeng920
Status: New => Confirmed
** Changed in: qemu (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: qemu (Ubuntu Disco)
Status: New => Confirmed
** Changed in: qemu (Ubuntu Focal)
Status: New => Confirmed
--
You received this bug
On Fri, Dec 06, 2019 at 06:07:58AM +0100, Philippe Mathieu-Daudé wrote:
> On 12/5/19 8:35 PM, Laszlo Ersek wrote:
> > On 12/05/19 17:50, Ard Biesheuvel wrote:
> > > On Thu, 5 Dec 2019 at 16:27, Philippe Mathieu-Daudé
> > > wrote:
> > > >
> > > > On 12/5/19 5:13 PM, Laszlo Ersek wrote:
> > > > >
On Fri, Oct 11, 2019 at 06:05:25AM +, Jan Glauber wrote:
> On Wed, Oct 09, 2019 at 11:15:04AM +0200, Paolo Bonzini wrote:
> > On 09/10/19 10:02, Jan Glauber wrote:
>
> > > I'm still not sure what the actual issue is here, but could it be some bad
> > > interaction between the notify_me and
On Fri, Oct 11, 2019 at 08:30:02AM +, Jan Glauber wrote:
> On Fri, Oct 11, 2019 at 10:18:18AM +0200, Paolo Bonzini wrote:
> > On 11/10/19 08:05, Jan Glauber wrote:
> > > On Wed, Oct 09, 2019 at 11:15:04AM +0200, Paolo Bonzini wrote:
> > >>> ...but if I bump notify_me size to uint64_t the issue
On Mon, Oct 07, 2019 at 01:06:20PM +0200, Paolo Bonzini wrote:
> On 02/10/19 11:23, Jan Glauber wrote:
> > I've looked into this on ThunderX2. The arm64 code generated for the
> > atomic_[add|sub] accesses of ctx->notify_me doesn't contain any
> > memory barriers. It is just plain ldaxr/stlxr.
> >
** Also affects: kunpeng920
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
qemu-img hangs on rcu_call_ready_event logic in Aarch64 when
On Wed, Sep 11, 2019 at 04:09:25PM -0300, Rafael David Tinoco wrote:
> > Zhengui's theory that notify_me doesn't work properly on ARM is more
> > promising, but he couldn't provide a clear explanation of why he thought
> > notify_me is involved. In particular, I would have expected notify_me to
>
*** This bug is a duplicate of bug 1805256 ***
https://bugs.launchpad.net/bugs/1805256
** This bug has been marked a duplicate of bug 1805256
qemu-img hangs on high core count ARM system
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
** Also affects: qemu (Ubuntu)
Importance: Undecided
Status: New
** Changed in: qemu (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
No, sorry - this bugs still persists w/ latest upstream (@ afccfc0). I
found a report of similar symptoms:
https://patchwork.kernel.org/patch/10047341/
https://bugzilla.redhat.com/show_bug.cgi?id=1524770#c13
To be clear, ^ is already fixed upstream, so it is not the *same* issue
- but
** Changed in: qemu
Status: New => Confirmed
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1805256
Title:
qemu-img hangs on high core count ARM system
Status in QEMU:
Confirmed
Bug
ext4 filesystem, SATA drive:
(gdb) thread apply all bt
Thread 3 (Thread 0x9bffc9a0 (LWP 9015)):
#0 0xaaa462cc in __GI___sigtimedwait (set=,
set@entry=0xe725c070, info=info@entry=0x9bffbf18,
timeout=0x3ff1, timeout@entry=0x0)
at
Public bug reported:
On the HiSilicon D06 system - a 96 core NUMA arm64 box - qemu-img
frequently hangs (~50% of the time) with this command:
qemu-img convert -f qcow2 -O qcow2 /tmp/cloudimg /tmp/cloudimg2
Where "cloudimg" is a standard qcow2 Ubuntu cloud image. This
qcow2->qcow2 conversion
** Tags removed: verification-needed-zesty
** Tags added: verification-done-zesty
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1719196
Title:
[arm64 ocata] newly created instances are unable to
Thanks Christian - I've now verified this. I took a stepwise approach:
1) We originally observed this issue w/ the ocata cloud archive on
xenial, so I redeployed that. I verified that I was still seeing the
problem. I then created a PPA[*] w/ an arm64 build of QEMU from the
ocata-staging PPA,
Thanks so much for doing that Sean.
Omitting expected changes (uuid, mac address, etc), here's are the
significant changes I see:
1) N uses the QEMU 'virt' model, O uses 'virt-2.8'
2) N and O both expose a pci root, but N also exposed 2 PCI bridges that O does
not.
3) N exposes an additional
or critical bug fixes.
Signed-off-by: dann frazier <dann.fraz...@canonical.com>
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 7d5aab2..8a9794b 100755
--- a/configure
+++ b/configure
@@ -1878,7 +1878,7 @@ fi
if test &qu
or critical bug fixes.
Signed-off-by: dann frazier <dann.fraz...@canonical.com>
---
configure | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 913ae4a..b6f4694 100755
--- a/configure
+++ b/configure
@@ -1873,13 +1873,13 @@ fi
if test &qu
Using 2.1+dfsg-2ubuntu2 from utopic within a trusty ubuntu core:
# /usr/bin/qemu-aarch64-static -d unimp /usr/bin/java
host mmap_min_addr=0x1
Reserved 0x12000 bytes of guest address space
Relocating guest address space from 0x0040 to 0x40
guest_base 0x0
startend
I'm also seeing a SEGV (not a SIGILL) when testing the version of QEMU
that shipped in trusty. So, we might just consider this bug fixed and
track this segfault issue separately.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
On Tue, Feb 25, 2014 at 1:39 AM, Alex Bennée alex.ben...@linaro.org wrote:
Dann Frazier dann.fraz...@canonical.com writes:
On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée alex.ben...@linaro.org wrote:
Hi,
Thanks to all involved for your work here!
After a solid few months of work the QEMU
** Also affects: qemu
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1289527
Title:
qemu-aarch64-static: java dies with SIGILL
Status in QEMU:
New
@Serge: I can confirm that this is fixed in 1.7.0+dfsg-3ubuntu5sig1 from
your ppa.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1285363
Title:
qemu-aarch64-static segfaults
Status in QEMU:
New
[Adding Alex Barcelo to the CC]
On Thu, Feb 27, 2014 at 6:20 AM, Michael Matz m...@suse.de wrote:
Hi,
On Wed, 26 Feb 2014, Dann Frazier wrote:
I've narrowed down the changes that seem to prevent both types of
segfaults to the following changes that introduce a wrapper around
sigprocmask
On Tue, Feb 25, 2014 at 1:39 AM, Alex Bennée alex.ben...@linaro.org wrote:
Dann Frazier dann.fraz...@canonical.com writes:
On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée alex.ben...@linaro.org wrote:
Hi,
Thanks to all involved for your work here!
After a solid few months of work the QEMU
On Mon, Feb 17, 2014 at 6:40 AM, Alex Bennée alex.ben...@linaro.org wrote:
Hi,
Thanks to all involved for your work here!
After a solid few months of work the QEMU master branch [1] has now reached
instruction feature parity with the suse-1.6 [6] tree that a lot of people
have been using to
happen to have a physical 82540EM controller, and it also sets the
Capabilities Bit, but it actually has items on the capabilities list to go
with it :)
Signed-off-by: dann frazier dann.fraz...@canonical.com
---
hw/e1000.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git
38 matches
Mail list logo
