From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lucio De Re To: 9fans@cse.psu.edu Subject: Re: [9fans] ATA next Message-ID: <20040123113748.K28365@cackle.proxima.alt.za> References: <20040123071911.G28365@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from Charles Forsyth on Fri, Jan 23, 2004 at 09:11:31AM +0000 Date: Fri, 23 Jan 2004 11:37:49 +0200 Topicbox-Message-UUID: bf8f9280-eacc-11e9-9e20-41e7f4b1d025 On Fri, Jan 23, 2004 at 09:11:31AM +0000, Charles Forsyth wrote: > > 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.) > Perfectly likely, I'll have a look at your suggested reading in a moment. Still, something must have triggered the increased frequency, and only the kernel has changed. I'm merely suggesting that there has been some change in the interrupt handling. I'm not curious enough to run a different OS, what I ought to do, instead, would be to configure PRN in the kernel. In fact, that may have been the case on the old kernel. But then I still wouldn't know why I was getting blank lines, much more rarely, with the old kernel. Since I patched trap.c, there have been none. > 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 I could :-) It's a shame that some things are just too much bother to pursue. But if I get to reboot the machine, I certainly will remember to do it. ++L