From owner-freebsd-mobile@FreeBSD.ORG Wed Mar 9 11:54:20 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 2793216A4CE for ; Wed, 9 Mar 2005 11:54:20 +0000 (GMT) Received: from brev.sics.se (brev.sics.se [193.10.64.200]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C83E43D41 for ; Wed, 9 Mar 2005 11:54:19 +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 j29BsEo3029925; Wed, 9 Mar 2005 12:54:14 +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 j29BsJBf000891; Wed, 9 Mar 2005 12:54:19 +0100 (CET) (envelope-from bengta@P142.sics.se) Received: (from bengta@localhost) by P142.sics.se (8.13.1/8.13.1/Submit) id j29BsI3w000888; Wed, 9 Mar 2005 12:54:18 +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: 09 Mar 2005 12:54:18 +0100 Message-ID: Lines: 54 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: Wed, 09 Mar 2005 11:54:20 -0000 Warner Losh writes: > > 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. A little more info from devinfo -u, after boot: 0xd0100e00-0xd01fffff (root0) 0xd0200000-0xd020ffff ---- 0xd0210000-0xd02100ff ---- 0xd0210100-0xd021ffff (root0) 0xd0220000-0xd023ffff (em0) After loading if_ath: 0xd0100e00-0xd01fffff (root0) 0xd0200000-0xd020ffff (ath0) 0xd0210000-0xd02100ff ---- 0xd0210100-0xd021ffff (root0) 0xd0220000-0xd023ffff (em0) After unloading if_ath: 0xd0100e00-0xd020ffff (root0) 0xd0210000-0xd02100ff ---- 0xd0210100-0xd021ffff (root0) 0xd0220000-0xd023ffff (em0) The ath memory resource was merged to the preceding "root0" resource. (And after this, no pccard is recognised.) What does "----" mean in the devinfo printout? After using devinfo, the system once froze up when I inserted a pccard. That never happened before. Bengt