genirq: add infrastructure for threaded interrupt handlers
Subsystems (11)
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
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
@@ -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
@@ -1,25 +1,17 @@ -/* irqreturn.h */ #ifndef _LINUX_IRQRETURN_H#define _LINUX_IRQRETURN_H -/* -* For 2.4.x compatibility, 2.4.x can use -* -* typedef void irqreturn_t; -* #define IRQ_NONE -* #define IRQ_HANDLED -* #define IRQ_RETVAL(x) -* -* To mix old-style and new-style irq handler returns. -* -* IRQ_NONE means we didn't handle it. -* IRQ_HANDLED means that we did have a valid interrupt and handled it. -* IRQ_RETVAL(x) selects on the two depending on x being non-zero (for handled) +/** +* enum irqreturn +* @IRQ_NONE interrupt was not from this device +* @IRQ_HANDLED interrupt was handled by this device */ -typedef int irqreturn_t ; +enum irqreturn { +IRQ_NONE , +IRQ_HANDLED , +}; -#define IRQ_NONE (0) -#define IRQ_HANDLED (1) -#define IRQ_RETVAL (x) ((x) != 0) +#define irqreturn_t enum irqreturn +#define IRQ_RETVAL (x) ((x) != IRQ_NONE)#endif
RFC PATCH 2/5 genirq: add a quick check handler
In reply to Thomas GleixnerPreparatory 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
@@ -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
@@ -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
@@ -137,9 +137,21 @@ irqreturn_t handle_IRQ_event(unsigned inlocal_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
@@ -563,9 +563,14 @@ void free_irq(unsigned int irq, void *deEXPORT_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_haif (!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_hareturn retval; } -EXPORT_SYMBOL (request_irq); +EXPORT_SYMBOL (request_irq_quickcheck);
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.
Steven Rostedt
reviewerRe: [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
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.
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
Steven Rostedt
reviewerRe: [RFC patch 2/5] genirq: add a quick check handler
In reply to Thomas GleixnerThomas,
Nice work, thanks for doing this.
Little comments below.
include/linux/interrupt.h struct irqaction { · line 77
Quoted 8 lines · Thomas Gleixner
extern
irqreturn_tno_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 irqreturnIndex:
linux-2.6-tip/kernel/irq/handle.c
===================================================================kernel/irq/handle.c +15
-3@@ -137,9 +137,21 @@ irqreturn_t handle_IRQ_event(unsigned inlocal_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 *deEXPORT_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_haif (!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_hareturn retval; } -EXPORT_SYMBOL (request_irq); +EXPORT_SYMBOL (request_irq_quickcheck);
Re: [RFC patch 2/5] genirq: add a quick check handler
In reply to Thomas GleixnerQuoted 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..
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_HANDLINGto get a separatethread_fncalled. This seems more intuitive and means less mess in the fastpath.
see patch 3/5 :)
Quoted 2 lines
Maybe
IRQ_NEEDS_HANDLINGmight better be namedIRQ_THREADEDos similar, but that's really getting into nitpicking..
The reason why I split this out is: when you start to convert your driver, then you can split out the quick check handler first w/o making the real handler threaded in the first place. Once you got that right you can work on moving the real handler into a thread.
Thanks,
tglx
RFC PATCH 3/5 genirq: add threaded interrupt handler support
In reply to Thomas GleixnerAdd 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
@@ -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 0x00008000typedef 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_handlereturn 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
@@ -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
@@ -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
Steven Rostedt
reviewerRe: [RFC patch 3/5] genirq: add threaded interrupt handler support
Quoted 16 lines · Thomas Gleixner
#define
irqreturn_tenum 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
-4break ; -case IRQ_NEEDS_HANDLING : - ret = action->handler (irq, action->dev_id); -if (ret ==IRQ_HANDLED ) - status |= action->flags; +default :break ; } retval |= ret;
-- Steve
RFC PATCH 4/5 genirq: add a helper to check whether the irq thread should run
In reply to Thomas GleixnerThe 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
@@ -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
@@ -341,7 +341,7 @@ static int irq_thread(void *data)set_current_state (TASK_INTERRUPTIBLE );while (!kthread_should_stop ()) { -if (!test_and_clear_bit (IRQF_RUNTHREAD , &action->flags)) { +if (!irq_thread_should_run (action)) {schedule ();/* Avoid running the handler on stop */ if (kthread_should_stop ())
RFC PATCH 5/5 genirq: make irq threading robust
In reply to Thomas GleixnerTo 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
@@ -61,6 +61,7 @@#define IRQF_THREADED 0x00002000#define IRQF_RUNTHREAD 0x00004000#define IRQF_WARNED_THREADED 0x00008000 +#define IRQF_THREAD_DIED 0x00010000typedef 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
@@ -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
@@ -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
@@ -161,8 +161,17 @@ irqreturn_t handle_IRQ_event(unsigned inset_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
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_irqand trying tokthread_stopthe dead thread, we plug a pointer to irqaction intotask_struct, which is evaluated indo_exit(). When the thread crashes thedo_exitcode marks the thread as DIED inirqaction->flagsto 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.
Steven Rostedt
reviewerRe: [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_irqand trying tokthread_stopthe dead thread, we plug a pointer to irqaction intotask_struct, which is evaluated indo_exit(). When the thread crashes thedo_exitcode marks the thread as DIED inirqaction->flagsto 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_structsthis 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
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?
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
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.
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
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.
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
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 : 0vendor_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 : 2fdiv_bug : nohlt_bug : nof00f_bug : nocoma_bug : no
fpu : yesfpu_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 : 1vendor_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 : 2fdiv_bug : nohlt_bug : nof00f_bug : nocoma_bug : no
fpu : yesfpu_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
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
Steven Rostedt
reviewerQuoted 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
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_locksandspin_lock_irqsand mutexes.By creating an interrupt thread, we can skip the softirq/tasklet altogether, and this simplifies locking.
How does this simplify locking ?
Daniel
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
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
Steven Rostedt
reviewerQuoted 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
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
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
Steven Rostedt
reviewerQuoted 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
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
Steven Rostedt
reviewerQuoted 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
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
Steven Rostedt
reviewerQuoted 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
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
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
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
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]
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
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
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]
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
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
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]
RFC PATCH 1/1 genirq threading for ehci, ohci and uhci USB hosts
In reply to Thomas GleixnerQuoted 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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, ®s->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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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);
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.
:
Theieee1394/ohci1394.cis a bit more problematic, since it does not use structusb_hcd, and therefore another place for the status cache must be found, in structti_ohcipresumably.
I will send a separate patch forieee1394/ohci1394.cafter looking at it more.
Thanks for sending this through; I will endeavour to test it over the coming days. I'll also see if I can test it for the case where USB and ieee1394 share IRQs. Even though ieee1394 isn't done yet these changes should prevent the USB-related problems we've seen in FFADO when USB shares the firewire IRQ.
Having said that, the forthcoming ohci1394.c patch will also be interesting since that is the other area which will greatly benefit FFADO.
Regards
jonathan
Re: [RFC patch] genirq threading (v2) for ehci, ohci and uhci USB hosts and ohci1394
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.
:
Theieee1394/ohci1394.cis a bit more problematic, since it does not use structusb_hcd, and therefore another place for the status cache must be found, in structti_ohcipresumably.
I will send a separate patch forieee1394/ohci1394.cafter 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.cpatch 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