From owner-freebsd-current@FreeBSD.ORG Tue Jun 10 16:17:04 2003 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 AEF9237B401; Tue, 10 Jun 2003 16:17:04 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8511843F93; Tue, 10 Jun 2003 16:17:03 -0700 (PDT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [IPv6:3ffe:400:8d0:301:200:92ff:fe9b:20e7]) by srv1.cosmo-project.de (8.12.9/8.12.9) with ESMTP id h5ANGrTh063403 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Wed, 11 Jun 2003 01:16:57 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.9/8.12.9) with ESMTP id h5ANGpOs064014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 11 Jun 2003 01:16:52 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.9/8.12.9) with ESMTP id h5ANGp9F032424; Wed, 11 Jun 2003 01:16:51 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h5ANGoHB032423; Wed, 11 Jun 2003 01:16:50 +0200 (CEST) Date: Wed, 11 Jun 2003 01:16:50 +0200 From: Bernd Walter To: "M. Warner Losh" , ticso@cicely.de, ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030610231649.GD26807@cicely12.cicely.de> References: <20030609.224621.71095461.imp@bsdimp.com> <20030610115615.GB10527@cicely12.cicely.de> <20030610121249.GE10527@cicely12.cicely.de> <20030610.082730.102566465.imp@bsdimp.com> <20030610223436.GC37257@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610223436.GC37257@funkthat.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-RELEASE alpha User-Agent: Mutt/1.5.4i Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jun 2003 23:17:05 -0000 On Tue, Jun 10, 2003 at 03:34:36PM -0700, John-Mark Gurney wrote: > M. Warner Losh wrote this message on Tue, Jun 10, 2003 at 08:27 -0600: > > : > > hdrtype = REG(PCIR_HEADERTYPE, 1); > > : > This needs to be tested on that given hardware. > > : > I don't know if REG will work as expected because it asks function 0, > > : > which is disabled. > > : > > : I've reread John-Mark's last mail about the readable registers. > > : So - yes it should work. > > > > That's what inspired me. Also, I'd expected that we'd need some kind > > of tweaking to make it actually compile and be neat. > > Ok, attached is a patched I tried, but sad to say, this doesn't work > out to well. I added a printf before and after the REG statement, and > a boot with the kernel give this output: > found-> vendor=0x108e, dev=0x5000, revid=0x13 > bus=0, slot=1, func=1 > class=06-04-00, hdrtype=0x01, mfdev=1 > cmdreg=0x0147, statreg=0x02a0, cachelnsz=16 (dwords) > lattimer=0x50 (2400 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) > about to read HEADERTYPE > panic: trap: data access error > cpuid = 0; > Uptime: 1s > panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 > cpuid = 0; > Uptime: 1s > panic: Assertion mtx_unowned(m) failed at ../../../kern/kern_mutex.c:956 > cpuid = 0; > Uptime: 1s > > the last three lines repeate for a while, but this is because of: > psycho_read_config(...) > [...] > /* > * The psycho bridge does not tolerate accesses to unconfigured PCI > * devices' or function's config space, so look up the device in the > * firmware device tree first, and if it is not present, return a value > * that will make the detection code think that there is no device here. > * This is ugly... > */ > if (reg == 0 && ofw_pci_find_node(bus, slot, func) == 0) > return (0xffffffff); > > Which obviously will fail if reg != 0 which we try to do when reading > the PCIR_HEADERTYPE.. > > So, the question is, does other arch's do something nasty like this > too? Should I change the check to just do ofw_pci_find_node? Is this > why pciconf -r is returning 0xffffffff when reading the ebus and firewire > parts of the SME2300BGA? Simply because it isn't in the ofw tree? Possible - in fact I was very surprised that a disabled device was not readable on some registers. We have a similar situation on alpha, where we get traps for reading non available devices. It's handled in that we tell the system to expect traps before accessing registers. This is done by reading with the badaddr function, which sets a flag for our trap handler so it can continue in case the device doesn't exist. badaddr() returns a flags which tells if reading was successfull. > I don't have any data sheets or the PCI spec, so making heads or tails > of this is going be hard. It's OK to get errors when reading locations that aren't available. Some chipsets nerver trap, others only trap for type2 access (behind Bridges) and some always trap. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de