Messages in this thread | | | From | (Krzysztof Hałasa) | Date | Thu, 02 Jan 2014 11:02:44 +0100 | Subject | Re: v3.13-rc6+ regression (ARM board) |
| |
>> 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
| |