lkml.org 
[lkml]   [2014]   [Jan]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: 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


\
 
 \ /
  Last update: 2014-01-02 11:41    [W:0.061 / U:5.144 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site