public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Sven-Thorsten Dietrich <sven@mvista.com>,
	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>
Subject: Re: Ingo's  realtime_preempt patch causes kernel oops
Date: Wed, 24 May 2006 18:03:34 +0200	[thread overview]
Message-ID: <1148486614.5239.63.camel@localhost.localdomain> (raw)
In-Reply-To: <1148485943.24623.54.camel@localhost.localdomain>

On Wed, 2006-05-24 at 11:52 -0400, Steven Rostedt wrote:
> > > As I said yesterday. You need a demultiplexer for such cases.
> > > 
> > 
> > Would IRQs stay masked until the thread has finished running?
> 
> I would say yes.  But the system is basically broken if you have the
> same interrupt line that needs both to be threaded and NODELAY.
> 
> Basically, the best I can think to have for such a case, is all
> interrupt threads that have a shared NODELAY run at MAX_PRIO (99).  So
> that they act like a NODELAY interrupt, in that they run over everything
> else, but they can still schedule.

Err. That's why you use demultiplexers. The demux handler is always
NODELAY.

shared IRQ
-> demux_handler
	disable shared irq
	identify interrupt sources
	for all sources:
		calculate the interrupt number
		irq_desc[number]->handle_irq(.....)
			disable/ack a particular source
			if NODELAY 
				call handler and reenable if appropriate
			else 
				wakeup thread
	enable shared irq

That's the way you really want to do it. Granted, that this is not
possible with the current implementation of PCI cards, but for the SoC
peripherals this is usually simple to do.

The ARM tree has tons of examples which do exactly this.

	tglx



  reply	other threads:[~2006-05-24 16:03 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 [this message]
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                     ` 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=1148486614.5239.63.camel@localhost.localdomain \
    --to=tglx@linutronix.de \
    --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=sven@mvista.com \
    /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