[RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Thomas Gleixner]

This patch series implements support for threaded irq handlers for the
generic IRQ layer.

Threaded interrupt handlers are not only interesting in the preempt-rt
context. Threaded interrupt handlers can help to address common
problems in the interrupt handling code:

 - move long running handlers out of the hard interrupt context

 - avoid complex hardirq -> tasklet/softirq interaction and locking
   problems by integration of this functionality into the threaded
   handler code

 - improved debugability of the kernel: faulty handlers do not take
   down the system.

 - allows prioritizing of the handlers which share an interrupt line

The implementation provides an opt-in mechanism to convert drivers to
the threaded interrupt handler model contrary to the preempt-rt patch
where the threaded handlers are enabled by a brute force switch. The
brute force switch is suboptimal as it does not change the interrupt
handler -> tasklet/softirq interaction problems, but was the only way
which was possible for the limited man power of the preempt-rt
developers.

Converting an interrupt to threaded makes only sense when the handler
code takes advantage of it by integrating tasklet/softirq
functionality and simplifying the locking.

When a driver wants to use threaded interrupt handlers it needs to
provide a quick check handler function, which checks whether the
interrupt was originated from the device or not.

In case it was originated from the device the quick check handler must
disable the interrupt at the device level and return
IRQ_WAKE_THREAD. The generic interrupt handling core then sets the
IRQF_RUNTHREAD in the irqaction of the handler and wakes the
associated thread.

The irqaction is referenced in the threads task_struct so handlers can
check for newly arrived interrupts in action flags. Aside of that the
reference is used to prevent further referencing of the thread in the
interrupt code in the case of segfault to make sure that the system
(minus the now dead interrupt handler) survives and debug information
can be retrieved. In the best case the driver can be restarted, but
dont expect that as a given.

I hope to have a real converted driver (aside of the dummy module used
for testing) ready real soon - as far as bugs/regressions stay out of
my way for a while. :)

Comments, reviews, flames as usual.

Thanks,

	tglx

[RFC patch 1/5] genirq: make irqreturn_t an enum

[Thomas Gleixner]

[-- Attachment #1: genirq-makeirq-return-t-an-enum.patch --]
[-- Type: text/plain, Size: 2220 bytes --]

Remove the 2.4 compabiliy cruft

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@elte.hu>
---
 include/linux/irq.h       |    4 ++--
 include/linux/irqreturn.h |   28 ++++++++++------------------
 2 files changed, 12 insertions(+), 20 deletions(-)

Index: linux-2.6-tip/include/linux/irq.h
===================================================================
--- linux-2.6-tip.orig/include/linux/irq.h
+++ linux-2.6-tip/include/linux/irq.h
@@ -252,7 +252,7 @@ static inline int irq_balancing_disabled
 }
 
 /* Handle irq action chains: */
-extern int handle_IRQ_event(unsigned int irq, struct irqaction *action);
+extern irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action);
 
 /*
  * Built-in IRQ handlers for various IRQ types,
@@ -294,7 +294,7 @@ static inline void generic_handle_irq(un
 
 /* Handling of unhandled and spurious interrupts: */
 extern void note_interrupt(unsigned int irq, struct irq_desc *desc,
-			   int action_ret);
+			   irqreturn_t action_ret);
 
 /* Resending of interrupts :*/
 void check_irq_resend(struct irq_desc *desc, unsigned int irq);
Index: linux-2.6-tip/include/linux/irqreturn.h
===================================================================
--- linux-2.6-tip.orig/include/linux/irqreturn.h
+++ linux-2.6-tip/include/linux/irqreturn.h
@@ -1,25 +1,17 @@
-/* irqreturn.h */
 #ifndef _LINUX_IRQRETURN_H
 #define _LINUX_IRQRETURN_H
 
-/*
- * For 2.4.x compatibility, 2.4.x can use
- *
- *	typedef void irqreturn_t;
- *	#define IRQ_NONE
- *	#define IRQ_HANDLED
- *	#define IRQ_RETVAL(x)
- *
- * To mix old-style and new-style irq handler returns.
- *
- * IRQ_NONE means we didn't handle it.
- * IRQ_HANDLED means that we did have a valid interrupt and handled it.
- * IRQ_RETVAL(x) selects on the two depending on x being non-zero (for handled)
+/**
+ * enum irqreturn
+ * @IRQ_NONE		interrupt was not from this device
+ * @IRQ_HANDLED		interrupt was handled by this device
  */
-typedef int irqreturn_t;
+enum irqreturn {
+	IRQ_NONE,
+	IRQ_HANDLED,
+};
 
-#define IRQ_NONE	(0)
-#define IRQ_HANDLED	(1)
-#define IRQ_RETVAL(x)	((x) != 0)
+#define irqreturn_t	enum irqreturn
+#define IRQ_RETVAL(x)	((x) != IRQ_NONE)
 
 #endif

[RFC patch 2/5] genirq: add a quick check handler

[Thomas Gleixner]

