From owner-freebsd-scsi@FreeBSD.ORG Sun Nov 27 03:20:33 2005 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 7517116A41F for ; Sun, 27 Nov 2005 03:20:33 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id F05F343D95 for ; Sun, 27 Nov 2005 03:20:11 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.12.11/8.12.11) with ESMTP id jAR3KANG095828; Sat, 26 Nov 2005 20:20:10 -0700 (MST) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.12.11/8.12.5/Submit) id jAR3KAe8095827; Sat, 26 Nov 2005 20:20:10 -0700 (MST) (envelope-from ken) Date: Sat, 26 Nov 2005 20:20:10 -0700 From: "Kenneth D. Merry" To: Scott Long Message-ID: <20051127032010.GA95731@nargothrond.kdm.org> References: <4388CA8C.6080503@samsco.org> <20051126231119.GA43846@nargothrond.kdm.org> <4388F341.3040700@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4388F341.3040700@samsco.org> User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.86.1/1195/Fri Nov 25 02:29:55 2005 on nargothrond.kdm.org X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org, user Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) 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, 27 Nov 2005 03:20:33 -0000 On Sat, Nov 26, 2005 at 16:44:01 -0700, Scott Long wrote: > Kenneth D. Merry wrote: > > >On Sat, Nov 26, 2005 at 16:59:56 -0500, user wrote: > > > >>First off, thank you very much for your help. > >> > >>On Sat, 26 Nov 2005, Scott Long wrote: > >> > >> > >>>The problem is not with filesystem corruption, it's with parity > >>>corruption. It's possible to get a situation where a stripe is > >>>partially written out and then interrupted by a power failure, leaving > >>>the parity inconsistent with the stripe. You won't notice this until > >>>it's time to rebuild a failed drive from the parity, and then you'll > >>>get corruption. > >> > >> > >>I will only be creating mirrors. Is a mirror impervious to this, or are > >>the potential problems even worse ? (my guess is impervious .. ?) > > > > > >Mirrors are not impervious to the problem. You still have the same issue; > >you don't know whether any outstanding data got written to all drives, some > >drives or no drives. If you resync the mirror, you're basically choosing > >one drive as "good" and the other as "suspect", regardless of what the > >actual situation is. > > > > Well, it depends on how the controller recovers from improper shutdown. > If it forces a full resync, you'll wind up with two drives that are > consistent with each other. Whether the data on the drives represents > everything that the OS thought that it wrote before the crash is a > different matter, but that is no different than an unclean shutdown with > only a single disk. However, if the controller doesn't do a full > resync, you'll wind up with inconsistencies in the array. Take disk A1 > and A2 of array A. You issue writes to sectors 1, 2, and 3 of the > array. The controller caches those writes and issues them out to disks > A1 and A2. Then catastrophy strikes, and only some of the sectors get > written. Disk A1 has sectors 1 and 2 written, and disk A2 has sectors 2 > and 3 written. The sectors that didn't get written contain old data. > So now neither disk has data that is of the same age, and if a resync > isn't done you'll get inconsistent read results from sectors 1 and 3. > > All filesystems have to deal with the fact that not all data will get to > disk before a crash. Loosing cached sectors during a RAID-5 write is > bad because a resync won't restore consistency. Resyncing a RAID-1 will > restore consistency, even if it means that new sectors on the resync > slave get overwritten by older sectors from the resync master. Having a > battery for RAID-1 is definitely nice to have, but I don't view it as > essential since the potential for silent data corruption isn't there. Resyncing a RAID-5 should restore the consistency of the parity with data. It's just that you won't know whether or not your data is all good. You can still have the same sort of problem with a RAID-1. If one disk was in the middle of a write when the power failed, you can wind up with a half-updated chunk of data. If that disk is picked as the master for the resync, you'll wind up with a region on the array that is part old and part new. In either case, doing a verify will tell you that you have an inconsistency, but it won't tell you what the data should be. Ken -- Kenneth Merry ken@kdm.org From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 28 02:50:47 2005 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 5359816A424 for ; Mon, 28 Nov 2005 02:50:47 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1763E43D4C for ; Mon, 28 Nov 2005 02:50:46 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (av.hub.org [200.46.204.144]) by hub.org (Postfix) with ESMTP id 4AB6CC08BF2 for ; Sun, 27 Nov 2005 22:50:43 -0400 (AST) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 01429-05 for ; Sun, 27 Nov 2005 22:50:43 -0400 (AST) Received: from ganymede.hub.org (blk-222-82-85.eastlink.ca [24.222.82.85]) by hub.org (Postfix) with ESMTP id 952ECC08BED for ; Sun, 27 Nov 2005 22:50:42 -0400 (AST) Received: by ganymede.hub.org (Postfix, from userid 1000) id 2461036C9E; Sun, 27 Nov 2005 22:50:48 -0400 (AST) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id 238AC34272 for ; Sun, 27 Nov 2005 22:50:48 -0400 (AST) Date: Sun, 27 Nov 2005 22:50:48 -0400 (AST) From: "Marc G. Fournier" To: freebsd-scsi@freebsd.org Message-ID: <20051127224937.H1053@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Subject: CLI for GDT8514RZ controller ... 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: Mon, 28 Nov 2005 02:50:47 -0000 I downloaded the one from the web site (icpcon4.tgz), but it tells me no controllers found ... is there something that I need to do to make it recognize the controller? Thanks ... ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 28 05:20:26 2005 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 6E43716A41F for ; Mon, 28 Nov 2005 05:20:26 +0000 (GMT) (envelope-from user@dhp.com) Received: from shell.dhp.com (shell.dhp.com [199.245.105.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id DA8C343D46 for ; Mon, 28 Nov 2005 05:20:25 +0000 (GMT) (envelope-from user@dhp.com) Received: by shell.dhp.com (Postfix, from userid 896) id DA3F331307; Mon, 28 Nov 2005 00:20:24 -0500 (EST) Date: Mon, 28 Nov 2005 00:20:24 -0500 (EST) From: user To: "Kenneth D. Merry" In-Reply-To: <20051126231119.GA43846@nargothrond.kdm.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-scsi@freebsd.org Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) 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: Mon, 28 Nov 2005 05:20:26 -0000 On Sat, 26 Nov 2005, Kenneth D. Merry wrote: > > > It would be better to let the rebuild happen as fast as possible. Disks > > > have a bad habit of failing in groups, and you don't want to increase > > > the chance of a multi-disk failure by making recovery slow. > > > > So again ... only using mirrors ... and in a two-drive chassis, I can't > > have a hot spare, so I am not sure if it even really matters what I set > > that to ... comments ? > > If you only have a two drive chassis, your best bet is to replace a failed > drive as soon as you can and let the rebuild complete as soon as you can. This Dell CERC (adaptec 2610sa) is the first card I have seen with this rebuild-priority setting. Out of curiosity, of the three choices I have (low medium high), which choice approximates the behavior that the older cards (PERCs, etc.) had that _did not_ give you this choice ? Thanks so much for your (and everyone elses) great comments on this thread. From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 28 05:31:22 2005 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 4CB4816A422 for ; Mon, 28 Nov 2005 05:31:22 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id B65C143D5D for ; Mon, 28 Nov 2005 05:31:14 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jAS5V8WI071829; Sun, 27 Nov 2005 22:31:09 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <438A961C.2030504@samsco.org> Date: Sun, 27 Nov 2005 22:31:08 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: user References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org, "Kenneth D. Merry" Subject: Re: configuration choices with Dell CERC (adaptec 2610SA) 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: Mon, 28 Nov 2005 05:31:22 -0000 user wrote: > > On Sat, 26 Nov 2005, Kenneth D. Merry wrote: > > >>>>It would be better to let the rebuild happen as fast as possible. Disks >>>>have a bad habit of failing in groups, and you don't want to increase >>>>the chance of a multi-disk failure by making recovery slow. >>> >>>So again ... only using mirrors ... and in a two-drive chassis, I can't >>>have a hot spare, so I am not sure if it even really matters what I set >>>that to ... comments ? >> >>If you only have a two drive chassis, your best bet is to replace a failed >>drive as soon as you can and let the rebuild complete as soon as you can. > > > > This Dell CERC (adaptec 2610sa) is the first card I have seen with this > rebuild-priority setting. Out of curiosity, of the three choices I have > (low medium high), which choice approximates the behavior that the older > cards (PERCs, etc.) had that _did not_ give you this choice ? > > Thanks so much for your (and everyone elses) great comments on this > thread. > > > The aac line of controllers have had task priority selection for at least the last 6.5 years that I've been using them. Maybe it's only now being exposed to someplace that you've noticed? Anyways, the default priority for all tasks is 'high'. Scott From owner-freebsd-scsi@FreeBSD.ORG Mon Nov 28 11:02:43 2005 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 B3A6716A41F for ; Mon, 28 Nov 2005 11:02:43 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6018643D5C for ; Mon, 28 Nov 2005 11:02:18 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id jASB2CWp088296 for ; Mon, 28 Nov 2005 11:02:12 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id jASB2Bjj088290 for freebsd-scsi@freebsd.org; Mon, 28 Nov 2005 11:02:11 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 28 Nov 2005 11:02:11 GMT Message-Id: <200511281102.jASB2Bjj088290@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: freebsd-scsi@FreeBSD.org Cc: Subject: Current problem reports assigned to you 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: Mon, 28 Nov 2005 11:02:43 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2001/05/03] kern/27059 scsi [sym] SCSI subsystem hangs under heavy lo o [2001/06/29] kern/28508 scsi problems with backup to Tandberg SLR40 st o [2002/06/17] kern/39388 scsi ncr/sym drivers fail with 53c810 and more o [2002/07/22] kern/40895 scsi wierd kernel / device driver bug o [2003/05/24] kern/52638 scsi [panic] SCSI U320 on SMP server won't run s [2003/09/30] kern/57398 scsi [mly] Current fails to install on mly(4) o [2003/12/26] kern/60598 scsi wire down of scsi devices conflicts with o [2003/12/27] kern/60641 scsi [sym] Sporadic SCSI bus resets with 53C81 s [2004/01/10] kern/61165 scsi [panic] kernel page fault after calling c o [2004/12/02] kern/74627 scsi [ahc] [hang] Adaptec 2940U2W Can't boot 5 o [2005/06/04] kern/81887 scsi [aac] Adaptec SCSI 2130S aac0: GetDeviceP 11 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2000/12/06] kern/23314 scsi aic driver fails to detect Adaptec 1520B o [2001/08/15] kern/29727 scsi [amr] [patch] amr_enquiry3 structure in a o [2002/02/23] kern/35234 scsi World access to /dev/pass? (for scanner) o [2002/06/02] kern/38828 scsi [feature request] DPT PM2012B/90 doesn't o [2002/10/29] kern/44587 scsi dev/dpt/dpt.h is missing defines required o [2003/10/01] kern/57469 scsi [scsi] [patch] Quirk for Conner CP3500 o [2005/01/12] kern/76178 scsi [ahd] Problem with ahd and large SCSI Rai 7 problems total. From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 29 15:11:15 2005 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 4D6BA16A41F for ; Tue, 29 Nov 2005 15:11:15 +0000 (GMT) (envelope-from rajesh_ghanekar@persistent.co.in) Received: from smtp.persistent.co.in (smtp.persistent.co.in [202.54.11.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 704AA43D46 for ; Tue, 29 Nov 2005 15:11:13 +0000 (GMT) (envelope-from rajesh_ghanekar@persistent.co.in) Received: from [10.77.196.113] ([10.77.196.113]) (authenticated bits=0) by smtp.persistent.co.in (8.12.9/) with ESMTP id jATFBJMr023361 for ; Tue, 29 Nov 2005 20:41:22 +0530 Message-ID: <438C750D.5030604@persistent.co.in> Date: Tue, 29 Nov 2005 21:04:37 +0530 From: "Rajesh S. Ghanekar" User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE Subject: isp driver - inquiry changed 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: Tue, 29 Nov 2005 15:11:15 -0000 Hi, I am using FreeBSD-4.10 with isp driver on HP EVA-8k SAN box. The description of the problem is as follows: 1. Two machines are using HP EVA-8k with only single controller active. 2. Both of these machines are doing heavy IO on the their individual LUNs. 3. Now if any one of the machine is rebooted, the other machine's OS panics and reboots. Both the machines are using FreeBSD-4.10. Here is the debug info attached. ------------------------------ Debug Info -------------------------------------------------- (da0:isp0:0:2:1): (da0:isp0:0:2:1): (da0:isp0:0:2:1): (da0:isp0:0:2:1): (da0:isp0:0:2:1): (da0:isp0:0:2:1): (da 0:isp0:0:2:1): Invalidating pack (da0:isp0:0:2:1): . CDB: 1b 0 0 0 1 0 (da0:isp0:0:2:1): . CDB: 2a 0 e 40 1a 23 0 0 4 0 (da0:isp0:0:2:1): . CDB: 28 0 f 58 53 92 0 0 4 0 (da0:isp0:0:2:1): . CDB: 28 0 f 93 38 7f 0 0 4 0 (da0:isp0:0:2:1): . CDB: 2a 0 1a 6e 50 9b 0 0 4 0 (da0:isp0:0:2:1): (da0:isp0:0:2:1): (da0:isp0:0:2:1): (da0:isp0:0:2:1): . CDB: 2a 0 16 90 45 14 0 0 4 0 (da0:isp0:0:2:1): . CDB: 2a 0 1 58 a7 60 0 0 4 0 (da0:isp0:0:2:1): . CDB: 28 0 a d6 c1 9d 0 0 4 0 (probe0:isp0:0:2:1): . CDB: 1a 0 a 0 14 0 (da0:isp0:0:2:1): inquiry changed (da0:isp0:0:2:1): . CDB: 2a 0 8 9f 6d 25 0 0 4 0 Fatal trap 12: page fault while in kernel mode mp_lock = 01000002; cpuid = 1; lapic.id = 06000000 fault virtual address = 0x60 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01aec1b stack pointer = 0x10:0xf4f41d5c frame pointer = 0x10:0xf4f41d74 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 10750 (IOtest-static) interrupt mask = none <- SMP: XXX trap number = 12 panic: page fault mp_lock = 01000002; cpuid = 1; lapic.id = 06000000 boot() called on cpu#1 Boot called at 1133184305 seconds syncing disks... (probe0:isp0:0:2:1): . CDB: 12 1 80 0 ff 0 (probe0:isp0:0:2:1): . CDB: 12 0 0 0 24 0 (probe0:isp0:0:2:1): . CDB: 12 0 0 0 fb 0 (probe0:isp0:0:2:1): . CDB: 1a 0 a 0 14 0 (probe0:isp0:0:2:1): . CDB: 12 1 80 0 ff 0 (probe0:isp0:0:2:1): . CDB: 12 0 0 0 24 0 (probe0:isp0:0:2:1): . CDB: 12 0 0 0 fb 0 (probe0:isp0:0:2:1): . CDB: 1a 0 a 0 14 0 (probe0:isp0:0:2:1): . CDB: 12 1 80 0 ff 0 (probe0:isp0:0:2:1): . CDB: 12 0 0 0 24 0 ------------------------------------------------------------------------------------------ I am confused at why these "inquiry changed" messages are getting logged. This seems to work with SAN boxes other than HP EVA-8k and EVA-6k. Any ideas on why these "inquiry changed" messages are getting created and are they cause of this kernel panic? Thanks, Rajesh From owner-freebsd-scsi@FreeBSD.ORG Tue Nov 29 18:20:27 2005 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 F079F16A41F for ; Tue, 29 Nov 2005 18:20:27 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 686A443D53 for ; Tue, 29 Nov 2005 18:20:27 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by xproxy.gmail.com with SMTP id s19so2274298wxc for ; Tue, 29 Nov 2005 10:20:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=bObqROUjsN7KuNQzKl+A/wc35i+ChfoIv78NFB6lc22IP+MjkMgNQxQfuvFLHAXqfUxEskbTUZuOHFNZpF28NuODuoaPfaOxIcLiDlQPUIlrCNeTmhqwgMTK+ZjUEJZDBeEPb3RJD9ME9XeAoCYZYVy/iHtaYKjDwLegZ8B6pD4= Received: by 10.64.53.2 with SMTP id b2mr4183619qba; Tue, 29 Nov 2005 10:20:25 -0800 (PST) Received: by 10.65.154.13 with HTTP; Tue, 29 Nov 2005 10:20:25 -0800 (PST) Message-ID: <7579f7fb0511291020qc3c00c6v552fdd6c55d5574b@mail.gmail.com> Date: Tue, 29 Nov 2005 10:20:25 -0800 From: Matthew Jacob To: "Rajesh S. Ghanekar" In-Reply-To: <438C750D.5030604@persistent.co.in> MIME-Version: 1.0 References: <438C750D.5030604@persistent.co.in> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: isp driver - inquiry changed 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: Tue, 29 Nov 2005 18:20:28 -0000 > > (da0:isp0:0:2:1): inquiry changed Did you transcribe by hand? The closest would be: "Inquiry data has changed" This just means that the the EVA sent back a command with "Inquiry Data Changed" (da0:isp0:0:2:1): . CDB: 2a 0 8 9f 6d 25 0 0 4 0 > > Fatal trap 12: page fault while in kernel mode > mp_lock =3D 01000002; cpuid =3D 1; lapic.id =3D 06000000 > fault virtual address =3D 0x60 > fault code =3D supervisor read, page not present > instruction pointer =3D 0x8:0xc01aec1b > stack pointer =3D 0x10:0xf4f41d5c > frame pointer =3D 0x10:0xf4f41d74 > code segment =3D base 0x0, limit 0xfffff, type 0x1b > =3D DPL 0, pres 1, def32 1, gran 1 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > current process =3D 10750 (IOtest-static) > interrupt mask =3D none <- SMP: XXX > trap number =3D 12 > panic: page fault > mp_lock =3D 01000002; cpuid =3D 1; lapic.id =3D 06000000 > boot() called on cpu#1 w/o a traceback I can't really say what happened here with certainty. Given the other probe messages somehow we seem to be re-scanning due to the other system going down. Try a 'boot verbose' and see whether on the surviving system that the disks are being seen as going away by the ISP driver. What's the connection topology, btw? From owner-freebsd-scsi@FreeBSD.ORG Wed Nov 30 06:24:46 2005 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 A912816A41F for ; Wed, 30 Nov 2005 06:24:46 +0000 (GMT) (envelope-from rajesh_ghanekar@persistent.co.in) Received: from smtp.persistent.co.in (smtp.persistent.co.in [202.54.11.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2C0F43D69 for ; Wed, 30 Nov 2005 06:24:33 +0000 (GMT) (envelope-from rajesh_ghanekar@persistent.co.in) Received: from [10.77.196.113] ([10.77.196.113]) (authenticated bits=0) by smtp.persistent.co.in (8.12.9/) with ESMTP id jAU6O0Mr012204; Wed, 30 Nov 2005 11:54:25 +0530 Message-ID: <438D4AF9.7040600@persistent.co.in> Date: Wed, 30 Nov 2005 12:17:21 +0530 From: "Rajesh S. Ghanekar" User-Agent: Mozilla Thunderbird 0.8 (X11/20040913) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Jacob References: <438C750D.5030604@persistent.co.in> <7579f7fb0511291020qc3c00c6v552fdd6c55d5574b@mail.gmail.com> In-Reply-To: <7579f7fb0511291020qc3c00c6v552fdd6c55d5574b@mail.gmail.com> X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: isp driver - inquiry changed 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: Wed, 30 Nov 2005 06:24:46 -0000 Matthew Jacob wrote: > > > (da0:isp0:0:2:1): inquiry changed > > > Did you transcribe by hand? The closest would be: > > "Inquiry data has changed" > > This just means that the the EVA sent back a command with "Inquiry > Data Changed" > > (da0:isp0:0:2:1): . CDB: 2a 0 8 9f 6d 25 0 0 4 0 > > Fatal trap 12: page fault while in kernel mode > mp_lock = 01000002; cpuid = 1; lapic.id = 06000000 > fault virtual address = 0x60 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01aec1b > stack pointer = 0x10:0xf4f41d5c > frame pointer = 0x10:0xf4f41d74 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 10750 (IOtest-static) > interrupt mask = none <- SMP: XXX > trap number = 12 > panic: page fault > mp_lock = 01000002; cpuid = 1; lapic.id = 06000000 > boot() called on cpu#1 > > > > w/o a traceback I can't really say what happened here with certainty. > Given the other probe messages somehow we seem to be re-scanning due > to the other system going down. > > Try a 'boot verbose' and see whether on the surviving system that the > disks are being seen as going away by the ISP driver. > > What's the connection topology, btw? > Its a simple topology with all the hosts presented to all the available LUNs on EVA. I am sorry that I said it is FreeBSD-4.10, it is FreeBSD-4.1. This logs the message as "inquiry changed". -------------------------------------------- | HP EVA-8k | | (cntrl 1) | -------------------------------------------- | | -------------------------------------------------------------------------- | FC Switch | | | ------------------------------------------------------------------------- | | | | Machine 1 Machine 2 Backtrace is as follows: ----------------------------- (kgdb) #0 0xc01a44af in boot () #1 0xc01a4c0f in panic () #2 0xc02849f0 in trap_fatal () #3 0xc028466d in trap_pfault () #4 0xc02841df in trap () #5 0xc01aec1b in dscheck () #6 0xc01ae94a in diskstrategy () #7 0xc01a049c in physio () #8 0xc01e1ee6 in spec_read () #9 0xc0238160 in ufsspec_read () #10 0xc0238a5d in ufs_vnoperatespec () #11 0xc01d91fc in vn_read () #12 0xc01b31cd in dofileread () #13 0xc01b2fd6 in read () #14 0xc0284e86 in syscall2 () #15 0xc027066b in Xint0x80_syscall () cannot read proc at 0 On the surviving system (the machine which rebooted initially) can see all the LUNs after it comes up on reboot. Thanks, Rajesh From owner-freebsd-scsi@FreeBSD.ORG Thu Dec 1 03:33:47 2005 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 90D5D16A41F for ; Thu, 1 Dec 2005 03:33:47 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: from xproxy.gmail.com (xproxy.gmail.com [66.249.82.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE1EA43D5D for ; Thu, 1 Dec 2005 03:33:44 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by xproxy.gmail.com with SMTP id t13so168333wxc for ; Wed, 30 Nov 2005 19:33:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=risIhWNIeG2qgoF5fnPBb5+w8yzN49yoadchDhVcpg7+GHpiwvEFV/nRBrvdo3eA7TQBaid7R6DxyfBY08wF+/IZo0qk09TShjfRP3/fwfx73mwVZv/QAjkBIm646+Nh+iVmgLXYqBKgqFPDfH785EXUjrjmI7+m2UU1DY8mN3Q= Received: by 10.65.103.2 with SMTP id f2mr607053qbm; Wed, 30 Nov 2005 19:33:41 -0800 (PST) Received: by 10.65.154.13 with HTTP; Wed, 30 Nov 2005 19:33:41 -0800 (PST) Message-ID: <7579f7fb0511301933j2593b780wf3130bbcb37ab43f@mail.gmail.com> Date: Wed, 30 Nov 2005 19:33:41 -0800 From: Matthew Jacob To: "Rajesh S. Ghanekar" In-Reply-To: <438D4AF9.7040600@persistent.co.in> MIME-Version: 1.0 References: <438C750D.5030604@persistent.co.in> <7579f7fb0511291020qc3c00c6v552fdd6c55d5574b@mail.gmail.com> <438D4AF9.7040600@persistent.co.in> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-scsi@freebsd.org Subject: Re: isp driver - inquiry changed 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: Thu, 01 Dec 2005 03:33:47 -0000 Switch as in 'Fabric' or 'Segmented FC-AL'? The panic looks like the ones where as far as the system is concerned the disk went away. Right now, certain fabric and loop events cause the isp driver to think the target has gone away, and this gets sent as async event upstream. I'm beginning to think that this is a losing proposition for FreeBSD- on the other hand, the unexpected disappearance of a device isn't handled well by FreeBSD *either*. When I did a hardening exercise at Mirapoint for the FreeBSD isp driver and SCSI midlayer, I seem to recall that I put in a deferred device disappearance algorithm. Maybe I should check with Mirapoint to see if I ca= n pull that code back. Its a simple topology with all the hosts presented to all the available LUN= s > on EVA. > I am sorry that I said it is FreeBSD-4.10, it is FreeBSD-4.1. This logs > the message > as "inquiry changed". > > > -------------------------------------------- > | HP > EVA-8k | > | (cntrl > 1) | > > -------------------------------------------- > | > | > > -------------------------------------------------------------------------= - > | FC > Switch | > > | > | > > ------------------------------------------------------------------------- > > | | > > | | > Machine 1 Machine > 2 > > > > Backtrace is as follows: > ----------------------------- > > (kgdb) #0 0xc01a44af in boot () > #1 0xc01a4c0f in panic () > #2 0xc02849f0 in trap_fatal () > #3 0xc028466d in trap_pfault () > #4 0xc02841df in trap () > #5 0xc01aec1b in dscheck () > #6 0xc01ae94a in diskstrategy () > #7 0xc01a049c in physio () > #8 0xc01e1ee6 in spec_read () > #9 0xc0238160 in ufsspec_read () > #10 0xc0238a5d in ufs_vnoperatespec () > #11 0xc01d91fc in vn_read () > #12 0xc01b31cd in dofileread () > #13 0xc01b2fd6 in read () > #14 0xc0284e86 in syscall2 () > #15 0xc027066b in Xint0x80_syscall () > cannot read proc at 0 > > On the surviving system (the machine which rebooted initially) can see > all the LUNs after it comes up on reboot. > > Thanks, > Rajesh > > From owner-freebsd-scsi@FreeBSD.ORG Thu Dec 1 15:47:27 2005 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 98C0216A41F for ; Thu, 1 Dec 2005 15:47:27 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id A364B43D5A for ; Thu, 1 Dec 2005 15:47:16 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id jB1Fl8KB019020; Thu, 1 Dec 2005 08:47:09 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <438F1AFC.1080301@samsco.org> Date: Thu, 01 Dec 2005 08:47:08 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Jacob References: <438C750D.5030604@persistent.co.in> <7579f7fb0511291020qc3c00c6v552fdd6c55d5574b@mail.gmail.com> <438D4AF9.7040600@persistent.co.in> <7579f7fb0511301933j2593b780wf3130bbcb37ab43f@mail.gmail.com> In-Reply-To: <7579f7fb0511301933j2593b780wf3130bbcb37ab43f@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-1.4 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: freebsd-scsi@freebsd.org Subject: Re: isp driver - inquiry changed 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: Thu, 01 Dec 2005 15:47:27 -0000 Matthew Jacob wrote: > Switch as in 'Fabric' or 'Segmented FC-AL'? > > The panic looks like the ones where as far as the system is concerned the > disk went away. > > Right now, certain fabric and loop events cause the isp driver to think the > target has gone away, and this gets sent as async event upstream. I'm > beginning to think that this is a losing proposition for FreeBSD- on the > other hand, the unexpected disappearance of a device isn't handled well by > FreeBSD *either*. Yeah, the most serious and hard to fix problem is that most filesystems and I/O related parts of the VM assume that all I/O succeeds. > > When I did a hardening exercise at Mirapoint for the FreeBSD isp driver and > SCSI midlayer, I seem to recall that I put in a deferred device > disappearance algorithm. Maybe I should check with Mirapoint to see if I can > pull that code back. > John Polstra committed some fixes about a month ago related to device disappearance in SCSI. Might be good to look at that too. Scott