On 01/21/2014 03:17 AM, Steven Rostedt wrote:
> Signed-off-by: Steven Rostedt
>
> diff --git a/kernel/timer.c b/kernel/timer.c
> index 46467be..8212c10 100644
> --- a/kernel/timer.c
> +++ b/kernel/timer.c
> @@ -1464,13 +1464,11 @@ void run_local_timers(void)
>
On 01/21/2014 03:17 AM, Steven Rostedt wrote:
Signed-off-by: Steven Rostedt rost...@goodmis.org
diff --git a/kernel/timer.c b/kernel/timer.c
index 46467be..8212c10 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -1464,13 +1464,11 @@ void run_local_timers(void)
On Mon, 20 Jan 2014 21:17:36 -0500
Steven Rostedt wrote:
> I happen to have a i7 box to test on, and sure enough, the latest
> 3.12-rt locks up on boot and reverting the
> timers-do-not-raise-softirq-unconditionally.patch, it boots fine.
> Signed-off-by: Steven Rostedt
>
> diff --git
On Mon, 20 Jan 2014 21:17:36 -0500
Steven Rostedt rost...@goodmis.org wrote:
I happen to have a i7 box to test on, and sure enough, the latest
3.12-rt locks up on boot and reverting the
timers-do-not-raise-softirq-unconditionally.patch, it boots fine.
Signed-off-by: Steven Rostedt
On Tue, Jan 21, 2014 at 01:39:10AM -0500, Muli Baron wrote:
> On 21/1/2014 04:17, Steven Rostedt wrote:
> > On Sat, 18 Jan 2014 04:15:29 +0100
> > Mike Galbraith wrote:
> >
> >
> >>> So you also have the timers-do-not-raise-softirq-unconditionally.patch?
> >>
> >
> > People have been complaining
On Tue, Jan 21, 2014 at 01:39:10AM -0500, Muli Baron wrote:
On 21/1/2014 04:17, Steven Rostedt wrote:
On Sat, 18 Jan 2014 04:15:29 +0100
Mike Galbraith bitbuc...@online.de wrote:
So you also have the timers-do-not-raise-softirq-unconditionally.patch?
People have been complaining
On Sat, 18 Jan 2014 04:15:29 +0100
Mike Galbraith wrote:
> > So you also have the timers-do-not-raise-softirq-unconditionally.patch?
>
People have been complaining that the latest 3.12-rt does not boot on
intel i7 boxes. And by reverting this patch, it boots fine.
I happen to have a i7 box
On Sat, 18 Jan 2014 04:15:29 +0100
Mike Galbraith bitbuc...@online.de wrote:
So you also have the timers-do-not-raise-softirq-unconditionally.patch?
People have been complaining that the latest 3.12-rt does not boot on
intel i7 boxes. And by reverting this patch, it boots fine.
I happen
On Fri, 2014-01-17 at 18:00 +0100, Sebastian Andrzej Siewior wrote:
> * Mike Galbraith | 2013-12-24 16:47:47 [+0100]:
>
> >I built this kernel with Paul's patch and NO_HZ_FULL enabled again on 64
> >core box. I haven't seen RCU grip yet, but I just checked on it after
> >3.5 hours into this
* Mike Galbraith | 2013-12-24 16:47:47 [+0100]:
>I built this kernel with Paul's patch and NO_HZ_FULL enabled again on 64
>core box. I haven't seen RCU grip yet, but I just checked on it after
>3.5 hours into this boot/beat (after fixing crash+kdump setup), and
>found it in the process of
* Nicholas Mc Guire | 2013-12-27 21:00:24 [+0100]:
>> - A patch from Thomas Gleixner not to raise the timer softirq
>> unconditionally (only if a timer is pending)
>>
>
>This one seems to deadlock early in the boot sequence on x86
>(i3/i7/Phenom-4x here and Carsten Emde also had boot failures)
* Nicholas Mc Guire | 2013-12-27 21:00:24 [+0100]:
- A patch from Thomas Gleixner not to raise the timer softirq
unconditionally (only if a timer is pending)
This one seems to deadlock early in the boot sequence on x86
(i3/i7/Phenom-4x here and Carsten Emde also had boot failures)
after
* Mike Galbraith | 2013-12-24 16:47:47 [+0100]:
I built this kernel with Paul's patch and NO_HZ_FULL enabled again on 64
core box. I haven't seen RCU grip yet, but I just checked on it after
3.5 hours into this boot/beat (after fixing crash+kdump setup), and
found it in the process of dumping.
On Fri, 2014-01-17 at 18:00 +0100, Sebastian Andrzej Siewior wrote:
* Mike Galbraith | 2013-12-24 16:47:47 [+0100]:
I built this kernel with Paul's patch and NO_HZ_FULL enabled again on 64
core box. I haven't seen RCU grip yet, but I just checked on it after
3.5 hours into this boot/beat
On Fri, 27 Dec 2013 21:00:24 +0100
Nicholas Mc Guire wrote:
> On Mon, 23 Dec 2013, Sebastian Andrzej Siewior wrote:
>
> > Dear RT folks!
> >
> > I'm pleased to announce the v3.12.6-rt9 patch set.
> >
> > Changes since v3.12.6-rt8
>
> > - A patch from Thomas Gleixner not to raise the timer
On Fri, 27 Dec 2013 21:00:24 +0100
Nicholas Mc Guire der.h...@hofr.at wrote:
On Mon, 23 Dec 2013, Sebastian Andrzej Siewior wrote:
Dear RT folks!
I'm pleased to announce the v3.12.6-rt9 patch set.
Changes since v3.12.6-rt8
snip
- A patch from Thomas Gleixner not to raise the
On Sat, 2013-12-28 at 08:43 +0100, Nicholas Mc Guire wrote:
> This type of blowups will not help to go mainline (refereing to 3.12.X here,
> 3.4/6/8/10 is a different story).
Nah. Breakage is a vital sign. When breakage stops, bury it.
-Mike
--
To unsubscribe from this list: send the line
On Sat, 2013-12-28 at 08:43 +0100, Nicholas Mc Guire wrote:
This type of blowups will not help to go mainline (refereing to 3.12.X here,
3.4/6/8/10 is a different story).
Nah. Breakage is a vital sign. When breakage stops, bury it.
-Mike
--
To unsubscribe from this list: send the line
On Sat, 28 Dec 2013, Mike Galbraith wrote:
> On Sat, 2013-12-28 at 04:30 +0100, Mike Galbraith wrote:
>
> > (Less than wonderful changelogs probably comes from the fact that
> > maintaining -rt out of tree is time consuming as all hell. Everybody
> > gets to breaks it, a couple guys get to fix
On Sat, 2013-12-28 at 04:30 +0100, Mike Galbraith wrote:
> Watchdog barked at two such spots..
btw, lockdep doesn't grumble about that (didn't stare at annotation,
don't speak lockdep well). I fixed it up to not take it's toys and go
home in a snit at boot (rt_mutex debug offends it methinks),
On Sat, 2013-12-28 at 04:30 +0100, Mike Galbraith wrote:
> (Less than wonderful changelogs probably comes from the fact that
> maintaining -rt out of tree is time consuming as all hell. Everybody
> gets to breaks it, a couple guys get to fix it up again and again.)
P.S. try rolling your tree
On Fri, 2013-12-27 at 21:00 +0100, Nicholas Mc Guire wrote:
> On Mon, 23 Dec 2013, Sebastian Andrzej Siewior wrote:
>
> > Dear RT folks!
> >
> > I'm pleased to announce the v3.12.6-rt9 patch set.
> >
> > Changes since v3.12.6-rt8
>
> > - A patch from Thomas Gleixner not to raise the timer
On Mon, 23 Dec 2013, Sebastian Andrzej Siewior wrote:
> Dear RT folks!
>
> I'm pleased to announce the v3.12.6-rt9 patch set.
>
> Changes since v3.12.6-rt8
> - A patch from Thomas Gleixner not to raise the timer softirq
> unconditionally (only if a timer is pending)
>
This one seems to
On Mon, 23 Dec 2013, Sebastian Andrzej Siewior wrote:
Dear RT folks!
I'm pleased to announce the v3.12.6-rt9 patch set.
Changes since v3.12.6-rt8
snip
- A patch from Thomas Gleixner not to raise the timer softirq
unconditionally (only if a timer is pending)
This one seems to
On Fri, 2013-12-27 at 21:00 +0100, Nicholas Mc Guire wrote:
On Mon, 23 Dec 2013, Sebastian Andrzej Siewior wrote:
Dear RT folks!
I'm pleased to announce the v3.12.6-rt9 patch set.
Changes since v3.12.6-rt8
snip
- A patch from Thomas Gleixner not to raise the timer softirq
On Sat, 2013-12-28 at 04:30 +0100, Mike Galbraith wrote:
(Less than wonderful changelogs probably comes from the fact that
maintaining -rt out of tree is time consuming as all hell. Everybody
gets to breaks it, a couple guys get to fix it up again and again.)
P.S. try rolling your tree
On Sat, 2013-12-28 at 04:30 +0100, Mike Galbraith wrote:
Watchdog barked at two such spots..
btw, lockdep doesn't grumble about that (didn't stare at annotation,
don't speak lockdep well). I fixed it up to not take it's toys and go
home in a snit at boot (rt_mutex debug offends it methinks),
On Sat, 28 Dec 2013, Mike Galbraith wrote:
On Sat, 2013-12-28 at 04:30 +0100, Mike Galbraith wrote:
(Less than wonderful changelogs probably comes from the fact that
maintaining -rt out of tree is time consuming as all hell. Everybody
gets to breaks it, a couple guys get to fix it up
On Tue, 2013-12-24 at 20:39 +0400, Pavel Vasilyev wrote:
> 24.12.2013 19:47, Mike Galbraith пишет:
> > On Mon, 2013-12-23 at 23:50 +0100, Sebastian Andrzej Siewior wrote:
>
> > crash> bt
> > PID: 508TASK: 8802739ba340 CPU: 16 COMMAND: "ksoftirqd/16"
>
> YES!!! And ARM code broke :)
24.12.2013 19:47, Mike Galbraith пишет:
> On Mon, 2013-12-23 at 23:50 +0100, Sebastian Andrzej Siewior wrote:
> crash> bt
> PID: 508TASK: 8802739ba340 CPU: 16 COMMAND: "ksoftirqd/16"
YES!!! And ARM code broke :)
--
Pavel.
On Mon, 2013-12-23 at 23:50 +0100, Sebastian Andrzej Siewior wrote:
> Dear RT folks!
>
> I'm pleased to announce the v3.12.6-rt9 patch set.
>
> Changes since v3.12.6-rt8
> - ARM's mach-sti is now using rawlock as boot_lock (like the other
> mach-*)
> - There was a callpath to rcu_preempt_qs()
On Mon, 2013-12-23 at 23:50 +0100, Sebastian Andrzej Siewior wrote:
Dear RT folks!
I'm pleased to announce the v3.12.6-rt9 patch set.
Changes since v3.12.6-rt8
- ARM's mach-sti is now using rawlock as boot_lock (like the other
mach-*)
- There was a callpath to rcu_preempt_qs() with
24.12.2013 19:47, Mike Galbraith пишет:
On Mon, 2013-12-23 at 23:50 +0100, Sebastian Andrzej Siewior wrote:
crash bt
PID: 508TASK: 8802739ba340 CPU: 16 COMMAND: ksoftirqd/16
YES!!! And ARM code broke :)
--
Pavel.
On Tue, 2013-12-24 at 20:39 +0400, Pavel Vasilyev wrote:
24.12.2013 19:47, Mike Galbraith пишет:
On Mon, 2013-12-23 at 23:50 +0100, Sebastian Andrzej Siewior wrote:
crash bt
PID: 508TASK: 8802739ba340 CPU: 16 COMMAND: ksoftirqd/16
YES!!! And ARM code broke :)
And
Dear RT folks!
I'm pleased to announce the v3.12.6-rt9 patch set.
Changes since v3.12.6-rt8
- ARM's mach-sti is now using rawlock as boot_lock (like the other
mach-*)
- There was a callpath to rcu_preempt_qs() with interrupts enabled. Tiejun
Chen posted a patch to call it with interrupt
Dear RT folks!
I'm pleased to announce the v3.12.6-rt9 patch set.
Changes since v3.12.6-rt8
- ARM's mach-sti is now using rawlock as boot_lock (like the other
mach-*)
- There was a callpath to rcu_preempt_qs() with interrupts enabled. Tiejun
Chen posted a patch to call it with interrupt
36 matches
Mail list logo
