A small update:
the behavior is caused by setting unrestricted_guest feature to N, I
had this feature disabled everywhere from approx. three years ago when
its enablement was one of suspects of the host crashes with
contemporary then KVM module. Also nVMX is likely to not work at all
and produce t
*putting my tinfoil hat on*
After thinking a little bit more, the observable behavior is a quite
good match for a bios-level hypervisor (hardware trojan in a modern
terminology), as it likely is sensitive to timing[1], does not appear
more than once per VM during boot cycle and seemingly does not
On Wed, Apr 1, 2015 at 6:37 PM, Andrey Korolyov wrote:
> On Wed, Apr 1, 2015 at 4:19 PM, Paolo Bonzini wrote:
>>
>>
>> On 01/04/2015 14:26, Andrey Korolyov wrote:
>>> Yes, I disabled host watchdog during runtime. Indeed guest-induced NMI
>>> would look different and they had no reasons to be fire
On Wed, Apr 1, 2015 at 4:19 PM, Paolo Bonzini wrote:
>
>
> On 01/04/2015 14:26, Andrey Korolyov wrote:
>> Yes, I disabled host watchdog during runtime. Indeed guest-induced NMI
>> would look different and they had no reasons to be fired at this stage
>> inside guest. I`d suspect a hypervisor hardw
On 01/04/2015 14:26, Andrey Korolyov wrote:
> Yes, I disabled host watchdog during runtime. Indeed guest-induced NMI
> would look different and they had no reasons to be fired at this stage
> inside guest. I`d suspect a hypervisor hardware misbehavior there but
> have a very little idea on how AP
On Wed, Apr 1, 2015 at 2:49 PM, Radim Krčmář wrote:
> 2015-03-31 21:23+0300, Andrey Korolyov:
>> On Tue, Mar 31, 2015 at 9:04 PM, Bandan Das wrote:
>> > Bandan Das writes:
>> >> Andrey Korolyov writes:
>> >> ...
>> >>> http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.d
On 01/04/2015 13:49, Radim Krčmář wrote:
> 2015-03-31 21:23+0300, Andrey Korolyov:
>> On Tue, Mar 31, 2015 at 9:04 PM, Bandan Das wrote:
>>> Bandan Das writes:
Andrey Korolyov writes:
...
> http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz
>
>>
2015-03-31 21:23+0300, Andrey Korolyov:
> On Tue, Mar 31, 2015 at 9:04 PM, Bandan Das wrote:
> > Bandan Das writes:
> >> Andrey Korolyov writes:
> >> ...
> >>> http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz
> >>>
> >>> Something a bit more interesting, but the
On Tue, Mar 31, 2015 at 9:04 PM, Bandan Das wrote:
> Bandan Das writes:
>
>> Andrey Korolyov writes:
>> ...
>>> http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz
>>>
>>> Something a bit more interesting, but the mess is happening just
>>> *after* NMI firing.
>>
>>
Bandan Das writes:
> Andrey Korolyov writes:
> ...
>> http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz
>>
>> Something a bit more interesting, but the mess is happening just
>> *after* NMI firing.
>
> What happens if NMI is turned off on the host ?
Sorry, I mean
Andrey Korolyov writes:
...
> http://xdel.ru/downloads/kvm-e5v2-issue/another-tracepoint-fail-with-apicv.dat.gz
>
> Something a bit more interesting, but the mess is happening just
> *after* NMI firing.
What happens if NMI is turned off on the host ?
On Tue, Mar 31, 2015 at 7:45 PM, Radim Krčmář wrote:
> 2015-03-31 17:56+0300, Andrey Korolyov:
>> > Chasing the culprit this way could take a long time, so a new tracepoint
>> > that shows if 0xef is set on entry would let us guess the bug faster ...
>> >
>> > Please provide a failing trace with t
2015-03-31 17:56+0300, Andrey Korolyov:
> > Chasing the culprit this way could take a long time, so a new tracepoint
> > that shows if 0xef is set on entry would let us guess the bug faster ...
> >
> > Please provide a failing trace with the following patch:
>
> Thanks, please see below:
>
> http:
On Tue, Mar 31, 2015 at 4:45 PM, Radim Krčmář wrote:
> 2015-03-30 22:32+0300, Andrey Korolyov:
>> On Mon, Mar 30, 2015 at 9:56 PM, Radim Krčmář wrote:
>> > 2015-03-27 13:16+0300, Andrey Korolyov:
>> >> On Fri, Mar 27, 2015 at 12:03 AM, Bandan Das wrote:
>> >> > Radim Krčmář writes:
>> >> >> I s
2015-03-30 22:32+0300, Andrey Korolyov:
> On Mon, Mar 30, 2015 at 9:56 PM, Radim Krčmář wrote:
> > 2015-03-27 13:16+0300, Andrey Korolyov:
> >> On Fri, Mar 27, 2015 at 12:03 AM, Bandan Das wrote:
> >> > Radim Krčmář writes:
> >> >> I second Bandan -- checking that it reproduces on other machine
On Mon, Mar 30, 2015 at 9:56 PM, Radim Krčmář wrote:
> 2015-03-27 13:16+0300, Andrey Korolyov:
>> On Fri, Mar 27, 2015 at 12:03 AM, Bandan Das wrote:
>> > Radim Krčmář writes:
>> >> I second Bandan -- checking that it reproduces on other machine would be
>> >> great for sanity :) (Although a bu
2015-03-27 14:54+0300, Andrey Korolyov:
> Trace with new bits:
Thanks.
> KVM internal error. Suberror: 2
> extra data[0]: 80ef
> extra data[1]: 8b0d
> extra data[2]: 77b
The #GP code looks formatted as documented under INT in SDM,
(vector << 3) | 2 | ext
where 'ext' stands for 'externa
2015-03-27 13:16+0300, Andrey Korolyov:
> On Fri, Mar 27, 2015 at 12:03 AM, Bandan Das wrote:
> > Radim Krčmář writes:
> >> I second Bandan -- checking that it reproduces on other machine would be
> >> great for sanity :) (Although a bug in our APICv is far more likely.)
> >
> > If it's APICv re
On Thu, Mar 26, 2015 at 11:40 PM, Radim Krčmář wrote:
> 2015-03-26 21:24+0300, Andrey Korolyov:
>> On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář wrote:
>> > 2015-03-26 20:08+0300, Andrey Korolyov:
>> >> KVM internal error. Suberror: 2
>> >> extra data[0]: 80ef
>> >> extra data[1]: 8b0d
>>
On Fri, Mar 27, 2015 at 12:03 AM, Bandan Das wrote:
> Radim Krčmář writes:
>
>> 2015-03-26 21:24+0300, Andrey Korolyov:
>>> On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář wrote:
>>> > 2015-03-26 20:08+0300, Andrey Korolyov:
>>> >> KVM internal error. Suberror: 2
>>> >> extra data[0]: 80ef
>>>
Radim Krčmář writes:
> 2015-03-26 21:24+0300, Andrey Korolyov:
>> On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář wrote:
>> > 2015-03-26 20:08+0300, Andrey Korolyov:
>> >> KVM internal error. Suberror: 2
>> >> extra data[0]: 80ef
>> >> extra data[1]: 8b0d
>> >
>> > Btw. does this part ever
2015-03-26 21:24+0300, Andrey Korolyov:
> On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář wrote:
> > 2015-03-26 20:08+0300, Andrey Korolyov:
> >> KVM internal error. Suberror: 2
> >> extra data[0]: 80ef
> >> extra data[1]: 8b0d
> >
> > Btw. does this part ever change?
> >
> > I see that firs
On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář wrote:
> 2015-03-26 20:08+0300, Andrey Korolyov:
>> KVM internal error. Suberror: 2
>> extra data[0]: 80ef
>> extra data[1]: 8b0d
>
> Btw. does this part ever change?
>
> I see that first report had:
>
> KVM internal error. Suberror: 2
> ex
2015-03-26 20:08+0300, Andrey Korolyov:
> KVM internal error. Suberror: 2
> extra data[0]: 80ef
> extra data[1]: 8b0d
Btw. does this part ever change?
I see that first report had:
KVM internal error. Suberror: 2
extra data[0]: 80d1
extra data[1]: 8b0d
Was that a Windows gu
2015-03-26 12:36-0400, Kevin O'Connor:
> On Thu, Mar 26, 2015 at 04:58:07PM +0100, Radim Krčmář wrote:
> > Notice the 0xef. My best hypothesis so far is that we fail at resetting
> > devices, and 0xef is LOCAL_TIMER_VECTOR from Linux before we rebooted.
> > (The bug happens at the first place that
2015-03-26 19:48+0300, Andrey Korolyov:
> I`ll post a sample event
> capture with and without Radim`s proposed patch maybe today or
> tomorrow.
Thanks.
The patch doesn't change runtime behavior, it just adds another data
field to the error report, so t
On Thu, Mar 26, 2015 at 8:18 PM, Kevin O'Connor wrote:
> On Thu, Mar 26, 2015 at 08:08:52PM +0300, Andrey Korolyov wrote:
>> On Thu, Mar 26, 2015 at 8:06 PM, Kevin O'Connor wrote:
>> > On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote:
>> >> On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'
On Thu, Mar 26, 2015 at 08:08:52PM +0300, Andrey Korolyov wrote:
> On Thu, Mar 26, 2015 at 8:06 PM, Kevin O'Connor wrote:
> > On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote:
> >> On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor wrote:
> >> > I'm not sure if the crash always happen
On Thu, Mar 26, 2015 at 8:06 PM, Kevin O'Connor wrote:
> On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote:
>> On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor wrote:
>> > I'm not sure if the crash always happens at the "int $0x19" location
>> > though. Andrey, does the crash always
On Thu, Mar 26, 2015 at 07:48:09PM +0300, Andrey Korolyov wrote:
> On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor wrote:
> > I'm not sure if the crash always happens at the "int $0x19" location
> > though. Andrey, does the crash always happen with "EIP=d331" and/or
> > with "Code=... 19"?
>
>
On Thu, Mar 26, 2015 at 7:36 PM, Kevin O'Connor wrote:
> On Thu, Mar 26, 2015 at 04:58:07PM +0100, Radim Krčmář wrote:
>> 2015-03-25 20:05-0400, Kevin O'Connor:
>> > On Thu, Mar 26, 2015 at 02:35:58AM +0300, Andrey Korolyov wrote:
>> > > Thanks, strangely the reboot is always failing now and alway
On Thu, Mar 26, 2015 at 04:58:07PM +0100, Radim Krčmář wrote:
> 2015-03-25 20:05-0400, Kevin O'Connor:
> > On Thu, Mar 26, 2015 at 02:35:58AM +0300, Andrey Korolyov wrote:
> > > Thanks, strangely the reboot is always failing now and always reaching
> > > seabios greeting. May be prints straightened
2015-03-25 20:05-0400, Kevin O'Connor:
> On Thu, Mar 26, 2015 at 02:35:58AM +0300, Andrey Korolyov wrote:
> > Thanks, strangely the reboot is always failing now and always reaching
> > seabios greeting. May be prints straightened up a race (e.g. it is not
> > int19 problem really).
> >
> > object
On Thu, Mar 26, 2015 at 12:18 PM, Andrey Korolyov wrote:
> On Thu, Mar 26, 2015 at 5:47 AM, Bandan Das wrote:
>> Hi Andrey,
>>
>> Andrey Korolyov writes:
>>
>>> On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov wrote:
For now, it looks like bug have a mixed Murphy-Heisenberg nature, as
>>>
On Thu, Mar 26, 2015 at 5:47 AM, Bandan Das wrote:
> Hi Andrey,
>
> Andrey Korolyov writes:
>
>> On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov 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 laun
Hi Andrey,
Andrey Korolyov writes:
> On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov 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 characteri
On Thu, Mar 26, 2015 at 02:35:58AM +0300, Andrey Korolyov wrote:
> Thanks, strangely the reboot is always failing now and always reaching
> seabios greeting. May be prints straightened up a race (e.g. it is not
> int19 problem really).
>
> object file part:
>
> d331 :
> irq_trampoline_0x19():
On Thu, Mar 26, 2015 at 2:02 AM, Kevin O'Connor wrote:
> On Thu, Mar 26, 2015 at 01:31:11AM +0300, Andrey Korolyov wrote:
>> On Wed, Mar 25, 2015 at 11:54 PM, Kevin O'Connor wrote:
>> >
>> > Can you add something like:
>> >
>> > -chardev file,path=seabioslog.`date +%s`,id=seabios -device
>> >
On Thu, Mar 26, 2015 at 01:31:11AM +0300, Andrey Korolyov wrote:
> On Wed, Mar 25, 2015 at 11:54 PM, Kevin O'Connor wrote:
> >
> > Can you add something like:
> >
> > -chardev file,path=seabioslog.`date +%s`,id=seabios -device
> > isa-debugcon,iobase=0x402,chardev=seabios
> >
> > to the qemu co
On Wed, Mar 25, 2015 at 11:54 PM, Kevin O'Connor 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 wrote:
>> > For now, it looks like bug have a mixed Murphy-Heisenberg nature, as
>> > it appearance is very rare (compare
On Wed, Mar 25, 2015 at 11:43:31PM +0300, Andrey Korolyov wrote:
> On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov 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 boun
> - attach serial console (I am using virsh list for this exact purpose),
virsh console of course, sorry
On Mon, Mar 16, 2015 at 10:17 PM, Andrey Korolyov 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
* Andrey Korolyov (and...@xdel.ru) 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 repr
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 environmen
On Thu, Mar 12, 2015 at 12:59 PM, Dr. David Alan Gilbert
wrote:
> * Andrey Korolyov (and...@xdel.ru) wrote:
>> On Wed, Mar 11, 2015 at 10:59 PM, Dr. David Alan Gilbert
>> wrote:
>> > * Andrey Korolyov (and...@xdel.ru) wrote:
>> >> On Wed, Mar 11, 2015 at 10:33 PM, Dr. David Alan Gilbert
>> >> wr
* Andrey Korolyov (and...@xdel.ru) wrote:
> On Wed, Mar 11, 2015 at 10:59 PM, Dr. David Alan Gilbert
> wrote:
> > * Andrey Korolyov (and...@xdel.ru) wrote:
> >> On Wed, Mar 11, 2015 at 10:33 PM, Dr. David Alan Gilbert
> >> wrote:
> >> > * Kevin O'Connor (ke...@koconnor.net) wrote:
> >> >> On Wed,
On 10/03/2015 19:16, Dr. David Alan Gilbert wrote:
> KVM internal error. Suberror: 1
> emulation failure
> EAX= EBX= ECX= EDX=000fd2bc
> ESI= EDI= EBP= ESP=
> EIP=000fd2c5 EFL=00010007 [-PC] CPL=0 II=0 A20=1 SMM=0 HLT=0
> ES =0010 00
* Andrey Korolyov (and...@xdel.ru) wrote:
> On Sat, Mar 7, 2015 at 3:00 AM, Andrey Korolyov wrote:
> > On Fri, Mar 6, 2015 at 7:57 PM, Bandan Das wrote:
> >> Andrey Korolyov writes:
> >>
> >>> On Fri, Mar 6, 2015 at 1:14 AM, Andrey Korolyov wrote:
> Hello,
>
> recently I`ve got a
On Wed, Mar 11, 2015 at 10:59 PM, Dr. David Alan Gilbert
wrote:
> * Andrey Korolyov (and...@xdel.ru) wrote:
>> On Wed, Mar 11, 2015 at 10:33 PM, Dr. David Alan Gilbert
>> wrote:
>> > * Kevin O'Connor (ke...@koconnor.net) wrote:
>> >> On Wed, Mar 11, 2015 at 02:45:31PM -0400, Kevin O'Connor wrote:
* Andrey Korolyov (and...@xdel.ru) wrote:
> On Wed, Mar 11, 2015 at 10:33 PM, Dr. David Alan Gilbert
> wrote:
> > * Kevin O'Connor (ke...@koconnor.net) wrote:
> >> On Wed, Mar 11, 2015 at 02:45:31PM -0400, Kevin O'Connor wrote:
> >> > On Wed, Mar 11, 2015 at 02:40:39PM -0400, Kevin O'Connor wrote:
On Wed, Mar 11, 2015 at 10:33 PM, Dr. David Alan Gilbert
wrote:
> * Kevin O'Connor (ke...@koconnor.net) wrote:
>> On Wed, Mar 11, 2015 at 02:45:31PM -0400, Kevin O'Connor wrote:
>> > On Wed, Mar 11, 2015 at 02:40:39PM -0400, Kevin O'Connor wrote:
>> > > For what it's worth, I can't seem to trigger
"Dr. David Alan Gilbert" writes:
> * Kevin O'Connor (ke...@koconnor.net) wrote:
>> On Wed, Mar 11, 2015 at 02:45:31PM -0400, Kevin O'Connor wrote:
>> > On Wed, Mar 11, 2015 at 02:40:39PM -0400, Kevin O'Connor wrote:
>> > > For what it's worth, I can't seem to trigger the problem if I move the
>>
* Kevin O'Connor (ke...@koconnor.net) wrote:
> On Wed, Mar 11, 2015 at 02:45:31PM -0400, Kevin O'Connor wrote:
> > On Wed, Mar 11, 2015 at 02:40:39PM -0400, Kevin O'Connor wrote:
> > > For what it's worth, I can't seem to trigger the problem if I move the
> > > cmos read above the SIPI/LAPIC code (
On Wed, Mar 11, 2015 at 02:45:31PM -0400, Kevin O'Connor wrote:
> On Wed, Mar 11, 2015 at 02:40:39PM -0400, Kevin O'Connor wrote:
> > For what it's worth, I can't seem to trigger the problem if I move the
> > cmos read above the SIPI/LAPIC code (see patch below).
>
> Ugh!
>
> That's a seabios bug
On Wed, Mar 11, 2015 at 02:40:39PM -0400, Kevin O'Connor wrote:
> For what it's worth, I can't seem to trigger the problem if I move the
> cmos read above the SIPI/LAPIC code (see patch below).
Ugh!
That's a seabios bug. Main processor modifies the rtc index
(rtc_read()) while APs try to clear t
On Wed, Mar 11, 2015 at 05:59:04PM +, Dr. David Alan Gilbert wrote:
> * Kevin O'Connor (ke...@koconnor.net) wrote:
> > On Wed, Mar 11, 2015 at 04:52:03PM +, Dr. David Alan Gilbert wrote:
> > > * Kevin O'Connor (ke...@koconnor.net) wrote:
> > > > So, I couldn't get this to fail on my older A
"Dr. David Alan Gilbert" writes:
> * Kevin O'Connor (ke...@koconnor.net) wrote:
>> On Wed, Mar 11, 2015 at 04:52:03PM +, Dr. David Alan Gilbert wrote:
>> > * Kevin O'Connor (ke...@koconnor.net) wrote:
>> > > So, I couldn't get this to fail on my older AMD machine at all with
>> > > the defaul
"Kevin O'Connor" writes:
> On Wed, Mar 11, 2015 at 01:09:42PM -0400, Bandan Das wrote:
>> "Kevin O'Connor" writes:
>> ...
>> >
>> > 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 f
* Kevin O'Connor (ke...@koconnor.net) wrote:
> On Wed, Mar 11, 2015 at 04:52:03PM +, Dr. David Alan Gilbert wrote:
> > * Kevin O'Connor (ke...@koconnor.net) wrote:
> > > So, I couldn't get this to fail on my older AMD machine at all with
> > > the default SeaBIOS code. But, when I change the c
On 11/03/2015 18:37, Kevin O'Connor wrote:
> > I'm going to check the assembly for a compiler error, but is it
> > possible QEMU is returning incorrect data in cmos index 0x5f?
>
> I checked the SeaBIOS assembler and it looks sane. So, I think the
> question is, why is QEMU sometimes returning
On Wed, Mar 11, 2015 at 04:52:03PM +, Dr. David Alan Gilbert wrote:
> * Kevin O'Connor (ke...@koconnor.net) wrote:
> > So, I couldn't get this to fail on my older AMD machine at all with
> > the default SeaBIOS code. But, when I change the code with the patch
> > below, it failed right away.
[
On Wed, Mar 11, 2015 at 01:09:42PM -0400, Bandan Das wrote:
> "Kevin O'Connor" writes:
> ...
> >
> > 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
"Kevin O'Connor" writes:
...
>
> 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 tel
* Kevin O'Connor (ke...@koconnor.net) wrote:
> On Wed, Mar 11, 2015 at 03:53:07PM +, Dr. David Alan Gilbert wrote:
> > * Kevin O'Connor (ke...@koconnor.net) wrote:
> > > On Wed, Mar 11, 2015 at 01:45:57PM +, Dr. David Alan Gilbert wrote:
> > > > * Bandan Das (b...@redhat.com) wrote:
> > > >
On Wed, Mar 11, 2015 at 03:53:07PM +, Dr. David Alan Gilbert wrote:
> * Kevin O'Connor (ke...@koconnor.net) wrote:
> > On Wed, Mar 11, 2015 at 01:45:57PM +, Dr. David Alan Gilbert wrote:
> > > * Bandan Das (b...@redhat.com) wrote:
> > > > "Dr. David Alan Gilbert" writes:
> > > > > while tr
* Kevin O'Connor (ke...@koconnor.net) wrote:
> On Wed, Mar 11, 2015 at 01:45:57PM +, Dr. David Alan Gilbert wrote:
> > * Bandan Das (b...@redhat.com) wrote:
> > > "Dr. David Alan Gilbert" writes:
> > > > while true; do (sleep 5; echo -e
> > > > '\001cq\n')|/opt/qemu-try-world3/bin/qemu-system
On Wed, Mar 11, 2015 at 01:45:57PM +, Dr. David Alan Gilbert wrote:
> * Bandan Das (b...@redhat.com) wrote:
> > "Dr. David Alan Gilbert" 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
* Bandan Das (b...@redhat.com) wrote:
> "Dr. David Alan Gilbert" writes:
>
> > * Paolo Bonzini (pbonz...@redhat.com) wrote:
> >>
> >>
> >> On 10/03/2015 19:21, Bandan Das wrote:
> >> > Paolo Bonzini writes:
> >> >
> >> >> On 10/03/2015 17:57, Dr. David Alan Gilbert wrote:
> >> >>> I'm seeing
"Dr. David Alan Gilbert" writes:
> * Paolo Bonzini (pbonz...@redhat.com) wrote:
>>
>>
>> On 10/03/2015 19:21, Bandan Das wrote:
>> > Paolo Bonzini writes:
>> >
>> >> On 10/03/2015 17:57, Dr. David Alan Gilbert wrote:
>> >>> I'm seeing something similar; it's very intermittent and generally
>>
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 10/03/2015 19:21, Bandan Das wrote:
> > Paolo Bonzini writes:
> >
> >> On 10/03/2015 17:57, Dr. David Alan Gilbert wrote:
> >>> I'm seeing something similar; it's very intermittent and generally
> >>> happening right at boot of the guest;
* Paolo Bonzini (pbonz...@redhat.com) wrote:
>
>
> On 10/03/2015 19:21, Bandan Das wrote:
> > Paolo Bonzini writes:
> >
> >> On 10/03/2015 17:57, Dr. David Alan Gilbert wrote:
> >>> I'm seeing something similar; it's very intermittent and generally
> >>> happening right at boot of the guest;
On 10/03/2015 19:21, Bandan Das wrote:
> Paolo Bonzini writes:
>
>> On 10/03/2015 17:57, Dr. David Alan Gilbert wrote:
>>> I'm seeing something similar; it's very intermittent and generally
>>> happening right at boot of the guest; I'm running this on qemu
>>> head+my postcopy world (but it's
Paolo Bonzini writes:
> On 10/03/2015 17:57, Dr. David Alan Gilbert wrote:
>> I'm seeing something similar; it's very intermittent and generally
>> happening right at boot of the guest; I'm running this on qemu
>> head+my postcopy world (but it's happening right at boot before postcopy
>> gets
On Tue, Mar 10, 2015 at 9:16 PM, Dr. David Alan Gilbert
wrote:
> * Andrey Korolyov (and...@xdel.ru) wrote:
>> On Tue, Mar 10, 2015 at 7:57 PM, Dr. David Alan Gilbert
>> wrote:
>> > * Andrey Korolyov (and...@xdel.ru) wrote:
>> >> On Sat, Mar 7, 2015 at 3:00 AM, Andrey Korolyov wrote:
>> >> > On F
* Andrey Korolyov (and...@xdel.ru) wrote:
> On Tue, Mar 10, 2015 at 7:57 PM, Dr. David Alan Gilbert
> wrote:
> > * Andrey Korolyov (and...@xdel.ru) wrote:
> >> On Sat, Mar 7, 2015 at 3:00 AM, Andrey Korolyov wrote:
> >> > On Fri, Mar 6, 2015 at 7:57 PM, Bandan Das wrote:
> >> >> Andrey Korolyov
On 10/03/2015 17:57, Dr. David Alan Gilbert wrote:
> I'm seeing something similar; it's very intermittent and generally
> happening right at boot of the guest; I'm running this on qemu
> head+my postcopy world (but it's happening right at boot before postcopy
> gets a chance), and I'm using a 3
On Tue, Mar 10, 2015 at 7:57 PM, Dr. David Alan Gilbert
wrote:
> * Andrey Korolyov (and...@xdel.ru) wrote:
>> On Sat, Mar 7, 2015 at 3:00 AM, Andrey Korolyov wrote:
>> > On Fri, Mar 6, 2015 at 7:57 PM, Bandan Das wrote:
>> >> Andrey Korolyov writes:
>> >>
>> >>> On Fri, Mar 6, 2015 at 1:14 AM,
On Sat, Mar 7, 2015 at 3:00 AM, Andrey Korolyov wrote:
> On Fri, Mar 6, 2015 at 7:57 PM, Bandan Das wrote:
>> Andrey Korolyov writes:
>>
>>> On Fri, Mar 6, 2015 at 1:14 AM, Andrey Korolyov wrote:
Hello,
recently I`ve got a couple of shiny new Intel 2620v2s for future
replace
On Fri, Mar 6, 2015 at 7:57 PM, Bandan Das wrote:
> Andrey Korolyov writes:
>
>> On Fri, Mar 6, 2015 at 1:14 AM, Andrey Korolyov wrote:
>>> Hello,
>>>
>>> recently I`ve got a couple of shiny new Intel 2620v2s for future
>>> replacement of the E5-2620v1, but I experienced relatively many events
>
Andrey Korolyov writes:
> On Fri, Mar 6, 2015 at 1:14 AM, Andrey Korolyov wrote:
>> Hello,
>>
>> recently I`ve got a couple of shiny new Intel 2620v2s for future
>> replacement of the E5-2620v1, but I experienced relatively many events
>> with emulation errors, all traces looks simular to the on
On Fri, Mar 6, 2015 at 1:14 AM, Andrey Korolyov wrote:
> Hello,
>
> recently I`ve got a couple of shiny new Intel 2620v2s for future
> replacement of the E5-2620v1, but I experienced relatively many events
> with emulation errors, all traces looks simular to the one below. I am
> running qemu-2.1
Hello,
recently I`ve got a couple of shiny new Intel 2620v2s for future
replacement of the E5-2620v1, but I experienced relatively many events
with emulation errors, all traces looks simular to the one below. I am
running qemu-2.1 on x86 on top of 3.10 branch for testing purposes but
can switch to
83 matches
Mail list logo
