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