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: <20040122201917.E28365@cackle.proxima.alt.za> References: <20040122162315.D28365@cackle.proxima.alt.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii In-Reply-To: ; from jmk@plan9.bell-labs.com on Thu, Jan 22, 2004 at 10:22:37AM -0500 Date: Thu, 22 Jan 2004 20:19:18 +0200 Topicbox-Message-UUID: be591e18-eacc-11e9-9e20-41e7f4b1d025 On Thu, Jan 22, 2004 at 10:22:37AM -0500, jmk@plan9.bell-labs.com wrote: > > The code in sdata.c/atawctl() could perhaps be a little smarter and > not allow dmactl to be set if ctlr->prdt is nil, then at least you'd get > an error when you tried to set dma on, not later when you actually > tried some data transfers. Something like > There didn't use to be a noticeable problem with the kernel dating back a year or more ago. I didn't put it to the test, but I always assumed that DMA was permissible. It's a recent-ish change that seems to have (erroneously, I believe) detected that the disk/controller is not DMA capable. Is it not just an issue that DMA is (accidentally) no longer supported on non-PCI systems? Must I try another old computer to check? While on the subject of that particular host, it also seems to have developed an affinity for (once I enabled the warning message): cpu0: spurious interrupt 39, last 0 which immediately precedes each of those annoying blank lines. Since the newer kernel these have become very frequent, the previous kernel would have one or two blank lines in an hour, at a rough guess, now they occur every few seconds. The message is in "pc/trap.c". Never having promoted myself from the 8088 which I knew really well, I have no idea what would give rise to interrupt 39 (0x27 to save you working it out), and in a new, extremely frequent number. I suspect all IDE hosts do it to a greater or lesser degree and DMA also seems to have a bearing. But I'm none the wiser as to why. ++L