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


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