From owner-freebsd-new-bus Sun Nov 28 23:21:41 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 008F315343 for ; Sun, 28 Nov 1999 23:21:38 -0800 (PST) (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 AAA03305 for ; Mon, 29 Nov 1999 00:21:37 -0700 (MST) (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 AAA90820 for ; Mon, 29 Nov 1999 00:21:56 -0700 (MST) Message-Id: <199911290721.AAA90820@harmony.village.org> To: new-bus@freebsd.org Subject: Interrupt irq activation question Date: Mon, 29 Nov 1999 00:21:56 -0700 From: Warner Losh Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In my pccard_nbk I turned on interrupts when the IRQ resource was activated. In my newconfig pccard code, I'd like to do the same thing. I notice that the NetBSD code base turns them on/off in its intr_establish/intr_disestablish routines, which basically map to our bus_intr_setup and bus_intr_teardown methods. It got me thinking. Do I want to do them in the activate phase, or later in the establish phase. The advantage of doing them in the activate phase is that devices like sio that try to probe for the interrupt used can activate the interrupt w/o registering an actual interrupt handler for the device and somehow check to see if that interrupt is responding. The advantage for doing them in the setup/teardown methods is that I suppose this violates POLA less and might result in fewer stray interrupts. Any opinions on the matter? I seem to recall that Doug Rabson once told me activate/deactivate was the architecturally pure way to do this. I cannot find his email that told me this, so I thought I'd ask here in an archived forum. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Tue Nov 30 14:14: 7 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 93FBB157FF for ; Tue, 30 Nov 1999 14:13:43 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id WAA75085; Tue, 30 Nov 1999 22:19:00 GMT (envelope-from dfr@nlsystems.com) Date: Tue, 30 Nov 1999 22:18:59 +0000 (GMT) From: Doug Rabson To: Warner Losh Cc: new-bus@freebsd.org Subject: Re: Interrupt irq activation question In-Reply-To: <199911290721.AAA90820@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Mon, 29 Nov 1999, Warner Losh wrote: > > In my pccard_nbk I turned on interrupts when the IRQ resource was > activated. In my newconfig pccard code, I'd like to do the same > thing. I notice that the NetBSD code base turns them on/off in its > intr_establish/intr_disestablish routines, which basically map to our > bus_intr_setup and bus_intr_teardown methods. It got me thinking. Do > I want to do them in the activate phase, or later in the establish > phase. > > The advantage of doing them in the activate phase is that devices like > sio that try to probe for the interrupt used can activate the > interrupt w/o registering an actual interrupt handler for the device > and somehow check to see if that interrupt is responding. > > The advantage for doing them in the setup/teardown methods is that I > suppose this violates POLA less and might result in fewer stray > interrupts. > > Any opinions on the matter? I seem to recall that Doug Rabson once > told me activate/deactivate was the architecturally pure way to do > this. I cannot find his email that told me this, so I thought I'd ask > here in an archived forum. I think that doing this in activate/deactivate was Garrett's intention. Practically, its difficult to activate the irq without a handler in all cases. For pci, its really bad to trigger an interrupt without a handler... -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Dec 1 10:28:33 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 94CF814D0F for ; Wed, 1 Dec 1999 10:28:19 -0800 (PST) (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 LAA13783; Wed, 1 Dec 1999 11:28:10 -0700 (MST) (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 LAA03228; Wed, 1 Dec 1999 11:28:10 -0700 (MST) Message-Id: <199912011828.LAA03228@harmony.village.org> To: Christopher Masto Subject: Re: PCCARD eject freeze (was Re: your mail) Cc: new-bus@freebsd.org In-reply-to: Your message of "Wed, 01 Dec 1999 12:36:29 EST." <19991201123629.A5734@netmonger.net> References: <19991201123629.A5734@netmonger.net> <199912010938.BAA00461@mass.cdrom.com> <199912011605.JAA02250@harmony.village.org> Date: Wed, 01 Dec 1999 11:28:10 -0700 From: Warner Losh Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG [[ Moved to new-bus since this starts to get into what to do on a detach ]] Problem summary for the new-bus readers: device_detach deletes the softc allocated for the device. Drivers cache copies of softc in their ISRs and other places where they sleep and count on the cached copy of softc to still be around when they are woken up. If a pccard is ejected between these points, these cached copies disappear because the ejection code deletes the device from the device tree (an as a side effect calls detach, which frees the softc for the device). Suspend has a similar problem because it can come in while a device is sleeping. In message <19991201123629.A5734@netmonger.net> Christopher Masto writes: : I think it's pretty much a given, though, that once one puts a pccard : in a laptop, one is very unlikely to be happy if one can't remove it : without powering down the machine. Particularly given that laptops : are much more useful if you can suspend them. So we need something. Agreed. Someone else will have to do the something, however, as I'm not interested in doing work that extensive on the old pccard stuff. I do not have the time if I'm going to make progress on newcard. I'm interested in talking about how to do this generically, however, since this will be one of the problems that I'll run into with newcard. : I would like to see that something along the lines of a method to shut : down the card in preparation for removal, regardless of what kind of : card it is. There is some code floating around that would allow one to do a pccardc power off slot 2 (or something to that effect, I've not used it). That would be a good generic way of coping. The problem with this, as with the others, is that the device may be in the middle doing something and needs to be clear of its critical sections/busy loops. While it usually is in the old system (and I don't think my code changes this much at all) there is always a small window for it not to be. : There are other contexts for the same issues anyway. USB has devices : that go away suddenly, and it _is_ designed to be hot-removable, so : people are going to be pulling the plug on network adapters, ZIP : drives, etc. We need drivers that are capable of going away cleanly, : or at least without a panic. Right. That's why I've said things as "devices which support detach" rather than "pccard devices". This is a generic problem, not limited to pccard. While pccard was broken for newbus, the thing that has changed is the management of the softc. In the old regime it was managed by the driver. In the new one it is managed by the newbus code. Consequently, the time of softc's removal from the system has changed from maybe never to always at detach. Hence a device can no longer count on softc being there after the detach. Since the device can go away between any instructions, this may behard to fix. Or it may just be a matter of putting the pcic device's interrupt into the tty, net, bio, cam and whatever other device classes are needed so that the usual locking mechanisms would keep softc from disappearing at interrupt context/usual critical section protection. It won't help the actual hardware going away completely while interrupts are blocked, but at least you want have softc going away in your critical section. Less that completely satisfactory. Another problem that some (all?) detachable drivers have is that they don't keep a list of sleepers on a per instance basis, so when they detach, they can't terminate the sleepers and bail out with an error to the sleeping process (which makes these sleeps uninterruptable). I'm starting to thing that we need a "rundown" or "shutdown" method that gets called before the detach to give the device a chance to shutdown gracefully before the executioner comes and removes it from the tree. However, I think this just enshrines the race w/o actually fixing it. A final option would be to allow a sleep in the detach routine. The driver would keep track of its sleepers. Detach would look like: sc->gone = 1; foreach sleeper terminate sleep while (sc->refcount) sleep(&sc->refcount); each sleeper would then do something like sc->refcount++ sleep() if (sc->gone) { sc->refcount--; wakeup (&sc->refcount); return error; } ... sc->refcount--; return; With similar code (sans sleep) in the loops in the interrupt routines. Something about it strikes me as bad, but I can't quite put my finger on what that badness is. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Dec 1 10:50:49 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 9902D15015 for ; Wed, 1 Dec 1999 10:50:28 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id NAA54963; Wed, 1 Dec 1999 13:48:01 -0500 (EST) (envelope-from wollman) Date: Wed, 1 Dec 1999 13:48:01 -0500 (EST) From: Garrett Wollman Message-Id: <199912011848.NAA54963@khavrinen.lcs.mit.edu> To: Warner Losh Cc: new-bus@freebsd.org Subject: Re: PCCARD eject freeze (was Re: your mail) In-Reply-To: <199912011828.LAA03231@harmony.village.org> References: <199912011828.LAA03231@harmony.village.org> Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG < said: > Suspend has a similar problem because it can come in while a > device is sleeping. The device driver gets informed about suspends (although some broken drivers don't pay attention). Every DEVICE_SUSPEND method should place that device in a quiescent state. Here's a state table: NP = Not Present P = Present I = Inactive B = Busy S = Suspended to-------------------------------------- from NP P I B S NP probe probe - - - P attach - attach - - I - - - open suspend B - - close - suspend S detach - resume resume - (In this table, `open' and `close' also include ifconfig or other analogous behavior for non-device-interface drivers. There are a few more gradations which might turn out to be useful as well, but I think this is the model.) -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Dec 1 11:58:19 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id A3FC415041 for ; Wed, 1 Dec 1999 11:57:53 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id UAA68961; Wed, 1 Dec 1999 20:03:26 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 1 Dec 1999 20:03:25 +0000 (GMT) From: Doug Rabson To: Warner Losh Cc: Christopher Masto , new-bus@freebsd.org Subject: Re: PCCARD eject freeze (was Re: your mail) In-Reply-To: <199912011828.LAA03228@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 1 Dec 1999, Warner Losh wrote: > [[ Moved to new-bus since this starts to get into what to do on a > detach ]] > > Problem summary for the new-bus readers: > device_detach deletes the softc allocated for the device. > Drivers cache copies of softc in their ISRs and other places where > they sleep and count on the cached copy of softc to still be around > when they are woken up. If a pccard is ejected between these points, > these cached copies disappear because the ejection code deletes the > device from the device tree (an as a side effect calls detach, which > frees the softc for the device). > > Suspend has a similar problem because it can come in while a > device is sleeping. The device_detach routine *must* teardown all interrupt handlers and release all resources. If this rule is followed, then the handler shouldn't be called after detach, so there is no problem, right? -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Dec 1 12: 0:49 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id AD6BE15B91; Wed, 1 Dec 1999 12:00:36 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id UAA68982; Wed, 1 Dec 1999 20:07:10 GMT (envelope-from dfr@nlsystems.com) Date: Wed, 1 Dec 1999 20:07:10 +0000 (GMT) From: Doug Rabson To: Nick Hibma Cc: FreeBSD Newbus Mailing List , Doug Rabson Subject: Re: device_get_softc(devclass_get_unit(devclass, unit)) != devclass_get_softc(devclass, unit) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Fri, 26 Nov 1999, Nick Hibma wrote: > Executed _during_attach_, a > > sc = devclass_get_softc(devclass, unit); > > returns NULL, but a > > sc = device_get_softc(devclass_get_unit(devclass, unit)); > > returns the softc. The statements are equivalent but the result is > inconsistent. > > > I suggest removing the limitation > > if (!dev || dev->state < DS_ATTACHED) > return NULL; > > from devclass_get_softc (diff below). > > Reason: if you do initialisation (for example CAM, XPT_SCAN_BUS in my > case), you will end up in the routines that need this function before > attach is finished and state >= DS_ATTACHED. > > Second, none of the other functions uses this limitation > (devclass_get_devices(), devclass_get_unit()). > > Let me know your thoughts. You are right. There is no harm returning the softc in this situation and even if there is no driver, softc should be NULL which would be the correct thing to return in any case. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Dec 1 12:38:12 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from cheddar.netmonger.net (cheddar.netmonger.net [209.54.21.140]) by hub.freebsd.org (Postfix) with ESMTP id AEA131514D for ; Wed, 1 Dec 1999 12:37:28 -0800 (PST) (envelope-from chris@cheddar.netmonger.net) Received: (from chris@localhost) by cheddar.netmonger.net (8.8.8/8.8.8) id PAA19619; Wed, 1 Dec 1999 15:37:25 -0500 (EST) Message-ID: <19991201153724.B16857@netmonger.net> Date: Wed, 1 Dec 1999 15:37:24 -0500 From: Christopher Masto To: Warner Losh Cc: new-bus@freebsd.org Subject: Re: PCCARD eject freeze (was Re: your mail) References: <19991201123629.A5734@netmonger.net> <199912010938.BAA00461@mass.cdrom.com> <199912011605.JAA02250@harmony.village.org> <19991201123629.A5734@netmonger.net> <199912011828.LAA03228@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.91.1i In-Reply-To: <199912011828.LAA03228@harmony.village.org>; from Warner Losh on Wed, Dec 01, 1999 at 11:28:10AM -0700 Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, Dec 01, 1999 at 11:28:10AM -0700, Warner Losh wrote: > : I would like to see that something along the lines of a method to shut > : down the card in preparation for removal, regardless of what kind of > : card it is. > > There is some code floating around that would allow one to do a > pccardc power off slot 2 > (or something to that effect, I've not used it). That would be a good > generic way of coping. The problem with this, as with the others, is > that the device may be in the middle doing something and needs to be > clear of its critical sections/busy loops. While it usually is in the > old system (and I don't think my code changes this much at all) there > is always a small window for it not to be. What about setting a "terminate as soon as possible" flag, which the driver checks in some safe place? Drivers that are unloadable would have to be written with a mechanism to wake up and check the flag eventually. There could still be a "force" option. Then the userland tool that is used to shut down devices should be able to signal a shut down and then wait for it, so the user can get positive confirmation before ejecting and so APM suspend can be delayed until it is safe. -- Christopher Masto Senior Network Monkey NetMonger Communications chris@netmonger.net info@netmonger.net http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Wed Dec 1 12:50:15 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 9790315262 for ; Wed, 1 Dec 1999 12:50:10 -0800 (PST) (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 NAA14312; Wed, 1 Dec 1999 13:50:05 -0700 (MST) (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 NAA04082; Wed, 1 Dec 1999 13:50:05 -0700 (MST) Message-Id: <199912012050.NAA04082@harmony.village.org> To: Doug Rabson Subject: Re: PCCARD eject freeze (was Re: your mail) Cc: Christopher Masto , new-bus@freebsd.org In-reply-to: Your message of "Wed, 01 Dec 1999 20:03:25 GMT." References: Date: Wed, 01 Dec 1999 13:50:05 -0700 From: Warner Losh Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message Doug Rabson writes: : The device_detach routine *must* teardown all interrupt handlers and : release all resources. If this rule is followed, then the handler : shouldn't be called after detach, so there is no problem, right? Assuming that the interrupt handler isn't interrupted by a thread that removes the device. Further assuming that all sleepers for this device (eg in read, ioctl, etc) are terminated. These assumptions are what are commonly violated in the tree now. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Thu Dec 2 8:26:49 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id BCD5B14BD7 for ; Thu, 2 Dec 1999 08:26:42 -0800 (PST) (envelope-from hibma@skylink.it) Received: from skylink.it (va-151.skylink.it [194.185.55.151]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id RAA03390; Thu, 2 Dec 1999 17:26:10 +0100 Received: from localhost (localhost [127.0.0.1]) by skylink.it (8.9.3/8.9.3) with ESMTP id RAA02598; Thu, 2 Dec 1999 17:01:20 +0100 (CET) (envelope-from hibma@skylink.it) Date: Thu, 2 Dec 1999 17:01:20 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: Doug Rabson Cc: FreeBSD Newbus Mailing List Subject: Re: PCCARD eject freeze (was Re: your mail) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > device_detach deletes the softc allocated for the device. > > Drivers cache copies of softc in their ISRs and other places where > > they sleep and count on the cached copy of softc to still be around > > when they are woken up. If a pccard is ejected between these points, > > these cached copies disappear because the ejection code deletes the > > device from the device tree (an as a side effect calls detach, which > > frees the softc for the device). > > > > Suspend has a similar problem because it can come in while a > > device is sleeping. > > The device_detach routine *must* teardown all interrupt handlers and > release all resources. If this rule is followed, then the handler > shouldn't be called after detach, so there is no problem, right? The problem is that the following occurs now: DEVICE_DETACH called from device_delete_child wakes up all the sleepers and exits. The sleepers actually start running after DEVICE_DETACH has finished and the softc has been blown away by the device_delete_child that followed. I think this cries for a loop: Call detach and if EAGAIN is returned make sure sleepers can wake up and exit, and then try again. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ I have no idea how this 'wait for sleepers to have run' could be implemented, but this is I think the crucial part. Nick -- hibma@skylink.it n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Thu Dec 2 12:31: 5 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2EAFD14F42 for ; Thu, 2 Dec 1999 12:31:00 -0800 (PST) (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 NAA18804 for ; Thu, 2 Dec 1999 13:30:46 -0700 (MST) (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 NAA04669 for ; Thu, 2 Dec 1999 13:30:46 -0700 (MST) Message-Id: <199912022030.NAA04669@harmony.village.org> To: new-bus@freebsd.org Subject: How do I map attribute memory... Date: Thu, 02 Dec 1999 13:30:46 -0700 From: Warner Losh Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Thanks for the responces to the irq activation question. In newcard I'll move the activation to when the ISV is registered via bus_setup_intr. I may do this in oldcard as well, depending on how much I wanna work on the old code... Now, on to other matters. Different resource spaces. pccards have three resource spaces. They have shared memory, programmed I/O and attribute memory. The bridge chips support mapping the I/O ports into the host's I/O space. They also support mapping the shared memory and the attribute memory into the host's memory space. My question is how does newbus handle this? I don't see any place in the bus_alloc_resource to hang this information. One could add it as the resource argument, but that would require more hacking than I want to do to map a new type at the pcic bridge to the system space, and might have some undesirable side effects elsewhere. Overloading rid doesn't seem the right thing to do. I suppose I could add a flag bit, but what I really want is a parameter that says which address space is being allocated/activated, but that would force a lot of driver changes. My feeling is that a flag bit in the flags word, eg RF_ATTRIBUTE_MEM would be how I'd go and have the pcic (or any pccard bridge) driver look for this and do special things. I need this functionality generically for the pccard configuration code anyway... However, that seems the least wrong way to do it rather than actually being right. Comments? Warner P.S. Most normal pccards don't need this. The only thing that lives in the attribute space for them is the CIS and some write-only registers to activate the card, set which config to use, etc. There exists at least one modern pccard that uses it to control packets to be send or recieved :-(. Also the xircom folks need something similar, iirc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Dec 3 1:12: 4 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id 50BA8150BE for ; Fri, 3 Dec 1999 01:11:41 -0800 (PST) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id JAA57597; Fri, 3 Dec 1999 09:18:36 GMT (envelope-from dfr@nlsystems.com) Date: Fri, 3 Dec 1999 09:18:36 +0000 (GMT) From: Doug Rabson To: Nick Hibma Cc: FreeBSD Newbus Mailing List Subject: Re: PCCARD eject freeze (was Re: your mail) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 2 Dec 1999, Nick Hibma wrote: > > > device_detach deletes the softc allocated for the device. > > > Drivers cache copies of softc in their ISRs and other places where > > > they sleep and count on the cached copy of softc to still be around > > > when they are woken up. If a pccard is ejected between these points, > > > these cached copies disappear because the ejection code deletes the > > > device from the device tree (an as a side effect calls detach, which > > > frees the softc for the device). > > > > > > Suspend has a similar problem because it can come in while a > > > device is sleeping. > > > > The device_detach routine *must* teardown all interrupt handlers and > > release all resources. If this rule is followed, then the handler > > shouldn't be called after detach, so there is no problem, right? > > The problem is that the following occurs now: > > DEVICE_DETACH called from device_delete_child wakes up all the sleepers > and exits. The sleepers actually start running after DEVICE_DETACH has > finished and the softc has been blown away by the device_delete_child > that followed. > > I think this cries for a loop: Call detach and if EAGAIN is returned > make sure sleepers can wake up and exit, and then try again. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > I have no idea how this 'wait for sleepers to have run' could be > implemented, but this is I think the crucial part. I think that the solution is probably to use the busy counter more effectively. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message From owner-freebsd-new-bus Fri Dec 3 13: 4:56 1999 Delivered-To: freebsd-new-bus@freebsd.org Received: from ns.skylink.it (ns.skylink.it [194.177.113.1]) by hub.freebsd.org (Postfix) with ESMTP id D9D50153E0 for ; Fri, 3 Dec 1999 13:04:45 -0800 (PST) (envelope-from hibma@skylink.it) Received: from skylink.it (va-154.skylink.it [194.185.55.154]) by ns.skylink.it (8.9.1/8.8.8) with ESMTP id WAA09981; Fri, 3 Dec 1999 22:04:43 +0100 Received: from localhost (localhost [127.0.0.1]) by skylink.it (8.9.3/8.9.3) with ESMTP id PAA00323; Fri, 3 Dec 1999 15:46:45 +0100 (CET) (envelope-from hibma@skylink.it) Date: Fri, 3 Dec 1999 15:46:45 +0100 (CET) From: Nick Hibma X-Sender: n_hibma@henny.jrc.it Reply-To: Nick Hibma To: Doug Rabson Cc: FreeBSD Newbus Mailing List Subject: Re: PCCARD eject freeze (was Re: your mail) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-new-bus@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > DEVICE_DETACH called from device_delete_child wakes up all the sleepers > > and exits. The sleepers actually start running after DEVICE_DETACH has > > finished and the softc has been blown away by the device_delete_child > > that followed. > > > > I think this cries for a loop: Call detach and if EAGAIN is returned > > make sure sleepers can wake up and exit, and then try again. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > I have no idea how this 'wait for sleepers to have run' could be > > implemented, but this is I think the crucial part. > > I think that the solution is probably to use the busy counter more > effectively. No, as the device is gone and the driver should detach from it. What other mechanism is there to let the driver know that the physical device is gone? We can either solve this in a generic fashion or otherwise people will do things like, call detach and remember that it was called, then start detaching and, after finishing, the driver detaches itself with DEVICE_DETACH. It gets messy. I prefer a generic mechanism to let the driver know that it should go away and a detach method to make it go away now. Or the EAGAIN solution given above. Nick -- hibma@skylink.it n_hibma@freebsd.org USB project http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-new-bus" in the body of the message