9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ATA next
Date: Fri, 23 Jan 2004 07:19:12 +0200	[thread overview]
Message-ID: <20040123071911.G28365@cackle.proxima.alt.za> (raw)
In-Reply-To: <907d91e4f24372b364912eadff65de96@plan9.bell-labs.com>; from jmk@plan9.bell-labs.com on Thu, Jan 22, 2004 at 02:13:38PM -0500

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


  reply	other threads:[~2004-01-23  5:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-22 14:23 Lucio De Re
2004-01-22 15:22 ` jmk
2004-01-22 18:19   ` Lucio De Re
2004-01-22 19:13     ` jmk
2004-01-23  5:19       ` Lucio De Re [this message]
2004-01-23  9:11         ` Charles Forsyth
2004-01-23  9:37           ` Lucio De Re
2004-01-23 16:38           ` jmk
2004-01-23 16:47             ` C H Forsyth
2004-01-22 15:53 ` David Presotto
2004-01-22 18:36   ` Lucio De Re
2004-01-22 19:53     ` David Presotto
2004-01-23  5:55       ` [9fans] imap4d operation (Was: ATA next) Lucio De Re
2004-01-23 16:39         ` David Presotto
2004-01-22 20:10     ` [9fans] ATA next David Presotto
2004-01-23  7:11       ` Lucio De Re
2004-01-23  9:00         ` Lucio De Re
2004-01-23 16:37         ` David Presotto

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20040123071911.G28365@cackle.proxima.alt.za \
    --to=lucio@proxima.alt.za \
    --cc=9fans@cse.psu.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).