From owner-freebsd-sparc Thu Dec 5 4:14:27 2002 Delivered-To: freebsd-sparc@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 061FB37B401 for ; Thu, 5 Dec 2002 04:14:25 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 4964D43ECD for ; Thu, 5 Dec 2002 04:14:23 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 13984 invoked by uid 0); 5 Dec 2002 12:14:20 -0000 Received: from p508e73a3.dip.t-dialin.net (HELO forge.local) (80.142.115.163) by mail.gmx.net (mp009-rz3) with SMTP; 5 Dec 2002 12:14:20 -0000 Received: from tmm by forge.local with local (Exim 4.10 #1) id 18Jutq-0000Tt-00; Thu, 05 Dec 2002 13:14:38 +0100 Date: Thu, 5 Dec 2002 13:14:37 +0100 From: Thomas Moestl To: Oliver Blasnik Cc: Jake Burkholder , freebsd-sparc@FreeBSD.ORG Subject: Re: pci quad hme ethernet card Message-ID: <20021205121437.GA305@crow.dom2ip.de> Mail-Followup-To: Oliver Blasnik , Jake Burkholder , freebsd-sparc@FreeBSD.ORG References: <20021203124613.L35729@locore.ca> <010d01c29b74$65d3b4c0$2100a8c0@xpath1000> <20021204140045.S35729@locore.ca> <005b01c29c42$93cc75a0$2100a8c0@xpath1000> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005b01c29c42$93cc75a0$2100a8c0@xpath1000> User-Agent: Mutt/1.4i Sender: owner-freebsd-sparc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 2002/12/05 at 10:42:06 +0100, Oliver Blasnik wrote: > [PCI QFE] > > > > and let us know if it works for you. > > > Hmm. Yes its a similar patch with some other changes. The netra is a > > very quirky box, so it may be that additional hacks are required. Please > > send dmesg output if you have any problems. > > Still doesn't work. As you see in the dmsg, each of the hme on this qfe > gets the same irq assigned (which is "1" now instead "0", because of the > codechange "+1"?). But thats it, looks as no routing through the bridge > ("hme0: device timeout" after configure). Can you please post the output of "ofwdump -ap" (or "prtconf -vp" on Solaris) on this machine? > Because of this I think the atapci0 won't work, too, but it's > nothing connected to it so theres no chance to check it out. Taking > a deeper look, atapci0 gets irq 0 assigned after the last changes... A PCI interrupt number of 0 is legal on FreeBSD/sparc64. In this case, it must come from a firmware interrupt map, which could mean that it is not completely off. There are Netra t1 models on which the onboard ATA controller is confirmed to work, the interrupt assignments are different there though. > [PCI func>0] > > I've had conflicting reports as to wether this actually works. We've > > tried a hack in the MD code to deal with the missing function 0, but > > appparently there are still phy problems that stop the interface from > > working. > > Did it? It does work for me, thats interesting. The only thing I > was wondering about was that double-phy on hme0, but its because there is > an onboard-rj45 connector avail on the _mainboard_, and this one isn't the > one you connect the cables to ;) Hmmm, that is news to me; on the Netra that this was tried before, the second hme could not be persuaded to work. I'll sync up the MD patch Jake was talking about and post it later. > I'd recommend to switch pci bus detection / device assignment to another > scheme on sparc systems - as other ppl on the list also don't get it that > the "real hme0" gets assigned to "hme4" like in my case after adding a > additional card. It breaks connectivity and possibly hardwired rules. This is not likely to happen before 5.0. An OpenFirmware PCI bus driver, which I have started to work on, might solve this in the future, depending on how Solaris determines the device order. However, even if I finish this work in time for 5.0 and get permission to commit it from the release engineering team, it would be off by default until it has received much more testing. Fiddling with the probe order now would just lead to ugly hacks which would bite us later. Since the system setup is quite different from Solaris anyway, this should not hurt too much, apart from the possible confusion resulting from the labeling on the case. I'll see to get this documented somewhere. - 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-sparc" in the body of the message