Linus Torvalds writes:
> --- a/kernel/time/sched_clock.c
> +++ b/kernel/time/sched_clock.c
> @@ -36,6 +36,7 @@ core_param(irqtime, irqtime, int, 0400);
>
>static struct clock_data cd = {
> .mult = NSEC_PER_SEC / HZ,
> + .seq = SEQCNT_ZERO(cd.seq),
>};
>
>stat
On 01/02/2014 12:43 PM, Linus Torvalds wrote:
> On Thu, Jan 2, 2014 at 12:30 PM, John Stultz wrote:
>> So something else may be at play. Even with Linus' patch I reproduced a
>> similar hang here.
>>
>> Still chasing it down, but it looks like a seqlock deadlock where we're
>> calling read while h
On 01/02/2014 12:42 PM, Stephen Boyd wrote:
> On 01/02/14 12:30, John Stultz wrote:
>> On 01/02/2014 12:03 PM, John Stultz wrote:
>>> On 01/02/2014 11:38 AM, Linus Torvalds wrote:
On Thu, Jan 2, 2014 at 4:07 AM, Krzysztof Hałasa wrote:
> This means these two commits don't like each other:
On Thu, Jan 2, 2014 at 12:30 PM, John Stultz wrote:
>
> So something else may be at play. Even with Linus' patch I reproduced a
> similar hang here.
>
> Still chasing it down, but it looks like a seqlock deadlock where we're
> calling read while holding the lock.
Hmm. Only with lockdep, right?
D
On 01/02/14 12:30, John Stultz wrote:
> On 01/02/2014 12:03 PM, John Stultz wrote:
>> On 01/02/2014 11:38 AM, Linus Torvalds wrote:
>>> On Thu, Jan 2, 2014 at 4:07 AM, Krzysztof Hałasa wrote:
This means these two commits don't like each other:
seqcount: Add lockdep functionality
On 01/02/2014 12:03 PM, John Stultz wrote:
> On 01/02/2014 11:38 AM, Linus Torvalds wrote:
>> On Thu, Jan 2, 2014 at 4:07 AM, Krzysztof Hałasa wrote:
>>> This means these two commits don't like each other:
>>>
>>> seqcount: Add lockdep functionality to seqcount/seqlock structures
>>> sched
On 01/02/2014 11:38 AM, Linus Torvalds wrote:
> On Thu, Jan 2, 2014 at 4:07 AM, Krzysztof Hałasa wrote:
>> This means these two commits don't like each other:
>>
>> seqcount: Add lockdep functionality to seqcount/seqlock structures
>> sched_clock: Use seqcount instead of rolling our own
>
On Thu, Jan 2, 2014 at 4:07 AM, Krzysztof Hałasa wrote:
>
> This means these two commits don't like each other:
>
> seqcount: Add lockdep functionality to seqcount/seqlock structures
> sched_clock: Use seqcount instead of rolling our own
Does something like this fix it for you?
--- a/k
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
>> >>
Hello Krzysztof,
On Thu, Jan 02, 2014 at 11:02:44AM +0100, Krzysztof Hałasa wrote:
> >> 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
>> 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 secon
On Tue, Dec 31, 2013 at 11:37:21AM +0100, Krzysztof Ha??asa wrote:
> Hi,
>
> 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 w
12 matches
Mail list logo
