From mboxrd@z Thu Jan  1 00:00:00 1970
From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ATA next
Message-ID: <20040123071911.G28365@cackle.proxima.alt.za>
References: <20040122201917.E28365@cackle.proxima.alt.za> <907d91e4f24372b364912eadff65de96@plan9.bell-labs.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
In-Reply-To: <907d91e4f24372b364912eadff65de96@plan9.bell-labs.com>; from jmk@plan9.bell-labs.com on Thu, Jan 22, 2004 at 02:13:38PM -0500
Date: Fri, 23 Jan 2004 07:19:12 +0200
Topicbox-Message-UUID: bf63ab70-eacc-11e9-9e20-41e7f4b1d025

On Thu, Jan 22, 2004 at 02:13:38PM -0500, jmk@plan9.bell-labs.com wrote:
>
> 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.
>
I believe you _and_ the driver.  I had a kernel on the same hardware
that didn't complain about DMA settings (I still have the installation,
so I suppose I could prove it at least to myself) and that would
most likely be the source of the confusion.

> 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");'
>
I did look.  There's a chunk of code in between that wasn't suppressed
and therefore I added a counter to make the NL go away if no
intervening printing took place:

	if(0)print("cpu%d: spurious interrupt %d, last %d",
		m->machno, vno, m->lastintr);
	for(i = 0; i < 32; i++){
		if(!(active.machs & (1<<i)))
			continue;
		mach = MACHP(i);
		if(m->machno == mach->machno)
			continue;
		print(": cpu%d: last %d", mach->machno, mach->lastintr);
		i0++;
	}
	if (i0)
		print("\n");
	m->spuriousintr++;

I couldn't quite convince myself to make the conditional "if (0 && i0)"
to match the "if (0)" at the beginning.

> 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 ought to have known that, but I didn't put two and two together.
Yes, the dreaded int 7 so many motherboards seem so keen to generate.
A "-32" in the message would go a long way to clarify things, even if
the message is not printed or even compiled in.

Would it not be possible to have a default, empty interceptor that
gets displaced by the real thing if ever required?

> > 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.
> >
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
to the day when these idiosyncracies will be nothing more than a
bad memory.  Thanks for the explanations.

++L