On 10/16/2014 11:31 AM, Don Dutile wrote:
On 10/16/2014 05:45 AM, Christoffer Dall wrote:
Hi Joel,
On Wed, Oct 08, 2014 at 04:54:31PM +0200, Christoffer Dall wrote:
On Wed, Oct 08, 2014 at 09:14:09AM -0500, Joel Schopp wrote:
Traced it back to the introduction of NO_HZ. Going from
CONFIG_HZ_PERIODIC to CONFIG_NO_HZ_IDLE or CONFIG_NO_HZ_FULL is
enough
to do it.
Is this specific to running in a VM or do those options break your
host
system as well?
Just the guest. The same kernel boots on the host.
That's concerning.... We could be losing interrupts for some reason.
I tried to reproduce this and I really cannot reproduce it.
I talked to Don Dutile from Red Hat yesterday, and he said he had seen
the same behavior when configuring the NO_HZ incorrectly, something
about the clocksources getting confused and the system times out before
loading the libararies, producing the behavior you're seeing.
Are you setting these options with menuconfig or manually in the .config
file?
It owuld be interesting if you could do a blank defconfig and enable the
NO_HZ options through a menuconfig and see if you can reproduce that
way?
Thanks,
-Christoffer
Here are my (working) timer config options:
#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
If I recall correctly, having NO_HZ_FULL set to y
is what broke my kernel with similar stack trace that Christoffer
showed me yesterday.
I also had CONFIG_NO_HZ_FULL set in my broken config but not in the
working one.
_______________________________________________
kvmarm mailing list
kvmarm@xxxxxxxxxxxxxxxxxxxxx
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
