Re: Shared interrupt (lack of) handling

Re: Shared interrupt (lack of) handling

[David Schleef]

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
in a correctly functioning computer that shares interrupts between,
say, a NIC and SCSI card?

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.




dave...


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

Re: Shared interrupt (lack of) handling

[Richard B. Johnson]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=US-ASCII, Size: 1440 bytes --]

On Thu, 2 Sep 1999, Gerard Roudier wrote:
[SNIPPED]

> 
> In PCI, INTERRUPT ARE NOT SYNCHRONISATION EVENTS!  Synchronisation
> events are PCI TRANSACTIONS in the context of ordering rules defined by
> the specs,....

This sounds like something written by a lawyer. In plan language, any
hardware interrupt is a hardware request for some software to do
something. The interrupt event, itself, does not convey any
knowledge about the reason why the interrupt occurred. Software has
to inspect the hardware to determine the reason for the interrupt.

With shared interrupts, it is mandatory that the software that handles
an interrupt event (the ISR), not complain if it finds that it got
control and, upon inspecting the hardware, finds there is nothing to
do.

How the PCI controller, raises the maskable interrupt pin on the
CPU make no difference at all. One doesn't care if it's a 'PCI
TRANSACTION' or a 'PYROSYNCHROGEM'. If it happened fast enough so
the event isn't stale, nobody cares --and if the software cares,
it's broken.

> 
> Gérard.
> 


Cheers,
Dick Johnson
                   **** FILE SYSTEM WAS MODIFIED ****
Penguin : Linux version 2.3.13 on an i686 machine (400.59 BogoMips).
Warning : It's hard to remain at the trailing edge of technology.


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

Re: Shared interrupt (lack of) handling

[Gerard Roudier]

On Fri, 3 Sep 1999, Richard B. Johnson wrote:

> On Thu, 2 Sep 1999, Gerard Roudier wrote:
> [SNIPPED]
> 
> > 
> > In PCI, INTERRUPT ARE NOT SYNCHRONISATION EVENTS!  Synchronisation
> > events are PCI TRANSACTIONS in the context of ordering rules defined by
> > the specs,....
> 
> This sounds like something written by a lawyer. In plan language, any

The specifications _are_ the laws conformant hardwares and softwares shall
follow, and nothing else. People that use them as toilet paper are not
doing the right thing, in my opinion. ;-) 

> hardware interrupt is a hardware request for some software to do
> something. The interrupt event, itself, does not convey any
> knowledge about the reason why the interrupt occurred. Software has
> to inspect the hardware to determine the reason for the interrupt.

The piece of software that inspects the device status registers (or
memory) that tell about things to do must not care about the reason for
which it has been called, and must do proper things to synchronyze
correctly with the device, since INTERRUPTS ARE NOT SYNCHRONISATIONS
EVENTS in PCI.

> With shared interrupts, it is mandatory that the software that handles
> an interrupt event (the ISR), not complain if it finds that it got
> control and, upon inspecting the hardware, finds there is nothing to
> do.

NOT A SYNCHRONISATION EVENT as I wrote.

> How the PCI controller, raises the maskable interrupt pin on the
> CPU make no difference at all. One doesn't care if it's a 'PCI
> TRANSACTION' or a 'PYROSYNCHROGEM'. If it happened fast enough so
> the event isn't stale, nobody cares --and if the software cares,
> it's broken.

Donnot know what a PYROSYNCHROGEM is, but the prefix PYRO may let think
you wanted to flame somebody. ;-)

Indeed a software based in "fast enough" sorts of considerations is way
broken and is just race-based. It must base its behaviour on ordering
rules.

The order in which the PCI controller deals with data and raises the
interrupt, and the way both the PCI device and the C code access shared
memory or IO registers makes a GREAT difference, especially when posted
transactions are used. 

Obviously, the PCI device must make available the data to the CPU prior
to raising the interrupt. But both the PCI device and the C code must
behave correctly in order not to stall and not to see inconsistent data. 

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/