From owner-freebsd-mobile@FreeBSD.ORG Mon Mar 7 22:49:24 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 92A0616A4CE for ; Mon, 7 Mar 2005 22:49:24 +0000 (GMT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7381E43D55 for ; Mon, 7 Mar 2005 22:49:23 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j27MmtEd004981; Mon, 7 Mar 2005 15:48:56 -0700 (MST) (envelope-from imp@bsdimp.com) Date: Mon, 07 Mar 2005 15:48:55 -0700 (MST) Message-Id: <20050307.154855.74746009.imp@bsdimp.com> To: bengta@sics.se From: Warner Losh In-Reply-To: References: X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit cc: freebsd-mobile@freebsd.org 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: Mon, 07 Mar 2005 22:49:24 -0000 > After kldunload:ing if_ath, no pccard is recognised. For any pccard > (16-bit - cardbus is not affected!) it just says: > > pccard0: Card has no functions! Interesting. > The system has an Atheros mini-PCI wireless card. (If my theory is > right, the particular card is irrelevant. I got the same symptoms > with if_ipw earlier when I had an Intel Wireless PRO 2100 in the same > box.) I have no device driver for the card compiled into the kernel. > At boot the kernel says: > > pcib1: device (null) requested decoded memory range 0xd0200000-0xd020ffff OK. That makes sense. The above message really means nothing, and isn't a warning or an error. > When the if_ath driver is kldload:ed: > > ath0: mem 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2 Good, addresses match. > At this point (and also before loading if_ath), inserting a pccard > works: > > pcib1: device pccard0 requested decoded memory range 0xd0200000-0xdfffffff > cis mem map 0xd63ab000 (resource: 0xd0240000) > pccard0: check_cis_quirks > pccard0: CIS version PC Card Standard 5.0 > pccard0: CIS info: Lucent Technologies, WaveLAN/IEEE, Version 01.01, > (and so on...) > > 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. Warner