[Top][All Lists]

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

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

From: Andrey Korolyov
Subject: Re: [Qemu-devel] E5-2620v2 - emulation stop error
Date: Thu, 26 Mar 2015 01:31:11 +0300

On Wed, Mar 25, 2015 at 11:54 PM, Kevin O'Connor <address@hidden> wrote:
> On Wed, Mar 25, 2015 at 11:43:31PM +0300, Andrey Korolyov wrote:
>> On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov <address@hidden> wrote:
>> > For now, it looks like bug have a mixed Murphy-Heisenberg nature, as
>> > it appearance is very rare (compared to the number of actual launches)
>> > and most probably bounded to the physical characteristics of my
>> > production nodes. As soon as I reach any reproducible path for a
>> > regular workstation environment, I`ll let everyone know. Also I am
>> > starting to think that issue can belong to the particular motherboard
>> > firmware revision, despite fact that the CPU microcode is the same
>> > everywhere.
>> Hello everyone, I`ve managed to reproduce this issue
>> *deterministically* with latest seabios with smp fix and 3.18.3. The
>> error occuring just *once* per vm until hypervisor reboots, at least
>> in my setup, this is definitely crazy...
>> - launch two VMs (Centos 7 in my case),
>> - wait a little while they are booting,
>> - attach serial console (I am using virsh list for this exact purpose),
>> - issue acpi reboot or reset, does not matter,
>> - VM always hangs at boot, most times with sgabios initialization
>> string printed out [1], but sometimes it hangs a bit later [2],
>> - no matter how many times I try to relaunch the QEMU afterwards, the
>> issue does not appear on VM which experienced problem once;
>> - trace and sample args can be seen in [3] and [4] respectively.
> Can you add something like:
>   -chardev file,path=seabioslog.`date +%s`,id=seabios -device 
> isa-debugcon,iobase=0x402,chardev=seabios
> to the qemu command line and forward the resulting log from both a
> succesful boot and a failed one?
> -Kevin

Of course, logs are attached.

Attachment: reboot.failed
Description: Binary data

Attachment: reboot.succeeded
Description: Binary data

reply via email to

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