On Tuesday 27 May 2014 19:28:06 Corey Minyard wrote:
> On 05/27/2014 02:27 PM, Arnd Bergmann wrote:
> > On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
> >> On 05/27/14 11:49, Arnd Bergmann wrote:
> >>> You also commented in that thread about stop_critical_timings()/
> >>>
On Tuesday 27 May 2014 19:28:06 Corey Minyard wrote:
On 05/27/2014 02:27 PM, Arnd Bergmann wrote:
On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
On 05/27/14 11:49, Arnd Bergmann wrote:
You also commented in that thread about stop_critical_timings()/
start_critical_timings(). Corey,
On 05/27/2014 02:27 PM, Arnd Bergmann wrote:
> On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
>> On 05/27/14 11:49, Arnd Bergmann wrote:
>>> You also commented in that thread about stop_critical_timings()/
>>> start_critical_timings(). Corey, can you look at that, too? I
>>> think it's
On 05/27/14 12:39, Arnd Bergmann wrote:
> On Tuesday 27 May 2014 12:33:38 Stephen Boyd wrote:
>> On 05/27/14 12:27, Arnd Bergmann wrote:
>>> On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
On 05/27/14 11:49, Arnd Bergmann wrote:
> You also commented in that thread about
On Tuesday 27 May 2014 12:33:38 Stephen Boyd wrote:
> On 05/27/14 12:27, Arnd Bergmann wrote:
> > On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
> >> On 05/27/14 11:49, Arnd Bergmann wrote:
> >>> You also commented in that thread about stop_critical_timings()/
> >>> start_critical_timings().
On 05/27/14 12:27, Arnd Bergmann wrote:
> On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
>> On 05/27/14 11:49, Arnd Bergmann wrote:
>>> You also commented in that thread about stop_critical_timings()/
>>> start_critical_timings(). Corey, can you look at that, too? I
>>> think it's designed to
On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
> On 05/27/14 11:49, Arnd Bergmann wrote:
> >
> > You also commented in that thread about stop_critical_timings()/
> > start_critical_timings(). Corey, can you look at that, too? I
> > think it's designed to avoid the issue you are seeing but
> >
On 05/27/14 11:49, Arnd Bergmann wrote:
>
> You also commented in that thread about stop_critical_timings()/
> start_critical_timings(). Corey, can you look at that, too? I
> think it's designed to avoid the issue you are seeing but
> for some reason doesn't.
I sent a patch last week to "solve"
On 05/27/2014 11:16 AM, Arnd Bergmann wrote:
> On Tuesday 27 May 2014, Corey Minyard wrote:
>> On 05/26/2014 04:26 AM, Arnd Bergmann wrote:
>>> On Sunday 25 May 2014 14:15:23 miny...@acm.org wrote:
From: Corey Minyard
The CPU will go to idle with interrupts off, but the interrupts
On Tuesday 27 May 2014 18:38:33 Stanislav Meduna wrote:
> On 26.05.2014 11:26, Arnd Bergmann wrote:
>
> > It seems like the right thing to do, I just don't understand
> > why nobody hit this before.
>
> Looks like this is what I did hit a month ago and
> was not able to find the culprit:
>
On 26.05.2014 11:26, Arnd Bergmann wrote:
> It seems like the right thing to do, I just don't understand
> why nobody hit this before.
Looks like this is what I did hit a month ago and
was not able to find the culprit:
http://www.spinics.net/lists/linux-rt-users/msg11656.html
> How exactly do
On Tuesday 27 May 2014, Corey Minyard wrote:
> On 05/26/2014 04:26 AM, Arnd Bergmann wrote:
> > On Sunday 25 May 2014 14:15:23 miny...@acm.org wrote:
> >> From: Corey Minyard
> >>
> >> The CPU will go to idle with interrupts off, but the interrupts
> >> will wake up the idle. This was causing
On 05/26/2014 04:26 AM, Arnd Bergmann wrote:
> On Sunday 25 May 2014 14:15:23 miny...@acm.org wrote:
>> From: Corey Minyard
>>
>> The CPU will go to idle with interrupts off, but the interrupts
>> will wake up the idle. This was causing very long irqsoff trace
>> values because, basically, the
On 05/26/2014 04:26 AM, Arnd Bergmann wrote:
On Sunday 25 May 2014 14:15:23 miny...@acm.org wrote:
From: Corey Minyard cminy...@mvista.com
The CPU will go to idle with interrupts off, but the interrupts
will wake up the idle. This was causing very long irqsoff trace
values because,
On Tuesday 27 May 2014, Corey Minyard wrote:
On 05/26/2014 04:26 AM, Arnd Bergmann wrote:
On Sunday 25 May 2014 14:15:23 miny...@acm.org wrote:
From: Corey Minyard cminy...@mvista.com
The CPU will go to idle with interrupts off, but the interrupts
will wake up the idle. This was
On 26.05.2014 11:26, Arnd Bergmann wrote:
It seems like the right thing to do, I just don't understand
why nobody hit this before.
Looks like this is what I did hit a month ago and
was not able to find the culprit:
http://www.spinics.net/lists/linux-rt-users/msg11656.html
How exactly do you
On Tuesday 27 May 2014 18:38:33 Stanislav Meduna wrote:
On 26.05.2014 11:26, Arnd Bergmann wrote:
It seems like the right thing to do, I just don't understand
why nobody hit this before.
Looks like this is what I did hit a month ago and
was not able to find the culprit:
On 05/27/2014 11:16 AM, Arnd Bergmann wrote:
On Tuesday 27 May 2014, Corey Minyard wrote:
On 05/26/2014 04:26 AM, Arnd Bergmann wrote:
On Sunday 25 May 2014 14:15:23 miny...@acm.org wrote:
From: Corey Minyard cminy...@mvista.com
The CPU will go to idle with interrupts off, but the interrupts
On 05/27/14 11:49, Arnd Bergmann wrote:
You also commented in that thread about stop_critical_timings()/
start_critical_timings(). Corey, can you look at that, too? I
think it's designed to avoid the issue you are seeing but
for some reason doesn't.
I sent a patch last week to solve this
On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
On 05/27/14 11:49, Arnd Bergmann wrote:
You also commented in that thread about stop_critical_timings()/
start_critical_timings(). Corey, can you look at that, too? I
think it's designed to avoid the issue you are seeing but
for some
On 05/27/14 12:27, Arnd Bergmann wrote:
On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
On 05/27/14 11:49, Arnd Bergmann wrote:
You also commented in that thread about stop_critical_timings()/
start_critical_timings(). Corey, can you look at that, too? I
think it's designed to avoid the
On Tuesday 27 May 2014 12:33:38 Stephen Boyd wrote:
On 05/27/14 12:27, Arnd Bergmann wrote:
On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
On 05/27/14 11:49, Arnd Bergmann wrote:
You also commented in that thread about stop_critical_timings()/
start_critical_timings(). Corey, can you
On 05/27/14 12:39, Arnd Bergmann wrote:
On Tuesday 27 May 2014 12:33:38 Stephen Boyd wrote:
On 05/27/14 12:27, Arnd Bergmann wrote:
On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
On 05/27/14 11:49, Arnd Bergmann wrote:
You also commented in that thread about stop_critical_timings()/
On 05/27/2014 02:27 PM, Arnd Bergmann wrote:
On Tuesday 27 May 2014 11:53:59 Stephen Boyd wrote:
On 05/27/14 11:49, Arnd Bergmann wrote:
You also commented in that thread about stop_critical_timings()/
start_critical_timings(). Corey, can you look at that, too? I
think it's designed to avoid
On Sunday 25 May 2014 14:15:23 miny...@acm.org wrote:
> From: Corey Minyard
>
> The CPU will go to idle with interrupts off, but the interrupts
> will wake up the idle. This was causing very long irqsoff trace
> values because, basically, the whole idle time was traces with
> irqs off, even
On Sunday 25 May 2014 14:15:23 miny...@acm.org wrote:
From: Corey Minyard cminy...@mvista.com
The CPU will go to idle with interrupts off, but the interrupts
will wake up the idle. This was causing very long irqsoff trace
values because, basically, the whole idle time was traces with
irqs
From: Corey Minyard
The CPU will go to idle with interrupts off, but the interrupts
will wake up the idle. This was causing very long irqsoff trace
values because, basically, the whole idle time was traces with
irqs off, even though they weren't really off. Rework the idle
code to turn hardirq
From: Corey Minyard cminy...@mvista.com
The CPU will go to idle with interrupts off, but the interrupts
will wake up the idle. This was causing very long irqsoff trace
values because, basically, the whole idle time was traces with
irqs off, even though they weren't really off. Rework the idle
28 matches
Mail list logo
