> On September 15, 2014 at 12:48 PM Erik Rull <erik.rull@xxxxxxxxxxxxx> wrote: > > > > On September 12, 2014 at 7:29 PM Jan Kiszka <jan.kiszka@xxxxxxxxxxx> wrote: > > > > > > On 2014-09-12 19:15, Jan Kiszka wrote: > > > On 2014-09-12 14:29, Erik Rull wrote: > > >>> On September 11, 2014 at 3:32 PM Jan Kiszka <jan.kiszka@xxxxxxxxxxx> > > >>> wrote: > > >>> > > >>> > > >>> On 2014-09-11 15:25, Erik Rull wrote: > > >>>>> On August 6, 2014 at 1:19 PM Erik Rull <erik.rull@xxxxxxxxxxxxx> > > >>>>> wrote: > > >>>>> > > >>>>> > > >>>>> Hi all, > > >>>>> > > >>>>> I did already several tests and I'm not completely sure what's going > > >>>>> wrong, > > >>>>> but > > >>>>> here my scenario: > > >>>>> > > >>>>> When I start up QEMU w/ KVM 1.7.0 on a Core2Duo machine running a > > >>>>> vanilla > > >>>>> kernel > > >>>>> 3.4.67 to run a Windows 8.0 guest, the guest freezes at boot without > > >>>>> any > > >>>>> error. > > >>>>> When I dump the CPU registers via "info registers", nothing changes, > > >>>>> that > > >>>>> means > > >>>>> the system really stalled. Same happens with QEMU 2.0.0. > > >>>>> > > >>>>> But - when I run the very same guest using Kernel 2.6.32.12 and QEMU > > >>>>> 1.7.0 > > >>>>> on > > >>>>> the host side it works on the Core2Duo. Also the system above but just > > >>>>> with > > >>>>> an > > >>>>> i3 or i5 CPU it works, too. > > >>>>> > > >>>>> I already disabled networking and USB for the guest and changed the > > >>>>> graphics > > >>>>> card - no effect. I assume that some mean bits and bytes have to be > > >>>>> set > > >>>>> up > > >>>>> properly to get the thing running. > > >>>>> > > >>>>> Any hint what to change / test would be really appreciated. > > >>>>> > > >>>>> Thanks in advance, > > >>>>> > > >>>>> Best regards, > > >>>>> > > >>>>> Erik > > >>>>> > > >>>> > > >>>> Hi all, > > >>>> > > >>>> I opened a qemu bug report on that and Jan helped me creating a kvm > > >>>> trace. I > > >>>> attached it to the bug report. > > >>>> https://bugs.launchpad.net/qemu/+bug/1366836 > > >>>> > > >>>> If you have further questions, please let me know. > > >>> > > >>> "File possibly truncated. Need at least 346583040, but file size is > > >>> 133414912." > > >>> > > >>> Does "trace-cmd report" work for you? Is your file larger? > > >>> > > >>> Again, please also validate the behavior on latest next branch from > > >>> kvm.git. > > >>> > > >>> Jan > > >>> > > >> > > >> Hi all, > > >> > > >> confirmed. The issue is still existing in the kvm.git Version of the > > >> kernel. > > >> The trace.tgz was uploaded to the bugtracker. > > > > > > Thanks. Could you provide a good-case of your setup as well, i.e. with > > > that older kernel version? At least I'm not yet seeing something > > > obviously wrong. > > > > Well, except that we have continuously EXTERNAL_INTERRUPTs, vector 0xf6, > > throughout most of the trace. Maybe a self-IPI (this is single-core), > > maybe something external that is stuck. You could do a full trace (-e > > all) and check for what happens after things like > > > > kvm_exit: reason EXTERNAL_INTERRUPT rip 0x8168ed83 info 0 800000ef > > > > Jan > > > > I captured the trace log (-e all) and uploaded it to the bug tracker. I was > not > yet able to get trace-cmd running for my old 2.6.32.12 kernel, as soon as I > get > it working, I'll send the -e all trace. > > Best regards, > > Erik The splice command is not available before glibc-2.5 in userspace, but my old system runs on glibc-2.3.6, so trace-cmd will never compile and run there, sorry :-( Best regards, Erik -- 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