Messages in this thread | | | Date | Tue, 10 Sep 2013 16:59:09 +0800 | Subject | Re: kernel deadlock | From | Lin Ming <> |
| |
On Tue, Sep 10, 2013 at 4:29 AM, John Stultz <john.stultz@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.
| |