Messages in this thread | | | Date | Wed, 11 Sep 2013 08:37:54 +0800 | Subject | Re: kernel deadlock | From | Lin Ming <> |
| |
On Wed, Sep 11, 2013 at 12:38 AM, John Stultz <john.stultz@linaro.org> wrote: > 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?
Sure. Tested-by: Lin Ming <minggr@gmail.com>
Thanks.
| |