From owner-freebsd-stable@FreeBSD.ORG Tue Sep 28 13:47:12 2004 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B837116A4CE for ; Tue, 28 Sep 2004 13:47:12 +0000 (GMT) Received: from email.eurowings.com (email.eurowings.com [193.96.182.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DE2043D41 for ; Tue, 28 Sep 2004 13:47:12 +0000 (GMT) (envelope-from h.kipp@eurowings.com) Received: from localhost (localhost [127.0.0.1]) by email.eurowings.com (Postfix) with ESMTP id 8B8E614E15B; Tue, 28 Sep 2004 15:47:10 +0200 (CEST) Received: from eurowings.com (unknown [10.100.24.81]) by email.eurowings.com (Postfix) with ESMTP id 86AAE14E1C5; Tue, 28 Sep 2004 15:47:08 +0200 (CEST) Message-ID: <41596B5B.1000102@eurowings.com> Date: Tue, 28 Sep 2004 15:47:07 +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-stable@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 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: hk@alogis.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Sep 2004 13:47:12 -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 are also welcome! Best regards, Holger Kipp