From owner-freebsd-mobile@FreeBSD.ORG Tue Mar 8 10:28:41 2005 Return-Path: Delivered-To: freebsd-mobile@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6E29416A4CE for ; Tue, 8 Mar 2005 10:28:41 +0000 (GMT) Received: from brev.sics.se (brev.sics.se [193.10.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id B7CE043D41 for ; Tue, 8 Mar 2005 10:28:40 +0000 (GMT) (envelope-from bengta@P142.sics.se) Received: from P142.sics.se (P142.sics.se [193.10.66.253]) by brev.sics.se (8.12.8/8.12.8) with ESMTP id j28ASao3021086; Tue, 8 Mar 2005 11:28:36 +0100 env-to () env-from (bengta@P142.sics.se) Received: from P142.sics.se (localhost [127.0.0.1]) by P142.sics.se (8.13.1/8.13.1) with ESMTP id j28ASejq062663; Tue, 8 Mar 2005 11:28:40 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.13.1/8.13.1/Submit) id j28ASdjU062660; Tue, 8 Mar 2005 11:28:39 +0100 (CET) (envelope-from bengta) To: freebsd-mobile@freebsd.org References: <20050307.154855.74746009.imp@bsdimp.com> From: Bengt Ahlgren In-Reply-To: Warner Losh's message of "Mon, 07 Mar 2005 15:48:55 -0700 (MST)" Date: 08 Mar 2005 11:28:39 +0100 Message-ID: Lines: 48 User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by amavisd-new Subject: Re: pccard0: Card has no functions! OR PCI memory range allocation problem? X-BeenThere: freebsd-mobile@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Mobile computing with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2005 10:28:41 -0000 Warner Losh writes: > > After unloading the if_ath driver, it says the following instead: > > > > pcib1: device pccard0 requested decoded memory range 0xd0200000-0xdfffffff > > cis mem map 0xd63ab000 (resource: 0xd0200000) > > Hmmm, looks like you're the first person to hit this bug. I knew it > was theoretically possible to provoke it, but never could construct a > test case locally that would. > > > Now to the bottom line: where is the bug? > > > > 1) In the if_ath driver module which deallocated a PCI memory range > > which it didn't allocate (the kernel did at boot). > > > > 2) In the PCI memory allocation/deallocation routines which allowed > > the loadable driver to deallocate a PCI memory range that was > > allocated at boot. > > > > 3) In cbb/pccard which perhaps shouldn't be allowed to use the memory > > range? > > > > 4) Or is the answer that I should not unload drivers for fixed > > hardware? > > 5) On kldunload, the resources shouldn't be freed. Only when then > child actually goes away should they be freed. I think this is the > heart of the bug. Once this is fixed, all the down stream badness > should go away. Isn't that the same as 1) or 2)? The driver just calls bus_release_resource(), regardless of whether the hardware or the driver goes away. In the first case, the resource should be deallocated. In the second case, the resource should only be handed to the parent driver, without deallocation. Cardbus devices usually have the complete opposite situation - the hardware goes away, but the driver stays. But what happens with the memory resources in the cardbus case if the driver is unloaded with the card in place? And if the memory resource is not deallocated then, who deallocates when the hardware also goes away? Maybe -stable is a better list for this topic? Should I file a PR? Bengt