From owner-freebsd-scsi@FreeBSD.ORG Wed Sep 29 11:13:08 2004 Return-Path: Delivered-To: freebsd-scsi@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BD3716A4CE for ; Wed, 29 Sep 2004 11:13:08 +0000 (GMT) Received: from email.eurowings.com (email.eurowings.com [193.96.182.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25F1743D53 for ; Wed, 29 Sep 2004 11:13:08 +0000 (GMT) (envelope-from h.kipp@eurowings.com) Received: from localhost (localhost [127.0.0.1]) by email.eurowings.com (Postfix) with ESMTP id 0F71614E240; Wed, 29 Sep 2004 13:13:07 +0200 (CEST) Received: from eurowings.com (unknown [10.100.24.81]) by email.eurowings.com (Postfix) with ESMTP id 0AD9414E1A9; Wed, 29 Sep 2004 13:13:05 +0200 (CEST) Message-ID: <415A98C0.2030005@eurowings.com> Date: Wed, 29 Sep 2004 13:13:04 +0200 From: Holger Kipp User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.6) Gecko/20040602 X-Accept-Language: de, en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at eurowings.com Subject: Interesting SCSI-Problem with Quantum Atlas10K3 (from freebsd-stable) X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 11:13:08 -0000 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 in this case are also welcome! Best regards, Holger Kipp