[-- Attachment #1: genirq-add-quickcheckhandler.patch --]
[-- Type: text/plain, Size: 4953 bytes --]

Preparatory patch for threaded interrupt handlers.

Adds a quick check handler which is called before the real handler.
The quick check handler can decide whether the interrupt was originated
from the device or not. It can also declare the interrupt as handled
and subsequently avoid that the real handler is called.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@elte.hu>
---
 include/linux/interrupt.h |   14 +++++++++++++-
 include/linux/irqreturn.h |    2 ++
 kernel/irq/handle.c       |   18 +++++++++++++++---
 kernel/irq/manage.c       |   19 +++++++++++++------
 4 files changed, 43 insertions(+), 10 deletions(-)

Index: linux-2.6-tip/include/linux/interrupt.h
===================================================================
--- linux-2.6-tip.orig/include/linux/interrupt.h
+++ linux-2.6-tip/include/linux/interrupt.h
@@ -58,6 +58,7 @@
 typedef irqreturn_t (*irq_handler_t)(int, void *);
 
 struct irqaction {
+	irq_handler_t quick_check_handler;
 	irq_handler_t handler;
 	unsigned long flags;
 	cpumask_t mask;
@@ -69,8 +70,19 @@ struct irqaction {
 };
 
 extern irqreturn_t no_action(int cpl, void *dev_id);
-extern int __must_check request_irq(unsigned int, irq_handler_t handler,
+
+extern int __must_check
+request_irq_quickcheck(unsigned int, irq_handler_t handler,
+		       irq_handler_t quick_check_handler,
 		       unsigned long, const char *, void *);
+
+static inline int __must_check
+request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,
+	    const char *name, void *dev)
+{
+	return request_irq_quickcheck(irq, handler, NULL, flags, name, dev);
+}
+
 extern void free_irq(unsigned int, void *);
 
 struct device;
Index: linux-2.6-tip/include/linux/irqreturn.h
===================================================================
--- linux-2.6-tip.orig/include/linux/irqreturn.h
+++ linux-2.6-tip/include/linux/irqreturn.h
@@ -5,10 +5,12 @@
  * enum irqreturn
  * @IRQ_NONE		interrupt was not from this device
  * @IRQ_HANDLED		interrupt was handled by this device
+ * @IRQ_NEEDS_HANDLING	quick check handler requests to run real handler
  */
 enum irqreturn {
 	IRQ_NONE,
 	IRQ_HANDLED,
+	IRQ_NEEDS_HANDLING,
 };
 
 #define irqreturn_t	enum irqreturn
Index: linux-2.6-tip/kernel/irq/handle.c
===================================================================
--- linux-2.6-tip.orig/kernel/irq/handle.c
+++ linux-2.6-tip/kernel/irq/handle.c
@@ -137,9 +137,21 @@ irqreturn_t handle_IRQ_event(unsigned in
 		local_irq_enable_in_hardirq();
 
 	do {
-		ret = action->handler(irq, action->dev_id);
-		if (ret == IRQ_HANDLED)
-			status |= action->flags;
+		if (action->quick_check_handler)
+			ret = action->quick_check_handler(irq, action->dev_id);
+		else
+			ret = IRQ_NEEDS_HANDLING;
+
+		switch (ret) {
+		default:
+			break;
+
+		case IRQ_NEEDS_HANDLING:
+			ret = action->handler(irq, action->dev_id);
+			if (ret == IRQ_HANDLED)
+				status |= action->flags;
+			break;
+		}
 		retval |= ret;
 		action = action->next;
 	} while (action);
Index: linux-2.6-tip/kernel/irq/manage.c
===================================================================
--- linux-2.6-tip.orig/kernel/irq/manage.c
+++ linux-2.6-tip/kernel/irq/manage.c
@@ -563,9 +563,14 @@ void free_irq(unsigned int irq, void *de
 EXPORT_SYMBOL(free_irq);
 
 /**
- *	request_irq - allocate an interrupt line
+ *	request_irq_quickcheck - allocate an interrupt line
  *	@irq: Interrupt line to allocate
- *	@handler: Function to be called when the IRQ occurs
+ *	@handler: Function to be called when the IRQ occurs.
+ *		  Primary handler for threaded interrupts
+ *      @quick_check_handler: Function to be called when the interrupt
+ *			   before the real handler is called to check
+ *                         whether the interrupt originated from the device
+ *                         can be NULL
  *	@irqflags: Interrupt type flags
  *	@devname: An ascii name for the claiming device
  *	@dev_id: A cookie passed back to the handler function
@@ -589,10 +594,11 @@ EXPORT_SYMBOL(free_irq);
  *	IRQF_SHARED		Interrupt is shared
  *	IRQF_DISABLED	Disable local interrupts while processing
  *	IRQF_SAMPLE_RANDOM	The interrupt can be used for entropy
- *
  */
-int request_irq(unsigned int irq, irq_handler_t handler,
-		unsigned long irqflags, const char *devname, void *dev_id)
+int request_irq_quickcheck(unsigned int irq, irq_handler_t handler,
+			   irq_handler_t quick_check_handler,
+			   unsigned long irqflags, const char *devname,
+			   void *dev_id)
 {
 	struct irqaction *action;
 	int retval;
@@ -622,6 +628,7 @@ int request_irq(unsigned int irq, irq_ha
 	if (!action)
 		return -ENOMEM;
 
+	action->quick_check_handler = quick_check_handler;
 	action->handler = handler;
 	action->flags = irqflags;
 	cpus_clear(action->mask);
@@ -651,4 +658,4 @@ int request_irq(unsigned int irq, irq_ha
 
 	return retval;
 }
-EXPORT_SYMBOL(request_irq);
+EXPORT_SYMBOL(request_irq_quickcheck);

Re: [RFC patch 2/5] genirq: add a quick check handler

[Jon Masters]

On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:

>  struct irqaction {
> +	irq_handler_t quick_check_handler;
>  	irq_handler_t handler;

When we originally discussed this, there was an idea to modify the
request_irq API to take this handler and an IRQF_THREADED type to mark
the interrupt accordingly. I understand why it's a separate function in
this implementation for ease of migration, but what do you think should
happen in the end? Also, I suggest calling this something like
"quiesce_device" because the quickcheck also needs to do that.

We probably need some documentation eventually so people realize what
this "quickcheck" handler is for and what it's not for - under no
circumstances should anything more than the bare minimum be done.
Otherwise it breaks the benefit of deferred threaded handling. It's hard
to enforce that - but this is *not* a return of top/bottom half handling
where you can do whatever crap you like in the quickcheck bit.

Jon.

Re: [RFC patch 2/5] genirq: add a quick check handler

[Steven Rostedt]

On Wed, 1 Oct 2008, Jon Masters wrote:
> 
> We probably need some documentation eventually so people realize what
> this "quickcheck" handler is for and what it's not for - under no
> circumstances should anything more than the bare minimum be done.
> Otherwise it breaks the benefit of deferred threaded handling. It's hard
> to enforce that - but this is *not* a return of top/bottom half handling
> where you can do whatever crap you like in the quickcheck bit.
> 

We could always implement something similar to what I was told Microsoft 
does (I was just told this, I don't know for fact). Time this function and 
if it takes longer than, say 50us, print a warning and kill the device
;-)

-- Steve

Re: [RFC patch 2/5] genirq: add a quick check handler

[Jon Masters]

On Thu, 2008-10-02 at 01:09 -0400, Steven Rostedt wrote:
> On Wed, 1 Oct 2008, Jon Masters wrote:
> > 
> > We probably need some documentation eventually so people realize what
> > this "quickcheck" handler is for and what it's not for - under no
> > circumstances should anything more than the bare minimum be done.
> > Otherwise it breaks the benefit of deferred threaded handling. It's hard
> > to enforce that - but this is *not* a return of top/bottom half handling
> > where you can do whatever crap you like in the quickcheck bit.
> > 
> 
> We could always implement something similar to what I was told Microsoft 
> does (I was just told this, I don't know for fact). Time this function and 
> if it takes longer than, say 50us, print a warning and kill the device
> ;-)

You know, it's funny you suggested that because I thought about going
there. But there's probably some silly patent on that groundshattering
Microsoft solution to the halting problem.

Anyway, I like to think we in the Linux community trust developers to do
the right thing more than Microsoft does :)

Jon.

Re: [RFC patch 2/5] genirq: add a quick check handler

[Greg KH]

On Thu, Oct 02, 2008 at 06:51:49AM -0400, Jon Masters wrote:
> On Thu, 2008-10-02 at 01:09 -0400, Steven Rostedt wrote:
> > On Wed, 1 Oct 2008, Jon Masters wrote:
> > > 
> > > We probably need some documentation eventually so people realize what
> > > this "quickcheck" handler is for and what it's not for - under no
> > > circumstances should anything more than the bare minimum be done.
> > > Otherwise it breaks the benefit of deferred threaded handling. It's hard
> > > to enforce that - but this is *not* a return of top/bottom half handling
> > > where you can do whatever crap you like in the quickcheck bit.
> > > 
> > 
> > We could always implement something similar to what I was told Microsoft 
> > does (I was just told this, I don't know for fact). Time this function and 
> > if it takes longer than, say 50us, print a warning and kill the device
> > ;-)
> 
> You know, it's funny you suggested that because I thought about going
> there. But there's probably some silly patent on that groundshattering
> Microsoft solution to the halting problem.
> 
> Anyway, I like to think we in the Linux community trust developers to do
> the right thing more than Microsoft does :)

"Trust, but verify" :)

We should just print out something if it takes longer than Xus, that way
we can fix the code, something that other operating systems can't do.

thanks,

greg k-h

Re: [RFC patch 2/5] genirq: add a quick check handler

[Steven Rostedt]

Thomas,

Nice work, thanks for doing this.

Little comments below.

On Wed, 1 Oct 2008, Thomas Gleixner wrote:
>  
>  extern irqreturn_t no_action(int cpl, void *dev_id);
> -extern int __must_check request_irq(unsigned int, irq_handler_t handler,
> +
> +extern int __must_check
> +request_irq_quickcheck(unsigned int, irq_handler_t handler,
> +		       irq_handler_t quick_check_handler,
>  		       unsigned long, const char *, void *);

It would be nice to still keep the name of the parameters here.
	unsigned long flags, const char *name, void *dev

> +
> +static inline int __must_check
> +request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,
> +	    const char *name, void *dev)
> +{
> +	return request_irq_quickcheck(irq, handler, NULL, flags, name, dev);
> +}
> +
>  extern void free_irq(unsigned int, void *);
>  
>  struct device;
> Index: linux-2.6-tip/include/linux/irqreturn.h
> ===================================================================
> --- linux-2.6-tip.orig/include/linux/irqreturn.h
> +++ linux-2.6-tip/include/linux/irqreturn.h
> @@ -5,10 +5,12 @@
>   * enum irqreturn
>   * @IRQ_NONE		interrupt was not from this device
>   * @IRQ_HANDLED		interrupt was handled by this device
> + * @IRQ_NEEDS_HANDLING	quick check handler requests to run real handler
>   */
>  enum irqreturn {
>  	IRQ_NONE,
>  	IRQ_HANDLED,
> +	IRQ_NEEDS_HANDLING,
>  };
>  
>  #define irqreturn_t	enum irqreturn
> Index: linux-2.6-tip/kernel/irq/handle.c
> ===================================================================
> --- linux-2.6-tip.orig/kernel/irq/handle.c
> +++ linux-2.6-tip/kernel/irq/handle.c
> @@ -137,9 +137,21 @@ irqreturn_t handle_IRQ_event(unsigned in
>  		local_irq_enable_in_hardirq();
>  
>  	do {
> -		ret = action->handler(irq, action->dev_id);
> -		if (ret == IRQ_HANDLED)
> -			status |= action->flags;
> +		if (action->quick_check_handler)
> +			ret = action->quick_check_handler(irq, action->dev_id);
> +		else
> +			ret = IRQ_NEEDS_HANDLING;
> +
> +		switch (ret) {
> +		default:
> +			break;
> +
> +		case IRQ_NEEDS_HANDLING:
> +			ret = action->handler(irq, action->dev_id);
> +			if (ret == IRQ_HANDLED)
> +				status |= action->flags;
> +			break;
> +		}
>  		retval |= ret;
>  		action = action->next;
>  	} while (action);
> Index: linux-2.6-tip/kernel/irq/manage.c
> ===================================================================
> --- linux-2.6-tip.orig/kernel/irq/manage.c
> +++ linux-2.6-tip/kernel/irq/manage.c
> @@ -563,9 +563,14 @@ void free_irq(unsigned int irq, void *de
>  EXPORT_SYMBOL(free_irq);
>  
>  /**
> - *	request_irq - allocate an interrupt line
> + *	request_irq_quickcheck - allocate an interrupt line
>   *	@irq: Interrupt line to allocate
> - *	@handler: Function to be called when the IRQ occurs
> + *	@handler: Function to be called when the IRQ occurs.
> + *		  Primary handler for threaded interrupts
> + *      @quick_check_handler: Function to be called when the interrupt
> + *			   before the real handler is called to check
> + *                         whether the interrupt originated from the device
> + *                         can be NULL


The above reads funny. How about something like:

	@quick_check_handler: Function called before the real interrupt
			handler. It checks if the interrupt originated
			from the device. This can be NULL.

-- Steve


>   *	@irqflags: Interrupt type flags
>   *	@devname: An ascii name for the claiming device
>   *	@dev_id: A cookie passed back to the handler function
> @@ -589,10 +594,11 @@ EXPORT_SYMBOL(free_irq);
>   *	IRQF_SHARED		Interrupt is shared
>   *	IRQF_DISABLED	Disable local interrupts while processing
>   *	IRQF_SAMPLE_RANDOM	The interrupt can be used for entropy
> - *
>   */
> -int request_irq(unsigned int irq, irq_handler_t handler,
> -		unsigned long irqflags, const char *devname, void *dev_id)
> +int request_irq_quickcheck(unsigned int irq, irq_handler_t handler,
> +			   irq_handler_t quick_check_handler,
> +			   unsigned long irqflags, const char *devname,
> +			   void *dev_id)
>  {
>  	struct irqaction *action;
>  	int retval;
> @@ -622,6 +628,7 @@ int request_irq(unsigned int irq, irq_ha
>  	if (!action)
>  		return -ENOMEM;
>  
> +	action->quick_check_handler = quick_check_handler;
>  	action->handler = handler;
>  	action->flags = irqflags;
>  	cpus_clear(action->mask);
> @@ -651,4 +658,4 @@ int request_irq(unsigned int irq, irq_ha
>  
>  	return retval;
>  }
> -EXPORT_SYMBOL(request_irq);
> +EXPORT_SYMBOL(request_irq_quickcheck);
> 
> 
> 

Re: [RFC patch 2/5] genirq: add a quick check handler

[Christoph Hellwig]

On Wed, Oct 01, 2008 at 11:02:18PM -0000, Thomas Gleixner wrote:
> Preparatory patch for threaded interrupt handlers.
> 
> Adds a quick check handler which is called before the real handler.
> The quick check handler can decide whether the interrupt was originated
> from the device or not. It can also declare the interrupt as handled
> and subsequently avoid that the real handler is called.

I'd rather leave the handler as a handle which could return
IRQ_NEEDS_HANDLING to get a separate thread_fn called.  This seems more
intuitive and means less mess in the fastpath.

Maybe IRQ_NEEDS_HANDLING might better be named IRQ_THREADED os similar,
but that's really getting into nitpicking..

Re: [RFC patch 2/5] genirq: add a quick check handler

[Thomas Gleixner]

On Fri, 3 Oct 2008, Christoph Hellwig wrote:

> On Wed, Oct 01, 2008 at 11:02:18PM -0000, Thomas Gleixner wrote:
> > Preparatory patch for threaded interrupt handlers.
> > 
> > Adds a quick check handler which is called before the real handler.
> > The quick check handler can decide whether the interrupt was originated
> > from the device or not. It can also declare the interrupt as handled
> > and subsequently avoid that the real handler is called.
> 
> I'd rather leave the handler as a handle which could return
> IRQ_NEEDS_HANDLING to get a separate thread_fn called.  This seems more
> intuitive and means less mess in the fastpath.

see patch 3/5 :)
 
> Maybe IRQ_NEEDS_HANDLING might better be named IRQ_THREADED os similar,
> but that's really getting into nitpicking..

The reason why I split this out is: when you start to convert your
driver, then you can split out the quick check handler first w/o
making the real handler threaded in the first place. Once you got that
right you can work on moving the real handler into a thread.

Thanks,

	tglx

[RFC patch 3/5] genirq: add threaded interrupt handler support

[Thomas Gleixner]

[-- Attachment #1: genirq-add-threaded-handler.patch --]
[-- Type: text/plain, Size: 8078 bytes --]

Add support for threaded interrupt handlers:

A device driver can request that its interrupt handler runs in a
thread. It needs to provide a quick check handler which checks whether
the interrupt originated from the device. In case the interrupt
originated from the device, the quick check handler can either return
IRQ_HANDLED or IRQ_WAKE_THREAD. IRQ_HANDLED is returned when no
further action is required. IRQ_WAKE_THREAD causes the genirq code to
invoke the threaded (main) handler.

When IRQ_WAKE_THREAD is returned, then the quick check handler must
have disabled the interrupt at the device level. This is mandatory for
shared interrupt handlers, but we need to do it as well for obscure
x86 hardware where disabling an interrupt on the IO_APIC level
redirects the interrupt to the legacy PIC interrupt lines.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@elte.hu>
---
 include/linux/interrupt.h |   17 +++++++++++++++
 include/linux/irqreturn.h |    2 +
 kernel/irq/handle.c       |   31 +++++++++++++++++++++++----
 kernel/irq/manage.c       |   51 ++++++++++++++++++++++++++++++++++++++++++++--
 4 files changed, 94 insertions(+), 7 deletions(-)

Index: linux-2.6-tip/include/linux/interrupt.h
===================================================================
--- linux-2.6-tip.orig/include/linux/interrupt.h
+++ linux-2.6-tip/include/linux/interrupt.h
@@ -45,6 +45,10 @@
  * IRQF_IRQPOLL - Interrupt is used for polling (only the interrupt that is
  *                registered first in an shared interrupt is considered for
  *                performance reasons)
+ * IRQF_THREADED - request threaded interrupt handler
+ * IRQF_RUNTHREAD - signals that the interrupt handler thread should run
+ * IRQF_WARNED_THREADED - warning rate limit when a threaded handler is
+ *			requested to run in hard interrupt context
  */
 #define IRQF_DISABLED		0x00000020
 #define IRQF_SAMPLE_RANDOM	0x00000040
@@ -54,6 +58,9 @@
 #define IRQF_PERCPU		0x00000400
 #define IRQF_NOBALANCING	0x00000800
 #define IRQF_IRQPOLL		0x00001000
+#define IRQF_THREADED		0x00002000
+#define IRQF_RUNTHREAD		0x00004000
+#define IRQF_WARNED_THREADED	0x00008000
 
 typedef irqreturn_t (*irq_handler_t)(int, void *);
 
@@ -67,6 +74,7 @@ struct irqaction {
 	struct irqaction *next;
 	int irq;
 	struct proc_dir_entry *dir;
+	struct task_struct *thread;
 };
 
 extern irqreturn_t no_action(int cpl, void *dev_id);
@@ -83,6 +91,15 @@ request_irq(unsigned int irq, irq_handle
 	return request_irq_quickcheck(irq, handler, NULL, flags, name, dev);
 }
 
+static inline int __must_check
+request_threaded_irq(unsigned int irq, irq_handler_t handler,
+		     irq_handler_t quick_check_handler,
+		     unsigned long flags, const char *name, void *dev)
+{
+	return request_irq_quickcheck(irq, handler, quick_check_handler,
+				    flags | IRQF_THREADED, name, dev);
+}
+
 extern void free_irq(unsigned int, void *);
 
 struct device;
Index: linux-2.6-tip/include/linux/irqreturn.h
===================================================================
--- linux-2.6-tip.orig/include/linux/irqreturn.h
+++ linux-2.6-tip/include/linux/irqreturn.h
@@ -6,11 +6,13 @@
  * @IRQ_NONE		interrupt was not from this device
  * @IRQ_HANDLED		interrupt was handled by this device
  * @IRQ_NEEDS_HANDLING	quick check handler requests to run real handler
+ * @IRQ_WAKE_THREAD	quick check handler requests to wake the handker thread
  */
 enum irqreturn {
 	IRQ_NONE,
 	IRQ_HANDLED,
 	IRQ_NEEDS_HANDLING,
+	IRQ_WAKE_THREAD,
 };
 
 #define irqreturn_t	enum irqreturn
Index: linux-2.6-tip/kernel/irq/handle.c
===================================================================
--- linux-2.6-tip.orig/kernel/irq/handle.c
+++ linux-2.6-tip/kernel/irq/handle.c
@@ -143,13 +143,34 @@ irqreturn_t handle_IRQ_event(unsigned in
 			ret = IRQ_NEEDS_HANDLING;
 
 		switch (ret) {
-		default:
+		case IRQ_NEEDS_HANDLING:
+			if (!(action->flags & IRQF_THREADED)) {
+				ret = action->handler(irq, action->dev_id);
+				if (ret == IRQ_HANDLED)
+					status |= action->flags;
+				break;
+			}
+			/*
+			 * Warn once when a quick check handler asked
+			 * for invoking the threaded (main) handler
+			 * directly
+			 */
+			WARN(!(action->flags & IRQF_WARNED_THREADED),
+			     "IRQ %d requested to run threaded handler "
+			     "in hard interrupt context\n", irq);
+			set_bit(IRQF_WARNED_THREADED, &action->flags);
+
+		case IRQ_WAKE_THREAD:
+			set_bit(IRQF_RUNTHREAD, &action->flags);
+			wake_up_process(action->thread);
+			/*
+			 * Set it to handled so the spurious check
+			 * does not trigger.
+			 */
+			ret = IRQ_HANDLED;
 			break;
 
-		case IRQ_NEEDS_HANDLING:
-			ret = action->handler(irq, action->dev_id);
-			if (ret == IRQ_HANDLED)
-				status |= action->flags;
+		default:
 			break;
 		}
 		retval |= ret;
Index: linux-2.6-tip/kernel/irq/manage.c
===================================================================
--- linux-2.6-tip.orig/kernel/irq/manage.c
+++ linux-2.6-tip/kernel/irq/manage.c
@@ -8,6 +8,7 @@
  */
 
 #include <linux/irq.h>
+#include <linux/kthread.h>
 #include <linux/module.h>
 #include <linux/random.h>
 #include <linux/interrupt.h>
@@ -331,6 +332,30 @@ static int __irq_set_trigger(struct irq_
 }
 
 /*
+ * Interrupt handler thread
+ */
+static int irq_thread(void *data)
+{
+	struct irqaction *action = data;
+
+	set_current_state(TASK_INTERRUPTIBLE);
+
+	while (!kthread_should_stop()) {
+		if (!test_and_clear_bit(IRQF_RUNTHREAD, &action->flags)) {
+			schedule();
+			/* Avoid running the handler on stop */
+			if (kthread_should_stop())
+				break;
+		}
+		__set_current_state(TASK_RUNNING);
+		action->handler(action->irq, action->dev_id);
+		set_current_state(TASK_INTERRUPTIBLE);
+	}
+	__set_current_state(TASK_RUNNING);
+	return 0;
+}
+
+/*
  * Internal function to register an irqaction - typically used to
  * allocate special interrupts that are part of the architecture.
  */
@@ -348,6 +373,11 @@ int setup_irq(unsigned int irq, struct i
 
 	if (desc->chip == &no_irq_chip)
 		return -ENOSYS;
+
+	/* Threaded interrupts need a quickcheck handler */
+	if ((new->flags & IRQF_THREADED) && !new->quick_check_handler)
+		return -EINVAL;
+
 	/*
 	 * Some drivers like serial.c use request_irq() heavily,
 	 * so we have to be careful not to interfere with a
@@ -399,6 +429,20 @@ int setup_irq(unsigned int irq, struct i
 		shared = 1;
 	}
 
+	/*
+	 * Threaded handler ?
+	 */
+	if (new->flags & IRQF_THREADED) {
+		struct task_struct *t;
+
+		t = kthread_create(irq_thread, new, "irq/%d-%s", irq,
+				   new->name);
+		if (IS_ERR(t))
+			return PTR_ERR(t);
+
+		new->thread = t;
+	}
+
 	if (!shared) {
 		irq_chip_set_defaults(desc->chip);
 
@@ -521,6 +565,8 @@ void free_irq(unsigned int irq, void *de
 			if (desc->chip->release)
 				desc->chip->release(irq, dev_id);
 #endif
+			if (action->thread)
+				kthread_stop(action->thread);
 
 			if (!desc->action) {
 				desc->status |= IRQ_DISABLED;
@@ -570,7 +616,7 @@ EXPORT_SYMBOL(free_irq);
  *      @quick_check_handler: Function to be called when the interrupt
  *			   before the real handler is called to check
  *                         whether the interrupt originated from the device
- *                         can be NULL
+ *                         can be NULL, but is mandatory for threaded handlers
  *	@irqflags: Interrupt type flags
  *	@devname: An ascii name for the claiming device
  *	@dev_id: A cookie passed back to the handler function
@@ -594,6 +640,7 @@ EXPORT_SYMBOL(free_irq);
  *	IRQF_SHARED		Interrupt is shared
  *	IRQF_DISABLED	Disable local interrupts while processing
  *	IRQF_SAMPLE_RANDOM	The interrupt can be used for entropy
+ *      IRQF_THREADED           Interrupt is threaded
  */
 int request_irq_quickcheck(unsigned int irq, irq_handler_t handler,
 			   irq_handler_t quick_check_handler,
@@ -624,7 +671,7 @@ int request_irq_quickcheck(unsigned int 
 	if (!handler)
 		return -EINVAL;
 
-	action = kmalloc(sizeof(struct irqaction), GFP_ATOMIC);
+	action = kzalloc(sizeof(struct irqaction), GFP_ATOMIC);
 	if (!action)
 		return -ENOMEM;
 

Re: [RFC patch 3/5] genirq: add threaded interrupt handler support

[Steven Rostedt]

On Wed, 1 Oct 2008, Thomas Gleixner wrote:
>  #define irqreturn_t	enum irqreturn
> Index: linux-2.6-tip/kernel/irq/handle.c
> ===================================================================
> --- linux-2.6-tip.orig/kernel/irq/handle.c
> +++ linux-2.6-tip/kernel/irq/handle.c
> @@ -143,13 +143,34 @@ irqreturn_t handle_IRQ_event(unsigned in
>  			ret = IRQ_NEEDS_HANDLING;
>  
>  		switch (ret) {
> -		default:
> +		case IRQ_NEEDS_HANDLING:
> +			if (!(action->flags & IRQF_THREADED)) {
> +				ret = action->handler(irq, action->dev_id);
> +				if (ret == IRQ_HANDLED)
> +					status |= action->flags;
> +				break;
> +			}
> +			/*
> +			 * Warn once when a quick check handler asked
> +			 * for invoking the threaded (main) handler
> +			 * directly
> +			 */
> +			WARN(!(action->flags & IRQF_WARNED_THREADED),
> +			     "IRQ %d requested to run threaded handler "
> +			     "in hard interrupt context\n", irq);
> +			set_bit(IRQF_WARNED_THREADED, &action->flags);

Do you purposely fall through to the next case statement here?
If so, could you please add a comment.

			/* fall through */

or something similar so we know it's not a bug.

> +
> +		case IRQ_WAKE_THREAD:
> +			set_bit(IRQF_RUNTHREAD, &action->flags);
> +			wake_up_process(action->thread);
> +			/*
> +			 * Set it to handled so the spurious check
> +			 * does not trigger.
> +			 */
> +			ret = IRQ_HANDLED;
>  			break;
>  
> -		case IRQ_NEEDS_HANDLING:
> -			ret = action->handler(irq, action->dev_id);
> -			if (ret == IRQ_HANDLED)
> -				status |= action->flags;
> +		default:
>  			break;
>  		}
>  		retval |= ret;


-- Steve

[RFC patch 4/5] genirq: add a helper to check whether the irq thread should run

[Thomas Gleixner]

[-- Attachment #1: genirq-add-irq-trigger-check.patch --]
[-- Type: text/plain, Size: 1519 bytes --]

The helper allows threaded irq handlers to determine whether another
interrupt arrived or not while the thread is running.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@elte.hu>
---
 include/linux/interrupt.h |    5 +++++
 kernel/irq/manage.c       |    2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

Index: linux-2.6-tip/include/linux/interrupt.h
===================================================================
--- linux-2.6-tip.orig/include/linux/interrupt.h
+++ linux-2.6-tip/include/linux/interrupt.h
@@ -109,6 +109,11 @@ extern int __must_check devm_request_irq
 			    const char *devname, void *dev_id);
 extern void devm_free_irq(struct device *dev, unsigned int irq, void *dev_id);
 
+static inline int irq_thread_should_run(struct irqaction *action)
+{
+	return test_and_clear_bit(IRQF_RUNTHREAD, &action->flags);
+}
+
 /*
  * On lockdep we dont want to enable hardirqs in hardirq
  * context. Use local_irq_enable_in_hardirq() to annotate
Index: linux-2.6-tip/kernel/irq/manage.c
===================================================================
--- linux-2.6-tip.orig/kernel/irq/manage.c
+++ linux-2.6-tip/kernel/irq/manage.c
@@ -341,7 +341,7 @@ static int irq_thread(void *data)
 	set_current_state(TASK_INTERRUPTIBLE);
 
 	while (!kthread_should_stop()) {
-		if (!test_and_clear_bit(IRQF_RUNTHREAD, &action->flags)) {
+		if (!irq_thread_should_run(action)) {
 			schedule();
 			/* Avoid running the handler on stop */
 			if (kthread_should_stop())

[RFC patch 5/5] genirq: make irq threading robust

[Thomas Gleixner]

[-- Attachment #1: genirq-make-threading-robust.patch --]
[-- Type: text/plain, Size: 5948 bytes --]

To make sure that a crashed irq thread does not cause more trouble
when the irq code tries to wake up a gone thread or the device code
calling free_irq and trying to kthread_stop the dead thread, we plug a
pointer to irqaction into task_struct, which is evaluated in
do_exit(). When the thread crashes the do_exit code marks the thread
as DIED in irqaction->flags to prevent further wakeups from the
interrupt handler code.

On thread creation we get a reference to task_struct so it stays
around until the free_irq code releases it again.

The procedure vs. the crashed irq handler thread is slightly racy, but
we do not want to have additional locking in the hard interrupt code
path. The worst things which can happen are a warning that we tried to
wakeup a dead task and a hung kthread_stop in free_irq. I'm not
worried about that at all, as removing a module which had a crashed
interrupt handler is critical anyway.

The main purpose of this is to keep the system alive w/o the affected
device working.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Ingo Molnar <mingo@elte.hu>
---
 include/linux/interrupt.h |    3 +++
 include/linux/sched.h     |    1 +
 kernel/exit.c             |    2 ++
 kernel/irq/handle.c       |   13 +++++++++++--
 kernel/irq/manage.c       |   44 +++++++++++++++++++++++++++++++++++++++++---
 5 files changed, 58 insertions(+), 5 deletions(-)

Index: linux-2.6-tip/include/linux/interrupt.h
===================================================================
--- linux-2.6-tip.orig/include/linux/interrupt.h
+++ linux-2.6-tip/include/linux/interrupt.h
@@ -61,6 +61,7 @@
 #define IRQF_THREADED		0x00002000
 #define IRQF_RUNTHREAD		0x00004000
 #define IRQF_WARNED_THREADED	0x00008000
+#define IRQF_THREAD_DIED	0x00010000
 
 typedef irqreturn_t (*irq_handler_t)(int, void *);
 
@@ -114,6 +115,8 @@ static inline int irq_thread_should_run(
 	return test_and_clear_bit(IRQF_RUNTHREAD, &action->flags);
 }
 
+extern void exit_irq_thread(struct task_struct *tsk);
+
 /*
  * On lockdep we dont want to enable hardirqs in hardirq
  * context. Use local_irq_enable_in_hardirq() to annotate
Index: linux-2.6-tip/include/linux/sched.h
===================================================================
--- linux-2.6-tip.orig/include/linux/sched.h
+++ linux-2.6-tip/include/linux/sched.h
@@ -1301,6 +1301,7 @@ struct task_struct {
 	int latency_record_count;
 	struct latency_record latency_record[LT_SAVECOUNT];
 #endif
+	struct irqaction *irqaction;
 };
 
 /*
Index: linux-2.6-tip/kernel/exit.c
===================================================================
--- linux-2.6-tip.orig/kernel/exit.c
+++ linux-2.6-tip/kernel/exit.c
@@ -1030,6 +1030,8 @@ NORET_TYPE void do_exit(long code)
 		schedule();
 	}
 
+	exit_irq_thread(tsk);
+
 	exit_signals(tsk);  /* sets PF_EXITING */
 	/*
 	 * tsk->flags are checked in the futex code to protect against
Index: linux-2.6-tip/kernel/irq/handle.c
===================================================================
--- linux-2.6-tip.orig/kernel/irq/handle.c
+++ linux-2.6-tip/kernel/irq/handle.c
@@ -161,8 +161,17 @@ irqreturn_t handle_IRQ_event(unsigned in
 			set_bit(IRQF_WARNED_THREADED, &action->flags);
 
 		case IRQ_WAKE_THREAD:
-			set_bit(IRQF_RUNTHREAD, &action->flags);
-			wake_up_process(action->thread);
+			/*
+			 * In case the thread crashed and was killed
+			 * we just pretend that we handled the
+			 * interrupt. The quick check handler has
+			 * disabled the device interrupt, so no irq
+			 * storm is lurking.
+			 */
+			if (likely(!(action->flags & IRQF_THREAD_DIED))) {
+				set_bit(IRQF_RUNTHREAD, &action->flags);
+				wake_up_process(action->thread);
+			}
 			/*
 			 * Set it to handled so the spurious check
 			 * does not trigger.
Index: linux-2.6-tip/kernel/irq/manage.c
===================================================================
--- linux-2.6-tip.orig/kernel/irq/manage.c
+++ linux-2.6-tip/kernel/irq/manage.c
@@ -338,6 +338,8 @@ static int irq_thread(void *data)
 {
 	struct irqaction *action = data;
 
+	current->irqaction = action;
+
 	set_current_state(TASK_INTERRUPTIBLE);
 
 	while (!kthread_should_stop()) {
@@ -351,11 +353,36 @@ static int irq_thread(void *data)
 		action->handler(action->irq, action->dev_id);
 		set_current_state(TASK_INTERRUPTIBLE);
 	}
+	/*
+	 * Clear irqaction. Otherwise exit_irq_thread() would make
+	 * fuzz about an active irq thread going into nirvana.
+	 */
+	current->irqaction = NULL;
 	__set_current_state(TASK_RUNNING);
 	return 0;
 }
 
 /*
+ * Called from do_exit()
+ */
+void exit_irq_thread(struct task_struct *tsk)
+{
+	if (!tsk->irqaction)
+		return;
+
+	printk(KERN_ERR
+	       "exiting task \"%s\" (%d) is an active IRQ thread (irq %d)\n",
+	       tsk->comm ? tsk->comm : "", tsk->pid, tsk->irqaction->irq);
+
+	/*
+	 * Set the THREAD DIED flag to prevent further wakeups of the
+	 * soon to be gone threaded handler.
+	 */
+	set_bit(IRQF_THREAD_DIED, &tsk->irqaction->flags);
+	tsk->irqaction = NULL;
+}
+
+/*
  * Internal function to register an irqaction - typically used to
  * allocate special interrupts that are part of the architecture.
  */
@@ -439,7 +466,12 @@ int setup_irq(unsigned int irq, struct i
 				   new->name);
 		if (IS_ERR(t))
 			return PTR_ERR(t);
-
+		/*
+		 * We keep the reference to the task struct even if
+		 * the thread dies to avoid that the interrupt code
+		 * references an already gone task_struct.
+		 */
+		get_task_struct(t);
 		new->thread = t;
 	}
 
@@ -565,8 +597,14 @@ void free_irq(unsigned int irq, void *de
 			if (desc->chip->release)
 				desc->chip->release(irq, dev_id);
 #endif
-			if (action->thread)
-				kthread_stop(action->thread);
+			if (action->thread) {
+				struct task_struct *t = action->thread;
+
+				action->thread = NULL;
+				if (likely(!(action->flags & IRQF_THREAD_DIED)))
+					kthread_stop(t);
+				put_task_struct(t);
+			}
 
 			if (!desc->action) {
 				desc->status |= IRQ_DISABLED;

Re: [RFC patch 5/5] genirq: make irq threading robust

[Jon Masters]

On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:

> To make sure that a crashed irq thread does not cause more trouble
> when the irq code tries to wake up a gone thread or the device code
> calling free_irq and trying to kthread_stop the dead thread, we plug a
> pointer to irqaction into task_struct, which is evaluated in
> do_exit(). When the thread crashes the do_exit code marks the thread
> as DIED in irqaction->flags to prevent further wakeups from the
> interrupt handler code.

> @@ -1301,6 +1301,7 @@ struct task_struct {
>  	int latency_record_count;
>  	struct latency_record latency_record[LT_SAVECOUNT];
>  #endif
> +	struct irqaction *irqaction;
>  };

Is that going to fly? For the vast majority of task_structs this is now
a wasted 4/8 bytes that won't be used.

Jon.

Re: [RFC patch 5/5] genirq: make irq threading robust

[Steven Rostedt]

On Wed, 1 Oct 2008, Jon Masters wrote:

> On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:
> 
> > To make sure that a crashed irq thread does not cause more trouble
> > when the irq code tries to wake up a gone thread or the device code
> > calling free_irq and trying to kthread_stop the dead thread, we plug a
> > pointer to irqaction into task_struct, which is evaluated in
> > do_exit(). When the thread crashes the do_exit code marks the thread
> > as DIED in irqaction->flags to prevent further wakeups from the
> > interrupt handler code.
> 
> > @@ -1301,6 +1301,7 @@ struct task_struct {
> >  	int latency_record_count;
> >  	struct latency_record latency_record[LT_SAVECOUNT];
> >  #endif
> > +	struct irqaction *irqaction;
> >  };
> 
> Is that going to fly? For the vast majority of task_structs this is now
> a wasted 4/8 bytes that won't be used.

Perhaps we could convert parts of the task_struct into a union.
There is quite a lot of things that I'm not sure kernel threads use.

fpu_counter? well, it is only one byte.
binfmt?

Do kernel threads use group_leader?

What about the ptraced items?

group ids/info on kernel threads?

do kernel threads need robust futex info?

This was just a quick look at the task struct. Perhaps we could separate
out kernel only and user space only info and bring the total size down?

Although I'm not sure how much is there that is kernel_thread only :-/
Of course this irqaction will be.

-- Steve

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Andrew Morton]

On Wed, 01 Oct 2008 23:02:08 -0000
Thomas Gleixner <tglx@linutronix.de> wrote:

> This patch series implements support for threaded irq handlers for the
> generic IRQ layer.
> 
> ...
> 
> I hope to have a real converted driver (aside of the dummy module used
> for testing) ready real soon

That would be nice ;)


I'm a bit surprised to see that there is no facility for per-cpu
interrupt threads?

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Arjan van de Ven]

On Wed, 1 Oct 2008 16:23:33 -0700
Andrew Morton <akpm@linux-foundation.org> wrote:

> 
> I'm a bit surprised to see that there is no facility for per-cpu
> interrupt threads?
> 

per handler is the right approach (that way, if one dies, all other
interrupts will likely keep working)

now.. normally an interrupt only goes to one cpu, so effectively it is
per cpu already anyway

we should however make the irq threads follow the affinity masks of the
irq... that'd be an easy add-on and probably worthwhile.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Andrew Morton]

On Wed, 1 Oct 2008 16:29:50 -0700
Arjan van de Ven <arjan@infradead.org> wrote:

> On Wed, 1 Oct 2008 16:23:33 -0700
> Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> > 
> > I'm a bit surprised to see that there is no facility for per-cpu
> > interrupt threads?
> > 
> 
> per handler is the right approach (that way, if one dies, all other
> interrupts will likely keep working)
> 
> now.. normally an interrupt only goes to one cpu, so effectively it is
> per cpu already anyway

Yes, if a) the thread was asleep when it was woken up and b) if the
scheduler does the right thing and wakes the thread on the CPU which
called wake_up().

The ongoing sagas of tbench/mysql/volanomark regressions make me think
that any behaviour which we "expect" of the scheduler should be
triple-checked daily :(

> we should however make the irq threads follow the affinity masks of the
> irq... that'd be an easy add-on and probably worthwhile.

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Thomas Gleixner]

On Wed, 1 Oct 2008, Andrew Morton wrote:

> On Wed, 1 Oct 2008 16:29:50 -0700
> Arjan van de Ven <arjan@infradead.org> wrote:
> 
> > On Wed, 1 Oct 2008 16:23:33 -0700
> > Andrew Morton <akpm@linux-foundation.org> wrote:
> > 
> > > 
> > > I'm a bit surprised to see that there is no facility for per-cpu
> > > interrupt threads?
> > > 
> > 
> > per handler is the right approach (that way, if one dies, all other
> > interrupts will likely keep working)
> > 
> > now.. normally an interrupt only goes to one cpu, so effectively it is
> > per cpu already anyway
> 
> Yes, if a) the thread was asleep when it was woken up and b) if the
> scheduler does the right thing and wakes the thread on the CPU which
> called wake_up().
> 
> The ongoing sagas of tbench/mysql/volanomark regressions make me think
> that any behaviour which we "expect" of the scheduler should be
> triple-checked daily :(

Yup. I missed that detail when I dusted off the moldy patches. 

Of course we need to pin the thread to the affinity mask of the
hardware interrupt.

/me goes back to do home work :)

Thanks,

	tglx

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Jon Masters]

On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:

> I hope to have a real converted driver (aside of the dummy module used
> for testing) ready real soon - as far as bugs/regressions stay out of
> my way for a while. :)

Sven and I started poking at the various USB host drivers on the flight
back from Plumbers. I'll see if I can convert over a few here on the
systems that I have and send over some patches.

Jon.

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Greg KH]

On Wed, Oct 01, 2008 at 08:40:14PM -0400, Jon Masters wrote:
> On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:
> 
> > I hope to have a real converted driver (aside of the dummy module used
> > for testing) ready real soon - as far as bugs/regressions stay out of
> > my way for a while. :)
> 
> Sven and I started poking at the various USB host drivers on the flight
> back from Plumbers. I'll see if I can convert over a few here on the
> systems that I have and send over some patches.

There's only 3, how hard could it be?  :)

/me runs away quickly

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Ingo Oeser]

Hi there,

[CC'ed some distribution specific experts]

On Friday 03 October 2008, you wrote:
> On Wed, Oct 01, 2008 at 08:40:14PM -0400, Jon Masters wrote:
> > On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:
> > 
> > > I hope to have a real converted driver (aside of the dummy module used
> > > for testing) ready real soon - as far as bugs/regressions stay out of
> > > my way for a while. :)
> > 
> > Sven and I started poking at the various USB host drivers on the flight
> > back from Plumbers. I'll see if I can convert over a few here on the
> > systems that I have and send over some patches.
> 
> There's only 3, how hard could it be?  :)

Heh! That feature is the only thing, that keeps my crappy combination
of hardware and Ubuntu Hardy together :-)

With the non-RT Ubuntu kernel flavors, it just hangs in that situation. 
It looks like this at the moment with a Ubuntu RT-Kernel, in case someone 
likes to debug that:

[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Linux version 2.6.24-21-rt (buildd@palmer) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP PREEMPT RT Mon Aug 25 19:24:40 UTC 2008 (Ubuntu 2.6.24-4.6-generic)
[    0.000000] BIOS-provided physical RAM map:
[    0.000000]  BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[    0.000000]  BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[    0.000000]  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[    0.000000]  BIOS-e820: 0000000000100000 - 00000000cfff0000 (usable)
[    0.000000]  BIOS-e820: 00000000cfff0000 - 00000000cfff3000 (ACPI NVS)
[    0.000000]  BIOS-e820: 00000000cfff3000 - 00000000d0000000 (ACPI data)
[    0.000000]  BIOS-e820: 00000000d0000000 - 00000000e0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000e8000000 - 00000000f0000000 (reserved)
[    0.000000]  BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
[    0.000000]  BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
[    0.000000] Warning only 4GB will be used.
[    0.000000] Use a HIGHMEM64G enabled kernel.
[    0.000000] 3200MB HIGHMEM available.
[    0.000000] 896MB LOWMEM available.
[    0.000000] found SMP MP-table at 000f4b40
[    0.000000] Entering add_active_range(0, 0, 1048576) 0 entries of 256 used
[    0.000000] Zone PFN ranges:
[    0.000000]   DMA             0 ->     4096
[    0.000000]   Normal       4096 ->   229376
[    0.000000]   HighMem    229376 ->  1048576
[    0.000000] Movable zone start PFN for each node
[    0.000000] early_node_map[1] active PFN ranges
[    0.000000]     0:        0 ->  1048576
[    0.000000] On node 0 totalpages: 1048576
[    0.000000]   DMA zone: 56 pages used for memmap
[    0.000000]   DMA zone: 0 pages reserved
[    0.000000]   DMA zone: 4040 pages, LIFO batch:0
[    0.000000]   Normal zone: 3080 pages used for memmap
[    0.000000]   Normal zone: 222200 pages, LIFO batch:31
[    0.000000]   HighMem zone: 11200 pages used for memmap
[    0.000000]   HighMem zone: 808000 pages, LIFO batch:31
[    0.000000]   Movable zone: 0 pages used for memmap
[    0.000000] DMI 2.3 present.
[    0.000000] ACPI: RSDP signature @ 0xC00F6490 checksum 0
[    0.000000] ACPI: RSDP 000F6490, 0014 (r0 GBT   )
[    0.000000] ACPI: RSDT CFFF3000, 0030 (r1 GBT    NVDAACPI 42302E31 NVDA  1010101)
[    0.000000] ACPI: FACP CFFF3040, 0074 (r1 GBT    NVDAACPI 42302E31 NVDA  1010101)
[    0.000000] ACPI: DSDT CFFF30C0, 4B34 (r1 GBT    NVDAACPI     1000 MSFT  100000C)
[    0.000000] ACPI: FACS CFFF0000, 0040
[    0.000000] ACPI: MCFG CFFF7C80, 003C (r1 GBT    NVDAACPI 42302E31 NVDA  1010101)
[    0.000000] ACPI: APIC CFFF7C00, 007C (r1 GBT    NVDAACPI 42302E31 NVDA  1010101)
[    0.000000] Nvidia board detected. Ignoring ACPI timer override.
[    0.000000] If you got timer trouble try acpi_use_timer_override
[    0.000000] ACPI: PM-Timer IO Port: 0x1008
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[    0.000000] Processor #0 15:11 APIC version 16
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[    0.000000] Processor #1 15:11 APIC version 16
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
[    0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
[    0.000000] ACPI: Skipping IOAPIC probe due to 'noapic' option.
[    0.000000] Using ACPI for processor (LAPIC) configuration information
[    0.000000] Intel MultiProcessor Specification v1.4
[    0.000000]     Virtual Wire compatibility mode.
[    0.000000] OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
[    0.000000] I/O APIC #2 Version 17 at 0xFEC00000.
[    0.000000] Enabling APIC mode:  Flat.  Using 1 I/O APICs
[    0.000000] Processors: 2
[    0.000000] Allocating PCI resources starting at f1000000 (gap: f0000000:0ec00000)
[    0.000000] swsusp: Registered nosave memory region: 000000000009f000 - 00000000000a0000
[    0.000000] swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000f0000
[    0.000000] swsusp: Registered nosave memory region: 00000000000f0000 - 0000000000100000
[    0.000000] Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
[    0.000000] Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 1034240
[    0.000000] Kernel command line: root=/dev/mapper/Ubuntu-root ro noapic quiet splash
[    0.000000] mapped APIC to ffffb000 (fee00000)
[    0.000000] mapped IOAPIC to ffffa000 (fec00000)
[    0.000000] Enabling fast FPU save and restore... done.
[    0.000000] Enabling unmasked SIMD FPU exception support... done.
[    0.000000] Initializing CPU#0
[    0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes)
[    0.000000] Detected 2211.442 MHz processor.
[   18.517765] spurious 8259A interrupt: IRQ7.
[   18.519999] Console: colour VGA+ 80x25
[   18.520001] console [tty0] enabled
[   18.520235] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[   18.520537] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[   18.688113] Memory: 3335620k/4194304k available (2225k kernel code, 71024k reserved, 1059k data, 368k init, 2490304k highmem)
[   18.688120] virtual kernel memory layout:
[   18.688121]     fixmap  : 0xfff4b000 - 0xfffff000   ( 720 kB)
[   18.688122]     pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
[   18.688123]     vmalloc : 0xf8800000 - 0xff7fe000   ( 111 MB)
[   18.688124]     lowmem  : 0xc0000000 - 0xf8000000   ( 896 MB)
[   18.688125]       .init : 0xc043b000 - 0xc0497000   ( 368 kB)
[   18.688126]       .data : 0xc032c6d0 - 0xc0435324   (1059 kB)
[   18.688127]       .text : 0xc0100000 - 0xc032c6d0   (2225 kB)
[   18.688130] Checking if this processor honours the WP bit even in supervisor mode... Ok.
[   18.748223] Calibrating delay using timer specific routine.. 4424.69 BogoMIPS (lpj=2212348)
[   18.748260] Security Framework initialized
[   18.748264] SELinux:  Disabled at boot.
[   18.748270] AppArmor: AppArmor initialized
[   18.748273] Failure registering capabilities with primary security module.
[   18.748287] Mount-cache hash table entries: 512
[   18.748396] Initializing cgroup subsys ns
[   18.748399] Initializing cgroup subsys cpuacct
[   18.748408] CPU: After generic identify, caps: 178bfbff ebd3fbff 00000000 00000000 00002001 00000000 0000001f 00000000
[   18.748416] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[   18.748418] CPU: L2 Cache: 512K (64 bytes/line)
[   18.748420] CPU 0(2) -> Core 0
[   18.748422] CPU: After all inits, caps: 178bfbff ebd3fbff 00000000 00020410 00002001 00000000 0000001f 00000000
[   18.748431] Compat vDSO mapped to ffffe000.
[   18.748439] Checking 'hlt' instruction... OK.
[   18.752453] SMP alternatives: switching to UP code
[   18.753321] Early unpacking initramfs... done
[   19.066316] ACPI: Core revision 20070126
[   19.066372] ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found.
[   19.068299] ACPI: setting ELCR to 0200 (from 8ca0)
[   19.069950] CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping 02
[   19.069966] SMP alternatives: switching to SMP code
[   19.070290] Booting processor 1/1 eip 3000
[   19.080875] Initializing CPU#1
[   19.141627] Calibrating delay using timer specific routine.. 4422.03 BogoMIPS (lpj=2211015)
[   19.141633] CPU: After generic identify, caps: 178bfbff ebd3fbff 00000000 00000000 00002001 00000000 0000001f 00000000
[   19.141639] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[   19.141641] CPU: L2 Cache: 512K (64 bytes/line)
[   19.141642] CPU 1(2) -> Core 1
[   19.141644] CPU: After all inits, caps: 178bfbff ebd3fbff 00000000 00020410 00002001 00000000 0000001f 00000000
[   19.141254] CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping 02
[   19.141268] Total of 2 processors activated (8846.72 BogoMIPS).
[   19.243554] Brought up 2 CPUs
[   19.243573] CPU0 attaching sched-domain:
[   19.243576]  domain 0: span 03
[   19.243578]   groups: 01 02
[   19.243581] CPU1 attaching sched-domain:
[   19.243583]  domain 0: span 03
[   19.243585]   groups: 02 01
[   19.243785] net_namespace: 76 bytes
[   19.243790] Booting paravirtualized kernel on bare hardware
[   19.244211] Time:  5:45:17  Date: 10/08/08
[   19.244244] NET: Registered protocol family 16
[   19.244421] EISA bus registered
[   19.244425] ACPI: bus type pci registered
[   19.248898] PCI: PCI BIOS revision 3.00 entry at 0xfb2a0, last bus=3
[   19.248900] PCI: Using configuration type 1
[   19.248903] Setting up standard PCI resources
[   19.251879] ACPI: EC: Look up EC in DSDT
[   19.258260] ACPI: Interpreter enabled
[   19.258265] ACPI: (supports S0 S1 S4 S5)
[   19.258279] ACPI: Using PIC for interrupt routing
[   19.265816] ACPI: PCI Root Bridge [PCI0] (0000:00)
[   19.266397] PCI: Transparent bridge - 0000:00:06.0
[   19.266644] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[   19.266953] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
[   19.314347] ACPI: PCI Interrupt Link [LNK1] (IRQs *5 7 9 10 11 14 15)
[   19.314491] ACPI: PCI Interrupt Link [LNK2] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[   19.314634] ACPI: PCI Interrupt Link [LNK3] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[   19.314778] ACPI: PCI Interrupt Link [LNK4] (IRQs 5 7 9 10 11 14 *15)
[   19.314919] ACPI: PCI Interrupt Link [LNK5] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[   19.315068] ACPI: PCI Interrupt Link [LNK6] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[   19.315216] ACPI: PCI Interrupt Link [LNK7] (IRQs 5 7 9 10 *11 14 15)
[   19.315361] ACPI: PCI Interrupt Link [LNK8] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[   19.315506] ACPI: PCI Interrupt Link [LP2P] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[   19.315653] ACPI: PCI Interrupt Link [LUBA] (IRQs 5 *7 9 10 11 14 15)
[   19.315799] ACPI: PCI Interrupt Link [LMAC] (IRQs 5 *7 9 10 11 14 15)
[   19.315944] ACPI: PCI Interrupt Link [LAZA] (IRQs 5 7 9 *10 11 14 15)
[   19.316096] ACPI: PCI Interrupt Link [LPMU] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[   19.316243] ACPI: PCI Interrupt Link [LSMB] (IRQs 5 7 9 10 11 14 *15)
[   19.316389] ACPI: PCI Interrupt Link [LUB2] (IRQs *5 7 9 10 11 14 15)
[   19.316535] ACPI: PCI Interrupt Link [LIDE] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[   19.316681] ACPI: PCI Interrupt Link [LSID] (IRQs 5 7 9 10 *11 14 15)
[   19.316827] ACPI: PCI Interrupt Link [LFID] (IRQs 5 7 9 10 11 14 *15)
[   19.316973] ACPI: PCI Interrupt Link [LSA2] (IRQs 5 7 9 *10 11 14 15)
[   19.317161] ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled.
[   19.317331] ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled.
[   19.317501] ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled.
[   19.317669] ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled.
[   19.317837] ACPI: PCI Interrupt Link [APC5] (IRQs 16) *0, disabled.
[   19.318005] ACPI: PCI Interrupt Link [APC6] (IRQs 16) *0, disabled.
[   19.318183] ACPI: PCI Interrupt Link [APC7] (IRQs 16) *0, disabled.
[   19.318355] ACPI: PCI Interrupt Link [APC8] (IRQs 16) *0, disabled.
[   19.318526] ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.
[   19.318698] ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled.
[   19.318869] ACPI: PCI Interrupt Link [APMU] (IRQs 20 21 22 23) *0, disabled.
[   19.319041] ACPI: PCI Interrupt Link [AAZA] (IRQs 20 21 22 23) *0, disabled.
[   19.319220] ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.
[   19.319392] ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.
[   19.319564] ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22 23) *0, disabled.
[   19.319739] ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.
[   19.319911] ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled.
[   19.320089] ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled.
[   19.320263] ACPI: PCI Interrupt Link [ASA2] (IRQs 20 21 22 23) *0, disabled.
[   19.320395] Linux Plug and Play Support v0.97 (c) Adam Belay
[   19.320422] pnp: PnP ACPI init
[   19.320429] ACPI: bus type pnp registered
[   19.323619] pnp: PnP ACPI: found 10 devices
[   19.323621] ACPI: ACPI bus type pnp unregistered
[   19.323624] PnPBIOS: Disabled by ACPI PNP
[   19.323826] PCI: Using ACPI for IRQ routing
[   19.323830] PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
[   19.377034] NET: Registered protocol family 8
[   19.377036] NET: Registered protocol family 20
[   19.377111] AppArmor: AppArmor Filesystem Enabled
[   19.389057] system 00:01: ioport range 0x1000-0x107f has been reserved
[   19.389060] system 00:01: ioport range 0x1080-0x10ff has been reserved
[   19.389063] system 00:01: ioport range 0x1400-0x147f has been reserved
[   19.389065] system 00:01: ioport range 0x1480-0x14ff has been reserved
[   19.389067] system 00:01: ioport range 0x1800-0x187f has been reserved
[   19.389070] system 00:01: ioport range 0x1880-0x18ff has been reserved
[   19.389073] system 00:01: iomem range 0xd0000000-0xdfffffff could not be reserved
[   19.389079] system 00:02: ioport range 0x4d0-0x4d1 has been reserved
[   19.389081] system 00:02: ioport range 0x800-0x87f has been reserved
[   19.389084] system 00:02: ioport range 0x295-0x314 has been reserved
[   19.389086] system 00:02: ioport range 0x290-0x294 has been reserved
[   19.389094] system 00:08: iomem range 0xe8000000-0xefffffff could not be reserved
[   19.389100] system 00:09: iomem range 0xcc000-0xcffff has been reserved
[   19.389102] system 00:09: iomem range 0xf0000-0xf7fff could not be reserved
[   19.389105] system 00:09: iomem range 0xf8000-0xfbfff could not be reserved
[   19.389107] system 00:09: iomem range 0xfc000-0xfffff could not be reserved
[   19.389110] system 00:09: iomem range 0xcfff0000-0xcfffffff could not be reserved
[   19.389113] system 00:09: iomem range 0xffff0000-0xffffffff could not be reserved
[   19.389116] system 00:09: iomem range 0x0-0x9ffff could not be reserved
[   19.389118] system 00:09: iomem range 0x100000-0xcffeffff could not be reserved
[   19.389121] system 00:09: iomem range 0xfec00000-0xfec00fff could not be reserved
[   19.389124] system 00:09: iomem range 0xfee00000-0xfee00fff could not be reserved
[   19.419494] PCI: Bridge: 0000:00:06.0
[   19.419496]   IO window: 9000-9fff
[   19.419499]   MEM window: f5000000-f6ffffff
[   19.419501]   PREFETCH window: disabled.
[   19.419504] PCI: Bridge: 0000:02:00.0
[   19.419505]   IO window: disabled.
[   19.419510]   MEM window: f2000000-f4ffffff
[   19.419513]   PREFETCH window: f0000000-f1ffffff
[   19.419518] PCI: Bridge: 0000:00:0e.0
[   19.419519]   IO window: disabled.
[   19.419521]   MEM window: f2000000-f4ffffff
[   19.419523]   PREFETCH window: f0000000-f1ffffff
[   19.419531] PCI: Setting latency timer of device 0000:00:06.0 to 64
[   19.419539] PCI: Setting latency timer of device 0000:00:0e.0 to 64
[   19.419551] PCI: Setting latency timer of device 0000:02:00.0 to 64
[   19.419577] NET: Registered protocol family 2
[   19.454990] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[   19.455239] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
[   19.455855] TCP bind hash table entries: 65536 (order: 9, 2359296 bytes)
[   19.456869] TCP: Hash tables configured (established 131072 bind 65536)
[   19.456874] TCP reno registered
[   19.468060] checking if image is initramfs... it is
[   20.080746] Freeing initrd memory: 8382k freed
[   20.081459] audit: initializing netlink socket (disabled)
[   20.081471] audit(1223444718.291:1): initialized
[   20.081613] krcupreemptd setsched 0
[   20.081614]   prio = 98
[   20.081671] highmem bounce pool size: 64 pages
[   20.081742] VFS: Disk quotas dquot_6.5.1
[   20.081763] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[   20.081837] io scheduler noop registered
[   20.081838] io scheduler anticipatory registered
[   20.081840] io scheduler deadline registered
[   20.081849] io scheduler cfq registered (default)
[   20.106797] pci 0000:00:05.0: Enabling HT MSI Mapping
[   20.106811] pci 0000:00:05.1: Enabling HT MSI Mapping
[   20.106824] pci 0000:00:05.2: Enabling HT MSI Mapping
[   20.106836] pci 0000:00:06.0: Enabling HT MSI Mapping
[   20.106851] pci 0000:00:06.1: Enabling HT MSI Mapping
[   20.106866] pci 0000:00:08.0: Enabling HT MSI Mapping
[   20.106879] pci 0000:00:0e.0: Enabling HT MSI Mapping
[   20.106890] Boot video device is 0000:03:00.0
[   20.106992] PCI: Setting latency timer of device 0000:00:0e.0 to 64
[   20.107027] assign_interrupt_mode Found MSI capability
[   20.107044] Allocate Port Service[0000:00:0e.0:pcie00]
[   20.107265] isapnp: Scanning for PnP cards...
[   20.463165] isapnp: No Plug & Play device found
[   20.490553] Real Time Clock Driver v1.12ac
[   20.490664] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
[   20.491845] RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
[   20.491906] input: Macintosh mouse button emulation as /devices/virtual/input/input0
[   20.491985] PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[   20.491988] PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[   20.492106] serio: i8042 KBD port at 0x60,0x64 irq 1
[   20.503193] mice: PS/2 mouse device common for all mice
[   20.503308] EISA: Probing bus 0 at eisa.0
[   20.503314] Cannot allocate resource for EISA slot 1
[   20.503330] EISA: Detected 0 cards.
[   20.503332] cpuidle: using governor ladder
[   20.503404] NET: Registered protocol family 1
[   20.503427] Using IPI No-Shortcut mode
[   20.503456] registered taskstats version 1
[   20.503560]   Magic number: 12:388:769
[   20.503646]   hash matches device ptyp5
[   20.503660]   hash matches device kmsg
[   20.503666]   hash matches device 0000:00:05.0
[   20.503684] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[   20.503686] EDD information not available.
[   20.503872] Freeing unused kernel memory: 368k freed
[   20.525317] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1
[   21.742212] fuse init (API version 7.9)
[   21.768889] device-mapper: uevent: version 1.0.3
[   21.768936] device-mapper: ioctl: 4.12.0-ioctl (2007-10-02) initialised: dm-devel@redhat.com
[   21.783453] md: linear personality registered for level -1
[   21.787115] md: multipath personality registered for level -4
[   21.790905] md: raid0 personality registered for level 0
[   21.795291] md: raid1 personality registered for level 1
[   21.799015] xor: measuring software checksum speed
[   21.803477]    8regs     :  2896.000 MB/sec
[   21.808477]    8regs_prefetch:  2804.000 MB/sec
[   21.813478]    32regs    :  2192.000 MB/sec
[   21.818479]    32regs_prefetch:  1796.000 MB/sec
[   21.818481] xor: using function: 8regs (2896.000 MB/sec)
[   21.819566] async_tx: api initialized (async)
[   21.839519] raid6: int32x1    824 MB/s
[   21.856529] raid6: int32x2    871 MB/s
[   21.873550] raid6: int32x4    835 MB/s
[   21.890545] raid6: int32x8    609 MB/s
[   21.907509] raid6: mmxx1     1753 MB/s
[   21.924501] raid6: mmxx2     3230 MB/s
[   21.941508] raid6: sse1x1    1757 MB/s
[   21.958508] raid6: sse1x2    3011 MB/s
[   21.975510] raid6: sse2x1    2968 MB/s
[   21.992511] raid6: sse2x2    4074 MB/s
[   21.992512] raid6: using algorithm sse2x2 (4074 MB/s)
[   21.992515] md: raid6 personality registered for level 6
[   21.992517] md: raid5 personality registered for level 5
[   21.992518] md: raid4 personality registered for level 4
[   22.018354] md: raid10 personality registered for level 10
[   22.236163] usbcore: registered new interface driver usbfs
[   22.236183] usbcore: registered new interface driver hub
[   22.236259] usbcore: registered new device driver usb
[   22.247614] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
[   22.247891] ACPI: PCI Interrupt Link [LUBA] enabled at IRQ 7
[   22.247894] PCI: setting IRQ 7 as level-triggered
[   22.247898] ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LUBA] -> GSI 7 (level, low) -> IRQ 7
[   22.247907] PCI: Setting latency timer of device 0000:00:02.0 to 64
[   22.247910] ohci_hcd 0000:00:02.0: OHCI Host Controller
[   22.248138] ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
[   22.248186] ohci_hcd 0000:00:02.0: irq 7, io mem 0xf7005000
[   22.301202] usb usb1: configuration #1 chosen from 1 choice
[   22.301223] hub 1-0:1.0: USB hub found
[   22.301233] hub 1-0:1.0: 10 ports detected
[   22.662617] usb 1-9: new low speed USB device using ohci_hcd and address 2
[   22.853579] usb 1-9: configuration #1 chosen from 1 choice
[   22.922573] SCSI subsystem initialized
[   22.980791] libata version 3.00 loaded.
[   22.983376] pata_amd 0000:00:04.0: version 0.3.10
[   22.983423] PCI: Setting latency timer of device 0000:00:04.0 to 64
[   22.983502] scsi0 : pata_amd
[   22.983546] scsi1 : pata_amd
[   22.984057] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14
[   22.984060] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15
[   23.288979] ata1.00: ATAPI: TSSTcorpCD/DVDW SH-S182M, SB02, max UDMA/33
[   23.445904] ata1.00: configured for UDMA/33
[   23.445937] ata2: port disabled. ignoring.
[   23.446803] scsi 0:0:0:0: CD-ROM            TSSTcorp CD/DVDW SH-S182M SB02 PQ: 0 ANSI: 5
[   23.740145] ACPI: PCI Interrupt Link [LSID] enabled at IRQ 11
[   23.740150] PCI: setting IRQ 11 as level-triggered
[   23.740153] ACPI: PCI Interrupt 0000:00:05.0[A] -> Link [LSID] -> GSI 11 (level, low) -> IRQ 11
[   23.740187] PCI: Setting latency timer of device 0000:00:05.0 to 64
[   23.740196] ACPI: PCI interrupt for device 0000:00:05.0 disabled
[   23.740397] ACPI: PCI Interrupt Link [LFID] enabled at IRQ 15
[   23.740399] PCI: setting IRQ 15 as level-triggered
[   23.740403] ACPI: PCI Interrupt 0000:00:05.1[B] -> Link [LFID] -> GSI 15 (level, low) -> IRQ 15
[   23.740417] PCI: Setting latency timer of device 0000:00:05.1 to 64
[   23.740423] ACPI: PCI interrupt for device 0000:00:05.1 disabled
[   23.740621] ACPI: PCI Interrupt Link [LSA2] enabled at IRQ 10
[   23.740623] PCI: setting IRQ 10 as level-triggered
[   23.740626] ACPI: PCI Interrupt 0000:00:05.2[C] -> Link [LSA2] -> GSI 10 (level, low) -> IRQ 10
[   23.740641] PCI: Setting latency timer of device 0000:00:05.2 to 64
[   23.740647] ACPI: PCI interrupt for device 0000:00:05.2 disabled
[   24.228852] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
[   24.229104] ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 7
[   24.229107] ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LMAC] -> GSI 7 (level, low) -> IRQ 7
[   24.229112] PCI: Setting latency timer of device 0000:00:08.0 to 64
[   24.742086] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 1, addr 00:16:e6:88:c7:bc
[   24.742091] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt timirq gbit lnktim msi desc-v3
[   24.741991] ACPI: PCI Interrupt Link [LUB2] enabled at IRQ 5
[   24.741996] PCI: setting IRQ 5 as level-triggered
[   24.742000] ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LUB2] -> GSI 5 (level, low) -> IRQ 5
[   24.742010] PCI: Setting latency timer of device 0000:00:02.1 to 64
[   24.742013] ehci_hcd 0000:00:02.1: EHCI Host Controller
[   24.742044] ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2
[   24.742071] ehci_hcd 0000:00:02.1: debug port 1
[   24.742074] PCI: cache line size of 64 is not supported by device 0000:00:02.1
[   24.742487] ehci_hcd 0000:00:02.1: irq 5, io mem 0xf7006000
[   24.743042] usb 1-9: USB disconnect, address 2
[   24.747902] ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[   24.748097] usb usb2: configuration #1 chosen from 1 choice
[   24.748118] hub 2-0:1.0: USB hub found
[   24.748126] hub 2-0:1.0: 10 ports detected
[   24.849006] sata_nv 0000:00:05.0: version 3.5
[   24.849018] ACPI: PCI Interrupt 0000:00:05.0[A] -> Link [LSID] -> GSI 11 (level, low) -> IRQ 11
[   24.849056] PCI: Setting latency timer of device 0000:00:05.0 to 64
[   24.849682] scsi2 : sata_nv
[   24.849783] scsi3 : sata_nv
[   24.849933] ata3: SATA max UDMA/133 cmd 0xa400 ctl 0xa800 bmdma 0xb400 irq 11
[   24.849936] ata4: SATA max UDMA/133 cmd 0xac00 ctl 0xb000 bmdma 0xb408 irq 11
[   25.181614] Driver 'sr' needs updating - please use bus_type methods
[   25.189497] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
[   25.189502] Uniform CD-ROM driver Revision: 3.20
[   25.189552] sr 0:0:0:0: Attached scsi CD-ROM sr0
[   25.203748] sr 0:0:0:0: Attached scsi generic sg0 type 5
[   25.264959] usb 1-9: new low speed USB device using ohci_hcd and address 3
[   25.332719] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   25.455207] usb 1-9: configuration #1 chosen from 1 choice
[   25.458200] usbcore: registered new interface driver hiddev
[   25.467322] input: Logitech Trackball as /devices/pci0000:00/0000:00:02.0/usb1/1-9/1-9:1.0/input/input2
[   25.478011] input,hidraw0: USB HID v1.10 Mouse [Logitech Trackball] on usb-0000:00:02.0-9
[   25.478026] usbcore: registered new interface driver usbhid
[   25.478029] /build/buildd/linux-2.6.24/debian/build/custom-source-rt/drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
[   25.543836] ata3.00: HPA unlocked: 976771055 -> 976773168, native 976773168
[   25.543843] ata3.00: ATA-7: ST3500630NS, 3.AEG, max UDMA/133
[   25.543845] ata3.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
[   25.580880] ata3.00: configured for UDMA/133
[   25.883782] ata4: SATA link down (SStatus 0 SControl 300)
[   25.894907] scsi 2:0:0:0: Direct-Access     ATA      ST3500630NS      3.AE PQ: 0 ANSI: 5
[   25.894973] scsi 2:0:0:0: Attached scsi generic sg1 type 0
[   25.894521] ACPI: PCI Interrupt 0000:00:05.1[B] -> Link [LFID] -> GSI 15 (level, low) -> IRQ 15
[   25.894568] PCI: Setting latency timer of device 0000:00:05.1 to 64
[   25.894608] scsi4 : sata_nv
[   25.894662] scsi5 : sata_nv
[   25.894806] ata5: SATA max UDMA/133 cmd 0xb800 ctl 0xbc00 bmdma 0xc800 irq 15
[   25.894809] ata6: SATA max UDMA/133 cmd 0xc000 ctl 0xc400 bmdma 0xc808 irq 15
[   26.197073] ata5: SATA link down (SStatus 0 SControl 300)
[   26.510116] ata6: SATA link down (SStatus 0 SControl 300)
[   26.520469] ACPI: PCI Interrupt 0000:00:05.2[C] -> Link [LSA2] -> GSI 10 (level, low) -> IRQ 10
[   26.520505] PCI: Setting latency timer of device 0000:00:05.2 to 64
[   26.520560] scsi6 : sata_nv
[   26.520794] scsi7 : sata_nv
[   26.520936] ata7: SATA max UDMA/133 cmd 0xcc00 ctl 0xd000 bmdma 0xdc00 irq 10
[   26.520939] ata8: SATA max UDMA/133 cmd 0xd400 ctl 0xd800 bmdma 0xdc08 irq 10
[   26.823157] ata7: SATA link down (SStatus 0 SControl 300)
[   27.136196] ata8: SATA link down (SStatus 0 SControl 300)
[   27.149496] ACPI: PCI Interrupt Link [LNK4] enabled at IRQ 15
[   27.149500] ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [LNK4] -> GSI 15 (level, low) -> IRQ 15
[   27.149507] 3c59x: Donald Becker and others.
[   27.149511] 0000:01:07.0: 3Com PCI 3c905B Cyclone 100baseTx at f8886000.
[   27.158757] Driver 'sd' needs updating - please use bus_type methods
[   27.158833] sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
[   27.158844] sd 2:0:0:0: [sda] Write Protect is off
[   27.158846] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   27.158861] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   27.158901] sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
[   27.158909] sd 2:0:0:0: [sda] Write Protect is off
[   27.158911] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[   27.158925] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[   27.158928]  sda:ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 5
[   27.172844] ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [LNK1] -> GSI 5 (level, low) -> IRQ 5
[   27.172855] 0000:01:08.0: 3Com PCI 3c905B Cyclone 100baseTx at f89b6000.
[   27.177621]  sda1 sda2 < sda5 >
[   27.185442] sd 2:0:0:0: [sda] Attached SCSI disk
[   27.700325] EXT3-fs: mounted filesystem with ordered data mode.
[   27.700371] kjournald starting.  Commit interval 5 seconds
[   34.798310] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[   34.909990] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[   35.084447] i2c-adapter i2c-0: nForce2 SMBus adapter at 0x1c00
[   35.084466] i2c-adapter i2c-1: nForce2 SMBus adapter at 0x1c80
[   36.006688] udev: renamed network interface eth0 to lan
[   37.913301] input: Power Button (FF) as /devices/virtual/input/input3
[   37.930424] ACPI: Power Button (FF) [PWRF]
[   37.930474] input: Power Button (CM) as /devices/virtual/input/input4
[   37.949445] ACPI: Power Button (CM) [PWRB]
[   38.426176] udev: renamed network interface eth2 to dmz
[   38.435089] udev: renamed network interface eth1 to wan
[   39.990176] lan: no link during initialization.
[   40.072308] dmz:  setting half-duplex.
[   40.861083] ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 10
[   40.861087] ACPI: PCI Interrupt 0000:00:06.1[B] -> Link [LAZA] -> GSI 10 (level, low) -> IRQ 10
[   40.861102] PCI: Setting latency timer of device 0000:00:06.1 to 64
[   41.313471] NET: Registered protocol family 10
[   41.313839] lo: Disabled Privacy Extensions
[   41.314395] ADDRCONF(NETDEV_UP): lan: link is not ready
[   41.314915] ADDRCONF(NETDEV_UP): dmz: link is not ready
[   41.504445] lp: driver loaded but no devices found
[   41.699128] ACPI: PCI Interrupt Link [LNK7] enabled at IRQ 11
[   41.699133] ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [LNK7] -> GSI 11 (level, low) -> IRQ 11
[   41.699138] matroxfb: Matrox G550 detected
[   41.700140] PInS memtype = 5
[   41.700355] matroxfb: MTRR's turned on
[   41.700375] matroxfb: 640x480x8bpp (virtual: 640x26214)
[   41.700377] matroxfb: framebuffer at 0xF0000000, mapped to 0xf8c00000, size 33554432
[   41.700433] fb0: MATROX frame buffer device
[   41.700434] fb0: initializing hardware
[   42.307283] EXT3 FS on dm-0, internal journal
[   43.208393] kjournald starting.  Commit interval 5 seconds
[   43.217060] EXT3 FS on sda1, internal journal
[   43.217067] EXT3-fs: mounted filesystem with ordered data mode.
[   43.286046] Adding 10108920k swap on /dev/mapper/Ubuntu-swap_1.  Priority:-1 extents:1 across:10108920k
[   43.491686] ip_tables: (C) 2000-2006 Netfilter Core Team
[   43.582127] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[   43.643560] ip6_tables: (C) 2000-2006 Netfilter Core Team
[   43.903238] wan:  setting half-duplex.
[   43.904752] ADDRCONF(NETDEV_UP): wan: link is not ready
[   44.138697] PPP generic driver version 2.4.2
[   44.164043] NET: Registered protocol family 17
[   44.889602] No dock devices found.
[   45.332851] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ processors (2 cpu cores) (version 2.20.00)
[   45.332360] powernow-k8: MP systems not supported by PSB BIOS structure
[   45.333080] powernow-k8: MP systems not supported by PSB BIOS structure
[   48.448693] Linux agpgart interface v0.102
[   48.483364] [drm] Initialized drm 1.1.0 20060810
[   48.626623] [drm] Initialized mga 3.2.1 20051102 on minor 0
[   50.264062] ppdev: user-space parallel port driver
[   55.001104] apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
[   55.001111] apm: disabled - APM is not SMP safe.
[   65.381474] Bluetooth: Core ver 2.11
[   65.381855] NET: Registered protocol family 31
[   65.381859] Bluetooth: HCI device and connection manager initialized
[   65.381863] Bluetooth: HCI socket layer initialized
[   65.411817] Bluetooth: L2CAP ver 2.9
[   65.411822] Bluetooth: L2CAP socket layer initialized
[   65.469713] Bluetooth: RFCOMM socket layer initialized
[   65.469726] Bluetooth: RFCOMM TTY layer initialized
[   65.469728] Bluetooth: RFCOMM ver 1.8
[  940.928916] irq 7: nobody cared (try booting with the "irqpoll" option)
[  940.928922] Pid: 1606, comm: IRQ-7 Not tainted 2.6.24-21-rt #1
[  940.928943]  [<c016b924>] __report_bad_irq+0x24/0x80
[  940.928956]  [<c016bbfb>] note_interrupt+0x27b/0x2a0
[  940.928959]  [<c016a8dc>] handle_IRQ_event+0x5c/0x100
[  940.928974]  [<c016af3c>] thread_simple_irq+0x6c/0x90
[  940.928983]  [<c016b869>] do_irqd+0x229/0x290
[  940.928998]  [<c016b640>] do_irqd+0x0/0x290
[  940.929002]  [<c0141ea2>] kthread+0x42/0x70
[  940.929005]  [<c0141e60>] kthread+0x0/0x70
[  940.929011]  [<c0105847>] kernel_thread_helper+0x7/0x10
[  940.929022]  =======================
[  940.929023] handlers:
[  940.929024] [<f891ac70>] (usb_hcd_irq+0x0/0x60 [usbcore])
[  940.929043] turning off IO-APIC fast mode.
[ 1007.970826] irq 7: nobody cared (try booting with the "irqpoll" option)
[ 1007.970832] Pid: 1606, comm: IRQ-7 Not tainted 2.6.24-21-rt #1
[ 1007.970852]  [<c016b924>] __report_bad_irq+0x24/0x80
[ 1007.970864]  [<c016bbfb>] note_interrupt+0x27b/0x2a0
[ 1007.970868]  [<c016a8dc>] handle_IRQ_event+0x5c/0x100
[ 1007.970883]  [<c016af3c>] thread_simple_irq+0x6c/0x90
[ 1007.970892]  [<c016b869>] do_irqd+0x229/0x290
[ 1007.970907]  [<c016b640>] do_irqd+0x0/0x290
[ 1007.970911]  [<c0141ea2>] kthread+0x42/0x70
[ 1007.970914]  [<c0141e60>] kthread+0x0/0x70
[ 1007.970920]  [<c0105847>] kernel_thread_helper+0x7/0x10
[ 1007.970931]  =======================
[ 1007.970932] handlers:
[ 1007.970933] [<f891ac70>] (usb_hcd_irq+0x0/0x60 [usbcore])
[ 5970.101996] irq 7: nobody cared (try booting with the "irqpoll" option)
[ 5970.102003] Pid: 1606, comm: IRQ-7 Not tainted 2.6.24-21-rt #1
[ 5970.102022]  [<c016b924>] __report_bad_irq+0x24/0x80
[ 5970.102034]  [<c016bbfb>] note_interrupt+0x27b/0x2a0
[ 5970.102038]  [<c016a8dc>] handle_IRQ_event+0x5c/0x100
[ 5970.102053]  [<c016af3c>] thread_simple_irq+0x6c/0x90
[ 5970.102063]  [<c016b869>] do_irqd+0x229/0x290
[ 5970.102078]  [<c016b640>] do_irqd+0x0/0x290
[ 5970.102082]  [<c0141ea2>] kthread+0x42/0x70
[ 5970.102085]  [<c0141e60>] kthread+0x0/0x70
[ 5970.102091]  [<c0105847>] kernel_thread_helper+0x7/0x10
[ 5970.102102]  =======================
[ 5970.102103] handlers:
[ 5970.102105] [<f891ac70>] (usb_hcd_irq+0x0/0x60 [usbcore])
[ 7633.252211] irq 7: nobody cared (try booting with the "irqpoll" option)
[ 7633.252218] Pid: 1606, comm: IRQ-7 Not tainted 2.6.24-21-rt #1
[ 7633.252237]  [<c016b924>] __report_bad_irq+0x24/0x80
[ 7633.252249]  [<c016bbfb>] note_interrupt+0x27b/0x2a0
[ 7633.252253]  [<c016a8dc>] handle_IRQ_event+0x5c/0x100
[ 7633.252268]  [<c016af3c>] thread_simple_irq+0x6c/0x90
[ 7633.252278]  [<c016b869>] do_irqd+0x229/0x290
[ 7633.252292]  [<c016b640>] do_irqd+0x0/0x290
[ 7633.252297]  [<c0141ea2>] kthread+0x42/0x70
[ 7633.252300]  [<c0141e60>] kthread+0x0/0x70
[ 7633.252306]  [<c0105847>] kernel_thread_helper+0x7/0x10
[ 7633.252317]  =======================
[ 7633.252318] handlers:
[ 7633.252319] [<f891ac70>] (usb_hcd_irq+0x0/0x60 [usbcore])
[56238.249373] wan:  setting full-duplex.
[56238.250332] ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
[56249.237072] wan: no IPv6 routers present
[56352.342443] NET: Registered protocol family 24
[58562.155510] irq 7: nobody cared (try booting with the "irqpoll" option)
[58562.155516] Pid: 1606, comm: IRQ-7 Not tainted 2.6.24-21-rt #1
[58562.155537]  [<c016b924>] __report_bad_irq+0x24/0x80
[58562.155550]  [<c016bbfb>] note_interrupt+0x27b/0x2a0
[58562.155554]  [<c016a8dc>] handle_IRQ_event+0x5c/0x100
[58562.155569]  [<c016af3c>] thread_simple_irq+0x6c/0x90
[58562.155579]  [<c016b869>] do_irqd+0x229/0x290
[58562.155594]  [<c016b640>] do_irqd+0x0/0x290
[58562.155599]  [<c0141ea2>] kthread+0x42/0x70
[58562.155602]  [<c0141e60>] kthread+0x0/0x70
[58562.155608]  [<c0105847>] kernel_thread_helper+0x7/0x10
[58562.155620]  =======================
[58562.155622] handlers:
[58562.155623] [<f891ac70>] (usb_hcd_irq+0x0/0x60 [usbcore])


           CPU0       CPU1       
  0:        556          1    XT-PIC-XT        timer
  1:       5841        888    XT-PIC-XT        i8042
  2:          0          0    XT-PIC-XT        cascade
  5:          1          1    XT-PIC-XT        ehci_hcd:usb2, dmz
  7:     160816    1687071    XT-PIC-XT        ohci_hcd:usb1
  8:          2          1    XT-PIC-XT        rtc
  9:          0          0    XT-PIC-XT        acpi
 10:     383980      11338    XT-PIC-XT        sata_nv, HDA Intel
 11:     669673      57055    XT-PIC-XT        sata_nv
 14:     584674      64101    XT-PIC-XT        libata
 15:      42236      15407    XT-PIC-XT        libata, sata_nv, wan
