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
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?
On Wed, 1 Oct 2008 16:23:33 -0700
Andrew Morton <[email protected]> wrote:
>
> I'm a bit surprised to see that there is no facility for per-cpu
> interrupt threads?
>
per handler is the right approach (that way, if one dies, all other
interrupts will likely keep working)
now.. normally an interrupt only goes to one cpu, so effectively it is
per cpu already anyway
we should however make the irq threads follow the affinity masks of the
irq... that'd be an easy add-on and probably worthwhile.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Wed, 1 Oct 2008 16:29:50 -0700
Arjan van de Ven <[email protected]> wrote:
> On Wed, 1 Oct 2008 16:23:33 -0700
> Andrew Morton <[email protected]> wrote:
>
> >
> > I'm a bit surprised to see that there is no facility for per-cpu
> > interrupt threads?
> >
>
> per handler is the right approach (that way, if one dies, all other
> interrupts will likely keep working)
>
> now.. normally an interrupt only goes to one cpu, so effectively it is
> per cpu already anyway
Yes, if a) the thread was asleep when it was woken up and b) if the
scheduler does the right thing and wakes the thread on the CPU which
called wake_up().
The ongoing sagas of tbench/mysql/volanomark regressions make me think
that any behaviour which we "expect" of the scheduler should be
triple-checked daily :(
> we should however make the irq threads follow the affinity masks of the
> irq... that'd be an easy add-on and probably worthwhile.
On Wed, 1 Oct 2008, Andrew Morton wrote:
> On Wed, 1 Oct 2008 16:29:50 -0700
> Arjan van de Ven <[email protected]> wrote:
>
> > On Wed, 1 Oct 2008 16:23:33 -0700
> > Andrew Morton <[email protected]> wrote:
> >
> > >
> > > I'm a bit surprised to see that there is no facility for per-cpu
> > > interrupt threads?
> > >
> >
> > per handler is the right approach (that way, if one dies, all other
> > interrupts will likely keep working)
> >
> > now.. normally an interrupt only goes to one cpu, so effectively it is
> > per cpu already anyway
>
> Yes, if a) the thread was asleep when it was woken up and b) if the
> scheduler does the right thing and wakes the thread on the CPU which
> called wake_up().
>
> The ongoing sagas of tbench/mysql/volanomark regressions make me think
> that any behaviour which we "expect" of the scheduler should be
> triple-checked daily :(
Yup. I missed that detail when I dusted off the moldy patches.
Of course we need to pin the thread to the affinity mask of the
hardware interrupt.
/me goes back to do home work :)
Thanks,
tglx
On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:
> I hope to have a real converted driver (aside of the dummy module used
> for testing) ready real soon - as far as bugs/regressions stay out of
> my way for a while. :)
Sven and I started poking at the various USB host drivers on the flight
back from Plumbers. I'll see if I can convert over a few here on the
systems that I have and send over some patches.
Jon.
On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:
> The implementation provides an opt-in mechanism to convert drivers to
> the threaded interrupt handler model contrary to the preempt-rt patch
> where the threaded handlers are enabled by a brute force switch. The
> brute force switch is suboptimal as it does not change the interrupt
> handler -> tasklet/softirq interaction problems, but was the only way
> which was possible for the limited man power of the preempt-rt
> developers.
>
> Converting an interrupt to threaded makes only sense when the handler
> code takes advantage of it by integrating tasklet/softirq
> functionality and simplifying the locking.
I'm not clear on your direction here.. I don't have a problem with a
mass driver audit, which I think is what your suggesting with this patch
set .. However, a mass audit like that would push a fully real time
system out for quite some time..
I also don't see a clear connection between these changes and ultimately
removing spinlock level latency in the kernel. I realize you don't
address that in your comments, but this is part of the initiative to
remove spinlock level latency..
So with this set of changes and in terms of real time, I'm wonder your
going with this ?
Daniel
Thomas Gleixner <[email protected]> writes:
>
> - move long running handlers out of the hard interrupt context
I'm not sure I'm really looking forward to this brave new world
of very long running interrupt handlers. e.g. what do you
do for example when some handler blocks for a very long time?
> - improved debugability of the kernel: faulty handlers do not take
> down the system.
I had an old patch to handle this without threaded interrupts.
What normally happens is when a interrupt oopses it tries to kill the
idle process which panics. My fix was to just restart another idle
process instead of panicing.
But back then it was rejected by Linus with the argument that
a crashing interrupt handler will typically hold some lock
and the next time the interrupt happens it will deadlock on that
lock.
Has that changed with your threaded interrupts?
If it has changed I suspect the restart idle change could
be made to work to be equivalent in debuggability.
> Comments, reviews, flames as usual.
To be honest my opinion is that it will encourage badly written interrupt
code longer term.
-Andi
--
[email protected]
On Wed, 1 Oct 2008, Daniel Walker wrote:
> >
> > Converting an interrupt to threaded makes only sense when the handler
> > code takes advantage of it by integrating tasklet/softirq
> > functionality and simplifying the locking.
>
> I'm not clear on your direction here.. I don't have a problem with a
> mass driver audit, which I think is what your suggesting with this patch
> set .. However, a mass audit like that would push a fully real time
> system out for quite some time..
This has nothing to do with real time, although it helps.
>
> I also don't see a clear connection between these changes and ultimately
> removing spinlock level latency in the kernel. I realize you don't
> address that in your comments, but this is part of the initiative to
> remove spinlock level latency..
This is a completely different topic.
>
> So with this set of changes and in terms of real time, I'm wonder your
> going with this ?
This helps with latencies and locking. With the current scheme of hardirq,
softirq/tasklets, there are a lot of craziness with spin_locks and
spin_lock_irqs and mutexes.
By creating an interrupt thread, we can skip the softirq/tasklet
altogether, and this simplifies locking.
There are other cases where threaded interrupt handlers also improve
performance. But we will get to those in due time.
-- Steve
On Thu, 2008-10-02 at 11:02 -0400, Steven Rostedt wrote:
> On Wed, 1 Oct 2008, Daniel Walker wrote:
> > >
> > > Converting an interrupt to threaded makes only sense when the handler
> > > code takes advantage of it by integrating tasklet/softirq
> > > functionality and simplifying the locking.
> >
> > I'm not clear on your direction here.. I don't have a problem with a
> > mass driver audit, which I think is what your suggesting with this patch
> > set .. However, a mass audit like that would push a fully real time
> > system out for quite some time..
>
> This has nothing to do with real time, although it helps.
Clearly threading irq handlers does have something to do with real time,
unless this patch isn't actually threading anything ..
> >
> > I also don't see a clear connection between these changes and ultimately
> > removing spinlock level latency in the kernel. I realize you don't
> > address that in your comments, but this is part of the initiative to
> > remove spinlock level latency..
>
> This is a completely different topic.
It's all connected to the removal of latency .. One part depending on
the other parts, so you can't disconnect this from the rest of it.
> >
> > So with this set of changes and in terms of real time, I'm wonder your
> > going with this ?
>
> This helps with latencies and locking. With the current scheme of hardirq,
> softirq/tasklets, there are a lot of craziness with spin_locks and
> spin_lock_irqs and mutexes.
>
> By creating an interrupt thread, we can skip the softirq/tasklet
> altogether, and this simplifies locking.
How does this simplify locking ?
Daniel
On Thu, 2 Oct 2008, Daniel Walker wrote:
> On Thu, 2008-10-02 at 11:02 -0400, Steven Rostedt wrote:
> > On Wed, 1 Oct 2008, Daniel Walker wrote:
> > > >
> > > > Converting an interrupt to threaded makes only sense when the handler
> > > > code takes advantage of it by integrating tasklet/softirq
> > > > functionality and simplifying the locking.
> > >
> > > I'm not clear on your direction here.. I don't have a problem with a
> > > mass driver audit, which I think is what your suggesting with this patch
> > > set .. However, a mass audit like that would push a fully real time
> > > system out for quite some time..
> >
> > This has nothing to do with real time, although it helps.
>
> Clearly threading irq handlers does have something to do with real time,
> unless this patch isn't actually threading anything ..
Clearly you have neither clue about real time nor about operating
systems in general.
Solaris, some BSDs and MacOSX use interrupt threads. Where exactly is
the relation to realtime?
The concept of interrupt threads is nothing which is in any way
related to real time. It is a well known and pretty old concept in
operating system design.
The fact that real time operating systems benefit from interrupt
threads is a totally different topic.
tglx
On Thu, 2008-10-02 at 20:42 +0200, Thomas Gleixner wrote:
> Clearly you have neither clue about real time nor about operating
> systems in general.
Here we go again Thomas.. You think you can have a conversation without
the insults for once?
> Solaris, some BSDs and MacOSX use interrupt threads. Where exactly is
> the relation to realtime?
The very fact that you mention it in your release notes .. You mention
the type of system in "preempt-rt" and the advantage of your system..
> The concept of interrupt threads is nothing which is in any way
> related to real time. It is a well known and pretty old concept in
> operating system design.
>
> The fact that real time operating systems benefit from interrupt
> threads is a totally different topic.
>
The fact that a direct relationship exists means that any threaded
interrupt system needs to take into account the inevitable connection to
real time since it will be used in that system as a core component.. If
you can't effectively achieve real time with your system , than that's a
problem that needs to be addressed.
Daniel
On Thu, 2 Oct 2008, Daniel Walker wrote:
> On Thu, 2008-10-02 at 20:42 +0200, Thomas Gleixner wrote:
>
> > Clearly you have neither clue about real time nor about operating
> > systems in general.
>
> Here we go again Thomas.. You think you can have a conversation without
> the insults for once?
>
> > Solaris, some BSDs and MacOSX use interrupt threads. Where exactly is
> > the relation to realtime?
>
> The very fact that you mention it in your release notes .. You mention
> the type of system in "preempt-rt" and the advantage of your system..
>
> > The concept of interrupt threads is nothing which is in any way
> > related to real time. It is a well known and pretty old concept in
> > operating system design.
> >
> > The fact that real time operating systems benefit from interrupt
> > threads is a totally different topic.
> >
>
> The fact that a direct relationship exists means that any threaded
> interrupt system needs to take into account the inevitable connection to
> real time since it will be used in that system as a core component.. If
> you can't effectively achieve real time with your system , than that's a
> problem that needs to be addressed.
Daniel, what kind of logic is this? I was already accused of being on
crack today (but was just too much coffee). Perhaps you might be the one
that's on crack.
I build a pipe. There exists a relationship between a pipe and crap
running through it from my toilet. Does this mean that every time I need a
pipe, that I need to take into account the inevitable connection to crap
to run through it?
God, I can see the problems with my gas lines.
-- Steve
* Daniel Walker <[email protected]> wrote:
> > > Clearly threading irq handlers does have something to do with real
> > > time, unless this patch isn't actually threading anything ..
Well, that's clearly wrong: threaded IRQ handlers are not tied to
real-time in any way. Yes, they can be used for RT too but as far as the
upstream kernel is involved that's at most an afterthought.
and the "unless this patch isn't actually threading anything" bit does
not parse at all. The patches execute hard-IRQ handlers from special
kernel threads.
> > Clearly you have neither clue about real time nor about operating
> > systems in general.
>
> Here we go again Thomas.. You think you can have a conversation
> without the insults for once?
what Thomas said was a strong but fair reaction to your obviously
incorrect statement. What reaction did you expect?
Ingo
On Thu, 2008-10-02 at 21:28 +0200, Ingo Molnar wrote:
> * Daniel Walker <[email protected]> wrote:
>
> > > > Clearly threading irq handlers does have something to do with real
> > > > time, unless this patch isn't actually threading anything ..
>
> Well, that's clearly wrong: threaded IRQ handlers are not tied to
> real-time in any way. Yes, they can be used for RT too but as far as the
> upstream kernel is involved that's at most an afterthought.
You contradict yourself .. I said "Clearly threading irq handlers does
have something to do with real time" then you say "they can be used for
RT too" .. So my comments are clearly correct , they have "something" to
do with real time. There exists a relationship of some kind or type.
You should go back and read my initial questions, they are reasonable ..
> > > Clearly you have neither clue about real time nor about operating
> > > systems in general.
> >
> > Here we go again Thomas.. You think you can have a conversation
> > without the insults for once?
>
> what Thomas said was a strong but fair reaction to your obviously
> incorrect statement. What reaction did you expect?
We need less insults on this list not more.. Maybe I could understand
his reaction had I insulted him, but I didn't.. "Fair reaction" doesn't
fit in this case ..
Daniel
On Thu, 2 Oct 2008, Daniel Walker wrote:
> On Thu, 2008-10-02 at 21:28 +0200, Ingo Molnar wrote:
> > * Daniel Walker <[email protected]> wrote:
> >
> > > > > Clearly threading irq handlers does have something to do with real
> > > > > time, unless this patch isn't actually threading anything ..
> >
> > Well, that's clearly wrong: threaded IRQ handlers are not tied to
> > real-time in any way. Yes, they can be used for RT too but as far as the
> > upstream kernel is involved that's at most an afterthought.
>
> You contradict yourself .. I said "Clearly threading irq handlers does
No he did not.
> have something to do with real time" then you say "they can be used for
> RT too" .. So my comments are clearly correct , they have "something" to
> do with real time. There exists a relationship of some kind or type.
What Ingo is telling you is:
- RT needs threaded interrupts.
- Threaded interrupts do not need RT
My dog is an Italian Greyhound.
Italian Greyhound is a dog, but
a dog is not an Italian Greyhound.
-- Steve
On Thu, 2008-10-02 at 16:14 -0400, Steven Rostedt wrote:
> On Thu, 2 Oct 2008, Daniel Walker wrote:
>
> > On Thu, 2008-10-02 at 21:28 +0200, Ingo Molnar wrote:
> > > * Daniel Walker <[email protected]> wrote:
> > >
> > > > > > Clearly threading irq handlers does have something to do with real
> > > > > > time, unless this patch isn't actually threading anything ..
> > >
> > > Well, that's clearly wrong: threaded IRQ handlers are not tied to
> > > real-time in any way. Yes, they can be used for RT too but as far as the
> > > upstream kernel is involved that's at most an afterthought.
> >
> > You contradict yourself .. I said "Clearly threading irq handlers does
>
> No he did not.
Yes, he did.
> > have something to do with real time" then you say "they can be used for
> > RT too" .. So my comments are clearly correct , they have "something" to
> > do with real time. There exists a relationship of some kind or type.
>
>
> What Ingo is telling you is:
>
> - RT needs threaded interrupts.
>
> - Threaded interrupts do not need RT
>
> My dog is an Italian Greyhound.
>
> Italian Greyhound is a dog, but
> a dog is not an Italian Greyhound.
My comments are basically bidirectional , so what your saying doesn't
make any sense .. I said basically, that dogs and "Italian Greyhounds"
have _some_ connection .. Why are we even debating this.
Daniel
On Thu, 2 Oct 2008, Daniel Walker wrote:
> >
> > What Ingo is telling you is:
> >
> > - RT needs threaded interrupts.
> >
> > - Threaded interrupts do not need RT
> >
> > My dog is an Italian Greyhound.
> >
> > Italian Greyhound is a dog, but
> > a dog is not an Italian Greyhound.
>
> My comments are basically bidirectional , so what your saying doesn't
> make any sense .. I said basically, that dogs and "Italian Greyhounds"
> have _some_ connection .. Why are we even debating this.
Let's look at your original comments:
> I'm not clear on your direction here.. I don't have a problem with a
> mass driver audit, which I think is what your suggesting with this patch
> set .. However, a mass audit like that would push a fully real time
> system out for quite some time..
Why are you bringing up real time in this thread?? The thread has
absolutely nothing to do with real time. This thread is about a better
way to handle interrupt handlers.
>
> I also don't see a clear connection between these changes and ultimately
> removing spinlock level latency in the kernel. I realize you don't
> address that in your comments, but this is part of the initiative to
> remove spinlock level latency..
Again, this thread has nothing to do with removing spinlock level latency.
The reason Thomas did not address this is because it is OFF TOPIC!!!!
>
> So with this set of changes and in terms of real time, I'm wonder your
> going with this ?
You brought in this relationship with real time, just because real time
uses threaded interrupts. This thread has nothing to do with real time.
That is what Ingo, Thomas and myself are trying to ge through to you.
The strong reaction from Thomas is that you just brought up something that
is completely off topic.
Basically, drop the real time topic from this thread. It's not related.
Yes real time addresses threaded interrupts, but just because we are
talking about threaded interrupts does not mean we are talking about real
time.
Actually my analogy with dogs and IG's is wrong. The pipe and crap analogy
is better. Crap uses pipes to get out of the house. But if I'm talking
about pipes, I don't want to hear about crap.
We are debating this because YOU brought it up!
-- Steve
On Thu, 2008-10-02 at 17:05 -0400, Steven Rostedt wrote:
> Why are you bringing up real time in this thread?? The thread has
> absolutely nothing to do with real time. This thread is about a better
> way to handle interrupt handlers.
I'm concerned about the connection between the two, which is what I'm
commenting on.
> >
> > I also don't see a clear connection between these changes and ultimately
> > removing spinlock level latency in the kernel. I realize you don't
> > address that in your comments, but this is part of the initiative to
> > remove spinlock level latency..
>
> Again, this thread has nothing to do with removing spinlock level latency.
> The reason Thomas did not address this is because it is OFF TOPIC!!!!
If they are connected (which I think we established) , then it's not out
of line for me to discuss the direction of these changes as related to
other components of real time.
> >
> > So with this set of changes and in terms of real time, I'm wonder your
> > going with this ?
>
> You brought in this relationship with real time, just because real time
> uses threaded interrupts. This thread has nothing to do with real time.
> That is what Ingo, Thomas and myself are trying to ge through to you.
You know Steven, often times you start a conversation and you have no
idea where it will end up.. You can't always control which direction it
will go..
> The strong reaction from Thomas is that you just brought up something that
> is completely off topic.
We already debated this fact Steven. real time and this type of
threading are connected. It's not off topic to discuss connected
components.
If the intent here is to totally disconnect these threading patches from
any type of real time in the future, then that's a good answer to my
original question .. That these changes have no future what so ever in
regards to real time.
If they will be used in the future for real time then we should discuss
it. I don't think that's off topic at all.
> Basically, drop the real time topic from this thread. It's not related.
> Yes real time addresses threaded interrupts, but just because we are
> talking about threaded interrupts does not mean we are talking about real
> time.
I don't see why you are so concerned with this.. Real time is taboo now?
Daniel
On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
> Thomas Gleixner <[email protected]> writes:
> >
> > - move long running handlers out of the hard interrupt context
>
> I'm not sure I'm really looking forward to this brave new world
> of very long running interrupt handlers. e.g. what do you
> do for example when some handler blocks for a very long time?
We have this issue today with some irqs (USB is known for issue here...)
So I don't think this is a big issue, and in the end, a better idea as
it might force us to confront some of the big abusers and fix them.
thanks,
greg k-h
On Wed, Oct 01, 2008 at 08:40:14PM -0400, Jon Masters wrote:
> On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:
>
> > I hope to have a real converted driver (aside of the dummy module used
> > for testing) ready real soon - as far as bugs/regressions stay out of
> > my way for a while. :)
>
> Sven and I started poking at the various USB host drivers on the flight
> back from Plumbers. I'll see if I can convert over a few here on the
> systems that I have and send over some patches.
There's only 3, how hard could it be? :)
/me runs away quickly
On Thu, 2 Oct 2008, Daniel Walker wrote:
> On Thu, 2008-10-02 at 17:05 -0400, Steven Rostedt wrote:
>
> > Why are you bringing up real time in this thread?? The thread has
> > absolutely nothing to do with real time. This thread is about a better
> > way to handle interrupt handlers.
>
> I'm concerned about the connection between the two, which is what I'm
> commenting on.
Well, please take that up separately. Do you see these patches going
into the -rt tree? No, they are going in mainline. We will deal with
them for -rt when the time comes.
>
> > >
> > > I also don't see a clear connection between these changes and ultimately
> > > removing spinlock level latency in the kernel. I realize you don't
> > > address that in your comments, but this is part of the initiative to
> > > remove spinlock level latency..
> >
> > Again, this thread has nothing to do with removing spinlock level latency.
> > The reason Thomas did not address this is because it is OFF TOPIC!!!!
>
> If they are connected (which I think we established) , then it's not out
> of line for me to discuss the direction of these changes as related to
> other components of real time.
You are bringing up concerns about mainline changes with something that
is maintained outside the mainline tree. Changes to mainline have never
been influenced by changes maintained outside of mainline.
>
> > >
> > > So with this set of changes and in terms of real time, I'm wonder your
> > > going with this ?
> >
> > You brought in this relationship with real time, just because real time
> > uses threaded interrupts. This thread has nothing to do with real time.
> > That is what Ingo, Thomas and myself are trying to ge through to you.
>
> You know Steven, often times you start a conversation and you have no
> idea where it will end up.. You can't always control which direction it
> will go..
Yes Daniel, I know. But this is not a conversation. This is a email thread
that is talking about changes to mainline. The mainline kernel developers
really don't care about any issues that these changes will do to the
real time project. The real time project is a niche, and is currently
outside the mainline tree. Hence, lets stop bothering mainline
developers with our issues.
>
> > The strong reaction from Thomas is that you just brought up something that
> > is completely off topic.
>
> We already debated this fact Steven. real time and this type of
> threading are connected. It's not off topic to discuss connected
> components.
No Daniel, it is off topic. The thread is not about real time issues.
This thread is about mainline. If you have an issue that these changes
will make to the current mainline tree, then please, by all means, bring
them up. But do not bring up issues that only affect outside of mainline.
>
> If the intent here is to totally disconnect these threading patches from
> any type of real time in the future, then that's a good answer to my
> original question .. That these changes have no future what so ever in
> regards to real time.
No the intent here is to handle mainline issues. The real time issues you
consistantly bring up are not important to most kernel developers. If
you have real time issues with this change, bring that up on a real
time forum. Not in this thread. The changes in this thread are dealing
with mainline interrupt handlers. There have been several kernel device
driver writers who asked us to get interrupt threads in mainline. This was
not about real time, this was about helping out mainline kernel
developers.
>
> If they will be used in the future for real time then we should discuss
> it. I don't think that's off topic at all.
>
> > Basically, drop the real time topic from this thread. It's not related.
> > Yes real time addresses threaded interrupts, but just because we are
> > talking about threaded interrupts does not mean we are talking about real
> > time.
>
> I don't see why you are so concerned with this.. Real time is taboo now?
Not at all, Daniel, but this thread is not the appropriate place to
discuss your real time concerns. You are asking about what this patch has
to do with the future real time direction. Who on this thread cares?
(besides you)
The topic for mainline patch threads needs to stay focused on mainline.
Not on out of tree branches. When the rest of real time is in mainline,
then sure, you can discuss those concerns then. But until that happens,
keep to the topic of the thread. Which for now is not real time.
-- Steve
On Thu, 2 Oct 2008 14:31:46 -0700
Greg KH <[email protected]> wrote:
> On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
> > Thomas Gleixner <[email protected]> writes:
> > >
> > > - move long running handlers out of the hard interrupt context
> >
> > I'm not sure I'm really looking forward to this brave new world
> > of very long running interrupt handlers. e.g. what do you
> > do for example when some handler blocks for a very long time?
>
> We have this issue today with some irqs (USB is known for issue
> here...)
>
> So I don't think this is a big issue, and in the end, a better idea as
> it might force us to confront some of the big abusers and fix them.
>
one of the things irq threads gives you is that 'top' will show you
which ones are eating cpu ;-)
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
On Thu, 2008-10-02 at 18:28 -0400, Steven Rostedt wrote:
>
> On Thu, 2 Oct 2008, Daniel Walker wrote:
>
> > On Thu, 2008-10-02 at 17:05 -0400, Steven Rostedt wrote:
> >
> > > Why are you bringing up real time in this thread?? The thread has
> > > absolutely nothing to do with real time. This thread is about a better
> > > way to handle interrupt handlers.
> >
> > I'm concerned about the connection between the two, which is what I'm
> > commenting on.
>
> Well, please take that up separately. Do you see these patches going
> into the -rt tree? No, they are going in mainline. We will deal with
> them for -rt when the time comes.
It's an RFC after all, it's not going into anything at this point..
> >
> > > >
> > > > I also don't see a clear connection between these changes and ultimately
> > > > removing spinlock level latency in the kernel. I realize you don't
> > > > address that in your comments, but this is part of the initiative to
> > > > remove spinlock level latency..
> > >
> > > Again, this thread has nothing to do with removing spinlock level latency.
> > > The reason Thomas did not address this is because it is OFF TOPIC!!!!
> >
> > If they are connected (which I think we established) , then it's not out
> > of line for me to discuss the direction of these changes as related to
> > other components of real time.
>
> You are bringing up concerns about mainline changes with something that
> is maintained outside the mainline tree. Changes to mainline have never
> been influenced by changes maintained outside of mainline.
Again it's an RFC .. It's not going into mainline..
> >
> > > >
> > > > So with this set of changes and in terms of real time, I'm wonder your
> > > > going with this ?
> > >
> > > You brought in this relationship with real time, just because real time
> > > uses threaded interrupts. This thread has nothing to do with real time.
> > > That is what Ingo, Thomas and myself are trying to ge through to you.
> >
> > You know Steven, often times you start a conversation and you have no
> > idea where it will end up.. You can't always control which direction it
> > will go..
>
> Yes Daniel, I know. But this is not a conversation. This is a email thread
> that is talking about changes to mainline. The mainline kernel developers
> really don't care about any issues that these changes will do to the
> real time project. The real time project is a niche, and is currently
> outside the mainline tree. Hence, lets stop bothering mainline
> developers with our issues.
Your speaking for a lot of developers.. It's an RFC, it's coming from
real time developers, it's real time connected, and this is the real
time development list ..
Your preempt-rt patch isn't even what I'm commenting on.
> >
> > > The strong reaction from Thomas is that you just brought up something that
> > > is completely off topic.
> >
> > We already debated this fact Steven. real time and this type of
> > threading are connected. It's not off topic to discuss connected
> > components.
>
> No Daniel, it is off topic. The thread is not about real time issues.
> This thread is about mainline. If you have an issue that these changes
> will make to the current mainline tree, then please, by all means, bring
> them up. But do not bring up issues that only affect outside of mainline.
The issues I've brought up are specifically design comments/concerns
related to future directions.. I was not at all speaking to your real
time changes..
> >
> > If the intent here is to totally disconnect these threading patches from
> > any type of real time in the future, then that's a good answer to my
> > original question .. That these changes have no future what so ever in
> > regards to real time.
>
> No the intent here is to handle mainline issues. The real time issues you
> consistantly bring up are not important to most kernel developers. If
> you have real time issues with this change, bring that up on a real
> time forum. Not in this thread. The changes in this thread are dealing
> with mainline interrupt handlers. There have been several kernel device
> driver writers who asked us to get interrupt threads in mainline. This was
> not about real time, this was about helping out mainline kernel
> developers.
Real time forum ? That's what this list is .. If you want this thread to
stop , you should stop responding to my comments .. Really Steven ..
> >
> > If they will be used in the future for real time then we should discuss
> > it. I don't think that's off topic at all.
> >
> > > Basically, drop the real time topic from this thread. It's not related.
> > > Yes real time addresses threaded interrupts, but just because we are
> > > talking about threaded interrupts does not mean we are talking about real
> > > time.
> >
> > I don't see why you are so concerned with this.. Real time is taboo now?
>
> Not at all, Daniel, but this thread is not the appropriate place to
> discuss your real time concerns. You are asking about what this patch has
> to do with the future real time direction. Who on this thread cares?
> (besides you)
People that don't care about real time related comments, they can stop
reading the thread.. That's the nature of this list ..
Daniel
On Thu, 2 Oct 2008, Daniel Walker wrote:
> On Thu, 2008-10-02 at 18:28 -0400, Steven Rostedt wrote:
> > > > Why are you bringing up real time in this thread?? The thread has
> > > > absolutely nothing to do with real time. This thread is about a better
> > > > way to handle interrupt handlers.
> > >
> > > I'm concerned about the connection between the two, which is what I'm
> > > commenting on.
> >
> > Well, please take that up separately. Do you see these patches going
> > into the -rt tree? No, they are going in mainline. We will deal with
> > them for -rt when the time comes.
>
> It's an RFC after all, it's not going into anything at this point..
Because you are deciding what's going into mainline, right ?
> > You are bringing up concerns about mainline changes with something that
> > is maintained outside the mainline tree. Changes to mainline have never
> > been influenced by changes maintained outside of mainline.
>
> Again it's an RFC .. It's not going into mainline..
You made such a statement vs. hrtimers some time ago.
> > Yes Daniel, I know. But this is not a conversation. This is a email thread
> > that is talking about changes to mainline. The mainline kernel developers
> > really don't care about any issues that these changes will do to the
> > real time project. The real time project is a niche, and is currently
> > outside the mainline tree. Hence, lets stop bothering mainline
> > developers with our issues.
>
> Your speaking for a lot of developers.. It's an RFC, it's coming from
> real time developers, it's real time connected, and this is the real
> time development list ..
This RFC patch is from a mainline developer/ maintainer who happens to
be a real time developer as well.
Welcome to my real time incoherent nonsense filter
tglx
On Thu, Oct 02, 2008 at 02:31:46PM -0700, Greg KH wrote:
> On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
> > Thomas Gleixner <[email protected]> writes:
> > >
> > > - move long running handlers out of the hard interrupt context
> >
> > I'm not sure I'm really looking forward to this brave new world
> > of very long running interrupt handlers. e.g. what do you
> > do for example when some handler blocks for a very long time?
>
> We have this issue today with some irqs (USB is known for issue here...)
>
> So I don't think this is a big issue, and in the end, a better idea as
> it might force us to confront some of the big abusers and fix them.
Not sure I follow? You're saying you want to first allow very long running
IRQ handlers and then after the fact somehow fix them? Sounds like a weird
proposal to be honest.
The problem of course is that if you have such a very slow hardirq (let's
say one that runs for tens of ms) that what happens when another
interrupt comes in? How deep is your hardware queue? Or will you
just lose events in that case?
I suspect in the end you'll need another "fast interrupt" anyways
if the hardware queue is not deep enough to buffer at the software
side. Sounds a bit like the existing "interrupts" vs "softirq"
doesn't it?
So I'm just not sure what the "slow interrupt handler" will give
you longer term. It just sounds like a redundant concept to me.
The other issue is that if you allow sleeping locks in the interrupt
handler what guarantee is that it won't block for even longer than
tens of milliseconds? And lose even more events.
-Andi
--
[email protected]
On Thu, Oct 02, 2008 at 03:33:05PM -0700, Arjan van de Ven wrote:
> On Thu, 2 Oct 2008 14:31:46 -0700
> Greg KH <[email protected]> wrote:
>
> > On Thu, Oct 02, 2008 at 04:46:09PM +0200, Andi Kleen wrote:
> > > Thomas Gleixner <[email protected]> writes:
> > > >
> > > > - move long running handlers out of the hard interrupt context
> > >
> > > I'm not sure I'm really looking forward to this brave new world
> > > of very long running interrupt handlers. e.g. what do you
> > > do for example when some handler blocks for a very long time?
> >
> > We have this issue today with some irqs (USB is known for issue
> > here...)
> >
> > So I don't think this is a big issue, and in the end, a better idea as
> > it might force us to confront some of the big abusers and fix them.
> >
>
> one of the things irq threads gives you is that 'top' will show you
> which ones are eating cpu ;-)
oprofile does that job fine already and is imho any time preferable
for detailed analysis.
-andi
--
[email protected]
On Fri, 3 Oct 2008 05:25:04 +0200
Andi Kleen <[email protected]> wrote:
> >
> > one of the things irq threads gives you is that 'top' will show you
> > which ones are eating cpu ;-)
>
> oprofile does that job fine already and is imho any time preferable
> for detailed analysis.
while I don't disagree that oprofile will give you more detailed
results, I think there's a HUGE difference between asking a bugreporter
"can you paste a screen of 'top'" and "can you configure and run
oprofile".
CHances are good that the user already thought of top him/herself and
just reports "interrupt X is eating CPU" rather than "something seems
to be eating CPU".
I'm not going argue that this alone is enough justification for
irqthreads, but you can't deny it's an advantage.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
> while I don't disagree that oprofile will give you more detailed
> results, I think there's a HUGE difference between asking a bugreporter
> "can you paste a screen of 'top'" and "can you configure and run
> oprofile".
Perhaps the better fix would be to make oprofile easier to configure.
I never quite understood for example why it doesn't get the symbol
table simply from the kallsyms. Or simply unpacks gzip'ed vmlinux
by itself.
> CHances are good that the user already thought of top him/herself and
> just reports "interrupt X is eating CPU" rather than "something seems
> to be eating CPU".
>
> I'm not going argue that this alone is enough justification for
> irqthreads, but you can't deny it's an advantage.
Do we have that many cases of runaway irqs? The only common
one I can think of is ACPI, but that is a separate thread already.
Or for networking high performance goes into polling mode
and most of the work is outside hardirq so it wouldn't be visible
in the thread statistics either. But even there livelocks are not
very common.
Also that would assume that the proposed opt in irq threads are used
for all interrupts.
-Andi
On Fri, 2008-10-03 at 02:26 +0200, Thomas Gleixner wrote:
> On Thu, 2 Oct 2008, Daniel Walker wrote:
> > On Thu, 2008-10-02 at 18:28 -0400, Steven Rostedt wrote:
> > > > > Why are you bringing up real time in this thread?? The thread has
> > > > > absolutely nothing to do with real time. This thread is about a better
> > > > > way to handle interrupt handlers.
> > > >
> > > > I'm concerned about the connection between the two, which is what I'm
> > > > commenting on.
> > >
> > > Well, please take that up separately. Do you see these patches going
> > > into the -rt tree? No, they are going in mainline. We will deal with
> > > them for -rt when the time comes.
> >
> > It's an RFC after all, it's not going into anything at this point..
>
> Because you are deciding what's going into mainline, right ?
You flagged this as an RFC, typically that means it's a work in
progress .. Usually a work in progress does go into mainline.
> > > You are bringing up concerns about mainline changes with something that
> > > is maintained outside the mainline tree. Changes to mainline have never
> > > been influenced by changes maintained outside of mainline.
> >
> > Again it's an RFC .. It's not going into mainline..
>
> You made such a statement vs. hrtimers some time ago.
hrtimers didn't go RFC then straight to mainline either.
> > > Yes Daniel, I know. But this is not a conversation. This is a email thread
> > > that is talking about changes to mainline. The mainline kernel developers
> > > really don't care about any issues that these changes will do to the
> > > real time project. The real time project is a niche, and is currently
> > > outside the mainline tree. Hence, lets stop bothering mainline
> > > developers with our issues.
> >
> > Your speaking for a lot of developers.. It's an RFC, it's coming from
> > real time developers, it's real time connected, and this is the real
> > time development list ..
>
> This RFC patch is from a mainline developer/ maintainer who happens to
> be a real time developer as well.
And is submitting a real time core features.
> Welcome to my real time incoherent nonsense filter
You ask for comments, than get upset when you get some .. If anyone
needs to be filtered it's you.
Daniel
Hi there,
[CC'ed some distribution specific experts]
On Friday 03 October 2008, you wrote:
> On Wed, Oct 01, 2008 at 08:40:14PM -0400, Jon Masters wrote:
> > On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:
> >
> > > I hope to have a real converted driver (aside of the dummy module used
> > > for testing) ready real soon - as far as bugs/regressions stay out of
> > > my way for a while. :)
> >
> > Sven and I started poking at the various USB host drivers on the flight
> > back from Plumbers. I'll see if I can convert over a few here on the
> > systems that I have and send over some patches.
>
> There's only 3, how hard could it be? :)
Heh! That feature is the only thing, that keeps my crappy combination
of hardware and Ubuntu Hardy together :-)
With the non-RT Ubuntu kernel flavors, it just hangs in that situation.
It looks like this at the moment with a Ubuntu RT-Kernel, in case someone
likes to debug that:
[ 0.000000] Initializing cgroup subsys cpuset
[ 0.000000] Linux version 2.6.24-21-rt (buildd@palmer) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP PREEMPT RT Mon Aug 25 19:24:40 UTC 2008 (Ubuntu 2.6.24-4.6-generic)
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 00000000cfff0000 (usable)
[ 0.000000] BIOS-e820: 00000000cfff0000 - 00000000cfff3000 (ACPI NVS)
[ 0.000000] BIOS-e820: 00000000cfff3000 - 00000000d0000000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000d0000000 - 00000000e0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000e8000000 - 00000000f0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
[ 0.000000] BIOS-e820: 0000000100000000 - 0000000130000000 (usable)
[ 0.000000] Warning only 4GB will be used.
[ 0.000000] Use a HIGHMEM64G enabled kernel.
[ 0.000000] 3200MB HIGHMEM available.
[ 0.000000] 896MB LOWMEM available.
[ 0.000000] found SMP MP-table at 000f4b40
[ 0.000000] Entering add_active_range(0, 0, 1048576) 0 entries of 256 used
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 4096
[ 0.000000] Normal 4096 -> 229376
[ 0.000000] HighMem 229376 -> 1048576
[ 0.000000] Movable zone start PFN for each node
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 1048576
[ 0.000000] On node 0 totalpages: 1048576
[ 0.000000] DMA zone: 56 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 4040 pages, LIFO batch:0
[ 0.000000] Normal zone: 3080 pages used for memmap
[ 0.000000] Normal zone: 222200 pages, LIFO batch:31
[ 0.000000] HighMem zone: 11200 pages used for memmap
[ 0.000000] HighMem zone: 808000 pages, LIFO batch:31
[ 0.000000] Movable zone: 0 pages used for memmap
[ 0.000000] DMI 2.3 present.
[ 0.000000] ACPI: RSDP signature @ 0xC00F6490 checksum 0
[ 0.000000] ACPI: RSDP 000F6490, 0014 (r0 GBT )
[ 0.000000] ACPI: RSDT CFFF3000, 0030 (r1 GBT NVDAACPI 42302E31 NVDA 1010101)
[ 0.000000] ACPI: FACP CFFF3040, 0074 (r1 GBT NVDAACPI 42302E31 NVDA 1010101)
[ 0.000000] ACPI: DSDT CFFF30C0, 4B34 (r1 GBT NVDAACPI 1000 MSFT 100000C)
[ 0.000000] ACPI: FACS CFFF0000, 0040
[ 0.000000] ACPI: MCFG CFFF7C80, 003C (r1 GBT NVDAACPI 42302E31 NVDA 1010101)
[ 0.000000] ACPI: APIC CFFF7C00, 007C (r1 GBT NVDAACPI 42302E31 NVDA 1010101)
[ 0.000000] Nvidia board detected. Ignoring ACPI timer override.
[ 0.000000] If you got timer trouble try acpi_use_timer_override
[ 0.000000] ACPI: PM-Timer IO Port: 0x1008
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
[ 0.000000] Processor #0 15:11 APIC version 16
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
[ 0.000000] Processor #1 15:11 APIC version 16
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1])
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
[ 0.000000] ACPI: Skipping IOAPIC probe due to 'noapic' option.
[ 0.000000] Using ACPI for processor (LAPIC) configuration information
[ 0.000000] Intel MultiProcessor Specification v1.4
[ 0.000000] Virtual Wire compatibility mode.
[ 0.000000] OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
[ 0.000000] I/O APIC #2 Version 17 at 0xFEC00000.
[ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs
[ 0.000000] Processors: 2
[ 0.000000] Allocating PCI resources starting at f1000000 (gap: f0000000:0ec00000)
[ 0.000000] swsusp: Registered nosave memory region: 000000000009f000 - 00000000000a0000
[ 0.000000] swsusp: Registered nosave memory region: 00000000000a0000 - 00000000000f0000
[ 0.000000] swsusp: Registered nosave memory region: 00000000000f0000 - 0000000000100000
[ 0.000000] Real-Time Preemption Support (C) 2004-2007 Ingo Molnar
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 1034240
[ 0.000000] Kernel command line: root=/dev/mapper/Ubuntu-root ro noapic quiet splash
[ 0.000000] mapped APIC to ffffb000 (fee00000)
[ 0.000000] mapped IOAPIC to ffffa000 (fec00000)
[ 0.000000] Enabling fast FPU save and restore... done.
[ 0.000000] Enabling unmasked SIMD FPU exception support... done.
[ 0.000000] Initializing CPU#0
[ 0.000000] PID hash table entries: 4096 (order: 12, 16384 bytes)
[ 0.000000] Detected 2211.442 MHz processor.
[ 18.517765] spurious 8259A interrupt: IRQ7.
[ 18.519999] Console: colour VGA+ 80x25
[ 18.520001] console [tty0] enabled
[ 18.520235] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[ 18.520537] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 18.688113] Memory: 3335620k/4194304k available (2225k kernel code, 71024k reserved, 1059k data, 368k init, 2490304k highmem)
[ 18.688120] virtual kernel memory layout:
[ 18.688121] fixmap : 0xfff4b000 - 0xfffff000 ( 720 kB)
[ 18.688122] pkmap : 0xff800000 - 0xffc00000 (4096 kB)
[ 18.688123] vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB)
[ 18.688124] lowmem : 0xc0000000 - 0xf8000000 ( 896 MB)
[ 18.688125] .init : 0xc043b000 - 0xc0497000 ( 368 kB)
[ 18.688126] .data : 0xc032c6d0 - 0xc0435324 (1059 kB)
[ 18.688127] .text : 0xc0100000 - 0xc032c6d0 (2225 kB)
[ 18.688130] Checking if this processor honours the WP bit even in supervisor mode... Ok.
[ 18.748223] Calibrating delay using timer specific routine.. 4424.69 BogoMIPS (lpj=2212348)
[ 18.748260] Security Framework initialized
[ 18.748264] SELinux: Disabled at boot.
[ 18.748270] AppArmor: AppArmor initialized
[ 18.748273] Failure registering capabilities with primary security module.
[ 18.748287] Mount-cache hash table entries: 512
[ 18.748396] Initializing cgroup subsys ns
[ 18.748399] Initializing cgroup subsys cpuacct
[ 18.748408] CPU: After generic identify, caps: 178bfbff ebd3fbff 00000000 00000000 00002001 00000000 0000001f 00000000
[ 18.748416] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 18.748418] CPU: L2 Cache: 512K (64 bytes/line)
[ 18.748420] CPU 0(2) -> Core 0
[ 18.748422] CPU: After all inits, caps: 178bfbff ebd3fbff 00000000 00020410 00002001 00000000 0000001f 00000000
[ 18.748431] Compat vDSO mapped to ffffe000.
[ 18.748439] Checking 'hlt' instruction... OK.
[ 18.752453] SMP alternatives: switching to UP code
[ 18.753321] Early unpacking initramfs... done
[ 19.066316] ACPI: Core revision 20070126
[ 19.066372] ACPI: Looking for DSDT in initramfs... error, file /DSDT.aml not found.
[ 19.068299] ACPI: setting ELCR to 0200 (from 8ca0)
[ 19.069950] CPU0: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping 02
[ 19.069966] SMP alternatives: switching to SMP code
[ 19.070290] Booting processor 1/1 eip 3000
[ 19.080875] Initializing CPU#1
[ 19.141627] Calibrating delay using timer specific routine.. 4422.03 BogoMIPS (lpj=2211015)
[ 19.141633] CPU: After generic identify, caps: 178bfbff ebd3fbff 00000000 00000000 00002001 00000000 0000001f 00000000
[ 19.141639] CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
[ 19.141641] CPU: L2 Cache: 512K (64 bytes/line)
[ 19.141642] CPU 1(2) -> Core 1
[ 19.141644] CPU: After all inits, caps: 178bfbff ebd3fbff 00000000 00020410 00002001 00000000 0000001f 00000000
[ 19.141254] CPU1: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ stepping 02
[ 19.141268] Total of 2 processors activated (8846.72 BogoMIPS).
[ 19.243554] Brought up 2 CPUs
[ 19.243573] CPU0 attaching sched-domain:
[ 19.243576] domain 0: span 03
[ 19.243578] groups: 01 02
[ 19.243581] CPU1 attaching sched-domain:
[ 19.243583] domain 0: span 03
[ 19.243585] groups: 02 01
[ 19.243785] net_namespace: 76 bytes
[ 19.243790] Booting paravirtualized kernel on bare hardware
[ 19.244211] Time: 5:45:17 Date: 10/08/08
[ 19.244244] NET: Registered protocol family 16
[ 19.244421] EISA bus registered
[ 19.244425] ACPI: bus type pci registered
[ 19.248898] PCI: PCI BIOS revision 3.00 entry at 0xfb2a0, last bus=3
[ 19.248900] PCI: Using configuration type 1
[ 19.248903] Setting up standard PCI resources
[ 19.251879] ACPI: EC: Look up EC in DSDT
[ 19.258260] ACPI: Interpreter enabled
[ 19.258265] ACPI: (supports S0 S1 S4 S5)
[ 19.258279] ACPI: Using PIC for interrupt routing
[ 19.265816] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 19.266397] PCI: Transparent bridge - 0000:00:06.0
[ 19.266644] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 19.266953] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.HUB0._PRT]
[ 19.314347] ACPI: PCI Interrupt Link [LNK1] (IRQs *5 7 9 10 11 14 15)
[ 19.314491] ACPI: PCI Interrupt Link [LNK2] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[ 19.314634] ACPI: PCI Interrupt Link [LNK3] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[ 19.314778] ACPI: PCI Interrupt Link [LNK4] (IRQs 5 7 9 10 11 14 *15)
[ 19.314919] ACPI: PCI Interrupt Link [LNK5] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[ 19.315068] ACPI: PCI Interrupt Link [LNK6] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[ 19.315216] ACPI: PCI Interrupt Link [LNK7] (IRQs 5 7 9 10 *11 14 15)
[ 19.315361] ACPI: PCI Interrupt Link [LNK8] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[ 19.315506] ACPI: PCI Interrupt Link [LP2P] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[ 19.315653] ACPI: PCI Interrupt Link [LUBA] (IRQs 5 *7 9 10 11 14 15)
[ 19.315799] ACPI: PCI Interrupt Link [LMAC] (IRQs 5 *7 9 10 11 14 15)
[ 19.315944] ACPI: PCI Interrupt Link [LAZA] (IRQs 5 7 9 *10 11 14 15)
[ 19.316096] ACPI: PCI Interrupt Link [LPMU] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[ 19.316243] ACPI: PCI Interrupt Link [LSMB] (IRQs 5 7 9 10 11 14 *15)
[ 19.316389] ACPI: PCI Interrupt Link [LUB2] (IRQs *5 7 9 10 11 14 15)
[ 19.316535] ACPI: PCI Interrupt Link [LIDE] (IRQs 5 7 9 10 11 14 15) *0, disabled.
[ 19.316681] ACPI: PCI Interrupt Link [LSID] (IRQs 5 7 9 10 *11 14 15)
[ 19.316827] ACPI: PCI Interrupt Link [LFID] (IRQs 5 7 9 10 11 14 *15)
[ 19.316973] ACPI: PCI Interrupt Link [LSA2] (IRQs 5 7 9 *10 11 14 15)
[ 19.317161] ACPI: PCI Interrupt Link [APC1] (IRQs 16) *0, disabled.
[ 19.317331] ACPI: PCI Interrupt Link [APC2] (IRQs 17) *0, disabled.
[ 19.317501] ACPI: PCI Interrupt Link [APC3] (IRQs 18) *0, disabled.
[ 19.317669] ACPI: PCI Interrupt Link [APC4] (IRQs 19) *0, disabled.
[ 19.317837] ACPI: PCI Interrupt Link [APC5] (IRQs 16) *0, disabled.
[ 19.318005] ACPI: PCI Interrupt Link [APC6] (IRQs 16) *0, disabled.
[ 19.318183] ACPI: PCI Interrupt Link [APC7] (IRQs 16) *0, disabled.
[ 19.318355] ACPI: PCI Interrupt Link [APC8] (IRQs 16) *0, disabled.
[ 19.318526] ACPI: PCI Interrupt Link [APCF] (IRQs 20 21 22 23) *0, disabled.
[ 19.318698] ACPI: PCI Interrupt Link [APCH] (IRQs 20 21 22 23) *0, disabled.
[ 19.318869] ACPI: PCI Interrupt Link [APMU] (IRQs 20 21 22 23) *0, disabled.
[ 19.319041] ACPI: PCI Interrupt Link [AAZA] (IRQs 20 21 22 23) *0, disabled.
[ 19.319220] ACPI: PCI Interrupt Link [APCS] (IRQs 20 21 22 23) *0, disabled.
[ 19.319392] ACPI: PCI Interrupt Link [APCL] (IRQs 20 21 22 23) *0, disabled.
[ 19.319564] ACPI: PCI Interrupt Link [APCM] (IRQs 20 21 22 23) *0, disabled.
[ 19.319739] ACPI: PCI Interrupt Link [APCZ] (IRQs 20 21 22 23) *0, disabled.
[ 19.319911] ACPI: PCI Interrupt Link [APSI] (IRQs 20 21 22 23) *0, disabled.
[ 19.320089] ACPI: PCI Interrupt Link [APSJ] (IRQs 20 21 22 23) *0, disabled.
[ 19.320263] ACPI: PCI Interrupt Link [ASA2] (IRQs 20 21 22 23) *0, disabled.
[ 19.320395] Linux Plug and Play Support v0.97 (c) Adam Belay
[ 19.320422] pnp: PnP ACPI init
[ 19.320429] ACPI: bus type pnp registered
[ 19.323619] pnp: PnP ACPI: found 10 devices
[ 19.323621] ACPI: ACPI bus type pnp unregistered
[ 19.323624] PnPBIOS: Disabled by ACPI PNP
[ 19.323826] PCI: Using ACPI for IRQ routing
[ 19.323830] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
[ 19.377034] NET: Registered protocol family 8
[ 19.377036] NET: Registered protocol family 20
[ 19.377111] AppArmor: AppArmor Filesystem Enabled
[ 19.389057] system 00:01: ioport range 0x1000-0x107f has been reserved
[ 19.389060] system 00:01: ioport range 0x1080-0x10ff has been reserved
[ 19.389063] system 00:01: ioport range 0x1400-0x147f has been reserved
[ 19.389065] system 00:01: ioport range 0x1480-0x14ff has been reserved
[ 19.389067] system 00:01: ioport range 0x1800-0x187f has been reserved
[ 19.389070] system 00:01: ioport range 0x1880-0x18ff has been reserved
[ 19.389073] system 00:01: iomem range 0xd0000000-0xdfffffff could not be reserved
[ 19.389079] system 00:02: ioport range 0x4d0-0x4d1 has been reserved
[ 19.389081] system 00:02: ioport range 0x800-0x87f has been reserved
[ 19.389084] system 00:02: ioport range 0x295-0x314 has been reserved
[ 19.389086] system 00:02: ioport range 0x290-0x294 has been reserved
[ 19.389094] system 00:08: iomem range 0xe8000000-0xefffffff could not be reserved
[ 19.389100] system 00:09: iomem range 0xcc000-0xcffff has been reserved
[ 19.389102] system 00:09: iomem range 0xf0000-0xf7fff could not be reserved
[ 19.389105] system 00:09: iomem range 0xf8000-0xfbfff could not be reserved
[ 19.389107] system 00:09: iomem range 0xfc000-0xfffff could not be reserved
[ 19.389110] system 00:09: iomem range 0xcfff0000-0xcfffffff could not be reserved
[ 19.389113] system 00:09: iomem range 0xffff0000-0xffffffff could not be reserved
[ 19.389116] system 00:09: iomem range 0x0-0x9ffff could not be reserved
[ 19.389118] system 00:09: iomem range 0x100000-0xcffeffff could not be reserved
[ 19.389121] system 00:09: iomem range 0xfec00000-0xfec00fff could not be reserved
[ 19.389124] system 00:09: iomem range 0xfee00000-0xfee00fff could not be reserved
[ 19.419494] PCI: Bridge: 0000:00:06.0
[ 19.419496] IO window: 9000-9fff
[ 19.419499] MEM window: f5000000-f6ffffff
[ 19.419501] PREFETCH window: disabled.
[ 19.419504] PCI: Bridge: 0000:02:00.0
[ 19.419505] IO window: disabled.
[ 19.419510] MEM window: f2000000-f4ffffff
[ 19.419513] PREFETCH window: f0000000-f1ffffff
[ 19.419518] PCI: Bridge: 0000:00:0e.0
[ 19.419519] IO window: disabled.
[ 19.419521] MEM window: f2000000-f4ffffff
[ 19.419523] PREFETCH window: f0000000-f1ffffff
[ 19.419531] PCI: Setting latency timer of device 0000:00:06.0 to 64
[ 19.419539] PCI: Setting latency timer of device 0000:00:0e.0 to 64
[ 19.419551] PCI: Setting latency timer of device 0000:02:00.0 to 64
[ 19.419577] NET: Registered protocol family 2
[ 19.454990] IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 19.455239] TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
[ 19.455855] TCP bind hash table entries: 65536 (order: 9, 2359296 bytes)
[ 19.456869] TCP: Hash tables configured (established 131072 bind 65536)
[ 19.456874] TCP reno registered
[ 19.468060] checking if image is initramfs... it is
[ 20.080746] Freeing initrd memory: 8382k freed
[ 20.081459] audit: initializing netlink socket (disabled)
[ 20.081471] audit(1223444718.291:1): initialized
[ 20.081613] krcupreemptd setsched 0
[ 20.081614] prio = 98
[ 20.081671] highmem bounce pool size: 64 pages
[ 20.081742] VFS: Disk quotas dquot_6.5.1
[ 20.081763] Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
[ 20.081837] io scheduler noop registered
[ 20.081838] io scheduler anticipatory registered
[ 20.081840] io scheduler deadline registered
[ 20.081849] io scheduler cfq registered (default)
[ 20.106797] pci 0000:00:05.0: Enabling HT MSI Mapping
[ 20.106811] pci 0000:00:05.1: Enabling HT MSI Mapping
[ 20.106824] pci 0000:00:05.2: Enabling HT MSI Mapping
[ 20.106836] pci 0000:00:06.0: Enabling HT MSI Mapping
[ 20.106851] pci 0000:00:06.1: Enabling HT MSI Mapping
[ 20.106866] pci 0000:00:08.0: Enabling HT MSI Mapping
[ 20.106879] pci 0000:00:0e.0: Enabling HT MSI Mapping
[ 20.106890] Boot video device is 0000:03:00.0
[ 20.106992] PCI: Setting latency timer of device 0000:00:0e.0 to 64
[ 20.107027] assign_interrupt_mode Found MSI capability
[ 20.107044] Allocate Port Service[0000:00:0e.0:pcie00]
[ 20.107265] isapnp: Scanning for PnP cards...
[ 20.463165] isapnp: No Plug & Play device found
[ 20.490553] Real Time Clock Driver v1.12ac
[ 20.490664] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
[ 20.491845] RAMDISK driver initialized: 16 RAM disks of 65536K size 1024 blocksize
[ 20.491906] input: Macintosh mouse button emulation as /devices/virtual/input/input0
[ 20.491985] PNP: PS/2 Controller [PNP0303:PS2K] at 0x60,0x64 irq 1
[ 20.491988] PNP: PS/2 appears to have AUX port disabled, if this is incorrect please boot with i8042.nopnp
[ 20.492106] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 20.503193] mice: PS/2 mouse device common for all mice
[ 20.503308] EISA: Probing bus 0 at eisa.0
[ 20.503314] Cannot allocate resource for EISA slot 1
[ 20.503330] EISA: Detected 0 cards.
[ 20.503332] cpuidle: using governor ladder
[ 20.503404] NET: Registered protocol family 1
[ 20.503427] Using IPI No-Shortcut mode
[ 20.503456] registered taskstats version 1
[ 20.503560] Magic number: 12:388:769
[ 20.503646] hash matches device ptyp5
[ 20.503660] hash matches device kmsg
[ 20.503666] hash matches device 0000:00:05.0
[ 20.503684] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found
[ 20.503686] EDD information not available.
[ 20.503872] Freeing unused kernel memory: 368k freed
[ 20.525317] input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input1
[ 21.742212] fuse init (API version 7.9)
[ 21.768889] device-mapper: uevent: version 1.0.3
[ 21.768936] device-mapper: ioctl: 4.12.0-ioctl (2007-10-02) initialised: [email protected]
[ 21.783453] md: linear personality registered for level -1
[ 21.787115] md: multipath personality registered for level -4
[ 21.790905] md: raid0 personality registered for level 0
[ 21.795291] md: raid1 personality registered for level 1
[ 21.799015] xor: measuring software checksum speed
[ 21.803477] 8regs : 2896.000 MB/sec
[ 21.808477] 8regs_prefetch: 2804.000 MB/sec
[ 21.813478] 32regs : 2192.000 MB/sec
[ 21.818479] 32regs_prefetch: 1796.000 MB/sec
[ 21.818481] xor: using function: 8regs (2896.000 MB/sec)
[ 21.819566] async_tx: api initialized (async)
[ 21.839519] raid6: int32x1 824 MB/s
[ 21.856529] raid6: int32x2 871 MB/s
[ 21.873550] raid6: int32x4 835 MB/s
[ 21.890545] raid6: int32x8 609 MB/s
[ 21.907509] raid6: mmxx1 1753 MB/s
[ 21.924501] raid6: mmxx2 3230 MB/s
[ 21.941508] raid6: sse1x1 1757 MB/s
[ 21.958508] raid6: sse1x2 3011 MB/s
[ 21.975510] raid6: sse2x1 2968 MB/s
[ 21.992511] raid6: sse2x2 4074 MB/s
[ 21.992512] raid6: using algorithm sse2x2 (4074 MB/s)
[ 21.992515] md: raid6 personality registered for level 6
[ 21.992517] md: raid5 personality registered for level 5
[ 21.992518] md: raid4 personality registered for level 4
[ 22.018354] md: raid10 personality registered for level 10
[ 22.236163] usbcore: registered new interface driver usbfs
[ 22.236183] usbcore: registered new interface driver hub
[ 22.236259] usbcore: registered new device driver usb
[ 22.247614] ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
[ 22.247891] ACPI: PCI Interrupt Link [LUBA] enabled at IRQ 7
[ 22.247894] PCI: setting IRQ 7 as level-triggered
[ 22.247898] ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LUBA] -> GSI 7 (level, low) -> IRQ 7
[ 22.247907] PCI: Setting latency timer of device 0000:00:02.0 to 64
[ 22.247910] ohci_hcd 0000:00:02.0: OHCI Host Controller
[ 22.248138] ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
[ 22.248186] ohci_hcd 0000:00:02.0: irq 7, io mem 0xf7005000
[ 22.301202] usb usb1: configuration #1 chosen from 1 choice
[ 22.301223] hub 1-0:1.0: USB hub found
[ 22.301233] hub 1-0:1.0: 10 ports detected
[ 22.662617] usb 1-9: new low speed USB device using ohci_hcd and address 2
[ 22.853579] usb 1-9: configuration #1 chosen from 1 choice
[ 22.922573] SCSI subsystem initialized
[ 22.980791] libata version 3.00 loaded.
[ 22.983376] pata_amd 0000:00:04.0: version 0.3.10
[ 22.983423] PCI: Setting latency timer of device 0000:00:04.0 to 64
[ 22.983502] scsi0 : pata_amd
[ 22.983546] scsi1 : pata_amd
[ 22.984057] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14
[ 22.984060] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15
[ 23.288979] ata1.00: ATAPI: TSSTcorpCD/DVDW SH-S182M, SB02, max UDMA/33
[ 23.445904] ata1.00: configured for UDMA/33
[ 23.445937] ata2: port disabled. ignoring.
[ 23.446803] scsi 0:0:0:0: CD-ROM TSSTcorp CD/DVDW SH-S182M SB02 PQ: 0 ANSI: 5
[ 23.740145] ACPI: PCI Interrupt Link [LSID] enabled at IRQ 11
[ 23.740150] PCI: setting IRQ 11 as level-triggered
[ 23.740153] ACPI: PCI Interrupt 0000:00:05.0[A] -> Link [LSID] -> GSI 11 (level, low) -> IRQ 11
[ 23.740187] PCI: Setting latency timer of device 0000:00:05.0 to 64
[ 23.740196] ACPI: PCI interrupt for device 0000:00:05.0 disabled
[ 23.740397] ACPI: PCI Interrupt Link [LFID] enabled at IRQ 15
[ 23.740399] PCI: setting IRQ 15 as level-triggered
[ 23.740403] ACPI: PCI Interrupt 0000:00:05.1[B] -> Link [LFID] -> GSI 15 (level, low) -> IRQ 15
[ 23.740417] PCI: Setting latency timer of device 0000:00:05.1 to 64
[ 23.740423] ACPI: PCI interrupt for device 0000:00:05.1 disabled
[ 23.740621] ACPI: PCI Interrupt Link [LSA2] enabled at IRQ 10
[ 23.740623] PCI: setting IRQ 10 as level-triggered
[ 23.740626] ACPI: PCI Interrupt 0000:00:05.2[C] -> Link [LSA2] -> GSI 10 (level, low) -> IRQ 10
[ 23.740641] PCI: Setting latency timer of device 0000:00:05.2 to 64
[ 23.740647] ACPI: PCI interrupt for device 0000:00:05.2 disabled
[ 24.228852] forcedeth: Reverse Engineered nForce ethernet driver. Version 0.61.
[ 24.229104] ACPI: PCI Interrupt Link [LMAC] enabled at IRQ 7
[ 24.229107] ACPI: PCI Interrupt 0000:00:08.0[A] -> Link [LMAC] -> GSI 7 (level, low) -> IRQ 7
[ 24.229112] PCI: Setting latency timer of device 0000:00:08.0 to 64
[ 24.742086] forcedeth 0000:00:08.0: ifname eth0, PHY OUI 0x5043 @ 1, addr 00:16:e6:88:c7:bc
[ 24.742091] forcedeth 0000:00:08.0: highdma csum vlan pwrctl mgmt timirq gbit lnktim msi desc-v3
[ 24.741991] ACPI: PCI Interrupt Link [LUB2] enabled at IRQ 5
[ 24.741996] PCI: setting IRQ 5 as level-triggered
[ 24.742000] ACPI: PCI Interrupt 0000:00:02.1[B] -> Link [LUB2] -> GSI 5 (level, low) -> IRQ 5
[ 24.742010] PCI: Setting latency timer of device 0000:00:02.1 to 64
[ 24.742013] ehci_hcd 0000:00:02.1: EHCI Host Controller
[ 24.742044] ehci_hcd 0000:00:02.1: new USB bus registered, assigned bus number 2
[ 24.742071] ehci_hcd 0000:00:02.1: debug port 1
[ 24.742074] PCI: cache line size of 64 is not supported by device 0000:00:02.1
[ 24.742487] ehci_hcd 0000:00:02.1: irq 5, io mem 0xf7006000
[ 24.743042] usb 1-9: USB disconnect, address 2
[ 24.747902] ehci_hcd 0000:00:02.1: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
[ 24.748097] usb usb2: configuration #1 chosen from 1 choice
[ 24.748118] hub 2-0:1.0: USB hub found
[ 24.748126] hub 2-0:1.0: 10 ports detected
[ 24.849006] sata_nv 0000:00:05.0: version 3.5
[ 24.849018] ACPI: PCI Interrupt 0000:00:05.0[A] -> Link [LSID] -> GSI 11 (level, low) -> IRQ 11
[ 24.849056] PCI: Setting latency timer of device 0000:00:05.0 to 64
[ 24.849682] scsi2 : sata_nv
[ 24.849783] scsi3 : sata_nv
[ 24.849933] ata3: SATA max UDMA/133 cmd 0xa400 ctl 0xa800 bmdma 0xb400 irq 11
[ 24.849936] ata4: SATA max UDMA/133 cmd 0xac00 ctl 0xb000 bmdma 0xb408 irq 11
[ 25.181614] Driver 'sr' needs updating - please use bus_type methods
[ 25.189497] sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
[ 25.189502] Uniform CD-ROM driver Revision: 3.20
[ 25.189552] sr 0:0:0:0: Attached scsi CD-ROM sr0
[ 25.203748] sr 0:0:0:0: Attached scsi generic sg0 type 5
[ 25.264959] usb 1-9: new low speed USB device using ohci_hcd and address 3
[ 25.332719] ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[ 25.455207] usb 1-9: configuration #1 chosen from 1 choice
[ 25.458200] usbcore: registered new interface driver hiddev
[ 25.467322] input: Logitech Trackball as /devices/pci0000:00/0000:00:02.0/usb1/1-9/1-9:1.0/input/input2
[ 25.478011] input,hidraw0: USB HID v1.10 Mouse [Logitech Trackball] on usb-0000:00:02.0-9
[ 25.478026] usbcore: registered new interface driver usbhid
[ 25.478029] /build/buildd/linux-2.6.24/debian/build/custom-source-rt/drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
[ 25.543836] ata3.00: HPA unlocked: 976771055 -> 976773168, native 976773168
[ 25.543843] ata3.00: ATA-7: ST3500630NS, 3.AEG, max UDMA/133
[ 25.543845] ata3.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 0/32)
[ 25.580880] ata3.00: configured for UDMA/133
[ 25.883782] ata4: SATA link down (SStatus 0 SControl 300)
[ 25.894907] scsi 2:0:0:0: Direct-Access ATA ST3500630NS 3.AE PQ: 0 ANSI: 5
[ 25.894973] scsi 2:0:0:0: Attached scsi generic sg1 type 0
[ 25.894521] ACPI: PCI Interrupt 0000:00:05.1[B] -> Link [LFID] -> GSI 15 (level, low) -> IRQ 15
[ 25.894568] PCI: Setting latency timer of device 0000:00:05.1 to 64
[ 25.894608] scsi4 : sata_nv
[ 25.894662] scsi5 : sata_nv
[ 25.894806] ata5: SATA max UDMA/133 cmd 0xb800 ctl 0xbc00 bmdma 0xc800 irq 15
[ 25.894809] ata6: SATA max UDMA/133 cmd 0xc000 ctl 0xc400 bmdma 0xc808 irq 15
[ 26.197073] ata5: SATA link down (SStatus 0 SControl 300)
[ 26.510116] ata6: SATA link down (SStatus 0 SControl 300)
[ 26.520469] ACPI: PCI Interrupt 0000:00:05.2[C] -> Link [LSA2] -> GSI 10 (level, low) -> IRQ 10
[ 26.520505] PCI: Setting latency timer of device 0000:00:05.2 to 64
[ 26.520560] scsi6 : sata_nv
[ 26.520794] scsi7 : sata_nv
[ 26.520936] ata7: SATA max UDMA/133 cmd 0xcc00 ctl 0xd000 bmdma 0xdc00 irq 10
[ 26.520939] ata8: SATA max UDMA/133 cmd 0xd400 ctl 0xd800 bmdma 0xdc08 irq 10
[ 26.823157] ata7: SATA link down (SStatus 0 SControl 300)
[ 27.136196] ata8: SATA link down (SStatus 0 SControl 300)
[ 27.149496] ACPI: PCI Interrupt Link [LNK4] enabled at IRQ 15
[ 27.149500] ACPI: PCI Interrupt 0000:01:07.0[A] -> Link [LNK4] -> GSI 15 (level, low) -> IRQ 15
[ 27.149507] 3c59x: Donald Becker and others.
[ 27.149511] 0000:01:07.0: 3Com PCI 3c905B Cyclone 100baseTx at f8886000.
[ 27.158757] Driver 'sd' needs updating - please use bus_type methods
[ 27.158833] sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
[ 27.158844] sd 2:0:0:0: [sda] Write Protect is off
[ 27.158846] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 27.158861] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 27.158901] sd 2:0:0:0: [sda] 976773168 512-byte hardware sectors (500108 MB)
[ 27.158909] sd 2:0:0:0: [sda] Write Protect is off
[ 27.158911] sd 2:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 27.158925] sd 2:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 27.158928] sda:ACPI: PCI Interrupt Link [LNK1] enabled at IRQ 5
[ 27.172844] ACPI: PCI Interrupt 0000:01:08.0[A] -> Link [LNK1] -> GSI 5 (level, low) -> IRQ 5
[ 27.172855] 0000:01:08.0: 3Com PCI 3c905B Cyclone 100baseTx at f89b6000.
[ 27.177621] sda1 sda2 < sda5 >
[ 27.185442] sd 2:0:0:0: [sda] Attached SCSI disk
[ 27.700325] EXT3-fs: mounted filesystem with ordered data mode.
[ 27.700371] kjournald starting. Commit interval 5 seconds
[ 34.798310] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 34.909990] shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
[ 35.084447] i2c-adapter i2c-0: nForce2 SMBus adapter at 0x1c00
[ 35.084466] i2c-adapter i2c-1: nForce2 SMBus adapter at 0x1c80
[ 36.006688] udev: renamed network interface eth0 to lan
[ 37.913301] input: Power Button (FF) as /devices/virtual/input/input3
[ 37.930424] ACPI: Power Button (FF) [PWRF]
[ 37.930474] input: Power Button (CM) as /devices/virtual/input/input4
[ 37.949445] ACPI: Power Button (CM) [PWRB]
[ 38.426176] udev: renamed network interface eth2 to dmz
[ 38.435089] udev: renamed network interface eth1 to wan
[ 39.990176] lan: no link during initialization.
[ 40.072308] dmz: setting half-duplex.
[ 40.861083] ACPI: PCI Interrupt Link [LAZA] enabled at IRQ 10
[ 40.861087] ACPI: PCI Interrupt 0000:00:06.1[B] -> Link [LAZA] -> GSI 10 (level, low) -> IRQ 10
[ 40.861102] PCI: Setting latency timer of device 0000:00:06.1 to 64
[ 41.313471] NET: Registered protocol family 10
[ 41.313839] lo: Disabled Privacy Extensions
[ 41.314395] ADDRCONF(NETDEV_UP): lan: link is not ready
[ 41.314915] ADDRCONF(NETDEV_UP): dmz: link is not ready
[ 41.504445] lp: driver loaded but no devices found
[ 41.699128] ACPI: PCI Interrupt Link [LNK7] enabled at IRQ 11
[ 41.699133] ACPI: PCI Interrupt 0000:03:00.0[A] -> Link [LNK7] -> GSI 11 (level, low) -> IRQ 11
[ 41.699138] matroxfb: Matrox G550 detected
[ 41.700140] PInS memtype = 5
[ 41.700355] matroxfb: MTRR's turned on
[ 41.700375] matroxfb: 640x480x8bpp (virtual: 640x26214)
[ 41.700377] matroxfb: framebuffer at 0xF0000000, mapped to 0xf8c00000, size 33554432
[ 41.700433] fb0: MATROX frame buffer device
[ 41.700434] fb0: initializing hardware
[ 42.307283] EXT3 FS on dm-0, internal journal
[ 43.208393] kjournald starting. Commit interval 5 seconds
[ 43.217060] EXT3 FS on sda1, internal journal
[ 43.217067] EXT3-fs: mounted filesystem with ordered data mode.
[ 43.286046] Adding 10108920k swap on /dev/mapper/Ubuntu-swap_1. Priority:-1 extents:1 across:10108920k
[ 43.491686] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 43.582127] nf_conntrack version 0.5.0 (16384 buckets, 65536 max)
[ 43.643560] ip6_tables: (C) 2000-2006 Netfilter Core Team
[ 43.903238] wan: setting half-duplex.
[ 43.904752] ADDRCONF(NETDEV_UP): wan: link is not ready
[ 44.138697] PPP generic driver version 2.4.2
[ 44.164043] NET: Registered protocol family 17
[ 44.889602] No dock devices found.
[ 45.332851] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ processors (2 cpu cores) (version 2.20.00)
[ 45.332360] powernow-k8: MP systems not supported by PSB BIOS structure
[ 45.333080] powernow-k8: MP systems not supported by PSB BIOS structure
[ 48.448693] Linux agpgart interface v0.102
[ 48.483364] [drm] Initialized drm 1.1.0 20060810
[ 48.626623] [drm] Initialized mga 3.2.1 20051102 on minor 0
[ 50.264062] ppdev: user-space parallel port driver
[ 55.001104] apm: BIOS version 1.2 Flags 0x07 (Driver version 1.16ac)
[ 55.001111] apm: disabled - APM is not SMP safe.
[ 65.381474] Bluetooth: Core ver 2.11
[ 65.381855] NET: Registered protocol family 31
[ 65.381859] Bluetooth: HCI device and connection manager initialized
[ 65.381863] Bluetooth: HCI socket layer initialized
[ 65.411817] Bluetooth: L2CAP ver 2.9
[ 65.411822] Bluetooth: L2CAP socket layer initialized
[ 65.469713] Bluetooth: RFCOMM socket layer initialized
[ 65.469726] Bluetooth: RFCOMM TTY layer initialized
[ 65.469728] Bluetooth: RFCOMM ver 1.8
[ 940.928916] irq 7: nobody cared (try booting with the "irqpoll" option)
[ 940.928922] Pid: 1606, comm: IRQ-7 Not tainted 2.6.24-21-rt #1
[ 940.928943] [<c016b924>] __report_bad_irq+0x24/0x80
[ 940.928956] [<c016bbfb>] note_interrupt+0x27b/0x2a0
[ 940.928959] [<c016a8dc>] handle_IRQ_event+0x5c/0x100
[ 940.928974] [<c016af3c>] thread_simple_irq+0x6c/0x90
[ 940.928983] [<c016b869>] do_irqd+0x229/0x290
[ 940.928998] [<c016b640>] do_irqd+0x0/0x290
[ 940.929002] [<c0141ea2>] kthread+0x42/0x70
[ 940.929005] [<c0141e60>] kthread+0x0/0x70
[ 940.929011] [<c0105847>] kernel_thread_helper+0x7/0x10
[ 940.929022] =======================
[ 940.929023] handlers:
[ 940.929024] [<f891ac70>] (usb_hcd_irq+0x0/0x60 [usbcore])
[ 940.929043] turning off IO-APIC fast mode.
[ 1007.970826] irq 7: nobody cared (try booting with the "irqpoll" option)
[ 1007.970832] Pid: 1606, comm: IRQ-7 Not tainted 2.6.24-21-rt #1
[ 1007.970852] [<c016b924>] __report_bad_irq+0x24/0x80
[ 1007.970864] [<c016bbfb>] note_interrupt+0x27b/0x2a0
[ 1007.970868] [<c016a8dc>] handle_IRQ_event+0x5c/0x100
[ 1007.970883] [<c016af3c>] thread_simple_irq+0x6c/0x90
[ 1007.970892] [<c016b869>] do_irqd+0x229/0x290
[ 1007.970907] [<c016b640>] do_irqd+0x0/0x290
[ 1007.970911] [<c0141ea2>] kthread+0x42/0x70
[ 1007.970914] [<c0141e60>] kthread+0x0/0x70
[ 1007.970920] [<c0105847>] kernel_thread_helper+0x7/0x10
[ 1007.970931] =======================
[ 1007.970932] handlers:
[ 1007.970933] [<f891ac70>] (usb_hcd_irq+0x0/0x60 [usbcore])
[ 5970.101996] irq 7: nobody cared (try booting with the "irqpoll" option)
[ 5970.102003] Pid: 1606, comm: IRQ-7 Not tainted 2.6.24-21-rt #1
[ 5970.102022] [<c016b924>] __report_bad_irq+0x24/0x80
[ 5970.102034] [<c016bbfb>] note_interrupt+0x27b/0x2a0
[ 5970.102038] [<c016a8dc>] handle_IRQ_event+0x5c/0x100
[ 5970.102053] [<c016af3c>] thread_simple_irq+0x6c/0x90
[ 5970.102063] [<c016b869>] do_irqd+0x229/0x290
[ 5970.102078] [<c016b640>] do_irqd+0x0/0x290
[ 5970.102082] [<c0141ea2>] kthread+0x42/0x70
[ 5970.102085] [<c0141e60>] kthread+0x0/0x70
[ 5970.102091] [<c0105847>] kernel_thread_helper+0x7/0x10
[ 5970.102102] =======================
[ 5970.102103] handlers:
[ 5970.102105] [<f891ac70>] (usb_hcd_irq+0x0/0x60 [usbcore])
[ 7633.252211] irq 7: nobody cared (try booting with the "irqpoll" option)
[ 7633.252218] Pid: 1606, comm: IRQ-7 Not tainted 2.6.24-21-rt #1
[ 7633.252237] [<c016b924>] __report_bad_irq+0x24/0x80
[ 7633.252249] [<c016bbfb>] note_interrupt+0x27b/0x2a0
[ 7633.252253] [<c016a8dc>] handle_IRQ_event+0x5c/0x100
[ 7633.252268] [<c016af3c>] thread_simple_irq+0x6c/0x90
[ 7633.252278] [<c016b869>] do_irqd+0x229/0x290
[ 7633.252292] [<c016b640>] do_irqd+0x0/0x290
[ 7633.252297] [<c0141ea2>] kthread+0x42/0x70
[ 7633.252300] [<c0141e60>] kthread+0x0/0x70
[ 7633.252306] [<c0105847>] kernel_thread_helper+0x7/0x10
[ 7633.252317] =======================
[ 7633.252318] handlers:
[ 7633.252319] [<f891ac70>] (usb_hcd_irq+0x0/0x60 [usbcore])
[56238.249373] wan: setting full-duplex.
[56238.250332] ADDRCONF(NETDEV_CHANGE): wan: link becomes ready
[56249.237072] wan: no IPv6 routers present
[56352.342443] NET: Registered protocol family 24
[58562.155510] irq 7: nobody cared (try booting with the "irqpoll" option)
[58562.155516] Pid: 1606, comm: IRQ-7 Not tainted 2.6.24-21-rt #1
[58562.155537] [<c016b924>] __report_bad_irq+0x24/0x80
[58562.155550] [<c016bbfb>] note_interrupt+0x27b/0x2a0
[58562.155554] [<c016a8dc>] handle_IRQ_event+0x5c/0x100
[58562.155569] [<c016af3c>] thread_simple_irq+0x6c/0x90
[58562.155579] [<c016b869>] do_irqd+0x229/0x290
[58562.155594] [<c016b640>] do_irqd+0x0/0x290
[58562.155599] [<c0141ea2>] kthread+0x42/0x70
[58562.155602] [<c0141e60>] kthread+0x0/0x70
[58562.155608] [<c0105847>] kernel_thread_helper+0x7/0x10
[58562.155620] =======================
[58562.155622] handlers:
[58562.155623] [<f891ac70>] (usb_hcd_irq+0x0/0x60 [usbcore])
CPU0 CPU1
0: 556 1 XT-PIC-XT timer
1: 5841 888 XT-PIC-XT i8042
2: 0 0 XT-PIC-XT cascade
5: 1 1 XT-PIC-XT ehci_hcd:usb2, dmz
7: 160816 1687071 XT-PIC-XT ohci_hcd:usb1
8: 2 1 XT-PIC-XT rtc
9: 0 0 XT-PIC-XT acpi
10: 383980 11338 XT-PIC-XT sata_nv, HDA Intel
11: 669673 57055 XT-PIC-XT sata_nv
14: 584674 64101 XT-PIC-XT libata
15: 42236 15407 XT-PIC-XT libata, sata_nv, wan
222: 5929886 3346 PCI-MSI-edge lan
NMI: 0 0 Non-maskable interrupts
LOC: 59209279 59195939 Local timer interrupts
RES: 4365453 8967863 Rescheduling interrupts
CAL: 70549 64347 function call interrupts
TLB: 12860 12054 TLB shootdowns
TRM: 0 0 Thermal event interrupts
SPU: 0 0 Spurious interrupts
ERR: 14677
MIS: 0
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1)
Subsystem: Giga-byte Technology Unknown device 5001
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Capabilities: [44] HyperTransport: Slave or Primary Interface
Command: BaseUnitID=0 UnitCnt=15 MastHost- DefDir- DUL-
Link Control 0: CFlE+ CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0 IsocEn- LSEn+ ExtCTL- 64b-
Link Config 0: MLWI=16bit DwFcIn- MLWO=16bit DwFcOut- LWI=16bit DwFcInEn- LWO=16bit DwFcOutEn-
Link Control 1: CFlE- CST- CFE- <LkFail+ Init- EOC+ TXO+ <CRCErr=0 IsocEn- LSEn- ExtCTL- 64b-
Link Config 1: MLWI=8bit DwFcIn- MLWO=8bit DwFcOut- LWI=8bit DwFcInEn- LWO=8bit DwFcOutEn-
Revision ID: 1.03
Link Frequency 0: 1.0GHz
Link Error 0: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability 0: 200MHz+ 300MHz+ 400MHz+ 500MHz+ 600MHz+ 800MHz+ 1.0GHz+ 1.2GHz- 1.4GHz- 1.6GHz- Vend-
Feature Capability: IsocFC+ LDTSTOP+ CRCTM- ECTLT- 64bA- UIDRD-
Link Frequency 1: 200MHz
Link Error 1: <Prot- <Ovfl- <EOC- CTLTm-
Link Frequency Capability 1: 200MHz- 300MHz- 400MHz- 500MHz- 600MHz- 800MHz- 1.0GHz- 1.2GHz- 1.4GHz- 1.6GHz- Vend-
Error Handling: PFlE+ OFlE+ PFE- OFE- EOCFE- RFE- CRCFE- SERRFE- CF- RE- PNFE- ONFE- EOCNFE- RNFE- CRCNFE- SERRNFE-
Prefetchable memory behind bridge Upper: 00-00
Bus Number: 00
Capabilities: [e0] #00 [fee0]
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2)
Subsystem: Giga-byte Technology Unknown device 0c11
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2)
Subsystem: Giga-byte Technology Unknown device 0c11
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin A routed to IRQ 15
Region 4: I/O ports at 1c00 [size=64]
Region 5: I/O ports at 1c80 [size=64]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.2 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a2)
Subsystem: Giga-byte Technology Unknown device 0c11
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1) (prog-if 10 [OHCI])
Subsystem: Giga-byte Technology Unknown device 5004
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 7
Region 0: Memory at f7005000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:02.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2) (prog-if 20 [EHCI])
Subsystem: Giga-byte Technology Unknown device 5004
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin B routed to IRQ 5
Region 0: Memory at f7006000 (32-bit, non-prefetchable) [size=256]
Capabilities: [44] Debug port
Capabilities: [80] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME+
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1) (prog-if 8a [Master SecP PriP])
Subsystem: Unknown device f458:5002
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Region 0: [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
Region 1: [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
Region 2: [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
Region 3: [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
Region 4: I/O ports at f000 [size=16]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) (prog-if 85 [Master SecO PriO])
Subsystem: Giga-byte Technology Unknown device b002
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at a400 [size=8]
Region 1: I/O ports at a800 [size=4]
Region 2: I/O ports at ac00 [size=8]
Region 3: I/O ports at b000 [size=4]
Region 4: I/O ports at b400 [size=16]
Region 5: Memory at f700a000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [cc] HyperTransport: MSI Mapping
00:05.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) (prog-if 85 [Master SecO PriO])
Subsystem: Giga-byte Technology Unknown device b002
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin B routed to IRQ 15
Region 0: I/O ports at b800 [size=8]
Region 1: I/O ports at bc00 [size=4]
Region 2: I/O ports at c000 [size=8]
Region 3: I/O ports at c400 [size=4]
Region 4: I/O ports at c800 [size=16]
Region 5: Memory at f700b000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [cc] HyperTransport: MSI Mapping
00:05.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2) (prog-if 85 [Master SecO PriO])
Subsystem: Giga-byte Technology Unknown device b002
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (750ns min, 250ns max)
Interrupt: pin C routed to IRQ 10
Region 0: I/O ports at cc00 [size=8]
Region 1: I/O ports at d000 [size=4]
Region 2: I/O ports at d400 [size=8]
Region 3: I/O ports at d800 [size=4]
Region 4: I/O ports at dc00 [size=16]
Region 5: Memory at f7004000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [b0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/2 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [cc] HyperTransport: MSI Mapping
00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2) (prog-if 01 [Subtractive decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
I/O behind bridge: 00009000-00009fff
Memory behind bridge: f5000000-f6ffffff
Prefetchable memory behind bridge: fff00000-000fffff
Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
Capabilities: [b8] Subsystem: Gammagraphx, Inc. Unknown device 0000
Capabilities: [8c] HyperTransport: MSI Mapping
00:06.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2)
Subsystem: Giga-byte Technology Unknown device a002
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (500ns min, 1250ns max)
Interrupt: pin B routed to IRQ 10
Region 0: Memory at f7000000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/0 Enable-
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [6c] HyperTransport: MSI Mapping
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
Subsystem: Giga-byte Technology Unknown device e000
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0 (250ns min, 5000ns max)
Interrupt: pin A routed to IRQ 222
Region 0: Memory at f7007000 (32-bit, non-prefetchable) [size=4K]
Region 1: I/O ports at e400 [size=8]
Region 2: Memory at f7008000 (32-bit, non-prefetchable) [size=256]
Region 3: Memory at f7009000 (32-bit, non-prefetchable) [size=16]
Capabilities: [44] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable+ DSel=0 DScale=0 PME-
Capabilities: [70] MSI-X: Enable- Mask- TabSize=8
Vector table: BAR=2 offset=00000000
PBA: BAR=3 offset=00000000
Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+ Queue=0/3 Enable+
Address: 00000000fee0100c Data: 4141
Masking: 000000fe Pending: 00000000
Capabilities: [6c] HyperTransport: MSI Mapping
00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=00, secondary=02, subordinate=03, sec-latency=0
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: f2000000-f4ffffff
Prefetchable memory behind bridge: 00000000f0000000-00000000f1ffffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
Capabilities: [40] Subsystem: nVidia Corporation Unknown device 0000
Capabilities: [48] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+ Queue=0/1 Enable+
Address: 00000000fee0300c Data: 4139
Capabilities: [60] HyperTransport: MSI Mapping
Capabilities: [80] Express Root Port (Slot+) IRQ 0
Device: Supported: MaxPayload 256 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <512ns, L1 <4us
Device: Errors: Correctable+ Non-Fatal+ Fatal+ Unsupported+
Device: RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 1
Link: Latency L0s <512ns, L1 <4us
Link: ASPM Disabled RCB 64 bytes CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
Slot: AtnBtn- PwrCtrl- MRL- AtnInd- PwrInd- HotPlug- Surpise-
Slot: Number 0, PowerLimit 0.000000
Slot: Enabled AtnBtn- PwrFlt- MRL- PresDet- CmdCplt- HPIrq-
Slot: AttnInd Off, PwrInd On, Power-
Root: Correctable- Non-Fatal- Fatal- PME-
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Configuration
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Capabilities: [80] HyperTransport: Host or Secondary Interface
!!! Possibly incomplete decoding
Command: WarmRst+ DblEnd-
Link Control: CFlE- CST- CFE- <LkFail- Init+ EOC- TXO- <CRCErr=0
Link Config: MLWI=16bit MLWO=16bit LWI=16bit LWO=16bit
Revision ID: 1.02
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM Controller
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Miscellaneous Control
Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Capabilities: [f0] #0f [0010]
01:07.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24)
Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 15
Region 0: I/O ports at 9000 [size=128]
Region 1: Memory at f6000000 (32-bit, non-prefetchable) [size=128]
[virtual] Expansion ROM at f5000000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
01:08.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24)
Subsystem: 3Com Corporation 3C905B Fast Etherlink XL 10/100
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 64 (2500ns min, 2500ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at 9400 [size=128]
Region 1: Memory at f6001000 (32-bit, non-prefetchable) [size=128]
[virtual] Expansion ROM at f5020000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
02:00.0 PCI bridge: Texas Instruments XIO2000(A)/XIO2200(A) PCI Express-to-PCI Bridge (rev 03) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0, Cache Line Size: 32 bytes
Bus: primary=02, secondary=03, subordinate=03, sec-latency=32
I/O behind bridge: 0000f000-00000fff
Memory behind bridge: f2000000-f4ffffff
Prefetchable memory behind bridge: 00000000f0000000-00000000f1ffffff
Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Bridge: PM- B3+
Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/4 Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [80] Subsystem: Matrox Graphics, Inc. Unknown device 6666
Capabilities: [90] Express PCI/PCI-X Bridge IRQ 0
Device: Supported: MaxPayload 512 bytes, PhantFunc 0, ExtTag-
Device: Latency L0s <4us, L1 <64us
Device: AtnBtn- AtnInd- PwrInd-
Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
Device: MaxPayload 128 bytes, MaxReadReq 512 bytes
Link: Supported Speed 2.5Gb/s, Width x1, ASPM L0s L1, Port 0
Link: Latency L0s <512ns, L1 <16us
Link: ASPM Disabled CommClk+ ExtSynch-
Link: Speed 2.5Gb/s, Width x1
03:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G550 AGP (rev 01) (prog-if 00 [VGA controller])
Subsystem: Matrox Graphics, Inc. Unknown device 22c0
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 32 (4000ns min, 8000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f0000000 (32-bit, prefetchable) [size=32M]
Region 1: Memory at f2000000 (32-bit, non-prefetchable) [size=16K]
Region 2: Memory at f3000000 (32-bit, non-prefetchable) [size=8M]
[virtual] Expansion ROM at f2020000 [disabled] [size=128K]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [f0] AGP version 2.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 64bit- FW- AGP3- Rate=<none>
Command: RQ=32 ArqSz=0 Cal=0 SBA+ AGP+ GART64- 64bit- FW- Rate=x1
Bus 002 Device 001: ID 0000:0000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 1 Single TT
bMaxPacketSize0 64
idVendor 0x0000
idProduct 0x0000
bcdDevice 2.06
iManufacturer 3 Linux 2.6.24-21-rt ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:02.1
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0004 1x 4 bytes
bInterval 12
Hub Descriptor:
bLength 11
bDescriptorType 41
nNbrPorts 10
wHubCharacteristic 0x000a
No power switching (usb 1.0)
Per-port overcurrent protection
TT think time 8 FS bits
bPwrOn2PwrGood 10 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00 0x00
PortPwrCtrlMask 0xff 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0100 power
Port 7: 0000.0100 power
Port 8: 0000.0100 power
Port 9: 0000.0100 power
Port 10: 0000.0100 power
Device Status: 0x0003
Self Powered
Remote Wakeup Enabled
Bus 001 Device 003: ID 046d:c404 Logitech, Inc. TrackMan Wheel
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x046d Logitech, Inc.
idProduct 0xc404 TrackMan Wheel
bcdDevice 2.20
iManufacturer 1 Logitech
iProduct 2 Trackball
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 34
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 100mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 1 Boot Interface Subclass
bInterfaceProtocol 2 Mouse
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.10
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 103
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 10
Device Status: 0x0000
(Bus Powered)
Bus 001 Device 001: ID 0000:0000
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 1.10
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x0000
idProduct 0x0000
bcdDevice 2.06
iManufacturer 3 Linux 2.6.24-21-rt ohci_hcd
iProduct 2 OHCI Host Controller
iSerial 1 0000:00:02.0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 25
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xe0
Self Powered
Remote Wakeup
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 9 Hub
bInterfaceSubClass 0 Unused
bInterfaceProtocol 0 Full speed (or root) hub
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0002 1x 2 bytes
bInterval 255
Hub Descriptor:
bLength 11
bDescriptorType 41
nNbrPorts 10
wHubCharacteristic 0x0002
No power switching (usb 1.0)
Ganged overcurrent protection
bPwrOn2PwrGood 1 * 2 milli seconds
bHubContrCurrent 0 milli Ampere
DeviceRemovable 0x00 0x00
PortPwrCtrlMask 0xff 0xff
Hub Port Status:
Port 1: 0000.0100 power
Port 2: 0000.0100 power
Port 3: 0000.0100 power
Port 4: 0000.0100 power
Port 5: 0000.0100 power
Port 6: 0000.0100 power
Port 7: 0000.0100 power
Port 8: 0000.0100 power
Port 9: 0000.0303 lowspeed power enable connect
Port 10: 0000.0100 power
Device Status: 0x0003
Self Powered
Remote Wakeup Enabled
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping : 2
cpu MHz : 2211.442
cache size : 512 KB
physical id : 0
siblings : 2
core id : 0
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc
bogomips : 4424.69
clflush size : 64
processor : 1
vendor_id : AuthenticAMD
cpu family : 15
model : 75
model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4200+
stepping : 2
cpu MHz : 2211.442
cache size : 512 KB
physical id : 0
siblings : 2
core id : 1
cpu cores : 2
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt rdtscp lm 3dnowext 3dnow pni cx16 lahf_lm cmp_legacy svm extapic cr8_legacy ts fid vid ttp tm stc
bogomips : 4422.03
clflush size : 64
Booting without "noapic" panics while booting. I wish I could debug that
further and keep initrd stuff working at the same time...
Best Regards
Ingo Oeser
On Wed, 2008-10-01 at 23:02 +0000, Thomas Gleixner wrote:
> This patch series implements support for threaded irq handlers for the
> generic IRQ layer.
Subject: genirq threading for ehci, ohci and uhci USB hosts.
This is a functional POC for partitioning of the USB interrupt handlers into
a quickcheck function and a threaded main-handler function.
The quickcheck performs the following actions only:
1. read status and stores.
2. check if the device is asserting, disable device assert
3. wake irq thread or return IRQ_NONE (shared IRQ not this USB)
The handler thread performs all other operations, and is conditionally
invoked via return code from quickcheck.
A function pointer *quickcheck() has been added, as well as a status
cache, which remembers the status reported by the chip. The status must
be passed to the threaded handler, since it is cleared by the quickcheck
function.
Currently, non-reentrancy is assumed, i.e. the chip will not assert another
IRQ until the thread has completed running.
In contrast with that, I have tightened up the locking between the
quickcheck handler and the main thread, this may be overly conservative.
The WARN_ONCE notes when status reported by the chip does not match
cached status, although this is expected. Its to be removed.
Note, that locking is not explicitly used for ohci as it is
in uhci and ehci.
The ieee1394/ohci1394.c is a bit more problematic, since it does not use
struct usb_hcd, and therefore another place for the status cache must be found,
in struct ti_ohci presumably.
I will send a separate patch for ieee1394/ohci1394.c after looking at it more.
The patch increases the code size by 100 lines, but there are some cleanups
that account for maybe a dozen lines, which can be broken-out.
Infrastructure:
This hack in kernel/irq/handle.c needs to be looked at, set_bit failed to work
properly on my AMD x86_64 machine, not further investigated and the code path
is currently not triggered by this patch.
+ //set_bit(IRQF_WARNED_THREADED, &action->flags);
+ action->flags |= IRQF_WARNED_THREADED;
Testing:
I have copied hundreds of gigs over ohci and ehci threads to and from USB disk.
In addition, I have written to USB flash, and mouse, keyboard work.
I have only tested on x86_64 so far, but will start on i386 ASAP.
I encountered some hangs at shutdown, that I attributed to racing, and have
not reproduced it after the locking changes, and when always using the cached
chip status in the threaded handler.
A tarball of all required genirq patches and series against 2.6.27 can
be downloaded:
http://www.thebigcorporation.com/Sven/genirq-usb/
The patch series also applied fine against Linus's git as well as linux-tip
as of Saturday.
Signed-off-by: Sven-Thorsten Dietrich <[email protected]>
drivers/usb/core/hcd.h | 3 ++
drivers/usb/host/ehci-au1xxx.c | 1
drivers/usb/host/ehci-fsl.c | 1
drivers/usb/host/ehci-hcd.c | 40 +++++++++++++++++++++++---------
drivers/usb/host/ehci-ixp4xx.c | 1
drivers/usb/host/ehci-orion.c | 1
drivers/usb/host/ehci-pci.c | 1
drivers/usb/host/ehci-ppc-of.c | 1
drivers/usb/host/ehci-ps3.c | 1
drivers/usb/host/ohci-at91.c | 1
drivers/usb/host/ohci-au1xxx.c | 1
drivers/usb/host/ohci-ep93xx.c | 1
drivers/usb/host/ohci-hcd.c | 20 ++++++++++++++--
drivers/usb/host/ohci-lh7a404.c | 1
drivers/usb/host/ohci-omap.c | 1
drivers/usb/host/ohci-pci.c | 1
drivers/usb/host/ohci-pnx4008.c | 1
drivers/usb/host/ohci-pnx8550.c | 1
drivers/usb/host/ohci-ppc-of.c | 1
drivers/usb/host/ohci-ppc-soc.c | 1
drivers/usb/host/ohci-ps3.c | 1
drivers/usb/host/ohci-pxa27x.c | 1
drivers/usb/host/ohci-s3c2410.c | 1
drivers/usb/host/ohci-sa1111.c | 1
drivers/usb/host/ohci-sh.c | 1
drivers/usb/host/ohci-sm501.c | 1
drivers/usb/host/ohci-ssb.c | 1
drivers/usb/host/uhci-hcd.c | 23 +++++++++++++++++-
kernel/irq/handle.c | 8 +++---
30 files changed, 134 insertions(+), 34 deletions(-)
--
diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index 8ab389d..6afd769 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -1673,15 +1673,7 @@ EXPORT_SYMBOL_GPL(usb_bus_start_enum);
/*-------------------------------------------------------------------------*/
-/**
- * usb_hcd_irq - hook IRQs to HCD framework (bus glue)
- * @irq: the IRQ being raised
- * @__hcd: pointer to the HCD whose IRQ is being signaled
- *
- * If the controller isn't HALTed, calls the driver's irq handler.
- * Checks whether the controller is now dead.
- */
-irqreturn_t usb_hcd_irq (int irq, void *__hcd)
+irqreturn_t usb_hcd_irq_quickcheck(int irq, void *__hcd)
{
struct usb_hcd *hcd = __hcd;
unsigned long flags;
@@ -1696,20 +1688,44 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
if (unlikely(hcd->state == HC_STATE_HALT ||
!test_bit(HCD_FLAG_HW_ACCESSIBLE, &hcd->flags))) {
rc = IRQ_NONE;
- } else if (hcd->driver->irq(hcd) == IRQ_NONE) {
- rc = IRQ_NONE;
- } else {
+ } else if ((rc = hcd->driver->irq_quickcheck(hcd)) != IRQ_NONE) {
+
set_bit(HCD_FLAG_SAW_IRQ, &hcd->flags);
if (unlikely(hcd->state == HC_STATE_HALT))
usb_hc_died(hcd);
- rc = IRQ_HANDLED;
}
local_irq_restore(flags);
return rc;
}
+/**
+ * usb_hcd_irq - hook IRQs to HCD framework (bus glue)
+ * @irq: the IRQ being raised
+ * @__hcd: pointer to the HCD whose IRQ is being signaled
+ *
+ * If the controller isn't HALTed, calls the driver's irq handler.
+ * Checks whether the controller is now dead.
+ */
+irqreturn_t usb_hcd_irq (int irq, void *__hcd)
+{
+ struct usb_hcd *hcd = __hcd;
+ unsigned long flags;
+ irqreturn_t rc;
+
+ /* Remaining artifact from non-threaded. Is it needed? */
+ local_irq_save(flags);
+
+ rc = hcd->driver->irq(hcd);
+
+ if (unlikely(hcd->state == HC_STATE_HALT))
+ usb_hc_died(hcd);
+
+ local_irq_restore(flags);
+ return rc;
+}
+
/*-------------------------------------------------------------------------*/
/**
@@ -1881,10 +1897,12 @@ int usb_add_hcd(struct usb_hcd *hcd,
snprintf(hcd->irq_descr, sizeof(hcd->irq_descr), "%s:usb%d",
hcd->driver->description, hcd->self.busnum);
- if ((retval = request_irq(irqnum, &usb_hcd_irq, irqflags,
- hcd->irq_descr, hcd)) != 0) {
+ retval = request_threaded_irq(irqnum, &usb_hcd_irq,
+ &usb_hcd_irq_quickcheck, irqflags,
+ hcd->irq_descr, hcd);
+ if (retval != 0) {
dev_err(hcd->self.controller,
- "request interrupt %d failed\n", irqnum);
+ "request interrupt %d failed\n", irqnum);
goto err_request_irq;
}
hcd->irq = irqnum;
diff --git a/drivers/usb/core/hcd.h b/drivers/usb/core/hcd.h
index e710ce0..c0b8a12 100644
--- a/drivers/usb/core/hcd.h
+++ b/drivers/usb/core/hcd.h
@@ -113,6 +113,8 @@ struct usb_hcd {
struct dma_pool *pool [HCD_BUFFER_POOLS];
int state;
+ unsigned short status_cache; /* saved by irq quickcheck */
+
# define __ACTIVE 0x01
# define __SUSPEND 0x04
# define __TRANSIENT 0x80
@@ -164,6 +166,7 @@ struct hc_driver {
size_t hcd_priv_size; /* size of private data */
/* irq handler */
+ irqreturn_t (*irq_quickcheck) (struct usb_hcd *hcd);
irqreturn_t (*irq) (struct usb_hcd *hcd);
int flags;
diff --git a/drivers/usb/host/ehci-au1xxx.c b/drivers/usb/host/ehci-au1xxx.c
index bf69f47..b181815 100644
--- a/drivers/usb/host/ehci-au1xxx.c
+++ b/drivers/usb/host/ehci-au1xxx.c
@@ -77,6 +77,7 @@ static const struct hc_driver ehci_au1xxx_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ehci_irq_quickcheck,
.irq = ehci_irq,
.flags = HCD_MEMORY | HCD_USB2,
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index 01c3da3..32d0b89 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -292,6 +292,7 @@ static const struct hc_driver ehci_fsl_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ehci_irq_quickcheck,
.irq = ehci_irq,
.flags = HCD_USB2,
diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
index 8409e07..1f7cb48 100644
--- a/drivers/usb/host/ehci-hcd.c
+++ b/drivers/usb/host/ehci-hcd.c
@@ -640,15 +640,41 @@ static int ehci_run (struct usb_hcd *hcd)
/*-------------------------------------------------------------------------*/
+static irqreturn_t ehci_irq_quickcheck (struct usb_hcd *hcd)
+{
+ struct ehci_hcd *ehci = hcd_to_ehci (hcd);
+ u32 status;
+
+ spin_lock (&ehci->lock);
+
+ status = ehci_readl(ehci, &ehci->regs->status);
+ hcd->status_cache = status;
+
+ if (!status & INTR_MASK) { /* irq sharing? */
+ spin_unlock(&ehci->lock);
+ return IRQ_NONE;
+ }
+
+ /* clear (just) interrupts */
+ ehci_writel(ehci, status, &ehci->regs->status);
+ hcd->status_cache = status;
+ spin_unlock (&ehci->lock);
+
+ return IRQ_WAKE_THREAD;
+}
+
static irqreturn_t ehci_irq (struct usb_hcd *hcd)
{
struct ehci_hcd *ehci = hcd_to_ehci (hcd);
u32 status, pcd_status = 0, cmd;
int bh;
+ unsigned long flags;
- spin_lock (&ehci->lock);
+ spin_lock_irqsave(&ehci->lock, flags);
- status = ehci_readl(ehci, &ehci->regs->status);
+ WARN_ONCE((ehci_readl(ehci, &ehci->regs->status) != hcd->status_cache),
+ "Chip status change %X - %X\n", hcd->status_cache, status);
+ status = hcd->status_cache;
/* e.g. cardbus physical eject */
if (status == ~(u32) 0) {
@@ -656,14 +682,6 @@ static irqreturn_t ehci_irq (struct usb_hcd *hcd)
goto dead;
}
- status &= INTR_MASK;
- if (!status) { /* irq sharing? */
- spin_unlock(&ehci->lock);
- return IRQ_NONE;
- }
-
- /* clear (just) interrupts */
- ehci_writel(ehci, status, &ehci->regs->status);
cmd = ehci_readl(ehci, &ehci->regs->command);
bh = 0;
@@ -748,7 +766,7 @@ dead:
if (bh)
ehci_work (ehci);
- spin_unlock (&ehci->lock);
+ spin_unlock_irqrestore(&ehci->lock, flags);
if (pcd_status)
usb_hcd_poll_rh_status(hcd);
return IRQ_HANDLED;
diff --git a/drivers/usb/host/ehci-ixp4xx.c b/drivers/usb/host/ehci-ixp4xx.c
index f9575c4..f2ba793 100644
--- a/drivers/usb/host/ehci-ixp4xx.c
+++ b/drivers/usb/host/ehci-ixp4xx.c
@@ -42,6 +42,7 @@ static const struct hc_driver ixp4xx_ehci_hc_driver = {
.description = hcd_name,
.product_desc = "IXP4XX EHCI Host Controller",
.hcd_priv_size = sizeof(struct ehci_hcd),
+ .irq_quickcheck = ehci_irq_quickcheck,
.irq = ehci_irq,
.flags = HCD_MEMORY | HCD_USB2,
.reset = ixp4xx_ehci_init,
diff --git a/drivers/usb/host/ehci-orion.c b/drivers/usb/host/ehci-orion.c
index 5416cf9..98104e1 100644
--- a/drivers/usb/host/ehci-orion.c
+++ b/drivers/usb/host/ehci-orion.c
@@ -131,6 +131,7 @@ static const struct hc_driver ehci_orion_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ehci_irq_quickcheck,
.irq = ehci_irq,
.flags = HCD_MEMORY | HCD_USB2,
diff --git a/drivers/usb/host/ehci-pci.c b/drivers/usb/host/ehci-pci.c
index c46a58f..5e4cfa0 100644
--- a/drivers/usb/host/ehci-pci.c
+++ b/drivers/usb/host/ehci-pci.c
@@ -344,6 +344,7 @@ static const struct hc_driver ehci_pci_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ehci_irq_quickcheck,
.irq = ehci_irq,
.flags = HCD_MEMORY | HCD_USB2,
diff --git a/drivers/usb/host/ehci-ppc-of.c b/drivers/usb/host/ehci-ppc-of.c
index b018dee..52e2798 100644
--- a/drivers/usb/host/ehci-ppc-of.c
+++ b/drivers/usb/host/ehci-ppc-of.c
@@ -44,6 +44,7 @@ static const struct hc_driver ehci_ppc_of_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ehci_irq_quickcheck,
.irq = ehci_irq,
.flags = HCD_MEMORY | HCD_USB2,
diff --git a/drivers/usb/host/ehci-ps3.c b/drivers/usb/host/ehci-ps3.c
index 0eba894..f9fd4fe 100644
--- a/drivers/usb/host/ehci-ps3.c
+++ b/drivers/usb/host/ehci-ps3.c
@@ -56,6 +56,7 @@ static const struct hc_driver ps3_ehci_hc_driver = {
.description = hcd_name,
.product_desc = "PS3 EHCI Host Controller",
.hcd_priv_size = sizeof(struct ehci_hcd),
+ .irq_quickcheck = ehci_irq_quickcheck,
.irq = ehci_irq,
.flags = HCD_MEMORY | HCD_USB2,
.reset = ps3_ehci_hc_reset,
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 4ed228a..0790627 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -233,6 +233,7 @@ static const struct hc_driver ohci_at91_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
diff --git a/drivers/usb/host/ohci-au1xxx.c b/drivers/usb/host/ohci-au1xxx.c
index 2ac4e02..1afe6de 100644
--- a/drivers/usb/host/ohci-au1xxx.c
+++ b/drivers/usb/host/ohci-au1xxx.c
@@ -136,6 +136,7 @@ static const struct hc_driver ohci_au1xxx_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
diff --git a/drivers/usb/host/ohci-ep93xx.c b/drivers/usb/host/ohci-ep93xx.c
index fb3055f..30b366e 100644
--- a/drivers/usb/host/ohci-ep93xx.c
+++ b/drivers/usb/host/ohci-ep93xx.c
@@ -123,6 +123,7 @@ static struct hc_driver ohci_ep93xx_hc_driver = {
.description = hcd_name,
.product_desc = "EP93xx OHCI",
.hcd_priv_size = sizeof(struct ohci_hcd),
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
.start = ohci_ep93xx_start,
diff --git a/drivers/usb/host/ohci-hcd.c b/drivers/usb/host/ohci-hcd.c
index 8990196..9a122ec 100644
--- a/drivers/usb/host/ohci-hcd.c
+++ b/drivers/usb/host/ohci-hcd.c
@@ -28,6 +28,7 @@
#include <linux/slab.h>
#include <linux/errno.h>
#include <linux/init.h>
+#include <linux/irqreturn.h>
#include <linux/timer.h>
#include <linux/list.h>
#include <linux/usb.h>
@@ -745,8 +746,7 @@ retry:
/*-------------------------------------------------------------------------*/
/* an interrupt happens */
-
-static irqreturn_t ohci_irq (struct usb_hcd *hcd)
+static irqreturn_t ohci_irq_quickcheck(struct usb_hcd *hcd)
{
struct ohci_hcd *ohci = hcd_to_ohci (hcd);
struct ohci_regs __iomem *regs = ohci->regs;
@@ -774,6 +774,22 @@ static irqreturn_t ohci_irq (struct usb_hcd *hcd)
if (ints == 0)
return IRQ_NOTMINE;
+ ohci_writel (ohci, OHCI_INTR_MIE, &ohci->regs->intrdisable);
+ hcd->status_cache = ints;
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t ohci_irq (struct usb_hcd *hcd)
+{
+ struct ohci_hcd *ohci = hcd_to_ohci (hcd);
+ struct ohci_regs __iomem *regs = ohci->regs;
+ int ints;
+
+ WARN_ONCE((ohci_readl(ohci, ®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)) {
diff --git a/drivers/usb/host/ohci-lh7a404.c b/drivers/usb/host/ohci-lh7a404.c
index de42283..3b51be3 100644
--- a/drivers/usb/host/ohci-lh7a404.c
+++ b/drivers/usb/host/ohci-lh7a404.c
@@ -166,6 +166,7 @@ static const struct hc_driver ohci_lh7a404_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
diff --git a/drivers/usb/host/ohci-omap.c b/drivers/usb/host/ohci-omap.c
index 95b3ec8..f9c791a 100644
--- a/drivers/usb/host/ohci-omap.c
+++ b/drivers/usb/host/ohci-omap.c
@@ -442,6 +442,7 @@ static const struct hc_driver ohci_omap_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
diff --git a/drivers/usb/host/ohci-pci.c b/drivers/usb/host/ohci-pci.c
index a9c2ae3..d04f48b 100644
--- a/drivers/usb/host/ohci-pci.c
+++ b/drivers/usb/host/ohci-pci.c
@@ -426,6 +426,7 @@ static const struct hc_driver ohci_pci_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_MEMORY | HCD_USB11,
diff --git a/drivers/usb/host/ohci-pnx4008.c b/drivers/usb/host/ohci-pnx4008.c
index 658a2a9..ad0c6fe 100644
--- a/drivers/usb/host/ohci-pnx4008.c
+++ b/drivers/usb/host/ohci-pnx4008.c
@@ -249,6 +249,7 @@ static const struct hc_driver ohci_pnx4008_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
diff --git a/drivers/usb/host/ohci-pnx8550.c b/drivers/usb/host/ohci-pnx8550.c
index 28467e2..ee18f4a 100644
--- a/drivers/usb/host/ohci-pnx8550.c
+++ b/drivers/usb/host/ohci-pnx8550.c
@@ -175,6 +175,7 @@ static const struct hc_driver ohci_pnx8550_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
diff --git a/drivers/usb/host/ohci-ppc-of.c b/drivers/usb/host/ohci-ppc-of.c
index 7ac5326..2fe80ac 100644
--- a/drivers/usb/host/ohci-ppc-of.c
+++ b/drivers/usb/host/ohci-ppc-of.c
@@ -45,6 +45,7 @@ static const struct hc_driver ohci_ppc_of_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
diff --git a/drivers/usb/host/ohci-ppc-soc.c b/drivers/usb/host/ohci-ppc-soc.c
index cd3398b..5fd3dee 100644
--- a/drivers/usb/host/ohci-ppc-soc.c
+++ b/drivers/usb/host/ohci-ppc-soc.c
@@ -145,6 +145,7 @@ static const struct hc_driver ohci_ppc_soc_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
diff --git a/drivers/usb/host/ohci-ps3.c b/drivers/usb/host/ohci-ps3.c
index 2089d8a..bd7c1a7 100644
--- a/drivers/usb/host/ohci-ps3.c
+++ b/drivers/usb/host/ohci-ps3.c
@@ -56,6 +56,7 @@ static const struct hc_driver ps3_ohci_hc_driver = {
.description = hcd_name,
.product_desc = "PS3 OHCI Host Controller",
.hcd_priv_size = sizeof(struct ohci_hcd),
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_MEMORY | HCD_USB11,
.reset = ps3_ohci_hc_reset,
diff --git a/drivers/usb/host/ohci-pxa27x.c b/drivers/usb/host/ohci-pxa27x.c
index 7f0f35c..148e37b 100644
--- a/drivers/usb/host/ohci-pxa27x.c
+++ b/drivers/usb/host/ohci-pxa27x.c
@@ -271,6 +271,7 @@ static const struct hc_driver ohci_pxa27x_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
diff --git a/drivers/usb/host/ohci-s3c2410.c b/drivers/usb/host/ohci-s3c2410.c
index f46af7a..65a51ed 100644
--- a/drivers/usb/host/ohci-s3c2410.c
+++ b/drivers/usb/host/ohci-s3c2410.c
@@ -439,6 +439,7 @@ static const struct hc_driver ohci_s3c2410_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
diff --git a/drivers/usb/host/ohci-sa1111.c b/drivers/usb/host/ohci-sa1111.c
index e4bbe8e..910a313 100644
--- a/drivers/usb/host/ohci-sa1111.c
+++ b/drivers/usb/host/ohci-sa1111.c
@@ -205,6 +205,7 @@ static const struct hc_driver ohci_sa1111_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
diff --git a/drivers/usb/host/ohci-sh.c b/drivers/usb/host/ohci-sh.c
index 60f03cc..625bb29 100644
--- a/drivers/usb/host/ohci-sh.c
+++ b/drivers/usb/host/ohci-sh.c
@@ -41,6 +41,7 @@ static const struct hc_driver ohci_sh_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY,
diff --git a/drivers/usb/host/ohci-sm501.c b/drivers/usb/host/ohci-sm501.c
index cff2363..c1a0b6b 100644
--- a/drivers/usb/host/ohci-sm501.c
+++ b/drivers/usb/host/ohci-sm501.c
@@ -47,6 +47,7 @@ static const struct hc_driver ohci_sm501_hc_driver = {
/*
* generic hardware linkage
*/
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_USB11 | HCD_MEMORY | HCD_LOCAL_MEM,
diff --git a/drivers/usb/host/ohci-ssb.c b/drivers/usb/host/ohci-ssb.c
index 23fd6a8..5b3ab3c 100644
--- a/drivers/usb/host/ohci-ssb.c
+++ b/drivers/usb/host/ohci-ssb.c
@@ -65,6 +65,7 @@ static const struct hc_driver ssb_ohci_hc_driver = {
.product_desc = "SSB OHCI Controller",
.hcd_priv_size = sizeof(struct ssb_ohci_device),
+ .irq_quickcheck = ohci_irq_quickcheck,
.irq = ohci_irq,
.flags = HCD_MEMORY | HCD_USB11,
diff --git a/drivers/usb/host/uhci-hcd.c b/drivers/usb/host/uhci-hcd.c
index 3a7bfe7..4d4481b 100644
--- a/drivers/usb/host/uhci-hcd.c
+++ b/drivers/usb/host/uhci-hcd.c
@@ -407,11 +407,12 @@ __acquires(uhci->lock)
mod_timer(&uhci_to_hcd(uhci)->rh_timer, jiffies);
}
-static irqreturn_t uhci_irq(struct usb_hcd *hcd)
+static irqreturn_t uhci_irq_quickcheck(struct usb_hcd *hcd)
{
struct uhci_hcd *uhci = hcd_to_uhci(hcd);
unsigned short status;
+ spin_lock(&uhci->lock);
/*
* Read the interrupt status, and write it back to clear the
* interrupt cause. Contrary to the UHCI specification, the
@@ -421,6 +422,25 @@ static irqreturn_t uhci_irq(struct usb_hcd *hcd)
if (!(status & ~USBSTS_HCH)) /* shared interrupt, not mine */
return IRQ_NONE;
outw(status, uhci->io_addr + USBSTS); /* Clear it */
+ hcd->status_cache = status;
+ spin_unlock(&uhci->lock);
+
+ return IRQ_WAKE_THREAD;
+}
+
+static irqreturn_t uhci_irq(struct usb_hcd *hcd)
+{
+ struct uhci_hcd *uhci = hcd_to_uhci(hcd);
+ unsigned short status;
+ unsigned long flags;
+
+ spin_lock_irqsave(&uhci->lock, flags);
+
+ WARN_ONCE((inw(uhci->io_addr + USBSTS) != hcd->status_cache),
+ "Chip status change %X - %X\n", hcd->status_cache, status);
+ status = hcd->status_cache;
+
+ spin_unlock_irqrestore(&uhci->lock, flags);
if (status & ~(USBSTS_USBINT | USBSTS_ERROR | USBSTS_RD)) {
if (status & USBSTS_HSE)
@@ -900,6 +920,7 @@ static const struct hc_driver uhci_driver = {
.hcd_priv_size = sizeof(struct uhci_hcd),
/* Generic hardware linkage */
+ .irq_quickcheck = uhci_irq_quickcheck,
.irq = uhci_irq,
.flags = HCD_USB11,
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index b204455..d8faf88 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -152,14 +152,14 @@ irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action)
}
/*
* Warn once when a quick check handler asked
- * for invoking the threaded (main) handler
- * directly
+ * for invoking the threaded (main) handler directly
*/
WARN(!(action->flags & IRQF_WARNED_THREADED),
"IRQ %d requested to run threaded handler "
"in hard interrupt context\n", irq);
- set_bit(IRQF_WARNED_THREADED, &action->flags);
-
+ //set_bit(IRQF_WARNED_THREADED, &action->flags);
+ action->flags |= IRQF_WARNED_THREADED;
+
case IRQ_WAKE_THREAD:
/*
* In case the thread crashed and was killed
Hi
> > This patch series implements support for threaded irq handlers for the
> > generic IRQ layer.
>
> Subject: genirq threading for ehci, ohci and uhci USB hosts.
>
> This is a functional POC for partitioning of the USB interrupt handlers into
> a quickcheck function and a threaded main-handler function.
> :
> The ieee1394/ohci1394.c is a bit more problematic, since it does not use
> struct usb_hcd, and therefore another place for the status cache must be found,
> in struct ti_ohci presumably.
> I will send a separate patch for ieee1394/ohci1394.c after looking at it more.
Thanks for sending this through; I will endeavour to test it over the coming
days. I'll also see if I can test it for the case where USB and ieee1394
share IRQs. Even though ieee1394 isn't done yet these changes should
prevent the USB-related problems we've seen in FFADO when USB shares the
firewire IRQ.
Having said that, the forthcoming ohci1394.c patch will also be interesting
since that is the other area which will greatly benefit FFADO.
Regards
jonathan
On Tue, 2008-10-21 at 11:37 +0930, Jonathan Woithe wrote:
> Hi
>
> > > This patch series implements support for threaded irq handlers for the
> > > generic IRQ layer.
> >
> > Subject: genirq threading for ehci, ohci and uhci USB hosts.
> >
> > This is a functional POC for partitioning of the USB interrupt handlers into
> > a quickcheck function and a threaded main-handler function.
> > :
> > The ieee1394/ohci1394.c is a bit more problematic, since it does not use
> > struct usb_hcd, and therefore another place for the status cache must be found,
> > in struct ti_ohci presumably.
> > I will send a separate patch for ieee1394/ohci1394.c after looking at it more.
>
> Thanks for sending this through; I will endeavour to test it over the coming
> days. I'll also see if I can test it for the case where USB and ieee1394
> share IRQs. Even though ieee1394 isn't done yet these changes should
> prevent the USB-related problems we've seen in FFADO when USB shares the
> firewire IRQ.
>
> Having said that, the forthcoming ohci1394.c patch will also be interesting
> since that is the other area which will greatly benefit FFADO.
>
Hi,
I have re-released the patch set with support for ohci1394.
I have not tested, for lack of hardware :: it compiles.
The location of status_cache is now within the ti_ohci struct.
That organization not entirely consistent with the USB side, predicated
by other variation between the drivers.
The updated patch queue is available here.
http://www.thebigcorporation.com/Sven/genirq-usb/genirq-usb-v2.tar.bz2
Bug fix:
The declaration of status_cache has been made consistent u32.
The former declaration of unsigned short (copied from uhci-hcd.c) it was
probably too ambiguous for some architectures.
Thanks,
Sven
> Regards
> jonathan