From owner-freebsd-sparc64@FreeBSD.ORG Fri Aug 15 21:32:01 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 C5EF537B401 for ; Fri, 15 Aug 2003 21:32:01 -0700 (PDT) Received: from mail.seekingfire.com (coyote.seekingfire.com [24.72.10.212]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF27C43FBD for ; Fri, 15 Aug 2003 21:32:00 -0700 (PDT) (envelope-from tillman@seekingfire.com) Received: from blues.seekingfire.prv (blues.seekingfire.prv [192.168.23.211]) by mail.seekingfire.com (Postfix) with ESMTP id 6464246 for ; Fri, 15 Aug 2003 22:32:00 -0600 (CST) Received: (from tillman@localhost) by blues.seekingfire.prv (8.11.6/8.11.6) id h7G4VxM14169 for sparc64@freebsd.org; Fri, 15 Aug 2003 22:31:59 -0600 Date: Fri, 15 Aug 2003 22:31:59 -0600 From: Tillman To: sparc64@freebsd.org Message-ID: <20030815223159.F22214@seekingfire.com> References: <20030815121010.I97608@beagle.fokus.fraunhofer.de> <20030815135034.GA701@crow.dom2ip.de> <20030815080055.O22214@seekingfire.com> <20030815143404.GB701@crow.dom2ip.de> <20030815110221.T22214@seekingfire.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030815110221.T22214@seekingfire.com>; from tillman@seekingfire.com on Fri, Aug 15, 2003 at 11:02:21AM -0600 X-Urban-Legend: There is lots of hidden information in headers Subject: Re: Sparc slowdown - problem identified... 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: Sat, 16 Aug 2003 04:32:02 -0000 On Fri, Aug 15, 2003 at 11:02:21AM -0600, Tillman wrote: > On Fri, Aug 15, 2003 at 04:34:04PM +0200, Thomas Moestl wrote: > > On Fri, 2003/08/15 at 08:00:56 -0600, Tillman wrote: > > > Is OFW_NEWPCI where -CURRENT on Sparc is heading? I.e., if I enable it > > > now and go through any needed reconfiguration will I be saving myself > > > time in the future? > > > > Yes. > > Great, thanks for the info. I'll compile a new kernel with OFW_NEWPCI > and try installing it over the weekend (compiling isn't fast at the > moment ;-) ). I can boot on the new kernel, but my hme interfaces don't seem to work (I have 1 onboard and a 4-port card). I see this in dmesg: hme1: error signaled, status=0x20001 (etc) hme1: error signaled, status=0x30001eived, 100% packet loss hme1: too may errors; not reporting any more Here's my ifconfig: hme0: flags=8843 mtu 1500 inet 192.168.23.30 netmask 0xffffff00 broadcast 192.168.23.255 ether 08:00:20:c6:7f:c7 media: Ethernet autoselect (none) status: no carrier hme1: flags=8843 mtu 1500 inet 24.72.10.209 netmask 0xffffff00 broadcast 24.72.10.255 ether 08:00:20:c6:7f:c7 media: Ethernet autoselect (100baseTX ) status: active hme2: flags=8802 mtu 1500 ether 08:00:20:c6:7f:c7 media: Ethernet autoselect hme3: flags=8802 mtu 1500 ether 08:00:20:c6:7f:c7 media: Ethernet autoselect hme4: flags=8802 mtu 1500 ether 08:00:20:c6:7f:c7 media: Ethernet autoselect Some of the dmesg that looks relevent: pcib0: on nexus0 pcib0: Sabre, impl 0, version 0, ign 0x7c0, bus A DVMA map: 0xc0000000 to 0xc3ffffff pci0: on pcib0 pcib1: at device 1.1 on pci0 pci1: on pcib1 and: hme0: mem 0xe0000000-0xe0007fff at device 1.1 on pci1 hme0: Ethernet address: 08:00:20:c6:7f:c7 miibus0: on hme0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto and: hme1: mem 0x2800000-0x2807fff at device 0.1 on pci3 pcib3: slot 0 INTB is routed to irq 25 hme1: Ethernet address: 08:00:20:c6:7f:c7 miibus1: on hme1 ukphy0: on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto and: arp: 192.168.23.3 is on hme0 but got reply from 00:10:4b:69:2a:86 on hme1 arp: 192.168.23.3 is on hme0 but got reply from 00:10:4b:69:2a:86 on hme1 arp: 192.168.23.3 is on hme0 but got reply from 00:10:4b:69:2a:86 on hme1 Any ideas? Is it possible that the hme interfaces are numbered in a different order with the new kernel, similar to how the disk devices could have been renumbered (but that wasn't an issue for me)? I've reverted to the kernel.old in the meantime. -T