Re: [9fans] ATA next

[Lucio De Re <lucio@proxima.alt.za>]

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