From owner-freebsd-hardware@FreeBSD.ORG Mon Oct 16 07:06:00 2006 Return-Path: X-Original-To: freebsd-hardware@freebsd.org Delivered-To: freebsd-hardware@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3E3216A40F for ; Mon, 16 Oct 2006 07:05:59 +0000 (UTC) (envelope-from richw@richw.org) Received: from smtp3.stanford.edu (smtp3.Stanford.EDU [171.67.20.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id D838D43D5E for ; Mon, 16 Oct 2006 07:05:57 +0000 (GMT) (envelope-from richw@richw.org) Received: from smtp3.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id F35634BFD5 for ; Mon, 16 Oct 2006 00:05:56 -0700 (PDT) Received: from whodunit.richw.org (SW-90-716-276-1.Stanford.EDU [171.66.155.243]) by smtp3.stanford.edu (Postfix) with ESMTP id C63E74BDC2 for ; Mon, 16 Oct 2006 00:05:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by whodunit.richw.org (Postfix) with ESMTP id 834123C36D; Mon, 16 Oct 2006 00:05:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at richw.org Received: from whodunit.richw.org ([127.0.0.1]) by localhost (whodunit.richw.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mfxs4ktW8w3q; Mon, 16 Oct 2006 00:05:53 -0700 (PDT) Received: from [172.29.0.21] (evilempire.richw.org [172.29.0.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "evilempire.richw.org", Issuer "richw.org" (verified OK)) (Authenticated sender: richw) by whodunit.richw.org (Postfix) with ESMTP id 4801A3C36B; Mon, 16 Oct 2006 00:05:53 -0700 (PDT) Date: Mon, 16 Oct 2006 00:05:52 -0700 From: Rich Wales User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: freebsd-hardware@freebsd.org References: <453198AF.90604@donnex.net> In-Reply-To: <453198AF.90604@donnex.net> X-Enigmail-Version: 0.94.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <20061016070553.4801A3C36B@whodunit.richw.org> Subject: Re: SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly X-BeenThere: freebsd-hardware@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion of FreeBSD hardware List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Oct 2006 07:06:00 -0000 Daniel Johansson wrote: > Hello, I recently bought a Promise SATA300 TX4 SATA controller and two > Seagate 320 GB drives. I haven't used the disks very much until today > when I moved a bunch of backups to one of the disks and noticed these > messages in my dmesg. . . . > > Is this something I should worry about? Definitely yes. IMO, you need to do something about it ASAP. > Anything wrong with my disks or is it the SATA controller? See some recent discussion threads on this list with "SATA" in the subject line. The problem seems to be caused by a combination of iffy PCI implementations in some motherboards and aggressive, close-to-the- edge behaviour in some Promise chip designs. Your disks are probably OK -- though you should certainly set up "smartd" to monitor them in any case. Your first suspect should probably be your motherboard. If you have any BIOS setup options relating to the PCI bus -- controlling things like latency time, wait states, or burst mode -- you might want to try less aggressive settings and see if this helps. In an experimental system of mine (using an old "Slot A" Athlon motherboard), I was able to make problems similar to yours go away by disabling PCI master burst mode; this slowed down disk I/O significantly, but at least the system became rock-solid stable after I made that change. Another thing to do would be to ensure that your Promise card is not sharing an interrupt line with any other device in your system. Look at the output of "dmesg", checking particularly for device probing and the IRQ assignments. If your Promise card doesn't have its very own, dedicated IRQ, you might need to put it in a different PCI slot, and/or go into your BIOS setup and free up some IRQ's by disabling some things that you aren't using (such as serial or parallel ports, or on-board sound card functionality if this is a server rather than a desktop). What kind of CPU and motherboard are you using? What sorts of setup options related to PCI performance can you find in your BIOS? What other devices are you using in your system? > Bug in freebsd driver maybe? It doesn't seem at all clear whether this problem can be solved in the driver or not. People have been talking about it sporadically, for a long time, in Linux and NetBSD discussion lists and groups, as well as the FreeBSD lists, but so far no one seems to have come up with any ideas for improving their drivers to help the issue any. > Is it safe to continue to use the drives, everything seems to be > working fine. I would say no, not until/unless you can make the problem go away 100%. In some cases, I've seen timeout warnings like the ones you reported progress to actual I/O failures if the system is heavily enough loaded. Even if you don't get any failures, you'll have significantly degraded system performance when timeouts occur. Rich Wales Palo Alto, CA, USA richw@richw.org http://www.richw.org