222:    5929886       3346   PCI-MSI-edge      lan
NMI:          0          0   Non-maskable interrupts
LOC:   59209279   59195939   Local timer interrupts
RES:    4365453    8967863   Rescheduling interrupts
CAL:      70549      64347   function call interrupts
TLB:      12860      12054   TLB shootdowns
TRM:          0          0   Thermal event interrupts
SPU:          0          0   Spurious interrupts
ERR:      14677
MIS:          0

00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1)
	Subsystem: Giga-byte Technology Unknown device 5001
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: [44] HyperTransport: Slave or Primary Interface
		Command: BaseUnitID=0 UnitCnt=15 MastHost- DefDir- DUL-
		Link Control 0: CFlE+ CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn+ ExtCTL- 64b-
		Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
		Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
		Link Config 1: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit DwFcInEn- LWO=8bit DwFcOutEn-
		Revision ID: 1.03
		Link Frequency 0: 1.0GHz
		Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability 0: 200MHz+ 300MHz+ 400MHz+ 500MHz+ 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
		Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD-
		Link Frequency 1: 200MHz
		Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
		Link Frequency Capability 1: 200MHz- 300MHz- 400MHz- 500MHz- 600MHz- 800MHz- 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
		Error Handling: PFlE+ OFlE+ PFE- OFE- EOCFE- RFE- CRCFE- SERRFE- CF- RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
		Prefetchable memory behind bridge Upper: 00-00
		Bus Number: 00
	Capabilities: [e0] #00 [fee0]

