From owner-freebsd-alpha Mon Oct 30 14: 8:36 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id EE15137B479; Mon, 30 Oct 2000 14:08:33 -0800 (PST) Received: from beppo (beppo [192.67.166.79]) by feral.com (8.9.3/8.9.3) with ESMTP id OAA03324; Mon, 30 Oct 2000 14:08:34 -0800 Date: Mon, 30 Oct 2000 14:08:34 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: John Baldwin Cc: alpha@FreeBSD.org, "David O'Brien" , Bernd Walter Subject: Re: minor patchlet for others to try .. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 30 Oct 2000, John Baldwin wrote: > > On 30-Oct-00 Matthew Jacob wrote: > > > > Same for me. This little patchlet really doesn't cover the EB164 PC164 > > variants, but is mostly for me to see whether it *breaks* other folks. > > > > Formally speaking, if I can be so bold to say as much about code I didn't > > design and probably don't understand, as each interrupt comes in and a thread > > is scheduled to run but isn't running, there is an attempt to disable the > > interrupt source in h/w (not at the device but at h/w in the system that > > allows the transmission of interrupts). PCI interrupts were/are being handled > > by each alpha's platform PCI code. > > > > The isa code wasn't setting up enable/disable vectors. I want to add them and > > see if breaks people. The semantics should be the same as the PCI stuff- and, > > haha, even close the x86 code that this design seems to come from. > > Grrrr. So ISA interrupts are level-triggered on the 164? Ugh.. No. But don't assume that all platforms get it right. Let me give you a reverse example. The PCI implementation on TurboLaser (DWLPX, at the end of an I/O hose from a KTIA or a KTHA) breaks the notion of PCI being level-sensitive. The reason this is so is that events travel as packets up and down the hose- not as signal levels. Therefore, you can dismiss an interrupt (you think) for a PCI card, only to get a later 'spurious' interrupt. The point I've been groping toward is that the base design of this MP scheme is making some fairly serious assumptions about h/w capabilities. And even within the framework of the alpha implementation of that design, coding conservatively and allowing for enable/disable on what should nominally be an edge triggered interrupt, is not a bad thing to do. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message