[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <466E40BD.8080001@qumranet.com>
Date: Tue, 12 Jun 2007 09:44:13 +0300
From: Avi Kivity <avi@...ranet.com>
To: Luca <kronos.it@...il.com>
CC: kvm-devel@...ts.sf.net, linux-kernel@...r.kernel.org
Subject: Re: [kvm-devel] [BUG] Oops with KVM-27
Luca wrote:
> On 6/11/07, Avi Kivity <avi@...ranet.com> wrote:
>> Luca wrote:
>> >>
>> >> I've managed to reproduce this on kvm-21 (it takes many boots for
>> this
>> >> to happen, but it does eventually).
>> >
>> > Hum, any clue on the cause?
>>
>> From what I've seen, it's the new Linux clocksource code.
>
> Actually I tried forcing the PIT (and any other combination of
> tsc,acpi_pm,jiffies) as the clocksource, without success.
>
Well, there's lots of APIC stuff going on when it hangs.
>> > Should I test older versions?
>>
>> They're unlikely to be better. Instead, it would be best to see what
>> the guest is doing.
>>
>> I suggest downloading the source rpm for the kernel, building it, and
>> sprinkling printk()s until we know exactly what source the guest is
>> executing at the time of the hang.
>
> Ok, will do. Meanwhile I discovered that the kernel on the boot cd
> (the one that hangs) is compiled for i586, while the one installed on
> disk is for i686 (this one works).
Ah.
>
> i686 has this options enabled:
>
> +CONFIG_X86_GOOD_APIC=y
> +CONFIG_X86_USE_PPRO_CHECKSUM=y
> +CONFIG_X86_TSC=y
>
> but disabling tsc on the command line doesn't make any difference. Is
> it possible that KVM is choking on some instruction not used by the
> i686 kernel?
Unlikely, as then the hang would occur all the time instead of randomly.
--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists