From owner-freebsd-sparc64@FreeBSD.ORG Wed Jun 11 06:33:45 2003 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55C0D37B401 for ; Wed, 11 Jun 2003 06:33:45 -0700 (PDT) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 6596A43FD7 for ; Wed, 11 Jun 2003 06:33:43 -0700 (PDT) (envelope-from tmoestl@gmx.net) Received: (qmail 11025 invoked by uid 65534); 11 Jun 2003 13:33:41 -0000 Received: from p508E7CCE.dip.t-dialin.net (EHLO galatea.local) (80.142.124.206) by mail.gmx.net (mp008) with SMTP; 11 Jun 2003 15:33:41 +0200 Received: from tmm by galatea.local with local (Exim 4.20 #1) id 19Q5je-0004Hq-Bo; Wed, 11 Jun 2003 15:33:54 +0200 Date: Wed, 11 Jun 2003 15:33:54 +0200 From: Thomas Moestl To: ticso@cicely.de Message-ID: <20030611133353.GA634@crow.dom2ip.de> Mail-Followup-To: ticso@cicely.de, "M. Warner Losh" , ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org 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> <20030610231649.GD26807@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030610231649.GD26807@cicely12.cicely.de> User-Agent: Mutt/1.4.1i Sender: Thomas Moestl cc: ticso@cicely12.cicely.de cc: freebsd-current@freebsd.org cc: freebsd-sparc64@freebsd.org cc: "M. Warner Losh" Subject: Re: PCI bus numbering and orphaned devices X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jun 2003 13:33:45 -0000 On Wed, 2003/06/11 at 01:16:50 +0200, Bernd Walter wrote: > 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. I don't have the standard handy, but from my reading of the Shanley book, it seems that for the vendor ID register, a host bridge is required to return 0xffff if no device is present. Loading this task off to the software is a bit annoying. There is no mention of other registers, so reading them in the probe might theoretically cause problems even on host bridges that handle the vendor ID register correctly. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C