00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2)
	Subsystem: Giga-byte Technology Unknown device 0c11
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2)
	Subsystem: Giga-byte Technology Unknown device 0c11
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 15
	Region 4: I/O ports at 1c00 [size=64]
	Region 5: I/O ports at 1c80 [size=64]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.2 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2)
	Subsystem: Giga-byte Technology Unknown device 0c11
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) (prog-if 10 [OHCI])
	Subsystem: Giga-byte Technology Unknown device 5004
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 7
	Region 0: Memory at f7005000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) (prog-if 20 [EHCI])
	Subsystem: Giga-byte Technology Unknown device 5004
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin B routed to IRQ 5
	Region 0: Memory at f7006000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [44] Debug port
	Capabilities: [80] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME+

00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) (prog-if 8a [Master SecP PriP])
	Subsystem: Unknown device f458:5002
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
	Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
	Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
	Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
	Region 4: I/O ports at f000 [size=16]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) (prog-if 85 [Master SecO PriO])
	Subsystem: Giga-byte Technology Unknown device b002
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin A routed to IRQ 11
	Region 0: I/O ports at a400 [size=8]
	Region 1: I/O ports at a800 [size=4]
	Region 2: I/O ports at ac00 [size=8]
	Region 3: I/O ports at b000 [size=4]
	Region 4: I/O ports at b400 [size=16]
	Region 5: Memory at f700a000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [cc] HyperTransport: MSI Mapping

