From owner-freebsd-sparc64@FreeBSD.ORG Mon Sep 21 14:35:06 2009 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A9CF01065698 for ; Mon, 21 Sep 2009 14:35:06 +0000 (UTC) (envelope-from marius@alchemy.franken.de) Received: from alchemy.franken.de (alchemy.franken.de [194.94.249.214]) by mx1.freebsd.org (Postfix) with ESMTP id 3B4338FC0C for ; Mon, 21 Sep 2009 14:35:05 +0000 (UTC) Received: from alchemy.franken.de (localhost [127.0.0.1]) by alchemy.franken.de (8.14.3/8.14.3/ALCHEMY.FRANKEN.DE) with ESMTP id n8LEZ4DH005877; Mon, 21 Sep 2009 16:35:05 +0200 (CEST) (envelope-from marius@alchemy.franken.de) Received: (from marius@localhost) by alchemy.franken.de (8.14.3/8.14.3/Submit) id n8LEZ4rJ005876; Mon, 21 Sep 2009 16:35:04 +0200 (CEST) (envelope-from marius) Date: Mon, 21 Sep 2009 16:35:04 +0200 From: Marius Strobl To: Gavin Atkinson Message-ID: <20090921143504.GD73777@alchemy.franken.de> References: <3979a4b0909170200x754ea8c5l495e300b2a7a5113@mail.gmail.com> <20090917224556.GA41908@alchemy.franken.de> <3979a4b0909172329q3a113942xfcd71394a98fee19@mail.gmail.com> <20090918131416.GQ57060@alchemy.franken.de> <20090921150632.U4106@ury.york.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090921150632.U4106@ury.york.ac.uk> User-Agent: Mutt/1.4.2.3i Cc: freebsd-sparc64@freebsd.org Subject: Re: Is it posible to run FreeBSD/sparc64 on SunFire V215? X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Sep 2009 14:35:06 -0000 On Mon, Sep 21, 2009 at 03:09:44PM +0100, Gavin Atkinson wrote: > On Fri, 18 Sep 2009, Marius Strobl wrote: > >On Fri, Sep 18, 2009 at 02:23:49PM +0400, KOT MATPOCKuH wrote: > >>PS. Why net boot is too slow? Loading process occupies ~15 minutes > >>from start to last message. > > > >I don't know and it works fine here, you'd need to > >analyze the network traffic in order to get an idea > >which side is the culprit. IIRC I've seen similar > >effects when not using the full speed of the network > >interface of a sun4u machine, i.e. for example a > >Gigabit Ethernet interface with a Fast Ethernet > >switch, given that the loader relies on the firmware > >to provide support for the NIC there isn't much that > >can be done about that. > > Last time I looked at this, it looked like the problem was that for every > block transferred over the wire (which I think are 4k in size, but I may > be misremembering) the loader was calling into OpenFirmware to open the > network card, read the block, and close the network card. Each open/close > pair took enough time to be noticeable. I never had a chance to sit down > and fix this. > The behaviour you describe was present between r177108 and r182919 (and before r60506), since r182919 the loader just leaves the network interface instance opened forever again for sparc64 so this shouldn't be the reason for what KOT MATPOCKuH is seeing. Of course leaving the NIC instance opened isn't the right to do either and in fact likely is part of the problem which triggeres the panic he is seeing, I don't see an easy way to properly fix the loader/libstand to not do the open-close-dance for every access though. Marius