lkml.org 
[lkml]   [2013]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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



\
 
 \ /
  Last update: 2013-09-10 19:01    [W:0.082 / U:0.400 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site