public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
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, Ingo Molnar <mingo@elte.hu>
Subject: Re: Ingo's  realtime_preempt patch causes kernel oops
Date: Wed, 24 May 2006 19:06:14 +0200	[thread overview]
Message-ID: <1148490374.5239.81.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:
> 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.
> 
> 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.

That sounds scary. 

If you want your handler to be SA_NODELAY then you did this for a
reason. Simply refuse to share if the other device requests the
interrupt without SA_NODELAY.

A real solution for that problem needs more thought and the only thing
which comes to my mind is to have split handler functionality, which
allows to implement real cascaded interrupts. The short first stub would
just query, mask/ack the interrupt in the device and return the
appropriate information, so the real handler can be invoked at any given
time.

I know it would be a large pile of hacking, but it would be a clean
solution. OTOH it might be done gradually on a per driver base once the
basic infrastucture is in place.

	tglx



  reply	other threads:[~2006-05-24 17:05 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 [this message]
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                     ` Ingo's realtime_preempt patch causes kernel oops Sven-Thorsten Dietrich
     [not found] <OF928FB2B7.5CE25C69-ONC1257177.00596B7A-C1257177.005AAA6F@wavecom.fr>
2006-05-23 16:38 ` 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=1148490374.5239.81.camel@localhost.localdomain \
    --to=tglx@linutronix.de \
    --cc=Yann.LEPROVOST@wavecom.fr \
    --cc=dwalker@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rostedt@goodmis.org \
    --cc=simlo@phys.au.dk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox