From owner-freebsd-alpha Fri Nov 17 14:50:13 2000 Delivered-To: freebsd-alpha@freebsd.org Received: from pike.osd.bsdi.com (pike.osd.bsdi.com [204.216.28.222]) by hub.freebsd.org (Postfix) with ESMTP id 2BF0A37B4C5 for ; Fri, 17 Nov 2000 14:50:11 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by pike.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id eAHMnKB06350; Fri, 17 Nov 2000 14:49:20 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 17 Nov 2000 14:50:02 -0800 (PST) From: John Baldwin To: =?ISO-8859-1?Q?G=E9rard_Roudier?= Subject: Re: PC164 IDE only works (was: SMPng stability) Cc: freebsd-alpha@FreeBSD.org, Christian Weisgerber , Bernd Walter , Andrew Gallatin Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 17-Nov-00 Gérard Roudier wrote: > > > On Fri, 17 Nov 2000, Andrew Gallatin wrote: > >> >> An interesting comment found in the linux kernel sources: >> >> /* In theory, the PC164 has the same interrupt hardware as >> the other Cabriolet based systems. However, something >> got screwed up late in the development cycle which broke >> the interrupt masking hardware. Repeat, it is not >> possible to mask and ack interrupts. At all. >> >> In an attempt to work around this, while processing >> interrupts, we do not allow the IPL to drop below what >> it is currently. This prevents the possibility of >> recursion. >> >> ??? Another option might be to force all PCI devices >> to use edge triggered rather than level triggered >> interrupts. That might be too invasive though. */ >> >> >> Drew > > Interesting, indeed. > > Note that using edge triggerred interrupt for PCI devices is a broken > idea, since it would just break numerous drivers by making them lose > interrupt conditions. Btw, in my opinion, handling level sensitive > interrupts from some scheduled entity (i.e. not in the corresponding > interrupt context) does not look a better idea to me for other reasons. > This let me consider the above hardware not to be broken given proper > handling of level sensitive interrupts. What if your interrupt handler blocks on a mutex? Unless you make all mutexes used by interrupts spin locks (which will chew up CPU time) you lose. Falling back to using all spin mutexes should only be used as a last resort if you can't find a way to allow an interrupt handler to block, and thus, to run in its own context, potentially delayed. > Gérard. -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message