From owner-freebsd-current@FreeBSD.ORG Sun May 9 08:35:22 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88F4616A4CE for ; Sun, 9 May 2004 08:35:22 -0700 (PDT) Received: from harmony.village.org (rover.village.org [168.103.84.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id E9DFB43D1D for ; Sun, 9 May 2004 08:35:20 -0700 (PDT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.12.10/8.12.9) with ESMTP id i49E5DOd050372; Sun, 9 May 2004 08:05:13 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Sun, 09 May 2004 08:06:00 -0600 (MDT) Message-Id: <20040509.080600.122620289.imp@bsdimp.com> To: d.wylie@hccnet.nl From: "M. Warner Losh" In-Reply-To: <409E0D5A.19164.559D04D@localhost> References: <409D614D.7983.2B9BBDF@localhost> <20040508.172554.110767931.imp@bsdimp.com> <409E0D5A.19164.559D04D@localhost> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Sun_May__9_08:06:00_2004_162)--" Content-Transfer-Encoding: 7bit cc: freebsd-current@freebsd.org Subject: Re: cardbus trouble X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 May 2004 15:35:22 -0000 X-List-Received-Date: Sun, 09 May 2004 15:35:22 -0000 ----Next_Part(Sun_May__9_08:06:00_2004_162)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit In message: <409E0D5A.19164.559D04D@localhost> "Dylan Wylie" writes: : Yes, it used to work perfectly. I was afraid that you were going to say that :-(. : The dmesg with both cardbus and cbb debuging enabled is included below. : Again, it shows insertion of the cardbus card which fails, followed by the pccard : card, which succeedes. : I also don't remember any 'lazy allocation' with the working builds. The lazy allocation is fine, I'm pretty sure. Let's look at things in more detail, and I think the debug shows where we go off the rails: : pcib0: port 0xcf8-0xcff on acpi0 host bridge. : pci0: on pcib0 pci bus 0. : agp0: mem 0xf8000000-0xfbffffff at device 0.0 on pci0 : agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xf8000000 agp0 at pci0.0.0. : pcib1: at device 1.0 on pci0 : pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - : AE_NOT_FOUND : pci1: on pcib1 : pci1: at device 0.0 (no driver attached) VGA at pci1.0.0. : cbb0: at device 10.0 on pci0 cbb is at pci0.10.0. : cbb0: Secondary bus is 0 : cbb0: Secondary bus set to 1 subbus 2 DANGER WILL ROBINSON. Secondary bus is now being set to 1. Before I think we kludged it to 2 always, but I might be mistaken. However, this is clearly the problem reguardless of what we used to do. : cardbus0: at device 0.0 (no driver attached) Hmmm, odd that it is now being probed just like the device at pci1.0.0, don't you think? So, give the following patch a spin. Try 3 and 4 if this fails. Clearly this is a bogus patch from a generic point of view, but it is good for testing. Warner ----Next_Part(Sun_May__9_08:06:00_2004_162)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=kludge-o-matic Index: pccbb.c =================================================================== RCS file: /cache/ncvs/src/sys/dev/pccbb/pccbb.c,v retrieving revision 1.110 diff -u -r1.110 pccbb.c --- pccbb.c 4 May 2004 02:25:00 -0000 1.110 +++ pccbb.c 9 May 2004 14:01:37 -0000 @@ -683,7 +683,7 @@ static int cbb_attach(device_t brdev) { - static int curr_bus_number = 1; /* XXX EVILE BAD (see below) */ + static int curr_bus_number = 2; /* XXX EVILE BAD (see below) */ struct cbb_softc *sc = (struct cbb_softc *)device_get_softc(brdev); int rid, bus, pribus; device_t parent; ----Next_Part(Sun_May__9_08:06:00_2004_162)----