On 9/1/21 8:41 PM, Peter Maydell wrote:
On Wed, 1 Sept 2021 at 19:30, Richard W.M. Jones wrote:
On Wed, Sep 01, 2021 at 07:18:03PM +0100, Peter Maydell wrote:
On Wed, 1 Sept 2021 at 18:01, Richard W.M. Jones wrote:
This avoids the following assertion when the kernel initializes X.509
certi
On Thu, Sep 02, 2021 at 08:36:56AM +0100, Peter Maydell wrote:
> On Wed, 1 Sept 2021 at 21:24, Richard W.M. Jones wrote:
> >
> > On Wed, Sep 01, 2021 at 09:17:07PM +0100, Peter Maydell wrote:
> > > On Wed, 1 Sept 2021 at 19:51, Richard W.M. Jones
> > > wrote:
> > > >
> > > > On Wed, Sep 01, 2021
On Wed, 1 Sept 2021 at 21:24, Richard W.M. Jones wrote:
>
> On Wed, Sep 01, 2021 at 09:17:07PM +0100, Peter Maydell wrote:
> > On Wed, 1 Sept 2021 at 19:51, Richard W.M. Jones wrote:
> > >
> > > On Wed, Sep 01, 2021 at 07:41:21PM +0100, Peter Maydell wrote:
> > > > Is the failure case short enoug
On Wed, Sep 01, 2021 at 09:17:07PM +0100, Peter Maydell wrote:
> On Wed, 1 Sept 2021 at 19:51, Richard W.M. Jones wrote:
> >
> > On Wed, Sep 01, 2021 at 07:41:21PM +0100, Peter Maydell wrote:
> > > Is the failure case short enough to allow -d ... logging to
> > > be taken? That's usually the most
On Wed, 1 Sept 2021 at 19:51, Richard W.M. Jones wrote:
>
> On Wed, Sep 01, 2021 at 07:41:21PM +0100, Peter Maydell wrote:
> > Is the failure case short enough to allow -d ... logging to
> > be taken? That's usually the most useful info, but it's so huge
> > it's often not feasible.
>
> I can try
On Wed, Sep 01, 2021 at 07:41:21PM +0100, Peter Maydell wrote:
> Is the failure case short enough to allow -d ... logging to
> be taken? That's usually the most useful info, but it's so huge
> it's often not feasible.
I can try -- what exact -d option would be useful?
Rich.
--
Richard Jones, Vi
On Wed, 1 Sept 2021 at 19:30, Richard W.M. Jones wrote:
>
> On Wed, Sep 01, 2021 at 07:18:03PM +0100, Peter Maydell wrote:
> > On Wed, 1 Sept 2021 at 18:01, Richard W.M. Jones wrote:
> > >
> > > This avoids the following assertion when the kernel initializes X.509
> > > certificates:
> > >
> > >
On Wed, Sep 01, 2021 at 07:18:03PM +0100, Peter Maydell wrote:
> On Wed, 1 Sept 2021 at 18:01, Richard W.M. Jones wrote:
> >
> > This avoids the following assertion when the kernel initializes X.509
> > certificates:
> >
> > [7.315373] Loading compiled-in X.509 certificates
> > qemu-system-arm
On Wed, 1 Sept 2021 at 18:01, Richard W.M. Jones wrote:
>
> This avoids the following assertion when the kernel initializes X.509
> certificates:
>
> [7.315373] Loading compiled-in X.509 certificates
> qemu-system-arm: ../tcg/tcg.c:3063: temp_allocate_frame: Assertion `align <=
> TCG_TARGET_S
https://www.mail-archive.com/qemu-devel@nongnu.org/msg833146.html
I tested this patch which simply increases the stack alignment to 16
bytes and it fixes the assertion failure and otherwise appears to work
(in as far as it boots the libguestfs appliance). However I've no
idea if this is the right
This avoids the following assertion when the kernel initializes X.509
certificates:
[7.315373] Loading compiled-in X.509 certificates
qemu-system-arm: ../tcg/tcg.c:3063: temp_allocate_frame: Assertion `align <=
TCG_TARGET_STACK_ALIGN' failed.
Fixes: commit c1c091948ae
Resolves: https://bugzi
11 matches
Mail list logo