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

[Krzysztof HaÅasa]

>> 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.
>>
>> Bisecting shows 5e30025a319910695f5010dc0fb53a23299da14d as the first
>> bad commit. Interestingly it's a merge:

Reverting 1ca7d67cf5d5a2aef26a8d9afd789006fa098347 on top of current tip
(9a0bb2966efbf30a71c128c3af63307d8b5f5fc0) fixes my issue.

What now?

1ca7d67cf5d5a2aef26a8d9afd789006fa098347:
    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!
-- 
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/