Skip to contentSkip to conversation

genirq: add infrastructure for threaded interrupt handlers

RFC PATCH In review Thomas Gleixner 13 participants 49 messages Oct 1, 2008 – Oct 21, 2008

Subsystems (11)
lore
Share & tools
lore
#0 lore raw

cover genirq: add infrastructure for threaded interrupt handlers

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

#1 lore raw

RFC PATCH 1/5 genirq: make irqreturn_t an enum

Remove the 2.4 compabiliy cruft

---
 include/linux/irq.h       |    4 ++--
 include/linux/irqreturn.h |   28 ++++++++++------------------
 2 files changed, 12 insertions(+), 20 deletions(-)
include/linux/irq.h +2 -2
Index: 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);
include/linux/irqreturn.h +10 -18
Index: 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
#2 lore raw

RFC PATCH 2/5 genirq: add a quick check handler

In reply to Thomas Gleixner

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.

---
 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(-)
include/linux/interrupt.h +13 -1
Index: 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;
include/linux/irqreturn.h +2 -0
Index: 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
kernel/irq/handle.c +15 -3
Index: 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);
kernel/irq/manage.c +13 -6
Index: 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);
#3 lore raw

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

include/linux/interrupt.h line 62

Quoted 3 lines · Thomas Gleixner

struct irqaction {

include/linux/interrupt.h +1 -0
+	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.

#4 lore raw

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

Quoted 8 lines · Jon Masters

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

#5 lore raw

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

Quoted 10 lines · Steven Rostedt
Quoted 8 lines · Jon Masters

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.

Quoted 4 lines

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.

#6 lore raw

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

Quoted 16 lines · Jon Masters
Quoted 10 lines · Steven Rostedt
Quoted 8 lines · Jon Masters

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.

Quoted 4 lines

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 ;-)

Quoted 6 lines

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

#7 lore raw

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

In reply to Thomas Gleixner

Thomas,

Nice work, thanks for doing this.

Little comments below.

