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

> On Thu, Sep 02, 1999 at 06:18:01PM +0100, Paul Ashton wrote:
> >
> > Wouldn't it be clearer if request_irq() took a function pointer
> > to be used to determine whether the interrupt belongs to the
> > driver or not? i.e.:
> >
> > if (request_irq(irq, intr, SA_SHIRQ, "foo", foodev, isfoointr) { ... }
> >
> > static int isfoointr(int irq, void *foodev, struct pt_regs *regs) {
> > if (foodev && inw(FOOIO))
> > return 1; /* foo device generated this interrupt */
> > else
> > return 0; /* not my interrupt */
> > }
> >
> > At least it would force driver writers to address the shared interrupt
> > issue, and if the kernel determines that nobody claims the interrupt
> > it could do something about it, like complain, which it can't do at
> > the moment. Something that has caused me endless problems on a laptop
> > with some unidentifiable PCI device generating unhandled interrupts.
> >
> > Paul
> >
>
> 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).

About a PCI interrupt not handled that makes the system loop under
interrupt, it is a user issue. Using a device without a corresponding
driver is gross idioty, since:

- The OS does not reset the IO BUS at boot.
- So, all devices (intelligent?) that was running before the boot, are
not shut during boot and only a device driver for the device can ensure
the device will not do bad things (once the driver have caught it).

For example, using some programmable device, we can prepare a bomb from
DOS that will explode a few time after if the software does not take
a handle on the device on time.

That's quite feasible using SYM53C8XX chips for example and people that
would boot Linux from DOS without loading a driver for this device, would
see their Linux system explode at their face some time after boot, caused
by the execution of some bad SCRIPTS (kind of program) loaded into the SYM
device prior to the boot of Linux from DOS. :) :) :)

> interrupt handlers for an IRQ return this flag, the kernel belches out
> "Nobody handled interrupt X", which would quickly grab people's attention.
> Unfortunately, it would also grab your attention if there really are
> spurious interrupts that you don't care about.
>
> At the same time, it would be nice to have a RUN_MY_BOTTOM_HALF_PLEASE
> flag. This would be another way to grab driver writer's attention, since
> the bottom halves would break.

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.094 / U:0.972 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site