00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) (prog-if 85 [Master SecO PriO])
	Subsystem: Giga-byte Technology Unknown device b002
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin B routed to IRQ 15
	Region 0: I/O ports at b800 [size=8]
	Region 1: I/O ports at bc00 [size=4]
	Region 2: I/O ports at c000 [size=8]
	Region 3: I/O ports at c400 [size=4]
	Region 4: I/O ports at c800 [size=16]
	Region 5: Memory at f700b000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [cc] HyperTransport: MSI Mapping

00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) (prog-if 85 [Master SecO PriO])
	Subsystem: Giga-byte Technology Unknown device b002
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (750ns min, 250ns max)
	Interrupt: pin C routed to IRQ 10
	Region 0: I/O ports at cc00 [size=8]
	Region 1: I/O ports at d000 [size=4]
	Region 2: I/O ports at d400 [size=8]
	Region 3: I/O ports at d800 [size=4]
	Region 4: I/O ports at dc00 [size=16]
	Region 5: Memory at f7004000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [cc] HyperTransport: MSI Mapping

00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2) (prog-if 01 [Subtractive decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
	I/O behind bridge: 00009000-00009fff
	Memory behind bridge: f5000000-f6ffffff
	Prefetchable memory behind bridge: fff00000-000fffff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
	Capabilities: [b8] Subsystem: Gammagraphx, Inc. Unknown device 0000
	Capabilities: [8c] HyperTransport: MSI Mapping

00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2)
	Subsystem: Giga-byte Technology Unknown device a002
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (500ns min, 1250ns max)
	Interrupt: pin B routed to IRQ 10
	Region 0: Memory at f7000000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable-
		Address: 0000000000000000  Data: 0000
		Masking: 00000000  Pending: 00000000
	Capabilities: [6c] HyperTransport: MSI Mapping

00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
	Subsystem: Giga-byte Technology Unknown device e000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0 (250ns min, 5000ns max)
	Interrupt: pin A routed to IRQ 222
	Region 0: Memory at f7007000 (32-bit, non-prefetchable) [size=4K]
	Region 1: I/O ports at e400 [size=8]
	Region 2: Memory at f7008000 (32-bit, non-prefetchable) [size=256]
	Region 3: Memory at f7009000 (32-bit, non-prefetchable) [size=16]
	Capabilities: [44] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
	Capabilities: [70] MSI-X: Enable- Mask- TabSize=8
		Vector table: BAR=2 offset=00000000
		PBA: BAR=3 offset=00000000
	Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/3 Enable+
		Address: 00000000fee0100c  Data: 4141
		Masking: 000000fe  Pending: 00000000
	Capabilities: [6c] HyperTransport: MSI Mapping

00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=02, subordinate=03, sec-latency=0
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: f2000000-f4ffffff
	Prefetchable memory behind bridge: 00000000f0000000-00000000f1ffffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
	Capabilities: [40] Subsystem: nVidia Corporation Unknown device 0000
	Capabilities: [48] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
		Address: 00000000fee0300c  Data: 4139
	Capabilities: [60] HyperTransport: MSI Mapping
	Capabilities: [80] Express Root Port (Slot+) IRQ 0
		Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag-
		Device: Latency L0s <512ns, L1 <4us
		Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
		Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
		Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
		Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1
		Link: Latency L0s <512ns, L1 <4us
		Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
		Link: Speed 2.5Gb/s, Width x1
		Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise-
		Slot: Number 0, PowerLimit 0.000000
		Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
		Slot: AttnInd Off, PwrInd On, Power-
		Root: Correctable- Non-Fatal- Fatal- PME-

00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Capabilities: [80] HyperTransport: Host or Secondary Interface
		!!! Possibly incomplete decoding
		Command: WarmRst+ DblEnd-
		Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
		Link Config: MLWI=16bit MLWO=16bit LWI=16bit LWO=16bit
		Revision ID: 1.02

00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-

00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Capabilities: [f0] #0f [0010]

01:07.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24)
	Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 15
	Region 0: I/O ports at 9000 [size=128]
	Region 1: Memory at f6000000 (32-bit, non-prefetchable) [size=128]
	[virtual] Expansion ROM at f5000000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:08.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24)
	Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at 9400 [size=128]
	Region 1: Memory at f6001000 (32-bit, non-prefetchable) [size=128]
	[virtual] Expansion ROM at f5020000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 1
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

02:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=02, secondary=03, subordinate=03, sec-latency=32
	I/O behind bridge: 0000f000-00000fff
	Memory behind bridge: f2000000-f4ffffff
	Prefetchable memory behind bridge: 00000000f0000000-00000000f1ffffff
	Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
		Bridge: PM- B3+
	Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/4 Enable-
		Address: 0000000000000000  Data: 0000
	Capabilities: [80] Subsystem: Matrox Graphics, Inc. Unknown device 6666
	Capabilities: [90] Express PCI/PCI-X Bridge IRQ 0
		Device: Supported: MaxPayload 512 bytes, PhantFunc 0, ExtTag-
		Device: Latency L0s <4us, L1 <64us
		Device: AtnBtn- AtnInd- PwrInd-
		Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
		Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
		Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
		Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0
		Link: Latency L0s <512ns, L1 <16us
		Link: ASPM Disabled CommClk+ ExtSynch-
		Link: Speed 2.5Gb/s, Width x1

03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01) (prog-if 00 [VGA controller])
	Subsystem: Matrox Graphics, Inc. Unknown device 22c0
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (4000ns min, 8000ns max), Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
	Region 1: Memory at f2000000 (32-bit, non-prefetchable) [size=16K]
	Region 2: Memory at f3000000 (32-bit, non-prefetchable) [size=8M]
	[virtual] Expansion ROM at f2020000 [disabled] [size=128K]
	Capabilities: [dc] Power Management version 2
		Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [f0] AGP version 2.0
		Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=<none>
		Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x1



Bus 002 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         1 Single TT
  bMaxPacketSize0        64
  idVendor           0x0000 
  idProduct          0x0000 
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.24-21-rt ehci_hcd
  iProduct                2 EHCI Host Controller
  iSerial                 1 0000:00:02.1
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              12
Hub Descriptor:
  bLength              11
  bDescriptorType      41
  nNbrPorts            10
  wHubCharacteristic 0x000a
    No power switching (usb 1.0)
    Per-port overcurrent protection
    TT think time 8 FS bits
  bPwrOn2PwrGood       10 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0x00 0x00
  PortPwrCtrlMask    0xff 0xff
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power
   Port 3: 0000.0100 power
   Port 4: 0000.0100 power
   Port 5: 0000.0100 power
   Port 6: 0000.0100 power
   Port 7: 0000.0100 power
   Port 8: 0000.0100 power
   Port 9: 0000.0100 power
   Port 10: 0000.0100 power
Device Status:     0x0003
  Self Powered
  Remote Wakeup Enabled

Bus 001 Device 003: ID 046d:c404 Logitech, Inc. TrackMan Wheel
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x046d Logitech, Inc.
  idProduct          0xc404 TrackMan Wheel
  bcdDevice            2.20
  iManufacturer           1 Logitech
  iProduct                2 Trackball
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xa0
      (Bus Powered)
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     103
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              10
Device Status:     0x0000
  (Bus Powered)

Bus 001 Device 001: ID 0000:0000  
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0        64
  idVendor           0x0000 
  idProduct          0x0000 
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.24-21-rt ohci_hcd
  iProduct                2 OHCI Host Controller
  iSerial                 1 0000:00:02.0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval             255
Hub Descriptor:
  bLength              11
  bDescriptorType      41
  nNbrPorts            10
  wHubCharacteristic 0x0002
    No power switching (usb 1.0)
    Ganged overcurrent protection
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0x00 0x00
  PortPwrCtrlMask    0xff 0xff
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power
   Port 3: 0000.0100 power
   Port 4: 0000.0100 power
   Port 5: 0000.0100 power
   Port 6: 0000.0100 power
   Port 7: 0000.0100 power
   Port 8: 0000.0100 power
   Port 9: 0000.0303 lowspeed power enable connect
   Port 10: 0000.0100 power
Device Status:     0x0003
  Self Powered
  Remote Wakeup Enabled

processor	: 0
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 75
model name	: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping	: 2
cpu MHz		: 2211.442
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 0
cpu cores	: 2
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc
bogomips	: 4424.69
clflush size	: 64

processor	: 1
vendor_id	: AuthenticAMD
cpu family	: 15
model		: 75
model name	: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping	: 2
cpu MHz		: 2211.442
cache size	: 512 KB
physical id	: 0
siblings	: 2
core id		: 1
cpu cores	: 2
fdiv_bug	: no
hlt_bug		: no
f00f_bug	: no
coma_bug	: no
fpu		: yes
fpu_exception	: yes
cpuid level	: 1
wp		: yes
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc
bogomips	: 4422.03
clflush size	: 64


Booting without "noapic" panics while booting. I wish I could debug that 
further and keep initrd stuff working at the same time...

Best Regards

Ingo Oeser

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Daniel Walker]

On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:
> The implementation provides an opt-in mechanism to convert drivers to
> the threaded interrupt handler model contrary to the preempt-rt patch
> where the threaded handlers are enabled by a brute force switch. The
> brute force switch is suboptimal as it does not change the interrupt
> handler -> tasklet/softirq interaction problems, but was the only way
> which was possible for the limited man power of the preempt-rt
> developers.
> 
> Converting an interrupt to threaded makes only sense when the handler
> code takes advantage of it by integrating tasklet/softirq
> functionality and simplifying the locking.

I'm not clear on your direction here.. I don't have a problem with a
mass driver audit, which I think is what your suggesting with this patch
set .. However, a mass audit like that would push a fully real time
system out for quite some time..

I also don't see a clear connection between these changes and ultimately
removing spinlock level latency in the kernel. I realize you don't
address that in your comments, but this is part of the initiative to
remove spinlock level latency..

So with this set of changes and in terms of real time, I'm wonder your
going with this ?

Daniel

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Steven Rostedt]

On Wed, 1 Oct 2008, Daniel Walker wrote:
> > 
> > Converting an interrupt to threaded makes only sense when the handler
> > code takes advantage of it by integrating tasklet/softirq
> > functionality and simplifying the locking.
> 
> I'm not clear on your direction here.. I don't have a problem with a
> mass driver audit, which I think is what your suggesting with this patch
> set .. However, a mass audit like that would push a fully real time
> system out for quite some time..

This has nothing to do with real time, although it helps.

> 
> I also don't see a clear connection between these changes and ultimately
> removing spinlock level latency in the kernel. I realize you don't
> address that in your comments, but this is part of the initiative to
> remove spinlock level latency..

This is a completely different topic.

> 
> So with this set of changes and in terms of real time, I'm wonder your
> going with this ?

This helps with latencies and locking. With the current scheme of hardirq, 
softirq/tasklets, there are a lot of craziness with spin_locks and 
spin_lock_irqs and mutexes.

By creating an interrupt thread, we can skip the softirq/tasklet 
altogether, and this simplifies locking.

There are other cases where threaded interrupt handlers also improve 
performance. But we will get to those in due time.

-- Steve

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Daniel Walker]

On Thu, 2008-10-02 at 11:02 -0400, Steven Rostedt wrote:
> On Wed, 1 Oct 2008, Daniel Walker wrote:
> > > 
> > > Converting an interrupt to threaded makes only sense when the handler
> > > code takes advantage of it by integrating tasklet/softirq
> > > functionality and simplifying the locking.
> > 
> > I'm not clear on your direction here.. I don't have a problem with a
> > mass driver audit, which I think is what your suggesting with this patch
> > set .. However, a mass audit like that would push a fully real time
> > system out for quite some time..
> 
> This has nothing to do with real time, although it helps.

Clearly threading irq handlers does have something to do with real time,
unless this patch isn't actually threading anything ..

> > 
> > I also don't see a clear connection between these changes and ultimately
> > removing spinlock level latency in the kernel. I realize you don't
> > address that in your comments, but this is part of the initiative to
> > remove spinlock level latency..
> 
> This is a completely different topic.

It's all connected to the removal of latency .. One part depending on
the other parts, so you can't disconnect this from the rest of it.

> > 
> > So with this set of changes and in terms of real time, I'm wonder your
> > going with this ?
> 
> This helps with latencies and locking. With the current scheme of hardirq, 
> softirq/tasklets, there are a lot of craziness with spin_locks and 
> spin_lock_irqs and mutexes.
> 
> By creating an interrupt thread, we can skip the softirq/tasklet 
> altogether, and this simplifies locking.

How does this simplify locking ?

Daniel

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Thomas Gleixner]

On Thu, 2 Oct 2008, Daniel Walker wrote:
> On Thu, 2008-10-02 at 11:02 -0400, Steven Rostedt wrote:
> > On Wed, 1 Oct 2008, Daniel Walker wrote:
> > > > 
> > > > Converting an interrupt to threaded makes only sense when the handler
> > > > code takes advantage of it by integrating tasklet/softirq
> > > > functionality and simplifying the locking.
> > > 
> > > I'm not clear on your direction here.. I don't have a problem with a
> > > mass driver audit, which I think is what your suggesting with this patch
> > > set .. However, a mass audit like that would push a fully real time
> > > system out for quite some time..
> > 
> > This has nothing to do with real time, although it helps.
> 
> Clearly threading irq handlers does have something to do with real time,
> unless this patch isn't actually threading anything ..

Clearly you have neither clue about real time nor about operating
systems in general. 

Solaris, some BSDs and MacOSX use interrupt threads. Where exactly is
the relation to realtime?

The concept of interrupt threads is nothing which is in any way
related to real time. It is a well known and pretty old concept in
operating system design.

The fact that real time operating systems benefit from interrupt
threads is a totally different topic.

	tglx
	

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Daniel Walker]

On Thu, 2008-10-02 at 20:42 +0200, Thomas Gleixner wrote:

> Clearly you have neither clue about real time nor about operating
> systems in general. 

Here we go again Thomas.. You think you can have a conversation without
the insults for once?

> Solaris, some BSDs and MacOSX use interrupt threads. Where exactly is
> the relation to realtime?

The very fact that you mention it in your release notes .. You mention
the type of system in "preempt-rt" and the advantage of your system..

> The concept of interrupt threads is nothing which is in any way
> related to real time. It is a well known and pretty old concept in
> operating system design.
> 
> The fact that real time operating systems benefit from interrupt
> threads is a totally different topic.
> 

The fact that a direct relationship exists means that any threaded
interrupt system needs to take into account the inevitable connection to
real time since it will be used in that system as a core component.. If
you can't effectively achieve real time with your system , than that's a
problem that needs to be addressed. 

Daniel

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Steven Rostedt]

On Thu, 2 Oct 2008, Daniel Walker wrote:

> On Thu, 2008-10-02 at 20:42 +0200, Thomas Gleixner wrote:
> 
> > Clearly you have neither clue about real time nor about operating
> > systems in general. 
> 
> Here we go again Thomas.. You think you can have a conversation without
> the insults for once?
> 
> > Solaris, some BSDs and MacOSX use interrupt threads. Where exactly is
> > the relation to realtime?
> 
> The very fact that you mention it in your release notes .. You mention
> the type of system in "preempt-rt" and the advantage of your system..
> 
> > The concept of interrupt threads is nothing which is in any way
> > related to real time. It is a well known and pretty old concept in
> > operating system design.
> > 
> > The fact that real time operating systems benefit from interrupt
> > threads is a totally different topic.
> > 
> 
> The fact that a direct relationship exists means that any threaded
> interrupt system needs to take into account the inevitable connection to
> real time since it will be used in that system as a core component.. If
> you can't effectively achieve real time with your system , than that's a
> problem that needs to be addressed. 

Daniel, what kind of logic is this? I was already accused of being on 
crack today (but was just too much coffee). Perhaps you might be the one 
that's on crack.

I build a pipe. There exists a relationship between a pipe and crap 
running through it from my toilet. Does this mean that every time I need a 
pipe, that I need to take into account the inevitable connection to crap 
to run through it?

God, I can see the problems with my gas lines.

-- Steve

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Ingo Molnar]

* Daniel Walker <dwalker@mvista.com> wrote:

> > > Clearly threading irq handlers does have something to do with real 
> > > time, unless this patch isn't actually threading anything ..

Well, that's clearly wrong: threaded IRQ handlers are not tied to 
real-time in any way. Yes, they can be used for RT too but as far as the 
upstream kernel is involved that's at most an afterthought.

and the "unless this patch isn't actually threading anything" bit does 
not parse at all. The patches execute hard-IRQ handlers from special 
kernel threads.

> > Clearly you have neither clue about real time nor about operating 
> > systems in general.
> 
> Here we go again Thomas.. You think you can have a conversation 
> without the insults for once?

what Thomas said was a strong but fair reaction to your obviously 
incorrect statement. What reaction did you expect?

	Ingo

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Daniel Walker]

On Thu, 2008-10-02 at 21:28 +0200, Ingo Molnar wrote:
> * Daniel Walker <dwalker@mvista.com> wrote:
> 
> > > > Clearly threading irq handlers does have something to do with real 
> > > > time, unless this patch isn't actually threading anything ..
> 
> Well, that's clearly wrong: threaded IRQ handlers are not tied to 
> real-time in any way. Yes, they can be used for RT too but as far as the 
> upstream kernel is involved that's at most an afterthought.

You contradict yourself .. I said "Clearly threading irq handlers does
have something to do with real time" then you say "they can be used for 
RT too" .. So my comments are clearly correct , they have "something" to
do with real time. There exists a relationship of some kind or type.

You should go back and read my initial questions, they are reasonable ..

> > > Clearly you have neither clue about real time nor about operating 
> > > systems in general.
> > 
> > Here we go again Thomas.. You think you can have a conversation 
> > without the insults for once?
> 
> what Thomas said was a strong but fair reaction to your obviously 
> incorrect statement. What reaction did you expect?

We need less insults on this list not more.. Maybe I could understand
his reaction had I insulted him, but I didn't.. "Fair reaction" doesn't
fit in this case ..

Daniel

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Steven Rostedt]

On Thu, 2 Oct 2008, Daniel Walker wrote:

> On Thu, 2008-10-02 at 21:28 +0200, Ingo Molnar wrote:
> > * Daniel Walker <dwalker@mvista.com> wrote:
> > 
> > > > > Clearly threading irq handlers does have something to do with real 
> > > > > time, unless this patch isn't actually threading anything ..
> > 
> > Well, that's clearly wrong: threaded IRQ handlers are not tied to 
> > real-time in any way. Yes, they can be used for RT too but as far as the 
> > upstream kernel is involved that's at most an afterthought.
> 
> You contradict yourself .. I said "Clearly threading irq handlers does

No he did not.

> have something to do with real time" then you say "they can be used for 
> RT too" .. So my comments are clearly correct , they have "something" to
> do with real time. There exists a relationship of some kind or type.


What Ingo is telling you is:

  - RT needs threaded interrupts.

  - Threaded interrupts do not need RT

My dog is an Italian Greyhound.

Italian Greyhound is a dog, but
a dog is not an Italian Greyhound.

-- Steve

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Daniel Walker]

On Thu, 2008-10-02 at 16:14 -0400, Steven Rostedt wrote:
> On Thu, 2 Oct 2008, Daniel Walker wrote:
> 
> > On Thu, 2008-10-02 at 21:28 +0200, Ingo Molnar wrote:
> > > * Daniel Walker <dwalker@mvista.com> wrote:
> > > 
> > > > > > Clearly threading irq handlers does have something to do with real 
> > > > > > time, unless this patch isn't actually threading anything ..
> > > 
> > > Well, that's clearly wrong: threaded IRQ handlers are not tied to 
> > > real-time in any way. Yes, they can be used for RT too but as far as the 
> > > upstream kernel is involved that's at most an afterthought.
> > 
> > You contradict yourself .. I said "Clearly threading irq handlers does
> 
> No he did not.

Yes, he did.

> > have something to do with real time" then you say "they can be used for 
> > RT too" .. So my comments are clearly correct , they have "something" to
> > do with real time. There exists a relationship of some kind or type.
> 
> 
> What Ingo is telling you is:
> 
>   - RT needs threaded interrupts.
> 
>   - Threaded interrupts do not need RT
> 
> My dog is an Italian Greyhound.
> 
> Italian Greyhound is a dog, but
> a dog is not an Italian Greyhound.

My comments are basically bidirectional , so what your saying doesn't
make any sense .. I said basically, that dogs and "Italian Greyhounds"
have _some_ connection .. Why are we even debating this.

Daniel

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Steven Rostedt]

On Thu, 2 Oct 2008, Daniel Walker wrote:
> > 
> > What Ingo is telling you is:
> > 
> >   - RT needs threaded interrupts.
> > 
> >   - Threaded interrupts do not need RT
> > 
> > My dog is an Italian Greyhound.
> > 
> > Italian Greyhound is a dog, but
> > a dog is not an Italian Greyhound.
> 
> My comments are basically bidirectional , so what your saying doesn't
> make any sense .. I said basically, that dogs and "Italian Greyhounds"
> have _some_ connection .. Why are we even debating this.


Let's look at your original comments:

> I'm not clear on your direction here.. I don't have a problem with a
> mass driver audit, which I think is what your suggesting with this patch
> set .. However, a mass audit like that would push a fully real time
> system out for quite some time..

Why are you bringing up real time in this thread?? The thread has
absolutely nothing to do with real time. This thread is about a better
way to handle interrupt handlers.

> 
> I also don't see a clear connection between these changes and ultimately
> removing spinlock level latency in the kernel. I realize you don't
> address that in your comments, but this is part of the initiative to
> remove spinlock level latency..

Again, this thread has nothing to do with removing spinlock level latency.
The reason Thomas did not address this is because it is OFF TOPIC!!!!

> 
> So with this set of changes and in terms of real time, I'm wonder your
> going with this ?

You brought in this relationship with real time, just because real time 
uses threaded interrupts. This thread has nothing to do with real time. 
That is what Ingo, Thomas and myself are trying to ge through to you.

The strong reaction from Thomas is that you just brought up something that 
is completely off topic.

Basically, drop the real time topic from this thread. It's not related. 
Yes real time addresses threaded interrupts, but just because we are 
talking about threaded interrupts does not mean we are talking about real 
time.

Actually my analogy with dogs and IG's is wrong. The pipe and crap analogy 
is better. Crap uses pipes to get out of the house. But if I'm talking 
about pipes, I don't want to hear about crap.

We are debating this because YOU brought it up!

-- Steve

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Daniel Walker]

On Thu, 2008-10-02 at 17:05 -0400, Steven Rostedt wrote:

> Why are you bringing up real time in this thread?? The thread has
> absolutely nothing to do with real time. This thread is about a better
> way to handle interrupt handlers.

I'm concerned about the connection between the two, which is what I'm
commenting on.

> > 
> > I also don't see a clear connection between these changes and ultimately
> > removing spinlock level latency in the kernel. I realize you don't
> > address that in your comments, but this is part of the initiative to
> > remove spinlock level latency..
> 
> Again, this thread has nothing to do with removing spinlock level latency.
> The reason Thomas did not address this is because it is OFF TOPIC!!!!

If they are connected (which I think we established) , then it's not out
of line for me to discuss the direction of these changes as related to
other components of real time.

> > 
> > So with this set of changes and in terms of real time, I'm wonder your
> > going with this ?
> 
> You brought in this relationship with real time, just because real time 
> uses threaded interrupts. This thread has nothing to do with real time. 
> That is what Ingo, Thomas and myself are trying to ge through to you.

You know Steven, often times you start a conversation and you have no
idea where it will end up.. You can't always control which direction it
will go..

> The strong reaction from Thomas is that you just brought up something that 
> is completely off topic.

We already debated this fact Steven. real time and this type of
threading are connected. It's not off topic to discuss connected
components.

If the intent here is to totally disconnect these threading patches from
any type of real time in the future, then that's a good answer to my
original question .. That these changes have no future what so ever in
regards to real time.

If they will be used in the future for real time then we should discuss
it. I don't think that's off topic at all.

> Basically, drop the real time topic from this thread. It's not related. 
> Yes real time addresses threaded interrupts, but just because we are 
> talking about threaded interrupts does not mean we are talking about real 
> time.

I don't see why you are so concerned with this.. Real time is taboo now?

Daniel

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Steven Rostedt]

On Thu, 2 Oct 2008, Daniel Walker wrote:

> On Thu, 2008-10-02 at 17:05 -0400, Steven Rostedt wrote:
> 
> > Why are you bringing up real time in this thread?? The thread has
> > absolutely nothing to do with real time. This thread is about a better
> > way to handle interrupt handlers.
> 
> I'm concerned about the connection between the two, which is what I'm
> commenting on.

Well, please take that up separately. Do you see these patches going
into the -rt tree?  No, they are going in mainline. We will deal with
them for -rt when the time comes.

> 
> > > 
> > > I also don't see a clear connection between these changes and ultimately
> > > removing spinlock level latency in the kernel. I realize you don't
> > > address that in your comments, but this is part of the initiative to
> > > remove spinlock level latency..
> > 
> > Again, this thread has nothing to do with removing spinlock level latency.
> > The reason Thomas did not address this is because it is OFF TOPIC!!!!
> 
> If they are connected (which I think we established) , then it's not out
> of line for me to discuss the direction of these changes as related to
> other components of real time.

You are bringing up concerns about mainline changes with something that
is maintained outside the mainline tree.  Changes to mainline have never
been influenced by changes maintained outside of mainline.

> 
> > > 
> > > So with this set of changes and in terms of real time, I'm wonder your
> > > going with this ?
> > 
> > You brought in this relationship with real time, just because real time 
> > uses threaded interrupts. This thread has nothing to do with real time. 
> > That is what Ingo, Thomas and myself are trying to ge through to you.
> 
> You know Steven, often times you start a conversation and you have no
> idea where it will end up.. You can't always control which direction it
> will go..

Yes Daniel, I know. But this is not a conversation. This is a email thread
that is talking about changes to mainline. The mainline kernel developers
really don't care about any issues that these changes will do to the
real time project. The real time project is a niche, and is currently
outside the mainline tree. Hence, lets stop bothering mainline 
developers with our issues.

> 
> > The strong reaction from Thomas is that you just brought up something that 
> > is completely off topic.
> 
> We already debated this fact Steven. real time and this type of
> threading are connected. It's not off topic to discuss connected
> components.

No Daniel, it is off topic.  The thread is not about real time issues.
This thread is about mainline. If you have an issue that these changes
will make to the current mainline tree, then please, by all means, bring
them up. But do not bring up issues that only affect outside of mainline.

> 
> If the intent here is to totally disconnect these threading patches from
> any type of real time in the future, then that's a good answer to my
> original question .. That these changes have no future what so ever in
> regards to real time.

No the intent here is to handle mainline issues. The real time issues you
consistantly bring up are not important to most kernel developers. If
you have real time issues with this change, bring that up on a real 
time forum. Not in this thread.  The changes in this thread are dealing
with mainline interrupt handlers. There have been several kernel device 
driver writers who asked us to get interrupt threads in mainline. This was 
not about real time, this was about helping out mainline kernel 
developers.

> 
> If they will be used in the future for real time then we should discuss
> it. I don't think that's off topic at all.
> 
> > Basically, drop the real time topic from this thread. It's not related. 
> > Yes real time addresses threaded interrupts, but just because we are 
> > talking about threaded interrupts does not mean we are talking about real 
> > time.
> 
> I don't see why you are so concerned with this.. Real time is taboo now?

Not at all, Daniel, but this thread is not the appropriate place to 
discuss your real time concerns. You are asking about what this patch has 
to do with the future real time direction. Who on this thread cares?
(besides you)

The topic for mainline patch threads needs to stay focused on mainline. 
Not on out of tree branches. When the rest of real time is in mainline, 
then sure, you can discuss those concerns then. But until that happens, 
keep to the topic of the thread. Which for now is not real time.

-- Steve

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Daniel Walker]

On Thu, 2008-10-02 at 18:28 -0400, Steven Rostedt wrote:
> 
> On Thu, 2 Oct 2008, Daniel Walker wrote:
> 
> > On Thu, 2008-10-02 at 17:05 -0400, Steven Rostedt wrote:
> > 
> > > Why are you bringing up real time in this thread?? The thread has
> > > absolutely nothing to do with real time. This thread is about a better
> > > way to handle interrupt handlers.
> > 
> > I'm concerned about the connection between the two, which is what I'm
> > commenting on.
> 
> Well, please take that up separately. Do you see these patches going
> into the -rt tree?  No, they are going in mainline. We will deal with
> them for -rt when the time comes.

It's an RFC after all, it's not going into anything at this point..

> > 
> > > > 
> > > > I also don't see a clear connection between these changes and ultimately
> > > > removing spinlock level latency in the kernel. I realize you don't
> > > > address that in your comments, but this is part of the initiative to
> > > > remove spinlock level latency..
> > > 
> > > Again, this thread has nothing to do with removing spinlock level latency.
> > > The reason Thomas did not address this is because it is OFF TOPIC!!!!
> > 
> > If they are connected (which I think we established) , then it's not out
> > of line for me to discuss the direction of these changes as related to
> > other components of real time.
> 
> You are bringing up concerns about mainline changes with something that
> is maintained outside the mainline tree.  Changes to mainline have never
> been influenced by changes maintained outside of mainline.

Again it's an RFC .. It's not going into mainline.. 

> > 
> > > > 
> > > > So with this set of changes and in terms of real time, I'm wonder your
> > > > going with this ?
> > > 
> > > You brought in this relationship with real time, just because real time 
> > > uses threaded interrupts. This thread has nothing to do with real time. 
> > > That is what Ingo, Thomas and myself are trying to ge through to you.
> > 
> > You know Steven, often times you start a conversation and you have no
> > idea where it will end up.. You can't always control which direction it
> > will go..
> 
> Yes Daniel, I know. But this is not a conversation. This is a email thread
> that is talking about changes to mainline. The mainline kernel developers
> really don't care about any issues that these changes will do to the
> real time project. The real time project is a niche, and is currently
> outside the mainline tree. Hence, lets stop bothering mainline 
> developers with our issues.

