Subject: v3.13-rc6+ regression (ARM board)

From: [email-masked] (Krzysztof Hałasa)
Date: Thu, 02 Jan 2014 13:07:30 +0100

Hello Uwe,

>> >> There seems to be a regression in v3.13-rc6+ (up to current tip =
>> >> 71ce176ee6ed1735b9a1160a5704a915d13849b1).
>> >>
>> >> Board is Gateworks Cambria, CPU Intel IXP435 ARM big endian, gcc 4.7.3.
>> >> The board boots correctly and works (shell mostly, and SSHD) for about
>> >> 50 seconds. After 52-54 seconds, it frozes dead without any console
>> >> (UART) output.

Merging 1ca7d67cf5d5a2aef26a8d9afd789006fa098347 with
85c3d2dd15be4d577a37ffb8bbbd019fc8e3280a = issue, but

merging 1ca7d67cf5d5a2aef26a8d9afd789006fa098347 with
85c3d2dd15be4d577a37ffb8bbbd019fc8e3280a~1 = no issue.

This means these two commits don't like each other:

commit 1ca7d67cf5d5a2aef26a8d9afd789006fa098347
Author: John Stultz <[email-masked]>
Date:   Mon Oct 7 15:51:59 2013 -0700

    seqcount: Add lockdep functionality to seqcount/seqlock structures

    Currently seqlocks and seqcounts don't support lockdep.

    After running across a seqcount related deadlock in the timekeeping
    code, I used a less-refined and more focused variant of this patch
    to narrow down the cause of the issue.

    This is a first-pass attempt to properly enable lockdep functionality
    on seqlocks and seqcounts.

    Since seqcounts are used in the vdso gettimeofday code, I've provided
    non-lockdep accessors for those needs.

    I've also handled one case where there were nested seqlock writers
    and there may be more edge cases.

    Comments and feedback would be appreciated!

    Signed-off-by: John Stultz <[email-masked]>
    Signed-off-by: Peter Zijlstra <[email-masked]>
    Cc: Eric Dumazet <[email-masked]>
    Cc: Li Zefan <[email-masked]>
    Cc: Mathieu Desnoyers <[email-masked]>
    Cc: Steven Rostedt <[email-masked]>
    Cc: "David S. Miller" <[email-masked]>
    Cc: netdev at vger.kernel.org
    Link: http://lkml.kernel.org/r/1381186321-4906-3-git-send-email-john.stultz at linaro.org
    Signed-off-by: Ingo Molnar <[email-masked]>

 arch/x86/vdso/vclock_gettime.c |  8 ++++---- (not used on this machine)
 fs/dcache.c                    |  4 ++--
 fs/fs_struct.c                 |  2 +-
 include/linux/init_task.h      |  8 ++++----
 include/linux/lockdep.h        |  8 ++++++--
 include/linux/seqlock.h        | 79 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------
 mm/filemap_xip.c               |  2 +-       (not used on this machine)
 7 files changed, 90 insertions(+), 21 deletions(-)

and:

commit 85c3d2dd15be4d577a37ffb8bbbd019fc8e3280a
Author: Stephen Boyd <[email-masked]>
Date:   Thu Jul 18 16:21:15 2013 -0700

    sched_clock: Use seqcount instead of rolling our own

    We're going to increase the cyc value to 64 bits in the near
    future. Doing that is going to break the custom seqcount
    implementation in the sched_clock code because 64 bit numbers
    aren't guaranteed to be atomic. Replace the cyc_copy with a
    seqcount to avoid this problem.

    Cc: Russell King <[email-masked]>
    Acked-by: Will Deacon <[email-masked]>
    Signed-off-by: Stephen Boyd <[email-masked]>
    Signed-off-by: John Stultz <[email-masked]>

 kernel/time/sched_clock.c | 27 ++++++++-------------------
 1 file changed, 8 insertions(+), 19 deletions(-)
-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland