Re: [9fans] ATA next

[jmk@plan9.bell-labs.com]

On Fri Jan 23 04:12:42 EST 2004, forsyth@terzarima.net wrote:
> >>It all puts the lie to the above.  I must conclude that something
> >>in the interrupt handling rather than in the ATA DMA code has
> >>changed to cause so many more int 7s to occur.  I'm looking forward
>
> i thought IRQ7 was generated when a device requested an interrupt
> then incorrectly removed that irq signal before the cpu acknowledged it.
> a quick google search seems to confirm that.
> see http://www.geocrawler.com/archives/3/171/2000/5/0/3704984/
> (ie, it's not the driver code as such that causes it, but the hardware.)
>
> i wonder, though, whether it can happen if an interrupt
> is configured as level-triggered in the controller or system
> but is actually edge-triggered.  i didn't think there were level-triggered interrupts
> on a system without PCI, but perhaps there are.
> you might check your system's BIOS settings

if the driver has a loop in the interrupt routine:

	while(device has something new for me to do)
		do it

then, in the case of edge-triggered interrupts, the interrupt
routine can cause the reason for a 2nd interrupt to go away after
it has been received by the i8259. in this case the 8259 will
immediately interrupt the cpu again after the first interrupt has
returned, only to find it hasn't got the info about where the
interrupt came from. so it jumps up and says '7' (or '15' if it's
the 2nd i8259).

that's what i understood.
sometimes the interrupt routine can/should be rewritten to make
the problem go away, but edge-triggered interrupts just gulp buckets.