From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <907d91e4f24372b364912eadff65de96@plan9.bell-labs.com>
From: jmk@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ATA next
In-Reply-To: <20040122201917.E28365@cackle.proxima.alt.za>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Thu, 22 Jan 2004 14:13:38 -0500
Topicbox-Message-UUID: bea4fe64-eacc-11e9-9e20-41e7f4b1d025

On Thu Jan 22 13:20:42 EST 2004, lucio@proxima.alt.za wrote:
> 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?

You are just confused. The ATA driver has never done non-PCI dma on the PC.
If you looked at the comment in the driver where the 'disabling dma' was coming
from you'd see that it's the drive which is saying it can do DMA, even although
there is no hardware that the driver knows how to use to do it.

>
> 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".

Again, if you looked at the code you identified in trap.c you'd see that
someone attempted to disable the 'spurious interrupt' messages but left in
the final 'print("\n");'

>
> 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.

On a uniprocessor machine using the i8259 interrupt controller, Plan 9
offsets the interrupt vectors by 32 ('VectorPIC' in io.h). So the IRQ (which
is what you are thinking is 39) is 7. For an explanantion I again refer you
to a comment in trap.c, just above the 'spurious interrupt' code.
>
> 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