On 2012-07-26 12:01, Avi Kivity wrote: > On 07/26/2012 12:52 PM, Chris Clayton wrote: >> On 07/19/12 19:23, Chris Clayton wrote: >>> On 07/19/12 13:17, Avi Kivity wrote: >>>> On 07/19/2012 03:14 PM, Chris Clayton wrote: >>>> >>>>>> Change of diagnostics, unfortunately. qemu-kvm-1.0.1 can, in fact, >>>>>> crash >>>>>> on 3.5.0-rc6 (and rc7). I didn't get it earlier because it takes many >>>>>> times more invocations before the crash occurs with 1.0.1 and I >>>>>> haven't >>>>>> used qemu-kvm much in the past few weeks. >>>>>> >>>>>> I'm now checking whether I can get crashes (with 1.0.1 and/or >>>>>> 1.1.0) on >>>>>> linux-3.4.4. I'll report back in a day or two. >>>>> >>>>> I've started up qemu-kvm on kernel 3.4.4 many times and not see a >>>>> crash. >>>>> That would indicate that the problem is in the kernel. However, I >>>>> pulled >>>>> the latest and greatest from Linus yesterday evening and I now can't >>>>> get >>>>> the crash there either, so whatever it was seems to have been fixed. If >>>>> I checkout and build 3.5.0-rc[1..7], I can get the crash pretty >>>>> quickly, >>>>> so it's been fixed in the last few days. >>>> >>>> There were no kvm changes post-rc7. >>>> >>> Yes, I'm aware of that, Avi. This thread started because I was getting a >>> crash in qemu-kvm, which I thought was only in v1.1.0. Later it turned >>> out the the problem was also present in v1.0.1, but much harder to hit. >>> However, it only ever happened with 3.5.0 kernels. 3.4.4, with either >>> version of qemu-kvm, was stable. So then it seemed that the problem was >>> in the kernel, (but not necessarily in the kvm code). >>> >>> Something that's changed since rc7 has either fixed the problem or made >>> it much harder to hit. With rc7 and earlier I can recreate the crash >>> quite easily with qemu-kvm-1.1.0 and with enough runs of 1.0.1. With >>> rc7+, I haven't been able to get a crash at all. >>> >> Well, I'm getting the crash again, but this time I've managed to get a >> backtrace: >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0xb60ffb40 (LWP 9405)] >> 0xb7803d77 in __strcmp_sse4_2 () from /lib/libc.so.6 >> (gdb) bt >> #0 0xb7803d77 in __strcmp_sse4_2 () from /lib/libc.so.6 >> #1 0xb7e65333 in g_str_equal () from /usr/lib/libglib-2.0.so.0 >> #2 0xb7e6458d in g_hash_table_lookup () from /usr/lib/libglib-2.0.so.0 >> #3 0x8014e2cf in type_table_lookup (name=0x802b0c50 "apic-common") at >> qom/object.c:94 >> #4 type_get_by_name (name=name@entry=0x802b0c50 "apic-common") at >> qom/object.c:149 >> #5 0x8014e933 in object_dynamic_cast (obj=obj@entry=0x80a5d818, >> typename=typename@entry=0x802b0c50 "apic-common") >> at qom/object.c:416 >> #6 0x8014e8b9 in object_dynamic_cast_assert (obj=obj@entry=0x80a5d818, >> typename=typename@entry=0x802b0c50 "apic-common") at qom/object.c:478 >> #7 0x80193462 in cpu_set_apic_tpr (d=0x80a5d818, val=8 '\b') >> at /home/chris/rpm/BUILD/qemu-kvm-1.1.1/hw/apic_common.c:60 >> #8 0x801d0560 in kvm_arch_post_run (env=env@entry=0x80a55a60, >> run=run@entry=0xb6239000) >> at /home/chris/rpm/BUILD/qemu-kvm-1.1.1/target-i386/kvm.c:1695 >> #9 0x801cb05f in kvm_cpu_exec (env=env@entry=0x80a55a60) at >> /home/chris/rpm/BUILD/qemu-kvm-1.1.1/kvm-all.c:1269 >> #10 0x80199d1e in qemu_kvm_cpu_thread_fn (arg=0x80a55a60) at >> /home/chris/rpm/BUILD/qemu-kvm-1.1.1/cpus.c:752 >> #11 0xb7a1fd9e in start_thread () from /lib/libpthread.so.0 >> #12 0xb77bbbbe in clone () from /lib/libc.so.6 >> >> This is with kernel 3.5.0 and qemu-kvm-1.1.1. glibc is 2.16.0 built > > It looks like general memory corruption. Is this repeatable? What's > the guest uptime when it happens (i.e. is it immediate?) > > Jan, why are we calling cpu_set_apic_tpr() with kvm_irqchip_in_kernel? To sync the userspace state with what the kernel maintains. Will end up in kvm_apic_set_tpr which does precisely this. We always did, just the QOM modeling is new. Jan -- Siemens AG, Corporate Technology, CT RTC ITP SDP-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
