From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <3dcff730ab56eb83f41cd6200f9ce3a3@plan9.bell-labs.com> From: jmk@plan9.bell-labs.com To: 9fans@cse.psu.edu Subject: Re: [9fans] ATA next In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Date: Fri, 23 Jan 2004 11:38:31 -0500 Topicbox-Message-UUID: bf993268-eacc-11e9-9e20-41e7f4b1d025 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.