Date: Mon, 16 Oct 2006 00:05:52 -0700 From: Rich Wales <richw@richw.org> To: freebsd-hardware@freebsd.org Subject: Re: SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly Message-ID: <20061016070553.4801A3C36B@whodunit.richw.org> In-Reply-To: <453198AF.90604@donnex.net> References: <453198AF.90604@donnex.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061016070553.4801A3C36B>