From owner-freebsd-current@FreeBSD.ORG Thu Jun 12 16:23:53 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 F341C37B401; Thu, 12 Jun 2003 16:23:52 -0700 (PDT) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 385F843FBD; Thu, 12 Jun 2003 16:23:51 -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 h5CNNXHq007264 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Fri, 13 Jun 2003 01:23:36 +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 h5CNNVIf076845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 13 Jun 2003 01:23:32 +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 h5CNNV9F039687; Fri, 13 Jun 2003 01:23:31 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.9/8.12.9/Submit) id h5CNNUoW039686; Fri, 13 Jun 2003 01:23:30 +0200 (CEST) Date: Fri, 13 Jun 2003 01:23:30 +0200 From: Bernd Walter To: ticso@cicely.de, "M. Warner Losh" , ticso@cicely12.cicely.de, freebsd-current@freebsd.org, freebsd-sparc64@freebsd.org Message-ID: <20030612232329.GK26807@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> <20030610231649.GD26807@cicely12.cicely.de> <20030611133353.GA634@crow.dom2ip.de> <20030612225632.GK748@funkthat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030612225632.GK748@funkthat.com> X-Operating-System: FreeBSD cicely12.cicely.de 5.1-RELEASE alpha User-Agent: Mutt/1.5.4i Subject: Re: pci probing "fixed" (was 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: Thu, 12 Jun 2003 23:23:53 -0000 On Thu, Jun 12, 2003 at 03:56:32PM -0700, John-Mark Gurney wrote: > Well, I implemented PCI probing as per the UltraSparc IIi user's manual, > and now, I get quite a bit more than I bargined for: > bash-2.05b$ pciconf -l | wc > 38 228 3106 > > The complete pciconf -l -v is at: > http://people.freebsd.org/~jmg/pciconf-lv.sparc64 > > Now, I seem to be getting duplicates on some functions, and then of > course, I am now seeing the firewire part of the SME2300BGA that doesn't > have a phys attached to it. (The driver does attach to the firewire > part, but fails trying to talk to the phys.) Maybe they are not really disabled. > This also required updating the pci_read_device to ignore a all zero > return value for PCIR_DEVVENDOR, and not probe higher functions in > that case. If I tried to probe higher functions (such as 0.0.2), the > system would hang. The only defined invalid vendor number is 0xffff. The pcispace read functions should return all bits set in case a device does not exist. > A dmesg output of the boot is at: > http://people.freebsd.org/~jmg/dmesg.sparc64 > > I don't include the dmesg that shows me attaching the firewire driver. > > I have posted the patch to produce this at: > http://people.freebsd.org/~jmg/sparc.patch If the sparc64 part is the right way to do has to be commented by the sparc64 guys. Your patch still probes for additional functions without checking if the device really is a multifunction device. There are devices out there that react on every function although they are single function. Can you check this together with Warners patch? Maybe we can also keep the original code, as the problem was not not of machine independent nature as I originaly tought. > Warning, this contains much debugging data, and probes for PCI devices > that previously didn't get probed for. > > P.S. Sorry for the duplicate post to -sparc64. I forgot that some of > the -current crowd is interested in this work too. If it changes MI part - yes. -- B.Walter BWCT http://www.bwct.de ticso@bwct.de info@bwct.de