From owner-freebsd-amd64@FreeBSD.ORG Thu Jan 25 13:06:57 2007 Return-Path: X-Original-To: freebsd-amd64@freebsd.org Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id BD14C16A410 for ; Thu, 25 Jan 2007 13:06:57 +0000 (UTC) (envelope-from groot@kde.org) Received: from smeltpunt.science.ru.nl (smeltpunt.science.ru.nl [131.174.16.145]) by mx1.freebsd.org (Postfix) with ESMTP id 4743813C45A for ; Thu, 25 Jan 2007 13:06:57 +0000 (UTC) (envelope-from groot@kde.org) Received: from n142198.science.ru.nl [131.174.142.198] (helo=n142198.science.ru.nl) by smeltpunt.science.ru.nl (8.13.7/5.11) with ESMTP id l0PD6s2E027422 for ; Thu, 25 Jan 2007 14:06:55 +0100 (MET) From: Adriaan de Groot Organization: KDE e.V. To: freebsd-amd64@freebsd.org Date: Thu, 25 Jan 2007 14:09:26 +0100 User-Agent: KMail/1.9.4 References: <200701232121.58985.groot@kde.org> <20070125034300.GA65650@voi.aagh.net> In-Reply-To: <20070125034300.GA65650@voi.aagh.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200701251409.26276.groot@kde.org> X-Spam-Score: -1.3 () ALL_TRUSTED,BAYES_50 X-Scanned-By: MIMEDefang 2.56 on 131.174.16.145 Subject: Re: State of X4200 M2 (ok) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jan 2007 13:06:57 -0000 On Thursday 25 January 2007 04:43, Thomas Hurst wrote: > > 1000baseSX-FDX, 1000baseT, 1000baseT-FDX, auto > > nve0: Ethernet address: 04:4b:80:80:80:03 > > > > The machine hangs at boot for several seconds after nve0 before miibus0; > > I do not see this in other nForce4 based machines I've got. > > Urgh, so 2 of the 4 NIC's on the M2's are nVidia crap? That's quite a > step back from the 4 e1000's in earlier models :( The nve seem to work pretty well, but I have not loaded them that heavily. I have 40G of data to schlep later today, we'll see how it likes that. > > I don't get any /dev/mpt* either (but I > > guess that's more a comment for freebsd-hardware). The device isn't > > recognized by any of the LSI management tools (megamgr, megacli, megarc) > > either -- but then I'm not sure there's anything to manage there yet. > > There's some basic hardware RAID: > mpt0: Capabilities: ( RAID-0 RAID-1 ) > I doubt it's really worth using. With that kind of capabilities, I can see where GEOM has an adge (the hotswap doesn't work either, inserting a disk just gets cam events 0x16 and 0x12 again and no /dev/da* is created for the disk). > > The machine hasn't had much of a stress test yet. It gets through > > buildworlds and can shuffle data around and will write on standard > > SATA laptop drives too, if you can be bothered to stick them in the > > drive bays. > > Really? I wasn't aware these LSI's, nor mpt(4) supported SATA (despite > what the names say). Not very useful anyway, SAS drives are a far > better match for server workloads (i.e. they actually perform well and > are designed to run 24/7). > > Do they get exposed via ata(4) or appear as SCSI devices over CAM? Yes, really. They show up as SCSI over cam and are reasonable for sequential read (at about 30MB/s) and awful for random read; I wouldn't vouch for their longevity, though. The laptop drive *does* seem to go to sleep when not in use automatically, as I notice a second or two of lag when accessing it after an idle period. Here's one: da1: Fixed Direct Access SCSI-5 device da1: 300.000MB/s transfers, Tagged Queueing Enabled da1: 76319MB (156301488 512 byte sectors: 255H 63S/T 9729C) Dollar a gigabyte if your data is cheap :) Getting a *tray* for the disk is another issue. Anyway, that experiment is done; I'll be playing with various eSATA solutions next. That's off-topic on this list. -- Adriaan de Groot KDE Quality Team http://www.englishbreakfastnetwork.org/ SQO-OSS Researcher http://www.sqo-oss.eu/