On Wed, Mar 11, 2015 at 01:45:57PM +0000, Dr. David Alan Gilbert wrote: > * Bandan Das (bsd@xxxxxxxxxx) wrote: > > "Dr. David Alan Gilbert" <dgilbert@xxxxxxxxxx> 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 > > > [...] > > > [root@virtlab413 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 <kevin@xxxxxxxxxxxx> > > 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
