lkml.org 
[lkml]   [1999]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Shared interrupt (lack of) handling

On Thu, 2 Sep 1999, David Schleef wrote:

> On Thu, Sep 02, 1999 at 09:41:48PM +0200, Gerard Roudier wrote:
> > >
> > > I'd vote for changing the return value of the interrupt handlers to
> > > (int), and return a I_DID_SOME_STUFF flag. That way, if none of the
> >
> > This does not make sense at all for PCI.
> >
> > In PCI, INTERRUPT ARE NOT SYNCHRONISATION EVENTS! Synchronisation events
> > are PCI TRANSACTIONS in the context of ordering rules defined by the
> > specs, but unfortunately only a few hardware implemented that stuff
> > correctly. People that think interrupts as synchronisations events are not
> > able to write PCI device drivers that will work reliably in presence of
> > posted transactions. A PCI interrupt just kicks the driver code that has
> > then to synchronize correctly with de device, both using PCI transactions
> > and relying on PCI ordering rules (or the subset available on the involved
> > hardware).
>
>
> I appear to be missing something. What do PCI synchonization issues
> have anything to do with a driver giving the OS hints? The delivery
> of interrupts to the handlers would not change, but only that messages
> *might* get printk'd if an interrupt occurs and no handler thinks that
> the interrupt belongs to it. How often do spurious interrupts occur
BTW, "share" is kind of opposite of "belong".
> in a correctly functioning computer that shares interrupts between,
> say, a NIC and SCSI card?

An PCI interrupt that occurs and no device (sharing the INT line) having
things to do may happen in PCI without being a spurious interrupt (even if
this is probably a rare situation). Your statement let me think that your
knowledge on PCI is just ISA+.

> One thing that you could do with the I_DID_SOME_STUFF flag is use the
> statistics to reorder the execution of interrupt handlers so that the
> device that causes the most interrupts gets called first. Might be
> cool, difficult to tell.

You _must_ call all interrupt handlers that requested the same IRQ when
this IRQ is raised. So your flag does not optimize anything.

Gérard.


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

\
 
 \ /
  Last update: 2005-03-22 13:53    [W:0.116 / U:0.004 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site