From owner-freebsd-arch Mon Oct 25 11:44:12 1999 Delivered-To: freebsd-arch@freebsd.org Received: from ns1.yes.no (ns1.yes.no [195.204.136.10]) by hub.freebsd.org (Postfix) with ESMTP id A506414A1E for ; Mon, 25 Oct 1999 11:43:44 -0700 (PDT) (envelope-from eivind@bitbox.follo.net) Received: from bitbox.follo.net (bitbox.follo.net [195.204.143.218]) by ns1.yes.no (8.9.3/8.9.3) with ESMTP id UAA06569 for ; Mon, 25 Oct 1999 20:43:37 +0200 (CEST) Received: (from eivind@localhost) by bitbox.follo.net (8.8.8/8.8.6) id UAA15898 for freebsd-arch@freebsd.org; Mon, 25 Oct 1999 20:43:37 +0200 (MET DST) Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 02B4414A1E for ; Mon, 25 Oct 1999 11:40:24 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA31357; Mon, 25 Oct 1999 12:40:21 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA42028; Mon, 25 Oct 1999 12:41:07 -0600 (MDT) Message-Id: <199910251841.MAA42028@harmony.village.org> To: mjacob@feral.com Subject: Re: Racing interrupts Cc: arch@freebsd.org In-reply-to: Your message of "Sun, 24 Oct 1999 20:26:13 PDT." References: Date: Mon, 25 Oct 1999 12:41:07 -0600 From: Warner Losh Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Matthew Jacob writes: : Presumably the interrupt that notifies one that a card has been pulled is : actually then managed by the bus device driver for that bus. This should : ensure that the the bus nexus controlller is notified that the state of : the hardware is changed. Yes. That is correct. : This does nothing for threads that were active at the time of the : interrupt. In this case, either the hardware is sane enough to continue to : provide some rational non-faulting access (in the case of memory mapping), : or you have to design a framework such that when the interrupt occurs, and : the nexus driver now knows how to remap any memory mappings so that a safe : non-faulting (if nonsensical) access can occur. Then some additional : mechanism which notifies the actual node driver that things have changed : will be invoked. Hmmm. I could do this, but do not know of any way of mapping I/O ports sanely. The problem appears to be driver busy waits for bits to become active. At least that's what it appears to be in the few I've seen. Most of the problems would be solved if I could detach the device before unmapping the interrupts, which is the part I needed to think about... Or rather look hard at the code to see why it is doing what it is doing and fix it... : For systems I'm more familiar with, explicit obligate parent-child : relationships have these specific notification mechanisms specified on a : per parent-child type basis. It's hard to generalize such mechanisms into : a usable general event notification mechanism because each bus has : different possible async events. A PC cardbus has removal/insertion, a : fibre channel arbitrated loop has LIP and then (re)arbitration for : AL_PAs- who knows what Compact PCI provides? : : What does newbus provide for this? newbus provides methods, but that is about it.. However, methods are easily ignored/defaulted so one can send arbitrary method call message to a tree or subtree and have sane things happen. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message