All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: Nicholas Mc Guire <der.herr@hofr.at>
Cc: linux-rt-users <linux-rt-users@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	rostedt@goodmis.org, John Kacur <jkacur@redhat.com>
Subject: Re: [ANNOUNCE] 3.12.6-rt9
Date: Fri, 17 Jan 2014 17:10:16 +0100	[thread overview]
Message-ID: <20140117161016.GE5785@linutronix.de> (raw)
In-Reply-To: <20131227200024.GA19505@opentech.at>

* 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 droping this patch with:
>patch -p1 -R < ../paches/timers-do-not-raise-softirq-unconditionally.patch
>3.12.6-rt9 boots up fine. cyclictest seems to be back to what it was before
>(only ran for a few minutes idle and 1h with load on an i3).
>
>The main problem with this patch though are proceduaral isues 
>the commit note - which is a mail exchange - actually does not explain what 
>the rational for the changes is (...well I don't understand the logic of
>run_local_timers - if someone can explain - pleas do) and notably:
>
>from timers-do-not-raise-softirq-unconditionally.patch
><snip>
>well, that very same problem is in mainline if you add "threadirqs" to
>the command line. But we can be smart about this. The untested patch
>                                                    ^^^^^^^^^^^^^^^^^^
>below should address that issue. If that works on mainline we can
>adapt it for RT (needs a trylock(&base->lock) there).
><snip>
>
> does make me wonder why this went into -rt9 ?

It was on the mailing list for a few weeks. My understanding was that
Mike Galbraith tested it on mainline and then I added the RT specific
pieces and added it it to the tree.

> It also build fails with CONFIG_PREEMPT_RT_FULL not set.

I will add a non-RT based config to my compile tests.

> as with this patch, systems that booted just fine with 3.12.5-rt7 don't
> even boot (atleast my 3 x86 test boxes here did not) this raises some
> questions regarding the process of getting patches into -rtX - are
> we going to fast here ?
>
> I would prefere if such patches would go out with a request for testing
> or atleast a "might blow up your system" note in them...

I didn't expect that much trouble. In general I try to avoid adding
explosives unless marked as such.

>thx!
>hofrat

Sebastian

  parent reply	other threads:[~2014-01-17 16:10 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-23 22:50 [ANNOUNCE] 3.12.6-rt9 Sebastian Andrzej Siewior
2013-12-24 15:15 ` 3.12.6-rt9 build failure Nicholas Mc Guire
2013-12-24 15:47 ` [ANNOUNCE] 3.12.6-rt9 Mike Galbraith
2013-12-24 16:39   ` Pavel Vasilyev
2013-12-25  3:24     ` Mike Galbraith
2013-12-25  3:24       ` Mike Galbraith
2014-01-17 17:00   ` Sebastian Andrzej Siewior
2014-01-17 17:00     ` Sebastian Andrzej Siewior
2014-01-18  3:15     ` Mike Galbraith
2014-01-21  2:17       ` Steven Rostedt
2014-01-21  6:39         ` Muli Baron
2014-01-21 15:40           ` Joe Korty
2014-01-22 21:27         ` Joakim Hernberg
2014-01-24 11:19         ` Sebastian Andrzej Siewior
2013-12-27 20:00 ` Nicholas Mc Guire
2013-12-28  3:30   ` Mike Galbraith
2013-12-28  3:48     ` Mike Galbraith
2013-12-28  7:43       ` Nicholas Mc Guire
2013-12-28 13:57         ` Mike Galbraith
2013-12-28  4:33     ` Mike Galbraith
2014-01-11 20:25   ` Joakim Hernberg
2014-01-17 16:10   ` Sebastian Andrzej Siewior [this message]
2014-01-19 20:54   ` Fernando Lopez-Lezcano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140117161016.GE5785@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=der.herr@hofr.at \
    --cc=jkacur@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.