On Wed, 2024-02-28 at 10:25 -1000, Richard Henderson wrote:
> There are multiple issues with the implementation of shmat().
>
> (1) With reserved_va, which is the default for 32-on-64-bit, we mmap
> the
> entire guest address space. Unlike mmap, shmat refuses to
> replace an
> existing
On Mon, 2024-02-05 at 13:05 +1000, Richard Henderson wrote:
> On 1/26/24 23:52, Richard Purdie wrote:
> > On Fri, 2024-01-26 at 16:33 +0300, Michael Tokarev wrote:
> > > 26.01.2024 16:03, Richard Purdie wrote:
> > > > I've run into a problem with this change.
>
Hi Michael,
On Fri, 2024-01-26 at 16:33 +0300, Michael Tokarev wrote:
> 26.01.2024 16:03, Richard Purdie wrote:
> > I've run into a problem with this change.
> >
> > We (Yocto Project) upgraded to qemu 8.2.0 recently and after that we
> > started seeing errors cross co
Hi,
I've run into a problem with this change.
We (Yocto Project) upgraded to qemu 8.2.0 recently and after that we
started seeing errors cross compiling webkitgtk on x86_64 for x86_64
during the introspection code which runs under user mode qemu.
The error we see is:
qemu-x86_64: QEMU internal
On Wed, 2023-09-06 at 17:50 +0200, Philippe Mathieu-Daudé wrote:
> +rth/pm215/dhildenb
>
> On 5/9/23 16:50, Richard Purdie wrote:
> > On Tue, 2023-09-05 at 14:59 +0100, Alex Bennée wrote:
> > > Richard Purdie writes:
> > >
> > > > With qe
On Tue, 2023-09-05 at 18:46 +0200, Philippe Mathieu-Daudé wrote:
> On 5/9/23 17:53, Richard Purdie wrote:
> > On Tue, 2023-09-05 at 17:12 +0200, Philippe Mathieu-Daudé wrote:
> > > Hi Richard,
> > >
> > > On 5/9/23 16:50, Richard Purdie wrote:
> > &
On Tue, 2023-09-05 at 17:12 +0200, Philippe Mathieu-Daudé wrote:
> Hi Richard,
>
> On 5/9/23 16:50, Richard Purdie wrote:
> > On Tue, 2023-09-05 at 14:59 +0100, Alex Bennée wrote:
> > > Richard Purdie writes:
> > >
> > > > With qe
On Tue, 2023-09-05 at 14:59 +0100, Alex Bennée wrote:
> Richard Purdie writes:
>
> > With qemu 8.1.0 we see boot hangs fox x86-64 targets.
> >
> > These are fixed by 0d58c660689f6da1e3feff8a997014003d928b3b (softmmu:
> > Use async_run_on_cpu in tcg_commit)
With qemu 8.1.0 we see boot hangs fox x86-64 targets.
These are fixed by 0d58c660689f6da1e3feff8a997014003d928b3b (softmmu:
Use async_run_on_cpu in tcg_commit) but if I add that commit, mips and
mips64 break, hanging at boot unable to find a rootfs.
We use virtio for network and disk and both
Hi,
Yocto Project's CI is noticing a lot of issues with qemu-system-ppc
emulation on loaded systems after we switch glibc to 2.38.
This is manifesting as hangs in the emulated system and for example,
systemd units then timeout and restart. If we have long running
commands running over ssh (e.g.
On Mon, 2023-05-29 at 16:30 +1000, Nicholas Piggin wrote:
> On Mon May 29, 2023 at 4:01 PM AEST, Michael Tokarev wrote:
> > 29.05.2023 05:18, Nicholas Piggin wrote:
> > ..
> >
> > > > 01/10 target/ppc: Fix fallback to MFSS for MFFS* instructions on pre
> > > > 3.0 ISAs
> > > > 02/10 target/ppc:
have
the fallback for 3.0 onwards to match hardware behaviour.
Signed-off-by: Richard Purdie
---
target/ppc/insn32.decode | 20 +---
target/ppc/translate/fp-impl.c.inc | 22 --
2 files changed, 29 insertions(+), 13 deletions(-)
v3 - drop fallback
ensures
the MFSS instruction is used for currently reserved bits to handle other
potential
ISA additions more correctly.
Signed-off-by: Richard Purdie
---
target/ppc/insn32.decode | 19 ---
target/ppc/translate/fp-impl.c.inc | 30 --
2 files
is used in glibc libm functions for example.
Signed-off-by: Richard Purdie
---
target/ppc/translate/fp-impl.c.inc | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/target/ppc/translate/fp-impl.c.inc
b/target/ppc/translate/fp-impl.c.inc
index 57d8437851
On Thu, 2021-06-03 at 11:02 +0100, Richard Purdie wrote:
> We're seeing intermittent rcu stalls in qemu system mode emulation which is
> causing CI issues for us (Yocto Project). We're struggling to understand
> the cause and have tried several things to mitigate without muc
Hi,
We're seeing intermittent rcu stalls in qemu system mode emulation which is
causing CI issues for us (Yocto Project). We're struggling to understand
the cause and have tried several things to mitigate without much success.
The stalls are odd in that the log messages look incomplete. An
-by: Richard Purdie
On Sat, 2021-02-13 at 18:40 +0100, Laurent Vivier wrote:
> Le 08/01/2021 à 18:46, Richard Purdie a écrit :
> > When using qemu-i386 to run gobject introspection parts of a webkitgtk
> > build using musl as libc on a 64 bit host, it sits in an infinite loop
> > of mremap cal
On Fri, 2021-01-22 at 14:55 +0100, Philippe Mathieu-Daudé wrote:
> Hi Prasad, Richard.
>
> On 1/22/21 12:52 PM, P J P wrote:
> > +-- On Fri, 22 Jan 2021, Richard Purdie wrote --+
> > > If so can anyone point me at that change?
> > >
> > > I ask since
On Fri, 2018-10-12 at 02:22 +0200, Philippe Mathieu-Daudé wrote:
> The number of bytes can not be negative nor zero.
>
> Fixed 2 format string:
> - hw/char/spapr_vty.c
> - hw/usb/ccid-card-passthru.c
>
> Suggested-by: Paolo Bonzini
> Signed-off-by: Philippe Mathieu-Daudé
> Acked-by: Alberto
On Fri, 2021-01-08 at 17:46 +, Richard Purdie wrote:
> When using qemu-i386 to run gobject introspection parts of a webkitgtk
> build using musl as libc on a 64 bit host, it sits in an infinite loop
> of mremap calls of ever decreasing/increasing addresses.
>
> I su
On Fri, 2021-01-08 at 17:42 +, Richard Purdie wrote:
> If mremap() is called without the MREMAP_MAYMOVE flag with a start address
> just before the end of memory (reserved_va) where new_size would exceed
> it (and GUEST_ADDR_MAX), the assert(end - 1 <= GUEST_ADDR_MAX) in
>
, this appears to be a
better fix of the real issue?
Signed-off-by: Richard Purdie
lid() checks to prevent this and
avoid asserting binaries when reserved_va is set.
This meant a bug I was seeing locally now gives the same behaviour
regardless of whether reserved_va is set or not.
Signed-off-by: Richard Purdie
On Tue, 2020-10-13 at 19:22 -0700, Richard Henderson wrote:
> On 10/13/20 4:11 PM, Richard Henderson wrote:
> > On 10/13/20 6:25 AM, Philippe Mathieu-Daudé wrote:
> > > Yocto developers have expressed interest in running MIPS32
> > > CPU with custom number of TLB:
> > >
On Wed, 2020-10-14 at 01:36 +, Victor Kamensky (kamensky) wrote:
> Thank you very much for looking at this. I gave a spin to
> your 3 patch series in original setup, and as expected with
> '-cpu 34Kf,tlb-entries=64' option it works great.
>
> If nobody objects, and your patches could be
On Mon, 2017-12-04 at 12:44 +1100, David Gibson wrote:
> On Mon, Dec 04, 2017 at 12:00:40PM +1100, David Gibson wrote:
> >
> > On Fri, Dec 01, 2017 at 03:49:07PM +, Richard Purdie wrote:
> > >
> > > Occasionally in Linux guests on x86_64 we're seeing lo
hang. The calls
are made from a variety of contexts so a helper function is added to handle
the necessary locking. This can likely be improved and optimised in the future
but it ensures the code is correct and doesn't lockup as it stands today.
Signed-off-by: Richard Purdie <richard.pur...@linu
st to sit idle in its idle handler
and 'hang'.
The issue occurs due to races from code which sets CPU_INTERRUPT_EXITTB.
Rather than poking directly into cs->interrupt_request, that code needs to:
a) hold BQL
b) use the cpu_interrupt() helper
This patch fixes the call sites to do this, fixing the
On Tue, 2017-11-21 at 09:55 +, Alex Bennée wrote:
> Richard Purdie <richard.pur...@linuxfoundation.org> writes:
> > At this point I therefore wanted to seek advice on what the real
> > issue
> > is here and how to fix it!
> Code should be using cpu_interrupt(
st to sit idle in its idle handler
and 'hang'.
The issue occurs due to races from code which sets CPU_INTERRUPT_EXITTB.
Rather than poking directly into cs->interrupt_request, that code needs to:
a) hold BQL
b) use the cpu_interrupt() helper
This patch fixes the call sites to do this, fixing the
On Tue, 2017-11-21 at 07:50 +, Mark Cave-Ayland wrote:
> On 21/11/17 00:00, Richard Purdie wrote:
> > I work on the Yocto Project and we use qemu to test boot our Linux
> > images and run tests against them. We've been noticing some
> > instability
> > for ppc wher
Hi,
I work on the Yocto Project and we use qemu to test boot our Linux
images and run tests against them. We've been noticing some instability
for ppc where the images sometimes hang, usually around udevd bring up
time so just after booting into userspace.
To cut a long story short, I've tracked
On Fri, 2015-09-18 at 11:14 -0700, Peter Crosthwaite wrote:
> On Fri, Sep 18, 2015 at 10:23 AM, Richard Purdie
> <richard.pur...@linuxfoundation.org> wrote:
> > On Fri, 2015-09-18 at 09:46 -0700, Peter Crosthwaite wrote:
> >> >> My biggest fear is testing of th
On Fri, 2015-09-18 at 09:46 -0700, Peter Crosthwaite wrote:
> >> My biggest fear is testing of the changes for the affected boards.
> >> Peter, do you much coverage of these boards in your regressions? Do you
> >> have automated tests in a git repo somewhere?
> >
> > The answers to these questions
On Tue, 2015-09-15 at 11:02 -0700, Peter Crosthwaite wrote:
> On Mon, Sep 14, 2015 at 2:09 PM, Richard Purdie
> <richard.pur...@linuxfoundation.org> wrote:
> > Hi Peter,
> >
> > On Thu, 2015-09-10 at 21:23 -0700, Peter Crosthwaite wrote:
> >> This should h
Hi Peter,
On Thu, 2015-09-10 at 21:23 -0700, Peter Crosthwaite wrote:
> This should hopefully fix your bug, while addressing the extra concern
> I raised.
>
> There was also inconsistent behaviour with corking packets through a
> soft reset which I notice and fixed.
>
> Please let me know if
On Sun, 2015-09-06 at 17:48 -0700, Peter Crosthwaite wrote:
> On Sun, Sep 6, 2015 at 4:26 PM, Richard Purdie
> <richard.pur...@linuxfoundation.org> wrote:
> > On Sun, 2015-09-06 at 11:37 -0700, Peter Crosthwaite wrote:
> > I tested an assert in _recieve() which confir
On Sun, 2015-09-06 at 17:48 -0700, Peter Crosthwaite wrote:
> On Sun, Sep 6, 2015 at 4:26 PM, Richard Purdie
> <richard.pur...@linuxfoundation.org> wrote:
> > On Sun, 2015-09-06 at 11:37 -0700, Peter Crosthwaite wrote:
> > It seems can_receive isn't enough, we'd
On Sun, 2015-09-06 at 17:48 -0700, Peter Crosthwaite wrote:
> This doesn't sound right. There are other network controllers that
> rely of can_receive catching all cases properly. Is this a regression?
> Looking at logs, I see some refactoring of QEMU net framework around
> June timeframe, if you
On Sun, 2015-09-06 at 11:37 -0700, Peter Crosthwaite wrote:
> On Sun, Sep 6, 2015 at 7:21 AM, Richard Purdie
> <richard.pur...@linuxfoundation.org> wrote:
> > On Sat, 2015-09-05 at 13:30 -0700, Peter Crosthwaite wrote:
> >> On Fri, Sep 4, 2015 at 10:30 AM, Peter Maydel
On Sat, 2015-09-05 at 13:30 -0700, Peter Crosthwaite wrote:
> On Fri, Sep 4, 2015 at 10:30 AM, Peter Maydell <peter.mayd...@linaro.org>
> wrote:
> > On 4 September 2015 at 18:20, Richard Purdie
> > <richard.pur...@linuxfoundation.org> wrote:
> >> On Fri, 20
We're seeing repeated segfaults in qemu-system-arm when we heavily use
the network. I have a coredump backtrace:
Reading symbols from
/home/pokybuild/yocto-autobuilder/yocto-worker/nightly-arm-lsb/build/build/tmp/sysroots/x86_64-linux/usr/bin/qemu-system-arm...done.
[New LWP 4536]
[New LWP 4534]
On Fri, 2015-09-04 at 12:31 +0100, Peter Maydell wrote:
> On 4 September 2015 at 12:24, Richard Purdie
> <richard.pur...@linuxfoundation.org> wrote:
> > So just based on that, yes, seems that the rx_fifo looks to be
> > overrunning. I can add the asserts but I thi
On Fri, 2015-09-04 at 11:45 +0100, Peter Maydell wrote:
> On 4 September 2015 at 11:25, Richard Purdie
> <richard.pur...@linuxfoundation.org> wrote:
> > We're seeing repeated segfaults in qemu-system-arm when we heavily use
> > the network. I have a coredump backtra
On Fri, 2015-09-04 at 13:43 +0100, Richard Purdie wrote:
> On Fri, 2015-09-04 at 12:31 +0100, Peter Maydell wrote:
> > On 4 September 2015 at 12:24, Richard Purdie
> > <richard.pur...@linuxfoundation.org> wrote:
> > > So just based on that, yes, seems that the rx_fifo
The USB wacom device is missing a HID descriptor which causes it
to fail to operate with recent kernels (e.g. 3.17).
This patch adds a HID desriptor to the device, based upon one from
real wacom device and allows the device to work properly again.
Signed-off-by: Richard Purdie richard.pur
On Mon, 2013-09-30 at 22:20 +0100, Richard Purdie wrote:
This is a combination of bug report and patch. I'm not sure if you'll want to
fix it
like this but it illustrates the problem and should be easy to fix based on
this.
When we restore the mxcsr register with FXRSTOR, we need
update_sse_status(). If we don't, we end
up
using the status bits from some other context with interesting results.
I used a function prototype since it makes the fix clear, some code
rearrangement
might be needed ultimately.
Signed-off-by: Richard Purdie richard.pur...@linuxfoundation.org
Index
Hi,
OpenEmbedded/Poky use qemu for locale generation when cross compiling.
When we upgraded to qemu 0.9.1 it started giving locale generation
errors on all 64 bit machines and some 32 bit ones.
I've traced it to the writev syscall failing. localedef passes several
{ NULL, 0 } iovec entries which
50 matches
Mail list logo
