qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] E5-2620v2 - emulation stop error


From: Kevin O'Connor
Subject: Re: [Qemu-devel] E5-2620v2 - emulation stop error
Date: Wed, 11 Mar 2015 11:42:20 -0400
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, Mar 11, 2015 at 01:45:57PM +0000, Dr. David Alan Gilbert wrote:
> * Bandan Das (address@hidden) wrote:
> > "Dr. David Alan Gilbert" <address@hidden> writes:
> > > while true; do (sleep 5; echo -e 
> > > '\001cq\n')|/opt/qemu-try-world3/bin/qemu-system-x86_64 -machine 
> > > pc-i440fx-2.0,accel=kvm -m 1024 -smp 128 -nographic -device sga 2>&1 | 
> > > tee /tmp/qemu.op; grep "internal error" /tmp/qemu.op -q && break; done
> > >
[...]
> > > address@hidden qemu-world3]# git bisect bad
> > > 21f5826a04d38e19488f917e1eef22751490c769 is the first bad commit
> > 
> > I can reproduce this on E5-2620 v2 with  David's "while true" test.
> > (The emulation failure I mean, not the suberror 2 that Andrey is seeing)
> > The commit that seems to have introduced this is -
> > 
> > commit 0673b7870063a3affbad9046fb6d385a4e734c19
> > Author: Kevin O'Connor <address@hidden>
> > Date:   Sat May 24 10:49:50 2014 -0400
> > 
> >     smp: Replace QEMU SMP init assembler code with C; run only in 32bit 
> > mode.
[...]
> Turning on debug logging
> ( -chardev file,id=log,path=/tmp/debugcon.$$ -device 
> isa-debugcon,chardev=log,iobase=0x402 )
> 
> SeaBIOS (version rel-1.8.0-0-g4c59f5d-20150219_092859-nilsson.home.kraxel.org)
[...]
> Found 1 cpu(s) max supported 128 cpu(s)

Something is very odd here.  When I run the above command (on an older
AMD machine) I get:

Found 128 cpu(s) max supported 128 cpu(s)

That first value (1 vs 128) comes from QEMU (via cmos index 0x5f).
That is, during smp init, SeaBIOS expects QEMU to tell it how many
cpus are active, and SeaBIOS waits until that many CPUs check in from
its SIPI request before proceeding.

I wonder if QEMU reported only 1 active cpu via that cmos register,
but more were actually active.  If that was the case, it could
certainly explain the failure - as multiple cpus could be running
without the sipi trapoline in place.

What does the log look like on a non-failure case?

-Kevin



reply via email to

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