include/linux/interrupt.h struct irqaction { · line 77

Quoted 8 lines · Thomas Gleixner

extern irqreturn_t no_action(int cpl, void *dev_id);

include/linux/interrupt.h +4 -1
-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

Quoted 65 lines
include/linux/interrupt.h +8 -0
+
+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
===================================================================

include/linux/irqreturn.h +2 -0
@@ -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
===================================================================

kernel/irq/handle.c +15 -3
@@ -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
===================================================================

kernel/irq/manage.c +0 -0
@@ -563,9 +563,14 @@ void free_irq(unsigned int irq, void *de
 EXPORT_SYMBOL(free_irq);
 
 /**

kernel/irq/manage.c void free_irq(unsigned int irq, void *de · line 573

Quoted 10 lines
kernel/irq/manage.c +7 -2
- *	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

Quoted 35 lines
kernel/irq/manage.c +6 -4
  *	@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);
#8 lore raw

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

In reply to Thomas Gleixner
Quoted 6 lines · Thomas Gleixner

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..

#9 lore raw

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

Quoted 11 lines · Christoph Hellwig
Quoted 6 lines · Thomas Gleixner

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 :)

Quoted 2 lines

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

#10 lore raw

RFC PATCH 3/5 genirq: add threaded interrupt handler support

In reply to Thomas Gleixner

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.

---
 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(-)
include/linux/interrupt.h +17 -0
Index: 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;
include/linux/irqreturn.h +2 -0
Index: 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
kernel/irq/handle.c +26 -5
Index: 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;
kernel/irq/manage.c +49 -2

99 lines not on this page · raw message

#11 lore raw

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

Quoted 16 lines · Thomas Gleixner

#define irqreturn_t enum irqreturn
Index: linux-2.6-tip/kernel/irq/handle.c
===================================================================

kernel/irq/handle.c +6 -1
@@ -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;

kernel/irq/handle.c irqreturn_t handle_IRQ_event(unsigned in · line 161

Quoted 10 lines
kernel/irq/handle.c +10 -0
+			}
+			/*
+			 * 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.

Quoted 9 lines
kernel/irq/handle.c +9 -0
+
+		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;

kernel/irq/handle.c irqreturn_t handle_IRQ_event(unsigned in · line 176

Quoted 10 lines
kernel/irq/handle.c +1 -4
 			break;
 
-		case IRQ_NEEDS_HANDLING:
-			ret = action->handler(irq, action->dev_id);
-			if (ret == IRQ_HANDLED)
-				status |= action->flags;
+		default:
 			break;
 		}
 		retval |= ret;

-- Steve

#12 lore raw

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

In reply to Thomas Gleixner

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

---
 include/linux/interrupt.h |    5 +++++
 kernel/irq/manage.c       |    2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)
include/linux/interrupt.h +5 -0
Index: 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
kernel/irq/manage.c +1 -1
Index: 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())
#13 lore raw

RFC PATCH 5/5 genirq: make irq threading robust

In reply to Thomas Gleixner

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.

---
 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(-)
include/linux/interrupt.h +3 -0
Index: 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
include/linux/sched.h +1 -0
Index: 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;
 };
 
 /*
kernel/exit.c +2 -0
Index: 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
kernel/irq/handle.c +11 -2
Index: 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.
kernel/irq/manage.c +41 -3

73 lines not on this page · raw message

#14 lore raw

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

Quoted 9 lines · Thomas Gleixner

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.

include/linux/sched.h struct task_struct { · line 1305

Quoted 5 lines
include/linux/sched.h +1 -0
@@ -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.

#15 lore raw

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

Quoted 10 lines · Jon Masters
Quoted 7 lines · Thomas Gleixner

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.

Quoted 9 lines

include/linux/sched.h struct task_struct { · line 1305

Quoted 6 lines
include/linux/sched.h +1 -0
@@ -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

#16 lore raw
In reply to Thomas Gleixner
Quoted 7 lines · On Wed, 01 Oct 2008 23:02:08 -0000 Thomas Gleixner <[email protected]> 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?

#17 lore raw
Quoted 4 lines · On Wed, 1 Oct 2008 16:23:33 -0700 Andrew Morton <[email protected]>…

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.

Signature · 3 lines
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
#18 lore raw
Quoted 8 lines · On Wed, 1 Oct 2008 16:29:50 -0700 Arjan van de Ven <[email protected]> wrote:
Quoted 4 lines · On Wed, 1 Oct 2008 16:23:33 -0700 Andrew Morton <[email protected]>…

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

Quoted 5 lines

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 :(

Quoted 2 lines

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

#19 lore raw
Quoted 17 lines · Andrew Morton
Quoted 8 lines · On Wed, 1 Oct 2008 16:29:50 -0700 Arjan van de Ven <[email protected]> wrote:
Quoted 4 lines · On Wed, 1 Oct 2008 16:23:33 -0700 Andrew Morton <[email protected]>…

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

Quoted 5 lines

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

Quoted 7 lines

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

#20 lore raw
In reply to Thomas Gleixner
Quoted 3 lines · Thomas Gleixner

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.

#21 lore raw
Quoted 9 lines · Jon Masters
Quoted 3 lines · Thomas Gleixner

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

#22 lore raw

Hi there,

[CC'ed some distribution specific experts]

Quoted 7 lines · you
Quoted 6 lines · Jon Masters
Quoted 3 lines · Thomas Gleixner

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. :)

Quoted 5 lines
Quoted 3 lines

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: [email protected]
[   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

#23 lore raw
In reply to Thomas Gleixner
Quoted 11 lines · Thomas Gleixner

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

#24 lore raw
Quoted 9 lines · Daniel Walker
Quoted 4 lines

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.

Quoted 5 lines

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.

Quoted 3 lines

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

#25 lore raw
Quoted 6 lines · Steven Rostedt
Quoted 5 lines · Daniel Walker
Quoted 4 lines

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.

Quoted 6 lines
Quoted 4 lines

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 ..

Quoted 7 lines
Quoted 5 lines

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.

Quoted 10 lines
Quoted 3 lines

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

#26 lore raw
Quoted 12 lines · Daniel Walker
Quoted 11 lines · Steven Rostedt
Quoted 9 lines · Daniel Walker
Quoted 4 lines

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..

Quoted 4 lines
Quoted 1 line

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

#27 lore raw
Quoted 2 lines · Thomas Gleixner

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?

Quoted 2 lines

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..

Quoted 7 lines

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

#28 lore raw
Quoted 22 lines · Daniel Walker
Quoted 2 lines · Thomas Gleixner

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?

Quoted 2 lines

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..

Quoted 7 lines

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.

Quoted 5 lines

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

#29 lore raw
In reply to Daniel Walker
Quoted 2 lines · Daniel Walker
Quoted 2 lines
Quoted 2 lines

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.

Quoted 5 lines
Quoted 2 lines

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

#30 lore raw
Quoted 8 lines · Ingo Molnar
Quoted 2 lines · Daniel Walker
Quoted 2 lines
Quoted 2 lines

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 ..

Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

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

#31 lore raw
Quoted 11 lines · Daniel Walker
Quoted 8 lines · Ingo Molnar
Quoted 2 lines · Daniel Walker
Quoted 2 lines
Quoted 2 lines

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.

Quoted 3 lines

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

#32 lore raw
Quoted 8 lines · Steven Rostedt
Quoted 6 lines · Daniel Walker
Quoted 5 lines · Ingo Molnar
Quoted 2 lines · Daniel Walker
Quoted 2 lines
Quoted 2 lines

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

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 3 lines

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:

Quoted 8 lines

- 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

#33 lore raw
Quoted 7 lines · Daniel Walker
Quoted 7 lines

What Ingo is telling you is:

- RT needs threaded interrupts.

- Threaded interrupts do not need RT

Quoted 8 lines
Quoted 4 lines

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:

Quoted 4 lines

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.

Quoted 5 lines

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!!!!

Quoted 3 lines

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

#34 lore raw
Quoted 3 lines · Steven Rostedt

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.

Quoted 8 lines
Quoted 5 lines

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.

Quoted 7 lines
Quoted 3 lines

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..

Quoted 2 lines

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.

Quoted 4 lines

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

#35 lore raw
Quoted 8 lines · Daniel Walker
Quoted 3 lines · Steven Rostedt

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.

Quoted 7 lines
Quoted 7 lines
Quoted 6 lines

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..

Quoted 6 lines
Quoted 2 lines

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.

Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

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

Quoted 7 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 3 lines

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.

Quoted 5 lines

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.

Quoted 10 lines

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.

Quoted 4 lines

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

#36 lore raw
Quoted 9 lines · Steven Rostedt
Quoted 6 lines · Daniel Walker
Quoted 3 lines · Steven Rostedt

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.

Quoted 6 lines
Quoted 2 lines

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..

Quoted 10 lines
Quoted 10 lines
Quoted 9 lines
Quoted 6 lines

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!!!!

Quoted 7 lines
Quoted 3 lines

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..

Quoted 13 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines

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

Quoted 7 lines
Quoted 3 lines

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..

Quoted 6 lines

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.

Quoted 4 lines
Quoted 4 lines
Quoted 3 lines

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

Quoted 8 lines
Quoted 3 lines

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..

Quoted 6 lines
Quoted 5 lines

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.

Quoted 8 lines

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 ..

Quoted 9 lines
Quoted 9 lines

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.

Quoted 4 lines

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.

Quoted 6 lines
Quoted 1 line

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

#37 lore raw
Quoted 5 lines · Daniel Walker
Quoted 4 lines · Steven Rostedt
Quoted 4 lines
Quoted 3 lines

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.

Quoted 8 lines
Quoted 6 lines
Quoted 2 lines

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 ?

Quoted 5 lines
Quoted 3 lines

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.

Quoted 10 lines
Quoted 6 lines

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

#38 lore raw
Quoted 9 lines · Thomas Gleixner
Quoted 8 lines · Daniel Walker
Quoted 7 lines · Steven Rostedt
Quoted 6 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 5 lines
Quoted 3 lines

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.

Quoted 7 lines
Quoted 7 lines
Quoted 6 lines

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.

Quoted 6 lines
Quoted 3 lines

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.

Quoted 1 line

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

#39 lore raw
In reply to Thomas Gleixner
Quoted 2 lines · Thomas Gleixner

- 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?

Quoted 2 lines

- 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.

Quoted 1 line

Comments, reviews, flames as usual.

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

-Andi

Signature · 1 line
[email protected]
#40 lore raw
Quoted 7 lines · Andi Kleen
Quoted 2 lines · Thomas Gleixner

- 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

#41 lore raw
Quoted 9 lines · On Thu, 2 Oct 2008 14:31:46 -0700 Greg KH <[email protected]> wrote:
Quoted 7 lines · Andi Kleen
Quoted 2 lines · Thomas Gleixner

- 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?

Quoted 6 lines

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 ;-)

Signature · 3 lines
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
#42 lore raw
Quoted 15 lines · Arjan van de Ven
Quoted 12 lines · On Thu, 2 Oct 2008 14:31:46 -0700 Greg KH <[email protected]> wrote:
Quoted 7 lines · Andi Kleen
Quoted 2 lines · Thomas Gleixner

- 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...)

Quoted 6 lines
Quoted 3 lines

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

Signature · 1 line
[email protected]
#43 lore raw
Quoted 6 lines · On Fri, 3 Oct 2008 05:25:04 +0200 Andi Kleen <[email protected]> wrote:
Quoted 3 lines

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.

Signature · 3 lines
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
#44 lore raw
Quoted 4 lines

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.

Quoted 7 lines

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

#45 lore raw
In reply to Greg KH
Quoted 5 lines · Greg KH
Quoted 4 lines · Andi Kleen
Quoted 2 lines · Thomas Gleixner

- move long running handlers out of the hard interrupt context

Quoted 8 lines
Quoted 3 lines

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

Signature · 1 line
[email protected]
#46 lore raw

RFC PATCH 1/1 genirq threading for ehci, ohci and uhci USB hosts

In reply to Thomas Gleixner
Quoted 2 lines · Thomas Gleixner

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.

 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(-)

--

drivers/usb/core/hcd.c +34 -16
index 8ab389d..6afd769 100644
@@ -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;
drivers/usb/core/hcd.h +3 -0
index e710ce0..c0b8a12 100644
@@ -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;
drivers/usb/host/ehci-au1xxx.c +1 -0
index bf69f47..b181815 100644
@@ -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,
 
drivers/usb/host/ehci-fsl.c +1 -0
index 01c3da3..32d0b89 100644
@@ -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,
 
drivers/usb/host/ehci-hcd.c +29 -11
index 8409e07..1f7cb48 100644
@@ -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;
drivers/usb/host/ehci-ixp4xx.c +1 -0
index f9575c4..f2ba793 100644
@@ -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,
drivers/usb/host/ehci-orion.c +1 -0
index 5416cf9..98104e1 100644
@@ -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,
 
drivers/usb/host/ehci-pci.c +1 -0
index c46a58f..5e4cfa0 100644
@@ -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,
 
drivers/usb/host/ehci-ppc-of.c +1 -0
index b018dee..52e2798 100644
@@ -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,
 
drivers/usb/host/ehci-ps3.c +1 -0
index 0eba894..f9fd4fe 100644
@@ -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,
drivers/usb/host/ohci-at91.c +1 -0
index 4ed228a..0790627 100644
@@ -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,
 
drivers/usb/host/ohci-au1xxx.c +1 -0
index 2ac4e02..1afe6de 100644
@@ -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,
 
drivers/usb/host/ohci-ep93xx.c +1 -0
index fb3055f..30b366e 100644
@@ -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,
drivers/usb/host/ohci-hcd.c +18 -2
index 8990196..9a122ec 100644
@@ -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)) {
drivers/usb/host/ohci-lh7a404.c +1 -0
index de42283..3b51be3 100644
@@ -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,
 
drivers/usb/host/ohci-omap.c +1 -0
index 95b3ec8..f9c791a 100644
@@ -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,
 
drivers/usb/host/ohci-pci.c +1 -0
index a9c2ae3..d04f48b 100644
@@ -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,
 
drivers/usb/host/ohci-pnx4008.c +1 -0
index 658a2a9..ad0c6fe 100644
@@ -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,
 
drivers/usb/host/ohci-pnx8550.c +1 -0
index 28467e2..ee18f4a 100644
@@ -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,
 
drivers/usb/host/ohci-ppc-of.c +1 -0
index 7ac5326..2fe80ac 100644
@@ -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,
 
drivers/usb/host/ohci-ppc-soc.c +1 -0
index cd3398b..5fd3dee 100644
@@ -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,
 
drivers/usb/host/ohci-ps3.c +1 -0
index 2089d8a..bd7c1a7 100644
@@ -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,
drivers/usb/host/ohci-pxa27x.c +1 -0
index 7f0f35c..148e37b 100644
@@ -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,
 
drivers/usb/host/ohci-s3c2410.c +1 -0
index f46af7a..65a51ed 100644
@@ -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,
 
drivers/usb/host/ohci-sa1111.c +1 -0
index e4bbe8e..910a313 100644
@@ -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,
 
drivers/usb/host/ohci-sh.c +1 -0
index 60f03cc..625bb29 100644
@@ -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,
 
drivers/usb/host/ohci-sm501.c +1 -0
index cff2363..c1a0b6b 100644
@@ -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,
 
drivers/usb/host/ohci-ssb.c +1 -0
index 23fd6a8..5b3ab3c 100644
@@ -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,
 
drivers/usb/host/uhci-hcd.c +22 -1
index 3a7bfe7..4d4481b 100644
@@ -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,
 
kernel/irq/handle.c +1 -3
index b204455..d8faf88 100644
@@ -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);
#47 lore raw

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

Hi

Quoted 5 lines
Quoted 2 lines

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

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

Quoted 7 lines

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

#48 lore raw

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

Quoted 15 lines · Jonathan Woithe

Hi

Quoted 5 lines
Quoted 2 lines

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

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

Quoted 7 lines

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.

Quoted 9 lines

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

Quoted 2 lines

Regards
jonathan