From: Sven-Thorsten Dietrich <sven@mvista.com>
To: Esben Nielsen <simlo@phys.au.dk>
Cc: Steven Rostedt <rostedt@goodmis.org>,
Yann.LEPROVOST@wavecom.fr, Daniel Walker <dwalker@mvista.com>,
linux-kernel@vger.kernel.org, linux-kernel-owner@vger.kernel.org,
Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>
Subject: Re: Ingo's realtime_preempt patch causes kernel oops
Date: Wed, 24 May 2006 10:30:05 -0700 [thread overview]
Message-ID: <1148491805.17131.18.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.64.0605241834220.9777-100000@localhost>
On Wed, 2006-05-24 at 18:43 +0200, Esben Nielsen wrote:
> On Wed, 24 May 2006, Steven Rostedt wrote:
>
> > On Wed, 2006-05-24 at 10:06 +0200, Yann.LEPROVOST@wavecom.fr wrote:
> > [...]
> >
> > Thomas or Ingo,
> >
> > Maybe the handling of IRQs needs to handle the case that shared irq can
> > have both a NODELAY and a thread. The irq descriptor could have a
> > NODELAY set if any of the actions are NODELAY, but before calling the
> > interrupt handler (in interrupt context), check if the action is NODELAY
> > or not, and if not, wake up the thread if not done so already.
> >
> > thoughts?
> >
>
> I am working on patchset dealing with this problem. It still needs clean
> up. The basic idea is to add a SA_MUSTTHREAD along with SA_NODELAY. Under
> PREEMPT_RT all interrupthandlers, which doesn't have SA_NODELAY, will get
> SA_MUSTTHREAD unless the driver is changed. In irq_request() it is checked
> if the handler has SA_NODELAY and an old has SA_MUSTTHREAD and visa
> versa.
>
Its easy for some drivers to be divided into lockless portions, which
can run as SA_NODELAY. If these are kept short (minimum prevent the
device from re-asserting the IRQ once it is unmasked), then it should be
able to share certain devices on PCI, for example.
In a sense, this is how the drivers should be designed,
but of course in practice its not always ideal...
> I have also made a lock type which can be changed from rt_mutex to
> raw_spin_lock runtime. And I have made a system with a call-back from the
> irq-layer to the driver so they can change their spinlocks on the fly when
> needed.
>
Sven
next prev parent reply other threads:[~2006-05-24 17:31 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-23 13:40 Ingo's realtime_preempt patch causes kernel oops Yann.LEPROVOST
2006-05-23 14:09 ` Steven Rostedt
2006-05-23 14:19 ` Steven Rostedt
2006-05-23 14:26 ` Thomas Gleixner
2006-05-23 15:33 ` Daniel Walker
2006-05-23 16:02 ` Steven Rostedt
2006-05-23 16:27 ` Yann.LEPROVOST
2006-05-23 17:00 ` Steven Rostedt
2006-05-23 17:10 ` Yann.LEPROVOST
2006-05-23 18:21 ` Steven Rostedt
2006-05-24 8:06 ` Yann.LEPROVOST
2006-05-24 12:55 ` Steven Rostedt
2006-05-24 13:13 ` Thomas Gleixner
2006-05-24 15:32 ` Sven-Thorsten Dietrich
2006-05-24 15:52 ` Steven Rostedt
2006-05-24 16:03 ` Thomas Gleixner
2006-05-24 16:38 ` Steven Rostedt
2006-05-24 16:55 ` Thomas Gleixner
2006-05-24 17:09 ` Sven-Thorsten Dietrich
2006-05-24 16:06 ` Daniel Walker
2006-05-24 13:58 ` Yann.LEPROVOST
2006-05-24 16:43 ` Esben Nielsen
2006-05-24 17:06 ` Thomas Gleixner
2006-05-24 18:00 ` Sven-Thorsten Dietrich
2006-05-30 10:00 ` RT_PREEMPT problem with cascaded irqchip Yann.LEPROVOST
2006-05-30 10:27 ` Thomas Gleixner
2006-05-30 10:26 ` Yann.LEPROVOST
2006-05-30 11:22 ` Thomas Gleixner
2006-05-30 14:44 ` Yann.LEPROVOST
2006-05-30 23:25 ` Thomas Gleixner
2006-05-31 8:26 ` Yann.LEPROVOST
2006-05-24 17:30 ` Sven-Thorsten Dietrich [this message]
[not found] <OF928FB2B7.5CE25C69-ONC1257177.00596B7A-C1257177.005AAA6F@wavecom.fr>
2006-05-23 16:38 ` Ingo's realtime_preempt patch causes kernel oops Daniel Walker
2006-05-23 16:44 ` Thomas Gleixner
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=1148491805.17131.18.camel@localhost.localdomain \
--to=sven@mvista.com \
--cc=Yann.LEPROVOST@wavecom.fr \
--cc=dwalker@mvista.com \
--cc=linux-kernel-owner@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=simlo@phys.au.dk \
--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.