SETFEATURES SET TRANSFER MODE taskqueue timeout - completing request directly

Rich Wales richw at
Mon Oct 16 00:06:00 PDT 2006

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 at

More information about the freebsd-hardware mailing list