lkml.org 
[lkml]   [2005]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Posssible bug in kernel/irq/handle.c


On Wed, 9 Nov 2005, Benjamin Herrenschmidt wrote:
>
> Hrm... yah, it should... still, I find that a bit fragile.
>
> > So I think the code is correct. It has certainly worked for years on x86
> > (and it got serious debugging, since we had some rather nasty and subtle
> > issues with edge-triggered APIC interrupts that just get lost if they are
> > disabled at the controller).
>
> Well, we have a "funny" case with some pSeries... the firmware may
> enable interrupts behind our back, and expects us to call a firmware
> "try to handle that interrupt" kind of call when we get one we don't
> handle. That is, either all the handlers returned IRQ_NONE or there is
> no action. I'm not sure how to do that with the current code without
> having our own __do_IRQ() which I'd rather avoid...

Well, I don't think it would be _wrong_ to change the IRQ_INPROGRESS
handling to work so that it's usabel for PPC.

Some of it may actually be purely historical: I have this dim memory that
we may have used IRQ_INPROGRESS for the irq autodetection originally (it
now uses the IRQ_WAITING flag for that).

So I was really only arguing for it not being actively buggy the way it is
now - which is not to say that we can't change it to be friendlier to
whatever your needs are.

Be vewy vewy caweful when changing that code, though. If you end up with a
patch, please try to give it some nice stress-testing (both on ppc and
x86), and then post it for comments, ok? Maybe the arch mailing list and
Ingo (who else has touched that logic?)

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:0.049 / U:0.096 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site