Messages in this thread | | | Date | Thu, 2 Sep 1999 21:41:48 +0200 (MET DST) | From | Gerard Roudier <> | Subject | Re: 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/
| |