From owner-freebsd-scsi@FreeBSD.ORG Sun Aug 13 20:17:44 2006 Return-Path: X-Original-To: freebsd-scsi@freebsd.org 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 8F93D16A4DE for ; Sun, 13 Aug 2006 20:17:43 +0000 (UTC) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CBAD43D45 for ; Sun, 13 Aug 2006 20:17:42 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.24] (andersonbox4.centtech.com [192.168.42.24]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id k7DKHgZI017767; Sun, 13 Aug 2006 15:17:42 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <44DF88FB.90602@centtech.com> Date: Sun, 13 Aug 2006 15:18:03 -0500 From: Eric Anderson User-Agent: Thunderbird 1.5.0.5 (X11/20060802) MIME-Version: 1.0 To: Matthew Jacob References: <44DB8A9C.8090609@centtech.com> <44DC6F9F.4060405@centtech.com> <20060811154348.GA83765@chuggalug.clues.com> <44DCA9F1.1000302@centtech.com> <7579f7fb0608121101g112e006cy1112d282fab753d3@mail.gmail.com> In-Reply-To: <7579f7fb0608121101g112e006cy1112d282fab753d3@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.87.1/1655/Sun Aug 13 13:39:20 2006 on mh2.centtech.com X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org Subject: Re: isp issues on recent -STABLE X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Aug 2006 20:17:44 -0000 On 08/12/06 13:01, Matthew Jacob wrote: > Hmm. I have no special help on this one. This doesn't seem > *particularly* related to any changes I've made recently. > > If you could isolate a date/change when this occurred for you it would help. > > All I see in the messages below is indications that we've given your > storage way too much work to do. Yea, I think that's all it is. Once I did less work, the problem went away, although I still get a lot of warnings from ISP about pretty much the same thing (so maybe I'm *close* to the line). Also, I recently booted up 6.1-RELEASE cd with two qlogic 2312's, installed, and booted up. After updating to -STABLE, and rebooting, I either would hang forever (literally days went by), or I resulted in a panic (when ispfw was loaded). Once I plugged the hba's into something, the issues went away. Only when they were totally disconnected did I have any issue. Let me know if you need more info/testing. Eric > On 8/11/06, Eric Anderson wrote: >> On 08/11/06 10:43, Geoff Buckingham wrote: >>> On Fri, Aug 11, 2006 at 06:53:03AM -0500, Eric Anderson wrote: >>>> [..snip..] >>>> Aug 9 23:02:10 snapshot1 kernel: isp0: command timed out for 0.2.2 >>>> Aug 9 23:02:10 snapshot1 kernel: (da8:isp0:0:2:2): Command timed out >>>> Aug 9 23:02:10 snapshot1 kernel: (da8:isp0:0:2:2): Retrying Command >>>> Aug 9 23:26:58 snapshot1 kernel: (da3:isp0:0:1:0): Queue Full >>>> Aug 9 23:26:58 snapshot1 kernel: (da3:isp0:0:1:0): tagged openings now 254 >>> I don't what may have changed in the driver recently, but from your post >>> you seem to be using the FC isp and potentially a "SAN" presenting arrays as >>> luns to you rather than JBOD on a loop or switch. >>> >>> If you you have some kind of data mover presenting arrays, your SAN vendor >>> may well recomend a maximum queue size per lun (often 20-30) >> I have this one host connected to a single QLogic fiber channel switch, >> which has 5 ACNC fiber channel arrays attached to it, along with a tape >> robot and tape drives. Three of the arrays present 3 LUNs each (2TB per >> LUN), and two of them present 2 LUNs each, 4GB and 10TB - I'm not using >> these two arrays much yet, and are not really associated with the problems. >> >>> man camcontrol, look at the tags section. >>> >>> Your commands may be timing out because you have managed to queue too many >>> command (which I hope should not happen). Or..... >>> >>> Your queues could be filling because your commands are timing out. Which >>> would imply something is broke :-( >> Strange that I've never hit this in the past, but now I seem to be >> hitting it quite often. The vendor of the arrays says queue depth is >> 256 per LUN, and that coincides with my messages above I believe. >> >> Eric >> >> >> >> -- >> ------------------------------------------------------------------------ >> Eric Anderson Sr. Systems Administrator Centaur Technology >> Anything that works is better than anything that doesn't. >> ------------------------------------------------------------------------ >> _______________________________________________ >> freebsd-scsi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-scsi >> To unsubscribe, send any mail to "freebsd-scsi-unsubscribe@freebsd.org" >> -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology Anything that works is better than anything that doesn't. ------------------------------------------------------------------------