Your speaking for a lot of developers.. It's an RFC, it's coming from
real time developers, it's real time connected, and this is the real
time development list ..

Your preempt-rt patch isn't even what I'm commenting on.

> > 
> > > The strong reaction from Thomas is that you just brought up something that 
> > > is completely off topic.
> > 
> > We already debated this fact Steven. real time and this type of
> > threading are connected. It's not off topic to discuss connected
> > components.
> 
> No Daniel, it is off topic.  The thread is not about real time issues.
> This thread is about mainline. If you have an issue that these changes
> will make to the current mainline tree, then please, by all means, bring
> them up. But do not bring up issues that only affect outside of mainline.

The issues I've brought up are specifically design comments/concerns
related to future directions.. I was not at all speaking to your real
time changes..

> > 
> > If the intent here is to totally disconnect these threading patches from
> > any type of real time in the future, then that's a good answer to my
> > original question .. That these changes have no future what so ever in
> > regards to real time.
> 
> No the intent here is to handle mainline issues. The real time issues you
> consistantly bring up are not important to most kernel developers. If
> you have real time issues with this change, bring that up on a real 
> time forum. Not in this thread.  The changes in this thread are dealing
> with mainline interrupt handlers. There have been several kernel device 
> driver writers who asked us to get interrupt threads in mainline. This was 
> not about real time, this was about helping out mainline kernel 
> developers.

Real time forum ? That's what this list is .. If you want this thread to
stop , you should stop responding to my comments .. Really Steven ..

> > 
> > If they will be used in the future for real time then we should discuss
> > it. I don't think that's off topic at all.
> > 
> > > Basically, drop the real time topic from this thread. It's not related. 
> > > Yes real time addresses threaded interrupts, but just because we are 
> > > talking about threaded interrupts does not mean we are talking about real 
> > > time.
> > 
> > I don't see why you are so concerned with this.. Real time is taboo now?
> 
> Not at all, Daniel, but this thread is not the appropriate place to 
> discuss your real time concerns. You are asking about what this patch has 
> to do with the future real time direction. Who on this thread cares?
> (besides you)

People that don't care about real time related comments, they can stop
reading the thread.. That's the nature of this list ..

Daniel

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Thomas Gleixner]

On Thu, 2 Oct 2008, Daniel Walker wrote:
> On Thu, 2008-10-02 at 18:28 -0400, Steven Rostedt wrote:
> > > > Why are you bringing up real time in this thread?? The thread has
> > > > absolutely nothing to do with real time. This thread is about a better
> > > > way to handle interrupt handlers.
> > > 
> > > I'm concerned about the connection between the two, which is what I'm
> > > commenting on.
> > 
> > Well, please take that up separately. Do you see these patches going
> > into the -rt tree?  No, they are going in mainline. We will deal with
> > them for -rt when the time comes.
> 
> It's an RFC after all, it's not going into anything at this point..

Because you are deciding what's going into mainline, right ?

> > You are bringing up concerns about mainline changes with something that
> > is maintained outside the mainline tree.  Changes to mainline have never
> > been influenced by changes maintained outside of mainline.
> 
> Again it's an RFC .. It's not going into mainline.. 

You made such a statement vs. hrtimers some time ago. 

> > Yes Daniel, I know. But this is not a conversation. This is a email thread
> > that is talking about changes to mainline. The mainline kernel developers
> > really don't care about any issues that these changes will do to the
> > real time project. The real time project is a niche, and is currently
> > outside the mainline tree. Hence, lets stop bothering mainline 
> > developers with our issues.
> 
> Your speaking for a lot of developers.. It's an RFC, it's coming from
> real time developers, it's real time connected, and this is the real
> time development list ..

This RFC patch is from a mainline developer/ maintainer who happens to
be a real time developer as well.

Welcome to my real time incoherent nonsense filter

	tglx

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Daniel Walker]

On Fri, 2008-10-03 at 02:26 +0200, Thomas Gleixner wrote:
> On Thu, 2 Oct 2008, Daniel Walker wrote:
> > On Thu, 2008-10-02 at 18:28 -0400, Steven Rostedt wrote:
> > > > > Why are you bringing up real time in this thread?? The thread has
> > > > > absolutely nothing to do with real time. This thread is about a better
> > > > > way to handle interrupt handlers.
> > > > 
> > > > I'm concerned about the connection between the two, which is what I'm
> > > > commenting on.
> > > 
> > > Well, please take that up separately. Do you see these patches going
> > > into the -rt tree?  No, they are going in mainline. We will deal with
> > > them for -rt when the time comes.
> > 
> > It's an RFC after all, it's not going into anything at this point..
> 
> Because you are deciding what's going into mainline, right ?

You flagged this as an RFC, typically that means it's a work in
progress .. Usually a work in progress does go into mainline.

> > > You are bringing up concerns about mainline changes with something that
> > > is maintained outside the mainline tree.  Changes to mainline have never
> > > been influenced by changes maintained outside of mainline.
> > 
> > Again it's an RFC .. It's not going into mainline.. 
> 
> You made such a statement vs. hrtimers some time ago. 

hrtimers didn't go RFC then straight to mainline either.

> > > Yes Daniel, I know. But this is not a conversation. This is a email thread
> > > that is talking about changes to mainline. The mainline kernel developers
> > > really don't care about any issues that these changes will do to the
> > > real time project. The real time project is a niche, and is currently
> > > outside the mainline tree. Hence, lets stop bothering mainline 
> > > developers with our issues.
> > 
> > Your speaking for a lot of developers.. It's an RFC, it's coming from
> > real time developers, it's real time connected, and this is the real
> > time development list ..
> 
> This RFC patch is from a mainline developer/ maintainer who happens to
> be a real time developer as well.

And is submitting a real time core features.

> Welcome to my real time incoherent nonsense filter

You ask for comments, than get upset when you get some .. If anyone
needs to be filtered it's you.

Daniel

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Andi Kleen]

Thomas Gleixner <tglx@linutronix.de> writes:
>
>  - move long running handlers out of the hard interrupt context

I'm not sure I'm really looking forward to this brave new world
of very long running interrupt handlers. e.g. what do you
do for example when some handler blocks for a very long time?

>  - improved debugability of the kernel: faulty handlers do not take
>    down the system.

I had an old patch to handle this without threaded interrupts. 

What normally happens is when a interrupt oopses it tries to kill the
idle process which panics.  My fix was to just restart another idle
process instead of panicing.

But back then it was rejected by Linus with the argument that
a crashing interrupt handler will typically hold some lock
and the next time the interrupt happens it will deadlock on that
lock. 

Has that changed with your threaded interrupts? 

If it has changed I suspect the restart idle change could
be made to work to be equivalent in debuggability.

> Comments, reviews, flames as usual.

To be honest my opinion is that it will encourage badly written interrupt
code longer term.

-Andi

-- 
ak@linux.intel.com

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Greg KH]

On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
> >
> >  - move long running handlers out of the hard interrupt context
> 
> I'm not sure I'm really looking forward to this brave new world
> of very long running interrupt handlers. e.g. what do you
> do for example when some handler blocks for a very long time?

We have this issue today with some irqs (USB is known for issue here...)

So I don't think this is a big issue, and in the end, a better idea as
it might force us to confront some of the big abusers and fix them.

thanks,

greg k-h

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Arjan van de Ven]

On Thu, 2 Oct 2008 14:31:46 -0700
Greg KH <greg@kroah.com> wrote:

> On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
> > Thomas Gleixner <tglx@linutronix.de> writes:
> > >
> > >  - move long running handlers out of the hard interrupt context
> > 
> > I'm not sure I'm really looking forward to this brave new world
> > of very long running interrupt handlers. e.g. what do you
> > do for example when some handler blocks for a very long time?
> 
> We have this issue today with some irqs (USB is known for issue
> here...)
> 
> So I don't think this is a big issue, and in the end, a better idea as
> it might force us to confront some of the big abusers and fix them.
> 

one of the things irq threads gives you is that 'top' will show you
which ones are eating cpu ;-)


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Andi Kleen]

On Thu, Oct 02, 2008 at 03:33:05PM -0700, Arjan van de Ven wrote:
> On Thu, 2 Oct 2008 14:31:46 -0700
> Greg KH <greg@kroah.com> wrote:
> 
> > On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
> > > Thomas Gleixner <tglx@linutronix.de> writes:
> > > >
> > > >  - move long running handlers out of the hard interrupt context
> > > 
> > > I'm not sure I'm really looking forward to this brave new world
> > > of very long running interrupt handlers. e.g. what do you
> > > do for example when some handler blocks for a very long time?
> > 
> > We have this issue today with some irqs (USB is known for issue
> > here...)
> > 
> > So I don't think this is a big issue, and in the end, a better idea as
> > it might force us to confront some of the big abusers and fix them.
> > 
> 
> one of the things irq threads gives you is that 'top' will show you
> which ones are eating cpu ;-)

oprofile does that job fine already and is imho any time preferable
for detailed analysis.

-andi

-- 
ak@linux.intel.com

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Arjan van de Ven]

On Fri, 3 Oct 2008 05:25:04 +0200
Andi Kleen <andi@firstfloor.org> wrote:

> > 
> > one of the things irq threads gives you is that 'top' will show you
> > which ones are eating cpu ;-)
> 
> oprofile does that job fine already and is imho any time preferable
> for detailed analysis.

while I don't disagree that oprofile will give you more detailed
results, I think there's a HUGE difference between asking a bugreporter
"can you paste a screen of 'top'" and "can you configure and run
oprofile".
CHances are good that the user already thought of top him/herself and
just reports "interrupt X is eating CPU" rather than "something seems
to be eating CPU".

I'm not going argue that this alone is enough justification for
irqthreads, but you can't deny it's an advantage.


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Andi Kleen]

> while I don't disagree that oprofile will give you more detailed
> results, I think there's a HUGE difference between asking a bugreporter
> "can you paste a screen of 'top'" and "can you configure and run
> oprofile".

Perhaps the better fix would be to make oprofile easier to configure.
I never quite understood for example why it doesn't get the symbol
table simply from the kallsyms. Or simply unpacks gzip'ed vmlinux
by itself.

> CHances are good that the user already thought of top him/herself and
> just reports "interrupt X is eating CPU" rather than "something seems
> to be eating CPU".

> 
> I'm not going argue that this alone is enough justification for
> irqthreads, but you can't deny it's an advantage.

Do we have that many cases of runaway irqs? The only common
one I can think of is ACPI, but that is a separate thread already.

Or for networking high performance goes into polling mode
and most of the work is outside hardirq so it wouldn't be visible
in the thread statistics either. But even there livelocks are not
very common.

Also that would assume that the proposed opt in irq threads are used
for all interrupts.

-Andi

Re: [RFC patch 0/5] genirq: add infrastructure for threaded interrupt handlers

[Andi Kleen]

On Thu, Oct 02, 2008 at 02:31:46PM -0700, Greg KH wrote:
> On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
> > Thomas Gleixner <tglx@linutronix.de> writes:
> > >
> > >  - move long running handlers out of the hard interrupt context
> > 
> > I'm not sure I'm really looking forward to this brave new world
> > of very long running interrupt handlers. e.g. what do you
> > do for example when some handler blocks for a very long time?
> 
> We have this issue today with some irqs (USB is known for issue here...)
> 
> So I don't think this is a big issue, and in the end, a better idea as
> it might force us to confront some of the big abusers and fix them.

Not sure I follow? You're saying you want to first allow very long running
IRQ handlers and then after the fact somehow fix them?  Sounds like a weird
proposal to be honest.

The problem of course is that if you have such a very slow hardirq (let's
say one that runs for tens of ms) that what happens when another
interrupt comes in? How deep is your hardware queue?  Or will you 
just lose events in that case?

I suspect in the end you'll need another "fast interrupt" anyways
if the hardware queue is not deep enough to buffer at the software
side. Sounds a bit like the existing "interrupts" vs "softirq" 
doesn't it?

So I'm just not sure what the "slow interrupt handler" will give
you longer term. It just sounds like a redundant concept to me.

The other issue is that if you allow sleeping locks in the interrupt
handler what guarantee is that it won't block for even longer than
tens of milliseconds? And lose even more events.

-Andi

-- 
ak@linux.intel.com

[RFC patch] genirq threading for ehci, ohci and uhci USB hosts

[Sven-Thorsten Dietrich]

On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:
> This patch series implements support for threaded irq handlers for the
> generic IRQ layer.


Subject: genirq threading for ehci, ohci and uhci USB hosts.

This is a functional POC for partitioning of the USB interrupt handlers into
a quickcheck function and a threaded main-handler function.

The quickcheck performs the following actions only: 

        1. read status and stores.
        2. check if the device is asserting, disable device assert
        3. wake irq thread or return IRQ_NONE (shared IRQ not this USB)

The handler thread performs all other operations, and is conditionally
invoked via return code from quickcheck. 

A function pointer *quickcheck() has been added, as well as a status
cache, which remembers the status reported by the chip. The status must
be passed to the threaded handler, since it is cleared by the quickcheck
function.

Currently, non-reentrancy is assumed, i.e. the chip will not assert another
IRQ until the thread has completed running.

In contrast with that, I have tightened up the locking between the 
quickcheck handler and the main thread, this may be overly conservative. 

The WARN_ONCE notes when status reported by the chip does not match 
cached status, although this is expected. Its to be removed.

Note, that locking is not explicitly used for ohci as it is 
in uhci and ehci.

The ieee1394/ohci1394.c is a bit more problematic, since it does not use
struct usb_hcd, and therefore another place for the status cache must be found,
in struct ti_ohci presumably. 
I will send a separate patch for ieee1394/ohci1394.c after looking at it more.

The patch increases the code size by 100 lines, but there are some cleanups 
that account for maybe a dozen lines, which can be broken-out.

Infrastructure:

This hack in kernel/irq/handle.c needs to be looked at, set_bit failed to work
properly on my AMD x86_64 machine, not further investigated and the code path
is currently not triggered by this patch.
+			//set_bit(IRQF_WARNED_THREADED, &action->flags);
+			action->flags |= IRQF_WARNED_THREADED;

Testing:

I have copied hundreds of gigs over ohci and ehci threads to and from USB disk.
In addition, I have written to USB flash, and mouse, keyboard work. 

I have only tested on x86_64 so far, but will start on i386 ASAP.

I encountered some hangs at shutdown, that I attributed to racing, and have
not reproduced it after the locking changes, and when always using the cached
chip status in the threaded handler.

A tarball of all required genirq patches and series against 2.6.27 can 
be downloaded:

http://www.thebigcorporation.com/Sven/genirq-usb/

The patch series also applied fine against Linus's git as well as linux-tip
as of Saturday.


Signed-off-by: Sven-Thorsten Dietrich <sven@thebigcorporation.com>

 drivers/usb/core/hcd.h          |    3 ++
 drivers/usb/host/ehci-au1xxx.c  |    1 
 drivers/usb/host/ehci-fsl.c     |    1 
 drivers/usb/host/ehci-hcd.c     |   40 +++++++++++++++++++++++---------
 drivers/usb/host/ehci-ixp4xx.c  |    1 
 drivers/usb/host/ehci-orion.c   |    1 
 drivers/usb/host/ehci-pci.c     |    1 
 drivers/usb/host/ehci-ppc-of.c  |    1 
 drivers/usb/host/ehci-ps3.c     |    1 
 drivers/usb/host/ohci-at91.c    |    1 
 drivers/usb/host/ohci-au1xxx.c  |    1 
 drivers/usb/host/ohci-ep93xx.c  |    1 
 drivers/usb/host/ohci-hcd.c     |   20 ++++++++++++++--
 drivers/usb/host/ohci-lh7a404.c |    1 
 drivers/usb/host/ohci-omap.c    |    1 
 drivers/usb/host/ohci-pci.c     |    1 
 drivers/usb/host/ohci-pnx4008.c |    1 
 drivers/usb/host/ohci-pnx8550.c |    1 
 drivers/usb/host/ohci-ppc-of.c  |    1 
 drivers/usb/host/ohci-ppc-soc.c |    1 
 drivers/usb/host/ohci-ps3.c     |    1 
 drivers/usb/host/ohci-pxa27x.c  |    1 
 drivers/usb/host/ohci-s3c2410.c |    1 
 drivers/usb/host/ohci-sa1111.c  |    1 
 drivers/usb/host/ohci-sh.c      |    1 
 drivers/usb/host/ohci-sm501.c   |    1 
 drivers/usb/host/ohci-ssb.c     |    1 
 drivers/usb/host/uhci-hcd.c     |   23 +++++++++++++++++-
 kernel/irq/handle.c             |    8 +++---
 30 files changed, 134 insertions(+), 34 deletions(-)

--

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 8ab389d..6afd769 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1673,15 +1673,7 @@ EXPORT_SYMBOL_GPL(usb_bus_start_enum);
 
 /*-------------------------------------------------------------------------*/
 
-/**
- * usb_hcd_irq - hook IRQs to HCD framework (bus glue)
- * @irq: the IRQ being raised
- * @__hcd: pointer to the HCD whose IRQ is being signaled
- *
- * If the controller isn't HALTed, calls the driver's irq handler.
- * Checks whether the controller is now dead.
- */
-irqreturn_t usb_hcd_irq (int irq, void *__hcd)
+irqreturn_t usb_hcd_irq_quickcheck(int irq, void *__hcd)
 {
 	struct usb_hcd		*hcd = __hcd;
 	unsigned long		flags;
@@ -1696,20 +1688,44 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
 	if (unlikely(hcd->state == HC_STATE_HALT ||
 		     !test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags))) {
 		rc = IRQ_NONE;
-	} else if (hcd->driver->irq(hcd) == IRQ_NONE) {
-		rc = IRQ_NONE;
-	} else {
+	} else if ((rc = hcd->driver->irq_quickcheck(hcd)) != IRQ_NONE) {
+
 		set_bit(HCD_FLAG_SAW_IRQ, &hcd->flags);
 
 		if (unlikely(hcd->state == HC_STATE_HALT))
 			usb_hc_died(hcd);
-		rc = IRQ_HANDLED;
 	}
 
 	local_irq_restore(flags);
 	return rc;
 }
 
+/**
+ * usb_hcd_irq - hook IRQs to HCD framework (bus glue)
+ * @irq: the IRQ being raised
+ * @__hcd: pointer to the HCD whose IRQ is being signaled
+ *
+ * If the controller isn't HALTed, calls the driver's irq handler.
+ * Checks whether the controller is now dead.
+ */
+irqreturn_t usb_hcd_irq (int irq, void *__hcd)
+{
+	struct usb_hcd		*hcd = __hcd;
+	unsigned long		flags;
+	irqreturn_t		rc;
+
+	/* Remaining artifact from non-threaded. Is it needed? */
+	local_irq_save(flags);
+
+	rc = hcd->driver->irq(hcd);
+	
+	if (unlikely(hcd->state == HC_STATE_HALT))
+		usb_hc_died(hcd);
+	
+	local_irq_restore(flags);
+	return rc;
+}
+
 /*-------------------------------------------------------------------------*/
 
 /**
@@ -1881,10 +1897,12 @@ int usb_add_hcd(struct usb_hcd *hcd,
 
 		snprintf(hcd->irq_descr, sizeof(hcd->irq_descr), "%s:usb%d",
 				hcd->driver->description, hcd->self.busnum);
-		if ((retval = request_irq(irqnum, &usb_hcd_irq, irqflags,
-				hcd->irq_descr, hcd)) != 0) {
+		retval = request_threaded_irq(irqnum, &usb_hcd_irq, 
+					     &usb_hcd_irq_quickcheck, irqflags,
+					     hcd->irq_descr, hcd);
+		if (retval != 0) {
 			dev_err(hcd->self.controller,
-					"request interrupt %d failed\n", irqnum);
+				"request interrupt %d failed\n", irqnum);
 			goto err_request_irq;
 		}
 		hcd->irq = irqnum;
diff --git a/drivers/usb/core/hcd.h b/drivers/usb/core/hcd.h
index e710ce0..c0b8a12 100644
--- a/drivers/usb/core/hcd.h
+++ b/drivers/usb/core/hcd.h
@@ -113,6 +113,8 @@ struct usb_hcd {
 	struct dma_pool		*pool [HCD_BUFFER_POOLS];
 
 	int			state;
+	unsigned short		status_cache;  /* saved by irq quickcheck */
+
 #	define	__ACTIVE		0x01
 #	define	__SUSPEND		0x04
 #	define	__TRANSIENT		0x80
