Interesting SCSI-Problem with Quantum Atlas10K3 (from
h.kipp at eurowings.com
Wed Sep 29 04:13:08 PDT 2004
maybe someone could help me a bit with this.
OS is FreeBSD 4.10 , .. , 4.2
Questions at the end.
3 SCSI-Harddisks (Quantum ATLAS10K3) as Raid5 (vinum)
produce the following errors on current hardware
(ie LSI mtp-controller dual channel U320) - it takes
a few file operations, though:
mpt0: bullet missed in timeout
mpt1: bullet missed in timeout
(offending disks are located at mpt)
I/O-Performance is ok, but a simple 'find' that is
running through all directories will bring the
system to a near-halt after half a minute or so.
Copying a 90MB file on the vinum-raid works like a
charm and does not trigger this behaviour.
I tried reducing / disabling tagged queueing, but
that did not help
Even added an entry in cam_xpt.c with
/*quirks*/0, /*mintags*/24, /*maxtags*/32
which seemed to worsen the effect.
According to the datasheet I just found. These disks
have a queue depth of 64.
Mounting the drives (or the vinum-drive) read-only
gives no errors, and rebuilding the array does not
give an error either.
So it looks like I need many consecutive read- and write-
operations to trigger this behaviour (like with find,
changing access times of directories).
I have not found any possibility of updating the firmware
either, so any clue is welcome.
Disks located at mpt0 do not show any problems, even with
I had similar problems with the same disks on older hardware
(Asus P2B-S) with FreeBSD 4-2, then upgraded to 4.10-STABLE
and changed all the hardware except for the harddisks.
- Anyone else who had these problems?
- How can I find out on what drive the command queue grows
indefinitely (till the system halts completely), if this
is at all the case?
- can I tune FreeBSD in this respect?
- what are the exact meanings of mintags and maxtags and should
I try something like /*quirks*/0, /*mintags*/2, /*maxtags*/64 ?
Hints on how to use camdebug in this case are also welcome!
More information about the freebsd-scsi