Interesting SCSI-Problem with Quantum Atlas10K3

[Holger Kipp]

Hello,

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
buildworld.

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 are also welcome!

Best regards,
Holger Kipp