qemu-ppc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-ppc] [Qemu-devel] [PATCH 00/28] target-ppc: Altivec 2.07


From: Richard W.M. Jones
Subject: Re: [Qemu-ppc] [Qemu-devel] [PATCH 00/28] target-ppc: Altivec 2.07
Date: Thu, 20 Feb 2014 12:47:31 +0000
User-agent: Mutt/1.5.20 (2009-12-10)

On Thu, Feb 20, 2014 at 01:36:57PM +0100, Alexander Graf wrote:
> 
> On 20.02.2014, at 13:34, Richard W.M. Jones <address@hidden> wrote:
> 
> > On Thu, Feb 20, 2014 at 10:23:42AM +0000, Richard W.M. Jones wrote:
> >> I am now running a full libguestfs test which will take several hours,
> >> but it looks as if -- even if this test fails -- it won't be because
> >> of lack of emulation / missing instructions in qemu.
> > 
> > The tests ran.  I hit two bugs, but neither seems to be related to
> > qemu emulation.  Please push these patches into upstream qemu :-)
> 
> They will get into 2.0, no worries :).
> 
> > One bug is in btrfs and is related to page size being different (and
> > much larger) on ppc64.
> 
> I remember bugs (oopses) with btrfs when you use a 4k page size created fs 
> and use it on a 64k page size kernel and vice versa. They still haven't fixed 
> that?

The failure from the log is:

  wipefs -a --force /dev/sda1
  mkfs.btrfs --alloc-start 0 --byte-count 268435456 --data single --leafsize 
4096 --label test --metadata single --nodesize 4096 --sectorsize 512 /dev/sda1
  Illegal leafsize (or nodesize) 4096 (smaller than 65536)

I have not analysed this beyond simply looking at the command line
now, but it seems that this is NOT a bug in btrfs, but a bug in the
test suite, selecting a too small --leafsize parameter.  Or perhaps a
limitation in btrfs.  Anyway, doesn't look serious.

> > The second bug is kind of interesting.  If you add ~ 256 disks (using
> > virtio-scsi), then it looks as if the firmware crashes.  The total
> > console output is below.  It looks as if "c >" is some kind of prompt.
> > qemu spins using 100% of CPU after this.
>
> How much RAM do you pass into the guest? Could you please try to
> increase that size to see whether it makes a difference? If it
> doesn't, Aneesh is your man :)

In the test case we used -m 768.

I reran the test with -m 2048 -- it crashed the same way.

I reran the test with -m 20480 -- it crashed the same way.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]