Messages in this thread | | | Date | Tue, 10 Sep 2013 09:38:44 -0700 | From | John Stultz <> | Subject | Re: kernel deadlock |
| |
On 09/10/2013 01:59 AM, Lin Ming wrote: > 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. Yes. If you switch into the qemu monitor, you can use "info cpus" to show the current instruction pointers
> 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().
Once I had the instruction pointers, I ran gdb on the vmlinux and used "list *<address>" to show where it was stuck.
>> 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.
Great! Can I add a Tested-by: from you on the patch?
thanks -john
| |