On Tue, Sep 10, 2013 at 4:29 AM, John Stultz <john.stu...@linaro.org> wrote:
[snip] > > So I think I've managed to finally reproduce this and hunt it down. > > With Peter's "sched: Fix HRTICK" patch and HRTICK enabled, I found I > could trigger a hard hang at boot on my x86_64 kvm system. sysrq didn't > function, so I checked out info cpus and that pointed to both cpus being Hi, Is "info cpus" a command of kvm/qemu? That's very helpful. I can reproduce this bug, but there is no any output. How did you find out that both cpus being in ktime_get() and ktime_get_update_offsets(). > in ktime_get() and ktime_get_update_offsets(), which suggested a > seqcount deadlock (basically calling something that reads the seqlock > while we hold the write on it). HRTICK enabled, then I can reproduce this simply with, while [ 1 ] ; adjtimex -t 9999 done And your patch fixed it. Thanks, Lin Ming > > Unfortunately the seqlock/seqcount infrastructure doesn't support > lockdep, so I added some debug code to take and release the > timekeeper_lock in every function that does a read on the timekeeper_seq. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/