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

From: Krzysztof HaÅasa
Date: Thu Jan 02 2014 - 07:07:58 EST


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 <john.stultz@xxxxxxxxxx>
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 <john.stultz@xxxxxxxxxx>
Signed-off-by: Peter Zijlstra <peterz@xxxxxxxxxxxxx>
Cc: Eric Dumazet <eric.dumazet@xxxxxxxxx>
Cc: Li Zefan <lizefan@xxxxxxxxxx>
Cc: Mathieu Desnoyers <mathieu.desnoyers@xxxxxxxxxxxx>
Cc: Steven Rostedt <rostedt@xxxxxxxxxxx>
Cc: "David S. Miller" <davem@xxxxxxxxxxxxx>
Cc: netdev@xxxxxxxxxxxxxxx
Link: http://lkml.kernel.org/r/1381186321-4906-3-git-send-email-john.stultz@xxxxxxxxxx
Signed-off-by: Ingo Molnar <mingo@xxxxxxxxxx>

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 <sboyd@xxxxxxxxxxxxxx>
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 <linux@xxxxxxxxxxxxxxxx>
Acked-by: Will Deacon <will.deacon@xxxxxxx>
Signed-off-by: Stephen Boyd <sboyd@xxxxxxxxxxxxxx>
Signed-off-by: John Stultz <john.stultz@xxxxxxxxxx>

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/