On Fri, Mar 27, 2015 at 12:03 AM, Bandan Das <bsd@xxxxxxxxxx> wrote: > Radim Krčmář <rkrcmar@xxxxxxxxxx> writes: > >> 2015-03-26 21:24+0300, Andrey Korolyov: >>> On Thu, Mar 26, 2015 at 8:40 PM, Radim Krčmář <rkrcmar@xxxxxxxxxx> wrote: >>> > 2015-03-26 20:08+0300, Andrey Korolyov: >>> >> KVM internal error. Suberror: 2 >>> >> extra data[0]: 800000ef >>> >> extra data[1]: 80000b0d >>> > >>> > Btw. does this part ever change? >>> > >>> > I see that first report had: >>> > >>> > KVM internal error. Suberror: 2 >>> > extra data[0]: 800000d1 >>> > extra data[1]: 80000b0d >>> > >>> > Was that a Windows guest by any chance? >>> >>> Yes, exactly, different extra data output was from a Windows VMs. >> >> Windows uses vector 0xd1 for timer interrupts. > >> 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 related, a run without apicv enabled could give more hints. > > Your "devices not getting reset" hypothesis makes the most sense to me, > maybe the timer vector in the error message is just one part of > the whole story. Another misbehaving interrupt from the dark comes in at the > same time and leads to a double fault. Default trace (APICv enabled, first reboot introduced the issue): http://xdel.ru/downloads/kvm-e5v2-issue/hanged-reboot-apic-on.dat.gz Trace without APICv (three reboots, just to make sure to hit the problematic condition of supposed DF, as it still have not one hundred percent reproducibility): http://xdel.ru/downloads/kvm-e5v2-issue/apic-off.dat.gz It would be great of course to reproduce this somewhere else, otherwise all this thread may end in fixing a bug which exists only at my particular platform. Right now I have no hardware except a lot of well-known (in terms of existing issues) Supermicro boards of one model. -- 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