lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