From owner-freebsd-stable@FreeBSD.ORG Tue Apr 26 03:06:20 2005 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1E08216A4CE for ; Tue, 26 Apr 2005 03:06:20 +0000 (GMT) Received: from mail.lovett.com (foo.lovett.com [67.134.38.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE2F843D49 for ; Tue, 26 Apr 2005 03:06:19 +0000 (GMT) (envelope-from ade@FreeBSD.org) Received: from hellfire.lovett.com ([67.134.38.149]) by mail.lovett.com with esmtpa (Exim 4.50 (FreeBSD)) id 1DQGOx-0001ev-Ll; Mon, 25 Apr 2005 20:06:19 -0700 Message-ID: <426DB02B.4050807@FreeBSD.org> Date: Mon, 25 Apr 2005 20:06:19 -0700 From: Ade Lovett User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Guy Helmer References: <426D481D.7080502@palisadesys.com> In-Reply-To: <426D481D.7080502@palisadesys.com> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 5.3p6-5.4RC3, Supermicro X6DHR-8G, Dual 3.6GHzXeons,Adaptec aic7902 SCSI interface doesn't work in UP kernel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Apr 2005 03:06:20 -0000 Guy Helmer wrote: Reducing the problem to its relevant parts: > SuperMicro [...] Seagate [...] > on-board aic7902 and, from your dmesg output: da0: Fixed Direct Access SCSI-3 device da0: 320.000MB/s transfers [...] Supermicro boards and Seagates generally hate each other. Supermicro blames Seagate, Seagate blames Supermicro. Even under normal operation, you'll see spurious SCSI errors, both at bootup, and under load, exacerbated if you put more than one Seagate drive on the same chain, or run them at their native U320 speeds. To make matters worse, your ST373207LC model is, even by Seagate standards, a piece of unmitigated crap. At an absolute minimum, have the existing drive swapped out for an ST373453LC model, making VERY certain that the firmware is rev 0006 -- prior revisions WILL corrupt your data, set fire to your cat, and otherwise ruin your entire life -- and that's before they've actually spun up. A second option is to change the drive out for one from a vendor that actually cares -- ok, maybe only *just* cares, but cares nonetheless. Hitachi drives work fine, and certainly seem to be in the same ballpark for overall reliability. Likewise, swapping out the motherboard for a non-Supermicro unit may be an option, though be wary of anything with onboard Broadcom gigabit ethernet if you plan on doing continuous high network I/O -- Seagate drives *appear* to have considerably fewer problems when connected to non-Adaptec hardware in general, and the onboard Supermicro variant in particular. If you're stuck with the hardware you have (modulo this particular 73GB drive model, as mentioned above), pick up another SCSI controller and use that, not forgetting to disable the onboard controllers. At an absolute pinch, head in to the adaptec bios and lock down the drive to U160 speeds -- that *may* help in a few edge cases. Someone (I forget who, sorry) recently suggested a considerable portition of the Supermicro vs Seagate mess was down to a weird interaction between the bios and the occasional SMM interrupt -- a hackaround to run at boot was even suggested -- check the archives for details, though unfortunately it did not appear to fix the issues I was seeing on boxes here. You may have better luck. -aDe