>> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
