I'm sorry, but i can't agree with the response below: > -----Original Message----- > From: Ingraham, Andrew [mailto:[EMAIL PROTECTED] > Sent: maandag 24 februari 2003 22:07 > To: Multiple recipients of list CHIPDIR-L > Subject: RE: IRQ sharing on new m/bs? > > > > Conventional > > wisdom would be that irq sharing is the surest way to a > crash in a pc. > > Some would argue that conventional wisdom is that interrupt sharing > works just fine ... and indeed it often does ... with a > modern operating > system (unlike DOS) that is designed for it. On the other hand, DOS > experience is what says that it is sure to crash a PC. > > PCI interrupts are open-drain and level-sensitive, which means there > is no electrical problem sharing interrupts. Since each PCI slot has > four interrupts, sharing is a virtual necessity. > > The catch is that interrupt drivers must be written to > support interrupt > sharing. They do this by first checking to see whether the physical > device they support, needs to be serviced (i.e., whether it > was the one > that signalled the interrupt), and then passing control on to the next > interrupt driver in the chain. It's all supposed to work, > and indeed it > does work when all the players play by the rules, which I think is > most of the time with newer versions of Windows, and Linux. > > Sorry this probably doesn't help. > > Andy > > -- > Author: Ingraham, Andrew > INET: [EMAIL PROTECTED]
As for crashing a PC: I don't know. As for sharing interrupts on an ISA bus: As far as i know, the interrupts on an ISA bus are edge-triggered. That makes it impossible to share interrupts and guarantee that all interrupts will be 'seen' by the device drivers. What the response of the operating system will be to 'missed' interrupts, is a quite different matter. For some devices, that may not even be very important: A mouse driver that 'misses' a few mouse movements will work quite ok; A network interface that does not see an interrupt because a data packet has been sent or recieved may just rely on the TCP/IP layer to compensate for this 'unreliable network'. A disk or SCSI interface may well be a lot more 'sensitive' to missed interrupts. The problem with shared interrupts in combination with edge-triggering is that it is possible (perhaps unlikely..) that two interrupts happen almost at the same moment. The interrupt controller will 'see' the first one, and start 'asking' the device drivers 'did your device do this'. When the device driver for the 'seccond' interrupt is asked, before the seccond interrupt is generated, it will reply: 'No: my device did not generate the interrupt', and truthfully so. Next, the seccond interrupt is generated 'behind the back' of the question asked to the seccond driver, and it will *not* trigger another loop of questioning all the device drivers (the interrupts where *edge-triggered* remember..). This means that it's device driver will never be asked again, and the interrupt is missed. It can be worse than that: Some devices will *keep* the IRQ line active till the device driver services the interrupt (NB: this is the normal behaviour of level-triggered interruptiong devices..). If such a device is used to share edge-triggered interrupts the IRQ line of the shared interrupt is kept active (because the seccond interrupt is never serviced by the device driver) and *all* the interrupts on that IRQ will be blocked 'until further notice'. On a PCI bus, with level triggered interrupts, that guarantee is there; A PCI bus normally and routinely uses shared interrupts, and that works just fine. If a device activates it's IRQ after the question to the device driver, the operating system will simply be re-interrupted as soon as it attempts to drop out of the interrupt service routine. The questions to the device drivers will be started again, and this time the driver for the 'seccond' interrupt will answer: 'yep, my device did this', do the appropriate actions to reset the IRQ generation by the device, and trigger further actions of the device driver. NB: this *is* a famous way to make WinNT crash: If you manage to confuse the device drivers as to which device belongs to which interrupt (3C900B cards and their drivers come to mind..), then WinNT will 'poll' all the device drivers to find out which device generated the interrupt. If -in such a PCI system- *NONE* of the drivers claims responsibility for the interrupt, WinNT has no way to 'clear' the IRQ, and will blue-screen with the confusing IRQ-NOT-LESS-EQUAL-THAN message. Note that this is *not* specific to WinNT, any other OS will have the same problem with a non-claimed level-triggered interrupt, just that i've frequently observed this with WinNT 4.0 and it's drivers: our 'standard' network card is the 3C900, and it's drivers and/or hardware in a WinNT machine can be used to demonstrate this effect very nicely -- Author: Faasse, P.R. INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB CHIPDIR-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