@@ -164,6 +166,7 @@ struct hc_driver {
 	size_t		hcd_priv_size;	/* size of private data */
 
 	/* irq handler */
+	irqreturn_t	(*irq_quickcheck) (struct usb_hcd *hcd);
 	irqreturn_t	(*irq) (struct usb_hcd *hcd);
 
 	int	flags;
diff --git a/drivers/usb/host/ehci-au1xxx.c b/drivers/usb/host/ehci-au1xxx.c
index bf69f47..b181815 100644
--- a/drivers/usb/host/ehci-au1xxx.c
+++ b/drivers/usb/host/ehci-au1xxx.c
@@ -77,6 +77,7 @@ static const struct hc_driver ehci_au1xxx_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck		= ehci_irq_quickcheck,
 	.irq			= ehci_irq,
 	.flags			= HCD_MEMORY | HCD_USB2,
 
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 01c3da3..32d0b89 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -292,6 +292,7 @@ static const struct hc_driver ehci_fsl_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck = ehci_irq_quickcheck,
 	.irq = ehci_irq,
 	.flags = HCD_USB2,
 
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8409e07..1f7cb48 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -640,15 +640,41 @@ static int ehci_run (struct usb_hcd *hcd)
 
 /*-------------------------------------------------------------------------*/
 
+static irqreturn_t ehci_irq_quickcheck (struct usb_hcd *hcd)
+{
+	struct ehci_hcd		*ehci = hcd_to_ehci (hcd);
+	u32			status;
+
+	spin_lock (&ehci->lock);
+	
+	status = ehci_readl(ehci, &ehci->regs->status);
+	hcd->status_cache = status; 
+
+	if (!status & INTR_MASK) {	/* irq sharing? */
+		spin_unlock(&ehci->lock);
+		return IRQ_NONE;
+	}
+
+	/* clear (just) interrupts */
+	ehci_writel(ehci, status, &ehci->regs->status);
+	hcd->status_cache = status; 
+	spin_unlock (&ehci->lock);
+
+	return IRQ_WAKE_THREAD;
+}
+
 static irqreturn_t ehci_irq (struct usb_hcd *hcd)
 {
 	struct ehci_hcd		*ehci = hcd_to_ehci (hcd);
 	u32			status, pcd_status = 0, cmd;
 	int			bh;
+	unsigned long		flags;
 
-	spin_lock (&ehci->lock);
+	spin_lock_irqsave(&ehci->lock, flags);
 
-	status = ehci_readl(ehci, &ehci->regs->status);
+	WARN_ONCE((ehci_readl(ehci, &ehci->regs->status) != hcd->status_cache),
+		"Chip status change %X - %X\n", hcd->status_cache, status);
+	status = hcd->status_cache;
 
 	/* e.g. cardbus physical eject */
 	if (status == ~(u32) 0) {
@@ -656,14 +682,6 @@ static irqreturn_t ehci_irq (struct usb_hcd *hcd)
 		goto dead;
 	}
 
-	status &= INTR_MASK;
-	if (!status) {			/* irq sharing? */
-		spin_unlock(&ehci->lock);
-		return IRQ_NONE;
-	}
-
-	/* clear (just) interrupts */
-	ehci_writel(ehci, status, &ehci->regs->status);
 	cmd = ehci_readl(ehci, &ehci->regs->command);
 	bh = 0;
 
@@ -748,7 +766,7 @@ dead:
 
 	if (bh)
 		ehci_work (ehci);
-	spin_unlock (&ehci->lock);
+	spin_unlock_irqrestore(&ehci->lock, flags);
 	if (pcd_status)
 		usb_hcd_poll_rh_status(hcd);
 	return IRQ_HANDLED;
diff --git a/drivers/usb/host/ehci-ixp4xx.c b/drivers/usb/host/ehci-ixp4xx.c
index f9575c4..f2ba793 100644
--- a/drivers/usb/host/ehci-ixp4xx.c
+++ b/drivers/usb/host/ehci-ixp4xx.c
@@ -42,6 +42,7 @@ static const struct hc_driver ixp4xx_ehci_hc_driver = {
 	.description		= hcd_name,
 	.product_desc		= "IXP4XX EHCI Host Controller",
 	.hcd_priv_size		= sizeof(struct ehci_hcd),
+	.irq_quickcheck		= ehci_irq_quickcheck,
 	.irq			= ehci_irq,
 	.flags			= HCD_MEMORY | HCD_USB2,
 	.reset			= ixp4xx_ehci_init,
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index 5416cf9..98104e1 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -131,6 +131,7 @@ static const struct hc_driver ehci_orion_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck = ehci_irq_quickcheck,
 	.irq = ehci_irq,
 	.flags = HCD_MEMORY | HCD_USB2,
 
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index c46a58f..5e4cfa0 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -344,6 +344,7 @@ static const struct hc_driver ehci_pci_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck =	ehci_irq_quickcheck,
 	.irq =			ehci_irq,
 	.flags =		HCD_MEMORY | HCD_USB2,
 
diff --git a/drivers/usb/host/ehci-ppc-of.c b/drivers/usb/host/ehci-ppc-of.c
index b018dee..52e2798 100644
--- a/drivers/usb/host/ehci-ppc-of.c
+++ b/drivers/usb/host/ehci-ppc-of.c
@@ -44,6 +44,7 @@ static const struct hc_driver ehci_ppc_of_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck		= ehci_irq_quickcheck,
 	.irq			= ehci_irq,
 	.flags			= HCD_MEMORY | HCD_USB2,
 
diff --git a/drivers/usb/host/ehci-ps3.c b/drivers/usb/host/ehci-ps3.c
index 0eba894..f9fd4fe 100644
--- a/drivers/usb/host/ehci-ps3.c
+++ b/drivers/usb/host/ehci-ps3.c
@@ -56,6 +56,7 @@ static const struct hc_driver ps3_ehci_hc_driver = {
 	.description		= hcd_name,
 	.product_desc		= "PS3 EHCI Host Controller",
 	.hcd_priv_size		= sizeof(struct ehci_hcd),
+	.irq_quickcheck		= ehci_irq_quickcheck,
 	.irq			= ehci_irq,
 	.flags			= HCD_MEMORY | HCD_USB2,
 	.reset			= ps3_ehci_hc_reset,
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 4ed228a..0790627 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -233,6 +233,7 @@ static const struct hc_driver ohci_at91_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck = 	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_USB11 | HCD_MEMORY,
 
diff --git a/drivers/usb/host/ohci-au1xxx.c b/drivers/usb/host/ohci-au1xxx.c
index 2ac4e02..1afe6de 100644
--- a/drivers/usb/host/ohci-au1xxx.c
+++ b/drivers/usb/host/ohci-au1xxx.c
@@ -136,6 +136,7 @@ static const struct hc_driver ohci_au1xxx_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck = 	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_USB11 | HCD_MEMORY,
 
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index fb3055f..30b366e 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -123,6 +123,7 @@ static struct hc_driver ohci_ep93xx_hc_driver = {
 	.description		= hcd_name,
 	.product_desc		= "EP93xx OHCI",
 	.hcd_priv_size		= sizeof(struct ohci_hcd),
+	.irq_quickcheck 	= ohci_irq_quickcheck,
 	.irq			= ohci_irq,
 	.flags			= HCD_USB11 | HCD_MEMORY,
 	.start			= ohci_ep93xx_start,
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 8990196..9a122ec 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -28,6 +28,7 @@
 #include <linux/slab.h>
 #include <linux/errno.h>
 #include <linux/init.h>
+#include <linux/irqreturn.h>
 #include <linux/timer.h>
 #include <linux/list.h>
 #include <linux/usb.h>
@@ -745,8 +746,7 @@ retry:
 /*-------------------------------------------------------------------------*/
 
 /* an interrupt happens */
-
-static irqreturn_t ohci_irq (struct usb_hcd *hcd)
+static irqreturn_t ohci_irq_quickcheck(struct usb_hcd *hcd)
 {
 	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
 	struct ohci_regs __iomem *regs = ohci->regs;
@@ -774,6 +774,22 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd)
 	if (ints == 0)
 		return IRQ_NOTMINE;
 
+	ohci_writel (ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
+	hcd->status_cache = ints;
+
+	return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t ohci_irq (struct usb_hcd *hcd)
+{
+	struct ohci_hcd		*ohci = hcd_to_ohci (hcd);
+	struct ohci_regs __iomem *regs = ohci->regs;
+	int			ints;
+
+	WARN_ONCE((ohci_readl(ohci, &regs->intrstatus) != hcd->status_cache),
+		"Chip status change %X - %X\n", hcd->status_cache, ints);
+	ints = hcd->status_cache;
+
 	if (ints & OHCI_INTR_UE) {
 		// e.g. due to PCI Master/Target Abort
 		if (quirk_nec(ohci)) {
diff --git a/drivers/usb/host/ohci-lh7a404.c b/drivers/usb/host/ohci-lh7a404.c
index de42283..3b51be3 100644
--- a/drivers/usb/host/ohci-lh7a404.c
+++ b/drivers/usb/host/ohci-lh7a404.c
@@ -166,6 +166,7 @@ static const struct hc_driver ohci_lh7a404_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck = 	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_USB11 | HCD_MEMORY,
 
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 95b3ec8..f9c791a 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -442,6 +442,7 @@ static const struct hc_driver ohci_omap_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck = 	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_USB11 | HCD_MEMORY,
 
diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
index a9c2ae3..d04f48b 100644
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -426,6 +426,7 @@ static const struct hc_driver ohci_pci_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck =	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_MEMORY | HCD_USB11,
 
diff --git a/drivers/usb/host/ohci-pnx4008.c b/drivers/usb/host/ohci-pnx4008.c
index 658a2a9..ad0c6fe 100644
--- a/drivers/usb/host/ohci-pnx4008.c
+++ b/drivers/usb/host/ohci-pnx4008.c
@@ -249,6 +249,7 @@ static const struct hc_driver ohci_pnx4008_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck = ohci_irq_quickcheck,
 	.irq = ohci_irq,
 	.flags = HCD_USB11 | HCD_MEMORY,
 
diff --git a/drivers/usb/host/ohci-pnx8550.c b/drivers/usb/host/ohci-pnx8550.c
index 28467e2..ee18f4a 100644
--- a/drivers/usb/host/ohci-pnx8550.c
+++ b/drivers/usb/host/ohci-pnx8550.c
@@ -175,6 +175,7 @@ static const struct hc_driver ohci_pnx8550_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck = 	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_USB11 | HCD_MEMORY,
 
diff --git a/drivers/usb/host/ohci-ppc-of.c b/drivers/usb/host/ohci-ppc-of.c
index 7ac5326..2fe80ac 100644
--- a/drivers/usb/host/ohci-ppc-of.c
+++ b/drivers/usb/host/ohci-ppc-of.c
@@ -45,6 +45,7 @@ static const struct hc_driver ohci_ppc_of_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck =	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_USB11 | HCD_MEMORY,
 
diff --git a/drivers/usb/host/ohci-ppc-soc.c b/drivers/usb/host/ohci-ppc-soc.c
index cd3398b..5fd3dee 100644
--- a/drivers/usb/host/ohci-ppc-soc.c
+++ b/drivers/usb/host/ohci-ppc-soc.c
@@ -145,6 +145,7 @@ static const struct hc_driver ohci_ppc_soc_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck = 	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_USB11 | HCD_MEMORY,
 
diff --git a/drivers/usb/host/ohci-ps3.c b/drivers/usb/host/ohci-ps3.c
index 2089d8a..bd7c1a7 100644
--- a/drivers/usb/host/ohci-ps3.c
+++ b/drivers/usb/host/ohci-ps3.c
@@ -56,6 +56,7 @@ static const struct hc_driver ps3_ohci_hc_driver = {
 	.description		= hcd_name,
 	.product_desc		= "PS3 OHCI Host Controller",
 	.hcd_priv_size		= sizeof(struct ohci_hcd),
+	.irq_quickcheck 	= ohci_irq_quickcheck,
 	.irq			= ohci_irq,
 	.flags			= HCD_MEMORY | HCD_USB11,
 	.reset			= ps3_ohci_hc_reset,
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 7f0f35c..148e37b 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -271,6 +271,7 @@ static const struct hc_driver ohci_pxa27x_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck	= 	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_USB11 | HCD_MEMORY,
 
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index f46af7a..65a51ed 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -439,6 +439,7 @@ static const struct hc_driver ohci_s3c2410_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck = 	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_USB11 | HCD_MEMORY,
 
diff --git a/drivers/usb/host/ohci-sa1111.c b/drivers/usb/host/ohci-sa1111.c
index e4bbe8e..910a313 100644
--- a/drivers/usb/host/ohci-sa1111.c
+++ b/drivers/usb/host/ohci-sa1111.c
@@ -205,6 +205,7 @@ static const struct hc_driver ohci_sa1111_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck = 	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_USB11 | HCD_MEMORY,
 
diff --git a/drivers/usb/host/ohci-sh.c b/drivers/usb/host/ohci-sh.c
index 60f03cc..625bb29 100644
--- a/drivers/usb/host/ohci-sh.c
+++ b/drivers/usb/host/ohci-sh.c
@@ -41,6 +41,7 @@ static const struct hc_driver ohci_sh_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck = 	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_USB11 | HCD_MEMORY,
 
diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index cff2363..c1a0b6b 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -47,6 +47,7 @@ static const struct hc_driver ohci_sm501_hc_driver = {
 	/*
 	 * generic hardware linkage
 	 */
+	.irq_quickcheck =	ohci_irq_quickcheck,
 	.irq =			ohci_irq,
 	.flags =		HCD_USB11 | HCD_MEMORY | HCD_LOCAL_MEM,
 
diff --git a/drivers/usb/host/ohci-ssb.c b/drivers/usb/host/ohci-ssb.c
index 23fd6a8..5b3ab3c 100644
--- a/drivers/usb/host/ohci-ssb.c
+++ b/drivers/usb/host/ohci-ssb.c
@@ -65,6 +65,7 @@ static const struct hc_driver ssb_ohci_hc_driver = {
 	.product_desc		= "SSB OHCI Controller",
 	.hcd_priv_size		= sizeof(struct ssb_ohci_device),
 
+	.irq_quickcheck 	= ohci_irq_quickcheck,
 	.irq			= ohci_irq,
 	.flags			= HCD_MEMORY | HCD_USB11,
 
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 3a7bfe7..4d4481b 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -407,11 +407,12 @@ __acquires(uhci->lock)
 	mod_timer(&uhci_to_hcd(uhci)->rh_timer, jiffies);
 }
 
-static irqreturn_t uhci_irq(struct usb_hcd *hcd)
+static irqreturn_t uhci_irq_quickcheck(struct usb_hcd *hcd)
 {
 	struct uhci_hcd *uhci = hcd_to_uhci(hcd);
 	unsigned short status;
 
+	spin_lock(&uhci->lock);
 	/*
 	 * Read the interrupt status, and write it back to clear the
 	 * interrupt cause.  Contrary to the UHCI specification, the
@@ -421,6 +422,25 @@ static irqreturn_t uhci_irq(struct usb_hcd *hcd)
 	if (!(status & ~USBSTS_HCH))	/* shared interrupt, not mine */
 		return IRQ_NONE;
 	outw(status, uhci->io_addr + USBSTS);		/* Clear it */
+	hcd->status_cache = status;
+	spin_unlock(&uhci->lock);
+
+	return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t uhci_irq(struct usb_hcd *hcd)
+{
+	struct uhci_hcd *uhci = hcd_to_uhci(hcd);
+	unsigned short status;
+	unsigned long flags;
+
+	spin_lock_irqsave(&uhci->lock, flags);
+
+	WARN_ONCE((inw(uhci->io_addr + USBSTS) != hcd->status_cache),
+		"Chip status change %X - %X\n", hcd->status_cache, status);
+	status = hcd->status_cache;
+
+	spin_unlock_irqrestore(&uhci->lock, flags);
 
 	if (status & ~(USBSTS_USBINT | USBSTS_ERROR | USBSTS_RD)) {
 		if (status & USBSTS_HSE)
@@ -900,6 +920,7 @@ static const struct hc_driver uhci_driver = {
 	.hcd_priv_size =	sizeof(struct uhci_hcd),
 
 	/* Generic hardware linkage */
+	.irq_quickcheck =	uhci_irq_quickcheck,
 	.irq =			uhci_irq,
 	.flags =		HCD_USB11,
 
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index b204455..d8faf88 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -152,14 +152,14 @@ irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action)
 			}
 			/*
 			 * Warn once when a quick check handler asked
-			 * for invoking the threaded (main) handler
-			 * directly
+			 * for invoking the threaded (main) handler directly
 			 */
 			WARN(!(action->flags & IRQF_WARNED_THREADED),
 			     "IRQ %d requested to run threaded handler "
 			     "in hard interrupt context\n", irq);
-			set_bit(IRQF_WARNED_THREADED, &action->flags);
-
+			//set_bit(IRQF_WARNED_THREADED, &action->flags);
+			action->flags |= IRQF_WARNED_THREADED;
+	
 		case IRQ_WAKE_THREAD:
 			/*
 			 * In case the thread crashed and was killed

Re: [RFC patch] genirq threading for ehci, ohci and uhci USB hosts

[Jonathan Woithe]

Hi

> > This patch series implements support for threaded irq handlers for the
> > generic IRQ layer.
>
> Subject: genirq threading for ehci, ohci and uhci USB hosts.
> 
> This is a functional POC for partitioning of the USB interrupt handlers into
> a quickcheck function and a threaded main-handler function.
> :
> The ieee1394/ohci1394.c is a bit more problematic, since it does not use
> struct usb_hcd, and therefore another place for the status cache must be found,
> in struct ti_ohci presumably. 
> I will send a separate patch for ieee1394/ohci1394.c after looking at it more.

Thanks for sending this through; I will endeavour to test it over the coming
days.  I'll also see if I can test it for the case where USB and ieee1394
share IRQs.  Even though ieee1394 isn't done yet these changes should
prevent the USB-related problems we've seen in FFADO when USB shares the
firewire IRQ.

Having said that, the forthcoming ohci1394.c patch will also be interesting
since that is the other area which will greatly benefit FFADO.

Regards
  jonathan

Re: [RFC patch] genirq threading (v2) for ehci, ohci and uhci USB hosts and ohci1394

[Sven-Thorsten Dietrich]

On Tue, 2008-10-21 at 11:37 +0930, Jonathan Woithe wrote:
> Hi
> 
> > > This patch series implements support for threaded irq handlers for the
> > > generic IRQ layer.
> >
> > Subject: genirq threading for ehci, ohci and uhci USB hosts.
> > 
> > This is a functional POC for partitioning of the USB interrupt handlers into
> > a quickcheck function and a threaded main-handler function.
> > :
> > The ieee1394/ohci1394.c is a bit more problematic, since it does not use
> > struct usb_hcd, and therefore another place for the status cache must be found,
> > in struct ti_ohci presumably. 
> > I will send a separate patch for ieee1394/ohci1394.c after looking at it more.
> 
> Thanks for sending this through; I will endeavour to test it over the coming
> days.  I'll also see if I can test it for the case where USB and ieee1394
> share IRQs.  Even though ieee1394 isn't done yet these changes should
> prevent the USB-related problems we've seen in FFADO when USB shares the
> firewire IRQ.
> 
> Having said that, the forthcoming ohci1394.c patch will also be interesting
> since that is the other area which will greatly benefit FFADO.
> 

Hi, 

I have re-released the patch set with support for ohci1394. 

I have not tested, for lack of hardware :: it compiles.

The location of status_cache is now within the ti_ohci struct.

That organization not entirely consistent with the USB side, predicated
by other variation between the drivers.

The updated patch queue is available here.

http://www.thebigcorporation.com/Sven/genirq-usb/genirq-usb-v2.tar.bz2

Bug fix:
The declaration of status_cache has been made consistent u32. 
The former declaration of unsigned short (copied from uhci-hcd.c) it was
probably too ambiguous for some architectures.

Thanks,

Sven


> Regards
>   jonathan