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 -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux -- 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
