From owner-freebsd-scsi@FreeBSD.ORG Mon Feb 14 11:01:56 2005 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 A507716A4E2 for ; Mon, 14 Feb 2005 11:01:56 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6BF6D43D1F for ; Mon, 14 Feb 2005 11:01:56 +0000 (GMT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.13.1/8.13.1) with ESMTP id j1EB1u14015194 for ; Mon, 14 Feb 2005 11:01:56 GMT (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.13.1/8.13.1/Submit) id j1EB1trb015188 for freebsd-scsi@freebsd.org; Mon, 14 Feb 2005 11:01:55 GMT (envelope-from owner-bugmaster@freebsd.org) Date: Mon, 14 Feb 2005 11:01:55 GMT Message-Id: <200502141101.j1EB1trb015188@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 Subject: Current problem reports assigned to you 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: Mon, 14 Feb 2005 11:01:56 -0000 Current FreeBSD problem reports Critical problems Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- f [2000/08/18] kern/20689 scsi Newbusified version of ncr driver does no f [2001/05/03] kern/27059 scsi (symbios) SCSI subsystem hangs under heav 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 f [2002/09/15] kern/42796 scsi NCR/SYM 53C825 driver detects scsi cdrom f [2002/11/25] kern/45713 scsi If you use the amr driver, it is impossib f [2002/12/09] kern/46152 scsi Panic in adw dumping to tape f [2003/05/16] kern/52331 scsi 4.7 to 4.8-REL upgrade: SCSI disks on sym f [2003/09/14] kern/56759 scsi [hang] System freezes when writing CD Adv f [2003/09/14] kern/56760 scsi [hang] system hangs at boot with adaptec f [2003/09/14] kern/56871 scsi dd can't write variable length data block f [2003/09/18] kern/56973 scsi SCSI errors from on-board Adaptec (AIC7xx s [2003/09/30] kern/57398 scsi Current fails to install on mly(4) based o [2003/12/26] kern/60598 scsi wire down of scsi devices conflicts with a [2004/01/10] kern/61165 scsi [panic] kernel page fault after calling c o [2004/09/15] kern/71778 scsi 5.3 BETA3 doesnt see Adaptec 2015S FW Rev o [2004/12/02] kern/74607 scsi FreeBSD 5.3 install CD crashes on SCSI de o [2004/12/29] kern/75603 scsi 5.3 kernel crash 19 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/57468 scsi [patch] Quirk for Quantum LPS540S o [2003/10/01] kern/57469 scsi [patch] Quirk for Conner CP3500 o [2004/09/22] kern/72010 scsi [patch] mt -f /dev/rsa0.ctl comp off, or 8 problems total. From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 15 17:32:22 2005 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 7CB8416A4CE for ; Tue, 15 Feb 2005 17:32:22 +0000 (GMT) Received: from magellan.palisadesys.com (magellan.palisadesys.com [192.188.162.211]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3378343D39 for ; Tue, 15 Feb 2005 17:32:22 +0000 (GMT) (envelope-from ghelmer@palisadesys.com) Received: from [172.16.1.108] (cetus.palisadesys.com [192.188.162.7]) (authenticated bits=0)j1FHWBwX081935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 15 Feb 2005 11:32:12 -0600 (CST) (envelope-from ghelmer@palisadesys.com) Message-ID: <4212321B.2090707@palisadesys.com> Date: Tue, 15 Feb 2005 11:32:11 -0600 From: Guy Helmer User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) 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-Palisade-MailScanner-Information: Please contact the ISP for more information X-Palisade-MailScanner: Found to be clean X-MailScanner-From: ghelmer@palisadesys.com Subject: Re: 29320A: tons of "unexpected busfree while idle" 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: Tue, 15 Feb 2005 17:32:22 -0000 We are also having some trouble with many "unexpected busfree while idle" events under FreeBSD 5.3-RELEASE where the disk is busy with database activity. One model is configured thus: Bios: Phoenix - Award Bios v6.00PG Motherboard: Supermicro P4SCA/P4SCE BIOS 1.1C SCSI: Adaptec SCSI BIOS v4.30.0 29320A Controller Disk: 1 Seagate ST336607LW 0007 10K-RPM 73GB disk CPU: P4-2.8 533 FSB MB: Single P4 Intel 845GE Rolling the driver back to 2004-09-01 on the RELENG_5 branch seems to have alieviated the problem for us (thanks to Anton Berezin's email of 2005-01-21). Guy -- Guy Helmer, Ph.D. Principal System Architect Palisade Systems, Inc. From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 15 21:59:25 2005 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 1B2BF16A4CF; Tue, 15 Feb 2005 21:59:25 +0000 (GMT) Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20B7843D58; Tue, 15 Feb 2005 21:59:24 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id 6A9BA3B8F9; Tue, 15 Feb 2005 22:59:22 +0100 (CET) Received: from hal9000.schweikhardt.net (localhost [127.0.0.1]) j1FLx8dq001305; Tue, 15 Feb 2005 22:59:08 +0100 (CET) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.13.1/8.13.1/Submit) id j1FLx8Fb001304; Tue, 15 Feb 2005 22:59:08 +0100 (CET) (envelope-from schweikh) Date: Tue, 15 Feb 2005 22:59:08 +0100 From: Jens Schweikhardt To: mjacob@freebsd.org Message-ID: <20050215215908.GA1012@schweikhardt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i cc: FreeBSD SCSI Subject: cam_xpt.c 1.147 makes system hang at boot 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: Tue, 15 Feb 2005 21:59:25 -0000 Matthew et al, this commit to src/sys/cam/cam_xpt.c, Revision 1.147 Sat Jan 22 22:46:45 2005 UTC (3 weeks, 2 days ago) by mjacob Branch: MAIN Changes since 1.146: +13 -3 lines This is a somewhat imperfect means to try and bring FreeBSD forward in its ability to automatically scan and attach luns for modern storage which has luns in the 0..1000 range, not 0..7. The correct thing would be to do REPORT LUNS for devices whose LUN0 version shows a version >= SCSI3, but lacking that we should be able to search higher than LUN 7 if we're >= SCSI3 with no ill effects. This change keeps all of the QUIRK_HILUNS quirks, obeys the QUIRK_NOLUNS, and introduces a QUIRK_NOHILUNS which will keep searches above LUN 7 happening for devices that report >= SCSI3 compliance. I doubt the latter will be needed, but you never know. This allowed me to randomly scan and attach > 500 disks at a time in a situation where quirking for QUIRK_HILUNS wasn't practical (the vendor id and product id changes of the virtualization changes constantly). Reviewed by: ken@freebsd.org, scottl@freebsd.org, gibbs@freebsd.org MFC after: 2 weeks makes my system hang at boot with a card state dump, followed by (manually transcribed): ahd0:A:1:0: Target did not send an IDENTIFY message. LASTPHASE = 0xc0 ahd0:A:1:0: Protocol Violation in Status phase. Attempting to abort. ahd0:A:1:0: Abort for unidentified connection completed. (repeats about once a minute). I've nailed it exactly to that commit. With rev 1.146 everything works as it has always been. The system is a supermicro P4SCT with an "ahc" and an "ahd" driver (29160 and 29320), e.g. $ dmesg|grep da ahd0: port 0xc400-0xc4ff,0xc000-0xc0ff mem 0xeb000000-0xeb001fff irq 24 at device 1.0 on pci3 ahc0: port 0xc800-0xc8ff mem 0xeb002000-0xeb002fff irq 25 at device 2.0 on pci3 ipfw2 initialized, divert loadable, rule-based forwarding disabled, default to deny, logging limited to 100 packets/entry by default da0 at ahd0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Enabled da0: 35044MB (71771688 512 byte sectors: 255H 63S/T 4467C) da1 at ahd0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Enabled da1: 35044MB (71771688 512 byte sectors: 255H 63S/T 4467C) da2 at ahd0 bus 0 target 5 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da2: 35046MB (71775284 512 byte sectors: 255H 63S/T 4467C) da3 at ahd0 bus 0 target 6 lun 0 da3: Fixed Direct Access SCSI-3 device da3: 320.000MB/s transfers (160.000MHz, offset 127, 16bit), Tagged Queueing Enabled da3: 35046MB (71775284 512 byte sectors: 255H 63S/T 4467C) da4 at ahc0 bus 0 target 9 lun 0 da4: Fixed Direct Access SCSI-3 device da4: 160.000MB/s transfers (80.000MHz, offset 127, 16bit), Tagged Queueing Enabled da4: 70093MB (143552136 512 byte sectors: 255H 63S/T 8935C) Mounting root from ufs:/dev/da2s1a I'm happy to provide more info and test any patches you or anyone can come up with. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-scsi@FreeBSD.ORG Tue Feb 15 23:22:56 2005 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 B534716A4D1 for ; Tue, 15 Feb 2005 23:22:56 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 206D343D5C for ; Tue, 15 Feb 2005 23:22:56 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so954565rnf for ; Tue, 15 Feb 2005 15:22:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=rmumOoRjrCuMLDZxFGchxUs4D9yUm+O2tHh0VfEjnGbWAkiplWKCeO6SgRpKkVFaDTuSG6D1fybejtsHP2e6TdgKsUILr9kjrqwunTwsfQx8DG3RBxlRg+i/FwxZLIdqUg2vrRx8nvIooLouPfY09fYIxxHYh2B8TDbhn6yTOQQ= Received: by 10.38.15.19 with SMTP id 19mr296356rno; Tue, 15 Feb 2005 15:22:54 -0800 (PST) Received: by 10.38.104.14 with HTTP; Tue, 15 Feb 2005 15:22:54 -0800 (PST) Message-ID: <7579f7fb05021515227e7b8539@mail.gmail.com> Date: Tue, 15 Feb 2005 15:22:54 -0800 From: Matthew Jacob To: Jens Schweikhardt In-Reply-To: <20050215215908.GA1012@schweikhardt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050215215908.GA1012@schweikhardt.net> cc: FreeBSD SCSI cc: mjacob@freebsd.org Subject: Re: cam_xpt.c 1.147 makes system hang at boot X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Matthew Jacob List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Feb 2005 23:22:56 -0000 Yeah, looks like this is causing more grief than it should. I'm going to try up the ANSI rev level by one which is a quick instant fix which should avoid most of the issues seen so far. From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 16 00:05:35 2005 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 DE3DB16A4CE; Wed, 16 Feb 2005 00:05:35 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74F8343D3F; Wed, 16 Feb 2005 00:05:35 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.19] (ibook-nai.samsco.home [192.168.254.19]) (authenticated bits=0) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j1G05mn7036975; Tue, 15 Feb 2005 17:05:48 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <42128E4A.8080101@samsco.org> Date: Tue, 15 Feb 2005 17:05:30 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Matthew Jacob References: <20050215215908.GA1012@schweikhardt.net> <7579f7fb05021515227e7b8539@mail.gmail.com> In-Reply-To: <7579f7fb05021515227e7b8539@mail.gmail.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: FreeBSD SCSI cc: mjacob@freebsd.org Subject: Re: cam_xpt.c 1.147 makes system hang at boot 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, 16 Feb 2005 00:05:36 -0000 Matthew Jacob wrote: > Yeah, looks like this is causing more grief than it should. I'm going > to try up the ANSI rev level by one which is a quick instant fix which > should avoid most of the issues seen so far. Well, my guess is that the U160 drives the posted has are going to have a fairly high ANSI rev number already. Let's just dig in and fix this for real. Btw, does anyone by change have access to a bus scanner to see what Windows or Solaris does when scanning LUNs? Scott From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 16 03:42:41 2005 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 19DE316A4CE for ; Wed, 16 Feb 2005 03:42:41 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id B742B43D39 for ; Wed, 16 Feb 2005 03:42:18 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 34983 invoked by uid 0); 16 Feb 2005 03:33:35 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.99.7) by mail.freebsd.org.cn with SMTP; 16 Feb 2005 03:33:35 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 5356C1337AA; Wed, 16 Feb 2005 11:42:11 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89659-15; Wed, 16 Feb 2005 11:41:57 +0800 (CST) Received: from localhost.localdomain (unknown [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id 0E0C61335CD; Wed, 16 Feb 2005 11:41:56 +0800 (CST) From: Xin LI To: freebsd-scsi@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-5+NyQ6SWc3/wriYWGNNN" Organization: The FreeBSD Simplified Chinese Project Date: Wed, 16 Feb 2005 11:40:40 +0800 Message-Id: <1108525240.676.15.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at frontfree.net cc: gibbs@FreeBSD.org Subject: One channel, multiple ID+multiple LUN, Adaptec 39320: card dump during start X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: delphij@delphij.net List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2005 03:42:41 -0000 --=-5+NyQ6SWc3/wriYWGNNN Content-Type: multipart/mixed; boundary="=-Cy7OI+WGYBUP6PPaoT9T" --=-Cy7OI+WGYBUP6PPaoT9T Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dear folks, While trying to attach an Ultra320 disk array to Adaptec 39320, and configured as multiple ID mode, mapping two volumes on SCSI ID 0 and 1 on one channel of the card, the detection probe will trigger the driver to say: ahd1: Recovery Initiated - Card was not paused The volume is mapped as: DEVICE ID LUN Volume A 0 0 Volume B 0 1 Volume C 1 0 Volume D 1 1 However, fortunately, after five retries (by CAM?), all volumes are recognized and seems to work correctly. The system is running FreeBSD 5.3-RELEASE-p5 with src/sys/cam/cam_xpt manually patched to rev 1.142.2.2. BTW. What does the message like: "Copied 18 bytes of sense data offset 12: 0x70 0x0 0x6 0x0 0x0 0x0 0x0 0xa 0x0 0x0 0x0 0x0 0x29 0x0 0x0 0x0 0x0 0x0" mean? Is it just a debug message, or I should pay more attention on the situation? Thanks in advance! Cheers, --=20 Xin LI http://www.delphij.net/ --=-Cy7OI+WGYBUP6PPaoT9T Content-Disposition: attachment; filename=message-cut Content-Type: text/plain; name=message-cut; charset=ISO-8859-1 Content-Transfer-Encoding: base64 RmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBXYWl0aW5nIDE1IHNlY29uZHMgZm9yIFND U0kgZGV2aWNlcyB0byBzZXR0bGUNCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogYWFj ZDA6IDxSQUlEIDAgKFN0cmlwZSk+IG9uIGFhYzANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtl cm5lbDogYWFjZDA6IDQ3NjgzM01CICg5NzY1NTM5ODQgc2VjdG9ycykNCkZlYiAxNiAxMToxNzox NiBkYXN0ZXN0IGtlcm5lbDogYWhkMTogUmVjb3ZlcnkgSW5pdGlhdGVkIC0gQ2FyZCB3YXMgbm90 IHBhdXNlZA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiA+Pj4+Pj4+Pj4+Pj4+Pj4+ Pj4gRHVtcCBDYXJkIFN0YXRlIEJlZ2lucyA8PDw8PDw8PDw8PDw8PDw8PA0KRmViIDE2IDExOjE3 OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBEdW1waW5nIENhcmQgU3RhdGUgYXQgcHJvZ3JhbSBh ZGRyZXNzIDB4MWNlIE1vZGUgMHgxMQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBJ TlRTVEFUWzB4MF0gU0VMT0lEWzB4MV0gU0VMSURbMHgxMF0gSFNfTUFJTEJPWFsweDBdIA0KRmVi IDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBJTlRDVExbMHg4MF06KFNXVE1JTlRNQVNLKSBT RVFJTlRTVEFUWzB4MF0gU0FWRURfTU9ERVsweDExXSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0 IGtlcm5lbDogREZGU1RBVFsweDExXTooQ1VSUkZJRk9fMXxGSUZPMEZSRUUpIFNDU0lTSUdJWzB4 NF06KFBfREFUQU9VVHxCU1lJKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU0NT SVBIQVNFWzB4MF0gU0NTSUJVU1sweDgwXSBMQVNUUEhBU0VbMHg4MF06KFBfQ09NTUFORCkgDQpG ZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNDU0lTRVEwWzB4MF0gU0NTSVNFUTFbMHgx Ml06KEVOQVVUT0FUTlB8RU5SU0VMSSkgDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6 IFNFUUNUTDBbMHgxMF06KEZBU1RNT0RFKSBTRVFJTlRDVExbMHgwXSBTRVFfRkxBR1NbMHgwXSAN CkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU0VRX0ZMQUdTMlsweDBdIFFGUkVFWkVf Q09VTlRbMHgyXSBLRVJORUxfUUZSRUVaRV9DT1VOVFsweDJdIA0KRmViIDE2IDExOjE3OjE2IGRh c3Rlc3Qga2VybmVsOiBNS19NRVNTQUdFX1NDQlsweGZmMDBdIE1LX01FU1NBR0VfU0NTSUlEWzB4 ZmZdIFNTVEFUMFsweDBdIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBTU1RBVDFb MHgwXSBTU1RBVDJbMHgwXSBTU1RBVDNbMHgwXSBQRVJSRElBR1sweGMwXTooSElQRVJSfEhJWkVS TykgDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNJTU9ERTFbMHhhY106KEVOU0NT SVBFUlJ8RU5CVVNGUkVFfEVOU0NTSVJTVHxFTlNFTFRJTU8pIA0KRmViIDE2IDExOjE3OjE2IGRh c3Rlc3Qga2VybmVsOiBMUUlTVEFUMFsweDBdIExRSVNUQVQxWzB4MF0gTFFJU1RBVDJbMHg4MF06 KFBBQ0tFVElaRUQpIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBMUU9TVEFUMFsw eDBdIExRT1NUQVQxWzB4MF0gTFFPU1RBVDJbMHg4MF0gDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVz dCBrZXJuZWw6IA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBTQ0IgQ291bnQgPSAx NiBDTURTX1BFTkRJTkcgPSAyIExBU1RTQ0IgMHhmIENVUlJTQ0IgMHhmIE5FWFRTQ0IgMHgwDQpG ZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IHFpbnN0YXJ0ID0gMjcgcWluZmlmb25leHQg PSAyNw0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBRSU5GSUZPOg0KRmViIDE2IDEx OjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBXQUlUSU5HX1RJRF9RVUVVRVM6DQpGZWIgMTYgMTE6MTc6 MTYgZGFzdGVzdCBrZXJuZWw6IFBlbmRpbmcgbGlzdDoNCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0 IGtlcm5lbDogMSBGSUZPX1VTRVsweDBdIFNDQl9DT05UUk9MWzB4NDBdOihESVNDRU5CKSBTQ0Jf U0NTSUlEWzB4N10gDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IDE1IEZJRk9fVVNF WzB4MF0gU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4MTddIA0KRmViIDE2IDExOjE3OjE2 IGRhc3Rlc3Qga2VybmVsOiBUb3RhbCAyDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6 IEtlcm5lbCBGcmVlIFNDQiBsaXN0OiAyIDMgNCA1IDYgNyA4IDkgMTAgMTEgMTIgMTMgMTQgMCAN CkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU2VxdWVuY2VyIENvbXBsZXRlIERNQS1p bnByb2cgbGlzdDogDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNlcXVlbmNlciBD b21wbGV0ZSBsaXN0OiANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU2VxdWVuY2Vy IERNQS1VcCBhbmQgQ29tcGxldGUgbGlzdDogDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJu ZWw6IFNlcXVlbmNlciBPbiBRRnJlZXplIGFuZCBDb21wbGV0ZSBsaXN0OiANCkZlYiAxNiAxMTox NzoxNiBkYXN0ZXN0IGtlcm5lbDogDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IA0K RmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBGSUZPMCBGcmVlLCBMT05HSk1Q ID09IDB4ODBmZiwgU0NCIDB4MA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBTRVFJ TU9ERVsweDNmXTooRU5DRkc0VENNRHxFTkNGRzRJQ01EfEVOQ0ZHNFRTVEFUfEVOQ0ZHNElTVEFU fEVOQ0ZHNERBVEF8RU5TQVZFUFRSUykgDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6 IFNFUUlOVFNSQ1sweDBdIERGQ05UUkxbMHgwXSBERlNUQVRVU1sweDg5XTooRklGT0VNUHxIRE9O RXxQUkVMT0FEX0FWQUlMKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU0dfQ0FD SEVfU0hBRE9XWzB4Ml06KExBU1RfU0VHKSBTR19TVEFURVsweDBdIERGRlNYRlJDVExbMHgwXSAN CkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU09GRkNOVFsweDBdIE1ERkZTVEFUWzB4 NV06KEZJRk9GUkVFfERMWkVSTykgU0hBRERSID0gMHgwMCwgU0hDTlQgPSAweDAgDQpGZWIgMTYg MTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IEhBRERSID0gMHgwMCwgSENOVCA9IDB4MCBDQ1NHQ1RM WzB4MF0gDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IA0KRmViIDE2IDExOjE3OjE2 IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBGSUZPMSBBY3RpdmUsIExPTkdKTVAgPT0gMHg4MjllLCBT Q0IgMHhmDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNFUUlNT0RFWzB4M2ZdOihF TkNGRzRUQ01EfEVOQ0ZHNElDTUR8RU5DRkc0VFNUQVR8RU5DRkc0SVNUQVR8RU5DRkc0REFUQXxF TlNBVkVQVFJTKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU0VRSU5UU1JDWzB4 MF0gREZDTlRSTFsweDRdOihESVJFQ1RJT04pIERGU1RBVFVTWzB4ODldOihGSUZPRU1QfEhET05F fFBSRUxPQURfQVZBSUwpIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBTR19DQUNI RV9TSEFET1dbMHgzXTooTEFTVF9TRUdfRE9ORXxMQVNUX1NFRykgU0dfU1RBVEVbMHgwXSANCkZl YiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogREZGU1hGUkNUTFsweDBdIFNPRkZDTlRbMHgw XSBNREZGU1RBVFsweDE0XTooRExaRVJPfExBU1RTRE9ORSkgDQpGZWIgMTYgMTE6MTc6MTYgZGFz dGVzdCBrZXJuZWw6IFNIQUREUiA9IDB4MDYsIFNIQ05UID0gMHgwIEhBRERSID0gMHgwMCwgSENO VCA9IDB4MCANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogQ0NTR0NUTFsweDEwXToo U0dfQ0FDSEVfQVZBSUwpIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBMUUlOOiAw eDU1IDB4MCAweDAgMHgxIDB4MCAweDEgMHgwIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCAw eDAgMHgwIDB4MCAweDAgMHgwIDB4MCANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDog YWhkMTogTFFJU1RBVEUgPSAweDAsIExRT1NUQVRFID0gMHgwLCBPUFRJT05NT0RFID0gMHg0Mg0K RmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBPU19TUEFDRV9DTlQgPSAweDIw IE1BWENNRENOVCA9IDB4MQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBT QVZFRF9TQ1NJSUQgPSAweDAgU0FWRURfTFVOID0gMHgwDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVz dCBrZXJuZWw6IFNJTU9ERTBbMHhjXTooRU5PVkVSUlVOfEVOSU9FUlIpIA0KRmViIDE2IDExOjE3 OjE2IGRhc3Rlc3Qga2VybmVsOiBDQ1NDQkNUTFsweDRdOihDQ1NDQkRJUikgDQpGZWIgMTYgMTE6 MTc6MTYgZGFzdGVzdCBrZXJuZWw6IGFoZDE6IFJFRzAgPT0gMHhmLCBTSU5ERVggPSAweDExMSwg RElOREVYID0gMHgxMDQNCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogYWhkMTogU0NC UFRSID09IDB4ZiwgU0NCX05FWFQgPT0gMHhmZjgwLCBTQ0JfTkVYVDIgPT0gMHhmZjRjDQpGZWIg MTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IENEQiAzIDAgMCAwIDIwIDANCkZlYiAxNiAxMTox NzoxNiBkYXN0ZXN0IGtlcm5lbDogU1RBQ0s6IDB4ZmQgMHgxNDAgMHgwIDB4MCAweDAgMHgyODUg MHgyODUgMHhiOQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiA8PDw8PDw8PDw8PDw8 PDw8PCBEdW1wIENhcmQgU3RhdGUgRW5kcyA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCkZlYiAxNiAxMTox NzoxNiBkYXN0ZXN0IGtlcm5lbDogKHByb2JlMTY6YWhkMTowOjE6MCk6IFNDQiAweGYgLSB0aW1l ZCBvdXQNCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogKHByb2JlMTY6YWhkMTowOjE6 MCk6IEJEUiBtZXNzYWdlIGluIG1lc3NhZ2UgYnVmZmVyDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVz dCBrZXJuZWw6IGFoZDE6IFJlY292ZXJ5IEluaXRpYXRlZCAtIENhcmQgd2FzIG5vdCBwYXVzZWQN CkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogPj4+Pj4+Pj4+Pj4+Pj4+Pj4+IER1bXAg Q2FyZCBTdGF0ZSBCZWdpbnMgPDw8PDw8PDw8PDw8PDw8PDwNCkZlYiAxNiAxMToxNzoxNiBkYXN0 ZXN0IGtlcm5lbDogYWhkMTogRHVtcGluZyBDYXJkIFN0YXRlIGF0IHByb2dyYW0gYWRkcmVzcyAw eDFjZSBNb2RlIDB4MTENCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogSU5UU1RBVFsw eDBdIFNFTE9JRFsweDFdIFNFTElEWzB4MTBdIEhTX01BSUxCT1hbMHgwXSANCkZlYiAxNiAxMTox NzoxNiBkYXN0ZXN0IGtlcm5lbDogSU5UQ1RMWzB4ODBdOihTV1RNSU5UTUFTSykgU0VRSU5UU1RB VFsweDBdIFNBVkVEX01PREVbMHgxMV0gDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6 IERGRlNUQVRbMHgxMV06KENVUlJGSUZPXzF8RklGTzBGUkVFKSBTQ1NJU0lHSVsweDE0XTooUF9E QVRBT1VUfEJTWUl8QVROSSkgDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNDU0lQ SEFTRVsweDBdIFNDU0lCVVNbMHg4MF0gTEFTVFBIQVNFWzB4ODBdOihQX0NPTU1BTkQpIA0KRmVi IDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBTQ1NJU0VRMFsweDBdIFNDU0lTRVExWzB4MTJd OihFTkFVVE9BVE5QfEVOUlNFTEkpIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBT RVFDVEwwWzB4MTBdOihGQVNUTU9ERSkgU0VRSU5UQ1RMWzB4MF0gU0VRX0ZMQUdTWzB4MF0gDQpG ZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNFUV9GTEFHUzJbMHg0XTooU0VMRUNUT1VU X1FGUk9aRU4pIFFGUkVFWkVfQ09VTlRbMHgyXSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtl cm5lbDogS0VSTkVMX1FGUkVFWkVfQ09VTlRbMHgyXSBNS19NRVNTQUdFX1NDQlsweGZmMDBdIE1L X01FU1NBR0VfU0NTSUlEWzB4ZmZdIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBT U1RBVDBbMHgwXSBTU1RBVDFbMHgwXSBTU1RBVDJbMHgwXSBTU1RBVDNbMHgwXSBQRVJSRElBR1sw eGMwXTooSElQRVJSfEhJWkVSTykgDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNJ TU9ERTFbMHhhY106KEVOU0NTSVBFUlJ8RU5CVVNGUkVFfEVOU0NTSVJTVHxFTlNFTFRJTU8pIA0K RmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBMUUlTVEFUMFsweDBdIExRSVNUQVQxWzB4 MF0gTFFJU1RBVDJbMHg4MF06KFBBQ0tFVElaRUQpIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qg a2VybmVsOiBMUU9TVEFUMFsweDBdIExRT1NUQVQxWzB4MF0gTFFPU1RBVDJbMHg4MF0gDQpGZWIg MTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2Vy bmVsOiBTQ0IgQ291bnQgPSAxNiBDTURTX1BFTkRJTkcgPSAyIExBU1RTQ0IgMHhmIENVUlJTQ0Ig MHhmIE5FWFRTQ0IgMHgwDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IHFpbnN0YXJ0 ID0gMjcgcWluZmlmb25leHQgPSAyNw0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBR SU5GSUZPOg0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBXQUlUSU5HX1RJRF9RVUVV RVM6DQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFBlbmRpbmcgbGlzdDoNCkZlYiAx NiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogMSBGSUZPX1VTRVsweDBdIFNDQl9DT05UUk9MWzB4 NDBdOihESVNDRU5CKSBTQ0JfU0NTSUlEWzB4N10gDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBr ZXJuZWw6IDE1IEZJRk9fVVNFWzB4MF0gU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4MTdd IA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBUb3RhbCAyDQpGZWIgMTYgMTE6MTc6 MTYgZGFzdGVzdCBrZXJuZWw6IEtlcm5lbCBGcmVlIFNDQiBsaXN0OiAyIDMgNCA1IDYgNyA4IDkg MTAgMTEgMTIgMTMgMTQgMCANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU2VxdWVu Y2VyIENvbXBsZXRlIERNQS1pbnByb2cgbGlzdDogDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBr ZXJuZWw6IFNlcXVlbmNlciBDb21wbGV0ZSBsaXN0OiANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0 IGtlcm5lbDogU2VxdWVuY2VyIERNQS1VcCBhbmQgQ29tcGxldGUgbGlzdDogDQpGZWIgMTYgMTE6 MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNlcXVlbmNlciBPbiBRRnJlZXplIGFuZCBDb21wbGV0ZSBs aXN0OiANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogDQpGZWIgMTYgMTE6MTc6MTYg ZGFzdGVzdCBrZXJuZWw6IA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBG SUZPMCBGcmVlLCBMT05HSk1QID09IDB4ODBmZiwgU0NCIDB4MA0KRmViIDE2IDExOjE3OjE2IGRh c3Rlc3Qga2VybmVsOiBTRVFJTU9ERVsweDNmXTooRU5DRkc0VENNRHxFTkNGRzRJQ01EfEVOQ0ZH NFRTVEFUfEVOQ0ZHNElTVEFUfEVOQ0ZHNERBVEF8RU5TQVZFUFRSUykgDQpGZWIgMTYgMTE6MTc6 MTYgZGFzdGVzdCBrZXJuZWw6IFNFUUlOVFNSQ1sweDBdIERGQ05UUkxbMHgwXSBERlNUQVRVU1sw eDg5XTooRklGT0VNUHxIRE9ORXxQUkVMT0FEX0FWQUlMKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0 ZXN0IGtlcm5lbDogU0dfQ0FDSEVfU0hBRE9XWzB4Ml06KExBU1RfU0VHKSBTR19TVEFURVsweDBd IERGRlNYRlJDVExbMHgwXSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU09GRkNO VFsweDBdIE1ERkZTVEFUWzB4NV06KEZJRk9GUkVFfERMWkVSTykgU0hBRERSID0gMHgwMCwgU0hD TlQgPSAweDAgDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IEhBRERSID0gMHgwMCwg SENOVCA9IDB4MCBDQ1NHQ1RMWzB4MF0gDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6 IA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBGSUZPMSBBY3RpdmUsIExP TkdKTVAgPT0gMHg4MjllLCBTQ0IgMHhmDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6 IFNFUUlNT0RFWzB4M2ZdOihFTkNGRzRUQ01EfEVOQ0ZHNElDTUR8RU5DRkc0VFNUQVR8RU5DRkc0 SVNUQVR8RU5DRkc0REFUQXxFTlNBVkVQVFJTKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtl cm5lbDogU0VRSU5UU1JDWzB4MF0gREZDTlRSTFsweDRdOihESVJFQ1RJT04pIERGU1RBVFVTWzB4 ODldOihGSUZPRU1QfEhET05FfFBSRUxPQURfQVZBSUwpIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rl c3Qga2VybmVsOiBTR19DQUNIRV9TSEFET1dbMHgzXTooTEFTVF9TRUdfRE9ORXxMQVNUX1NFRykg U0dfU1RBVEVbMHgwXSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogREZGU1hGUkNU TFsweDBdIFNPRkZDTlRbMHgwXSBNREZGU1RBVFsweDE0XTooRExaRVJPfExBU1RTRE9ORSkgDQpG ZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNIQUREUiA9IDB4MDYsIFNIQ05UID0gMHgw IEhBRERSID0gMHgwMCwgSENOVCA9IDB4MCANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5l bDogQ0NTR0NUTFsweDEwXTooU0dfQ0FDSEVfQVZBSUwpIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rl c3Qga2VybmVsOiBMUUlOOiAweDU1IDB4MCAweDAgMHgxIDB4MCAweDEgMHgwIDB4MCAweDAgMHgw IDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCANCkZlYiAxNiAxMToxNzox NiBkYXN0ZXN0IGtlcm5lbDogYWhkMTogTFFJU1RBVEUgPSAweDAsIExRT1NUQVRFID0gMHgwLCBP UFRJT05NT0RFID0gMHg0Mg0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBP U19TUEFDRV9DTlQgPSAweDIwIE1BWENNRENOVCA9IDB4MQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rl c3Qga2VybmVsOiBhaGQxOiBTQVZFRF9TQ1NJSUQgPSAweDAgU0FWRURfTFVOID0gMHgwDQpGZWIg MTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNJTU9ERTBbMHhjXTooRU5PVkVSUlVOfEVOSU9F UlIpIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBDQ1NDQkNUTFsweDRdOihDQ1ND QkRJUikgDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IGFoZDE6IFJFRzAgPT0gMHhm LCBTSU5ERVggPSAweDExMSwgRElOREVYID0gMHgxMDQNCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0 IGtlcm5lbDogYWhkMTogU0NCUFRSID09IDB4ZiwgU0NCX05FWFQgPT0gMHhmZjgwLCBTQ0JfTkVY VDIgPT0gMHhmZjRjDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IENEQiAzIDAgMCAw IDIwIDANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU1RBQ0s6IDB4ZmQgMHgxNDAg MHgwIDB4MCAweDAgMHgyODUgMHgyODUgMHhiOQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2Vy bmVsOiA8PDw8PDw8PDw8PDw8PDw8PCBEdW1wIENhcmQgU3RhdGUgRW5kcyA+Pj4+Pj4+Pj4+Pj4+ Pj4+Pj4NCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogKHByb2JlMTY6YWhkMTowOjE6 MCk6IFNDQiAweGYgLSB0aW1lZCBvdXQNCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDog KHByb2JlMTY6YWhkMTowOjE6MCk6IG5vIGxvbmdlciBpbiB0aW1lb3V0LCBzdGF0dXMgPSAyNGIN CkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogYWhkMTogSXNzdWVkIENoYW5uZWwgQSBC dXMgUmVzZXQuIDIgU0NCcyBhYm9ydGVkDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6 IGFoZDE6IFVuZXhwZWN0ZWQgUEtUIGJ1c2ZyZWUgY29uZGl0aW9uDQpGZWIgMTYgMTE6MTc6MTYg ZGFzdGVzdCBrZXJuZWw6ID4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBEdW1wIENhcmQgU3RhdGUgQmVnaW5z IDw8PDw8PDw8PDw8PDw8PDw8DQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IGFoZDE6 IER1bXBpbmcgQ2FyZCBTdGF0ZSBhdCBwcm9ncmFtIGFkZHJlc3MgMHgxY2UgTW9kZSAweDMzDQpG ZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IENhcmQgd2FzIHBhdXNlZA0KRmViIDE2IDEx OjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBJTlRTVEFUWzB4OF06KFNDU0lJTlQpIFNFTE9JRFsweDBd IFNFTElEWzB4MF0gSFNfTUFJTEJPWFsweDBdIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2Vy bmVsOiBJTlRDVExbMHgwXSBTRVFJTlRTVEFUWzB4MF0gU0FWRURfTU9ERVsweDExXSBERkZTVEFU WzB4MzBdOihDVVJSRklGT18wfEZJRk8wRlJFRXxGSUZPMUZSRUUpIA0KRmViIDE2IDExOjE3OjE2 IGRhc3Rlc3Qga2VybmVsOiBTQ1NJU0lHSVsweDBdOihQX0RBVEFPVVQpIFNDU0lQSEFTRVsweDBd IFNDU0lCVVNbMHgwXSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogTEFTVFBIQVNF WzB4MV06KFBfREFUQU9VVHxQX0JVU0ZSRUUpIFNDU0lTRVEwWzB4MF0gDQpGZWIgMTYgMTE6MTc6 MTYgZGFzdGVzdCBrZXJuZWw6IFNDU0lTRVExWzB4MTJdOihFTkFVVE9BVE5QfEVOUlNFTEkpIFNF UUNUTDBbMHgxMF06KEZBU1RNT0RFKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDog U0VRSU5UQ1RMWzB4MF0gU0VRX0ZMQUdTWzB4NDBdOihOT19DREJfU0VOVCkgU0VRX0ZMQUdTMlsw eDBdIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBRRlJFRVpFX0NPVU5UWzB4MF0g S0VSTkVMX1FGUkVFWkVfQ09VTlRbMHgwXSBNS19NRVNTQUdFX1NDQlsweGZmMDBdIA0KRmViIDE2 IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBNS19NRVNTQUdFX1NDU0lJRFsweGZmXSBTU1RBVDBb MHgwXSBTU1RBVDFbMHg4XTooQlVTRlJFRSkgDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJu ZWw6IFNTVEFUMlsweDBdIFNTVEFUM1sweDBdIFBFUlJESUFHWzB4MF0gU0lNT0RFMVsweGFjXToo RU5TQ1NJUEVSUnxFTkJVU0ZSRUV8RU5TQ1NJUlNUfEVOU0VMVElNTykgDQpGZWIgMTYgMTE6MTc6 MTYgZGFzdGVzdCBrZXJuZWw6IExRSVNUQVQwWzB4MF0gTFFJU1RBVDFbMHgwXSBMUUlTVEFUMlsw eDBdIExRT1NUQVQwWzB4MF0gDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IExRT1NU QVQxWzB4MF0gTFFPU1RBVDJbMHgwXSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDog DQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNDQiBDb3VudCA9IDE2IENNRFNfUEVO RElORyA9IDIgTEFTVFNDQiAweGYgQ1VSUlNDQiAweGYgTkVYVFNDQiAweDANCkZlYiAxNiAxMTox NzoxNiBkYXN0ZXN0IGtlcm5lbDogcWluc3RhcnQgPSAyIHFpbmZpZm9uZXh0ID0gMg0KRmViIDE2 IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBRSU5GSUZPOg0KRmViIDE2IDExOjE3OjE2IGRhc3Rl c3Qga2VybmVsOiBXQUlUSU5HX1RJRF9RVUVVRVM6DQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBr ZXJuZWw6IDEgKCAweDEgKQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBQZW5kaW5n IGxpc3Q6DQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IDEgRklGT19VU0VbMHgwXSBT Q0JfQ09OVFJPTFsweDQwXTooRElTQ0VOQikgU0NCX1NDU0lJRFsweDE3XSANCkZlYiAxNiAxMTox NzoxNiBkYXN0ZXN0IGtlcm5lbDogMTUgRklGT19VU0VbMHgwXSBTQ0JfQ09OVFJPTFsweDUwXToo TUtfTUVTU0FHRXxESVNDRU5CKSBTQ0JfU0NTSUlEWzB4N10gDQpGZWIgMTYgMTE6MTc6MTYgZGFz dGVzdCBrZXJuZWw6IFRvdGFsIDINCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogS2Vy bmVsIEZyZWUgU0NCIGxpc3Q6IDIgMyA0IDUgNiA3IDggOSAxMCAxMSAxMiAxMyAxNCAwIA0KRmVi IDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBTZXF1ZW5jZXIgQ29tcGxldGUgRE1BLWlucHJv ZyBsaXN0OiANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU2VxdWVuY2VyIENvbXBs ZXRlIGxpc3Q6IA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBTZXF1ZW5jZXIgRE1B LVVwIGFuZCBDb21wbGV0ZSBsaXN0OiANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDog U2VxdWVuY2VyIE9uIFFGcmVlemUgYW5kIENvbXBsZXRlIGxpc3Q6IA0KRmViIDE2IDExOjE3OjE2 IGRhc3Rlc3Qga2VybmVsOiANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogDQpGZWIg MTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IGFoZDE6IEZJRk8wIEZyZWUsIExPTkdKTVAgPT0g MHg4MGZmLCBTQ0IgMHgwDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNFUUlNT0RF WzB4M2ZdOihFTkNGRzRUQ01EfEVOQ0ZHNElDTUR8RU5DRkc0VFNUQVR8RU5DRkc0SVNUQVR8RU5D Rkc0REFUQXxFTlNBVkVQVFJTKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU0VR SU5UU1JDWzB4MF0gREZDTlRSTFsweDBdIERGU1RBVFVTWzB4ODldOihGSUZPRU1QfEhET05FfFBS RUxPQURfQVZBSUwpIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBTR19DQUNIRV9T SEFET1dbMHgyXTooTEFTVF9TRUcpIFNHX1NUQVRFWzB4MF0gREZGU1hGUkNUTFsweDBdIA0KRmVi IDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBTT0ZGQ05UWzB4MF0gTURGRlNUQVRbMHg1XToo RklGT0ZSRUV8RExaRVJPKSBTSEFERFIgPSAweDAwLCBTSENOVCA9IDB4MCANCkZlYiAxNiAxMTox NzoxNiBkYXN0ZXN0IGtlcm5lbDogSEFERFIgPSAweDAwLCBIQ05UID0gMHgwIENDU0dDVExbMHgx MF06KFNHX0NBQ0hFX0FWQUlMKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogDQpG ZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IGFoZDE6IEZJRk8xIEZyZWUsIExPTkdKTVAg PT0gMHg4MDllLCBTQ0IgMHgwDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFNFUUlN T0RFWzB4M2ZdOihFTkNGRzRUQ01EfEVOQ0ZHNElDTUR8RU5DRkc0VFNUQVR8RU5DRkc0SVNUQVR8 RU5DRkc0REFUQXxFTlNBVkVQVFJTKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDog U0VRSU5UU1JDWzB4MF0gREZDTlRSTFsweDBdIERGU1RBVFVTWzB4ODldOihGSUZPRU1QfEhET05F fFBSRUxPQURfQVZBSUwpIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBTR19DQUNI RV9TSEFET1dbMHgyXTooTEFTVF9TRUcpIFNHX1NUQVRFWzB4MF0gREZGU1hGUkNUTFsweDBdIA0K RmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBTT0ZGQ05UWzB4MF0gTURGRlNUQVRbMHg1 XTooRklGT0ZSRUV8RExaRVJPKSBTSEFERFIgPSAweDAwLCBTSENOVCA9IDB4MCANCkZlYiAxNiAx MToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogSEFERFIgPSAweDAwLCBIQ05UID0gMHgwIENDU0dDVExb MHgxMF06KFNHX0NBQ0hFX0FWQUlMKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDog TFFJTjogMHgwIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCAweDAgMHgw IDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtl cm5lbDogYWhkMTogTFFJU1RBVEUgPSAweDAsIExRT1NUQVRFID0gMHgwLCBPUFRJT05NT0RFID0g MHg0Mg0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBPU19TUEFDRV9DTlQg PSAweDIwIE1BWENNRENOVCA9IDB4MA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBh aGQxOiBTQVZFRF9TQ1NJSUQgPSAweDAgU0FWRURfTFVOID0gMHgwDQpGZWIgMTYgMTE6MTc6MTYg ZGFzdGVzdCBrZXJuZWw6IA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBTSU1PREUw WzB4Y106KEVOT1ZFUlJVTnxFTklPRVJSKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5l bDogQ0NTQ0JDVExbMHg0XTooQ0NTQ0JESVIpIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2Vy bmVsOiBhaGQxOiBSRUcwID09IDB4ZiwgU0lOREVYID0gMHgxMzMsIERJTkRFWCA9IDB4MTAyDQpG ZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IGFoZDE6IFNDQlBUUiA9PSAweGYsIFNDQl9O RVhUID09IDB4ZmZjMCwgU0NCX05FWFQyID09IDB4MQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qg a2VybmVsOiBDREIgMWEgMCBhIDAgMTQgMA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVs OiBTVEFDSzogMHhmZCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCAweDM5DQpGZWIgMTYgMTE6MTc6 MTYgZGFzdGVzdCBrZXJuZWw6IDw8PDw8PDw8PDw8PDw8PDw8IER1bXAgQ2FyZCBTdGF0ZSBFbmRz ID4+Pj4+Pj4+Pj4+Pj4+Pj4+Pg0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBDb3Bp ZWQgMTggYnl0ZXMgb2Ygc2Vuc2UgZGF0YSBvZmZzZXQgMTI6IDB4NzAgMHgwIDB4NiAweDAgMHgw IDB4MCAweDAgMHhhIDB4MCAweDAgMHgwIDB4MCAweDI5IDB4MCAweDAgMHgwIDB4MCAweDANCkZl YiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogYWhkMTogUmVjb3ZlcnkgSW5pdGlhdGVkIC0g Q2FyZCB3YXMgbm90IHBhdXNlZA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiA+Pj4+ Pj4+Pj4+Pj4+Pj4+Pj4gRHVtcCBDYXJkIFN0YXRlIEJlZ2lucyA8PDw8PDw8PDw8PDw8PDw8PA0K RmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBEdW1waW5nIENhcmQgU3RhdGUg YXQgcHJvZ3JhbSBhZGRyZXNzIDB4YTggTW9kZSAweDANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0 IGtlcm5lbDogSU5UU1RBVFsweDBdIFNFTE9JRFsweDFdIFNFTElEWzB4MTBdIEhTX01BSUxCT1hb MHgwXSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogSU5UQ1RMWzB4ODBdOihTV1RN SU5UTUFTSykgU0VRSU5UU1RBVFsweDBdIFNBVkVEX01PREVbMHgxMV0gDQpGZWIgMTYgMTE6MTc6 MTYgZGFzdGVzdCBrZXJuZWw6IERGRlNUQVRbMHgzMV06KENVUlJGSUZPXzF8RklGTzBGUkVFfEZJ Rk8xRlJFRSkgU0NTSVNJR0lbMHgwXTooUF9EQVRBT1VUKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0 ZXN0IGtlcm5lbDogU0NTSVBIQVNFWzB4MF0gU0NTSUJVU1sweDBdIExBU1RQSEFTRVsweDFdOihQ X0RBVEFPVVR8UF9CVVNGUkVFKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU0NT SVNFUTBbMHgwXSBTQ1NJU0VRMVsweDEyXTooRU5BVVRPQVROUHxFTlJTRUxJKSANCkZlYiAxNiAx MToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU0VRQ1RMMFsweDEwXTooRkFTVE1PREUpIFNFUUlOVENU TFsweDBdIFNFUV9GTEFHU1sweDBdIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBT RVFfRkxBR1MyWzB4MF0gUUZSRUVaRV9DT1VOVFsweDJdIEtFUk5FTF9RRlJFRVpFX0NPVU5UWzB4 Ml0gDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IE1LX01FU1NBR0VfU0NCWzB4ZmYw MF0gTUtfTUVTU0FHRV9TQ1NJSURbMHhmZl0gU1NUQVQwWzB4MF0gDQpGZWIgMTYgMTE6MTc6MTYg ZGFzdGVzdCBrZXJuZWw6IFNTVEFUMVsweDhdOihCVVNGUkVFKSBTU1RBVDJbMHgwXSBTU1RBVDNb MHgwXSBQRVJSRElBR1sweGM4XTooQUlQRVJSfEhJUEVSUnxISVpFUk8pIA0KRmViIDE2IDExOjE3 OjE2IGRhc3Rlc3Qga2VybmVsOiBTSU1PREUxWzB4YTRdOihFTlNDU0lQRVJSfEVOU0NTSVJTVHxF TlNFTFRJTU8pIExRSVNUQVQwWzB4MF0gDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6 IExRSVNUQVQxWzB4MF0gTFFJU1RBVDJbMHgwXSBMUU9TVEFUMFsweDBdIExRT1NUQVQxWzB4MF0g DQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IExRT1NUQVQyWzB4MV06KExRT1NUT1Aw KSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogDQpGZWIgMTYgMTE6MTc6MTYgZGFz dGVzdCBrZXJuZWw6IFNDQiBDb3VudCA9IDE2IENNRFNfUEVORElORyA9IDIgTEFTVFNDQiAweDEg Q1VSUlNDQiAweDEgTkVYVFNDQiAweDANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDog cWluc3RhcnQgPSAxOCBxaW5maWZvbmV4dCA9IDE4DQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBr ZXJuZWw6IFFJTkZJRk86DQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IFdBSVRJTkdf VElEX1FVRVVFUzoNCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogUGVuZGluZyBsaXN0 Og0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiAxNSBGSUZPX1VTRVsweDBdIFNDQl9D T05UUk9MWzB4NTBdOihNS19NRVNTQUdFfERJU0NFTkIpIFNDQl9TQ1NJSURbMHg3XSANCkZlYiAx NiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogVG90YWwgMQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rl c3Qga2VybmVsOiBLZXJuZWwgRnJlZSBTQ0IgbGlzdDogMSAyIDMgNCA1IDYgNyA4IDkgMTAgMTEg MTIgMTMgMTQgMCANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU2VxdWVuY2VyIENv bXBsZXRlIERNQS1pbnByb2cgbGlzdDogDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6 IFNlcXVlbmNlciBDb21wbGV0ZSBsaXN0OiANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5l bDogU2VxdWVuY2VyIERNQS1VcCBhbmQgQ29tcGxldGUgbGlzdDogDQpGZWIgMTYgMTE6MTc6MTYg ZGFzdGVzdCBrZXJuZWw6IFNlcXVlbmNlciBPbiBRRnJlZXplIGFuZCBDb21wbGV0ZSBsaXN0OiAN CkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVz dCBrZXJuZWw6IA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBGSUZPMCBG cmVlLCBMT05HSk1QID09IDB4ODBmZiwgU0NCIDB4MA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qg a2VybmVsOiBTRVFJTU9ERVsweDNmXTooRU5DRkc0VENNRHxFTkNGRzRJQ01EfEVOQ0ZHNFRTVEFU fEVOQ0ZHNElTVEFUfEVOQ0ZHNERBVEF8RU5TQVZFUFRSUykgDQpGZWIgMTYgMTE6MTc6MTYgZGFz dGVzdCBrZXJuZWw6IFNFUUlOVFNSQ1sweDBdIERGQ05UUkxbMHgwXSBERlNUQVRVU1sweDg5XToo RklGT0VNUHxIRE9ORXxQUkVMT0FEX0FWQUlMKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtl cm5lbDogU0dfQ0FDSEVfU0hBRE9XWzB4Ml06KExBU1RfU0VHKSBTR19TVEFURVsweDBdIERGRlNY RlJDVExbMHgwXSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU09GRkNOVFsweDBd IE1ERkZTVEFUWzB4NV06KEZJRk9GUkVFfERMWkVSTykgU0hBRERSID0gMHgwMCwgU0hDTlQgPSAw eDAgDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IEhBRERSID0gMHgwMCwgSENOVCA9 IDB4MCBDQ1NHQ1RMWzB4MTBdOihTR19DQUNIRV9BVkFJTCkgDQpGZWIgMTYgMTE6MTc6MTYgZGFz dGVzdCBrZXJuZWw6IA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBGSUZP MSBGcmVlLCBMT05HSk1QID09IDB4ODI5ZSwgU0NCIDB4MQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rl c3Qga2VybmVsOiBTRVFJTU9ERVsweDNmXTooRU5DRkc0VENNRHxFTkNGRzRJQ01EfEVOQ0ZHNFRT VEFUfEVOQ0ZHNElTVEFUfEVOQ0ZHNERBVEF8RU5TQVZFUFRSUykgDQpGZWIgMTYgMTE6MTc6MTYg ZGFzdGVzdCBrZXJuZWw6IFNFUUlOVFNSQ1sweDBdIERGQ05UUkxbMHgwXSBERlNUQVRVU1sweDg5 XTooRklGT0VNUHxIRE9ORXxQUkVMT0FEX0FWQUlMKSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0 IGtlcm5lbDogU0dfQ0FDSEVfU0hBRE9XWzB4Ml06KExBU1RfU0VHKSBTR19TVEFURVsweDBdIERG RlNYRlJDVExbMHgwXSANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogU09GRkNOVFsw eDBdIE1ERkZTVEFUWzB4NV06KEZJRk9GUkVFfERMWkVSTykgU0hBRERSID0gMHgwMCwgU0hDTlQg PSAweDAgDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IEhBRERSID0gMHgwMCwgSENO VCA9IDB4MCBDQ1NHQ1RMWzB4MTBdOihTR19DQUNIRV9BVkFJTCkgDQpGZWIgMTYgMTE6MTc6MTYg ZGFzdGVzdCBrZXJuZWw6IExRSU46IDB4NTUgMHgwIDB4MCAweDEgMHgwIDB4NyAweDAgMHgwIDB4 MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIDB4MCAweDAgMHgwIA0KRmViIDE2IDEx OjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBMUUlTVEFURSA9IDB4MCwgTFFPU1RBVEUgPSAw eDAsIE9QVElPTk1PREUgPSAweDQyDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IGFo ZDE6IE9TX1NQQUNFX0NOVCA9IDB4MjAgTUFYQ01EQ05UID0gMHgxDQpGZWIgMTYgMTE6MTc6MTYg ZGFzdGVzdCBrZXJuZWw6IGFoZDE6IFNBVkVEX1NDU0lJRCA9IDB4MCBTQVZFRF9MVU4gPSAweDAN CkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVz dCBrZXJuZWw6IFNJTU9ERTBbMHhjXTooRU5PVkVSUlVOfEVOSU9FUlIpIA0KRmViIDE2IDExOjE3 OjE2IGRhc3Rlc3Qga2VybmVsOiBDQ1NDQkNUTFsweDBdIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rl c3Qga2VybmVsOiBhaGQxOiBSRUcwID09IDB4MTZiZiwgU0lOREVYID0gMHgxMTEsIERJTkRFWCA9 IDB4MTA0DQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IGFoZDE6IFNDQlBUUiA9PSAw eDAsIFNDQl9ORVhUID09IDB4ZmYwMCwgU0NCX05FWFQyID09IDB4MA0KRmViIDE2IDExOjE3OjE2 IGRhc3Rlc3Qga2VybmVsOiBDREIgMCAwIDAgMCAwIDANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0 IGtlcm5lbDogU1RBQ0s6IDB4MzYgMHgyNCAweDE0MCAweDE0MCAweGZkIDB4MCAweDI4NSAweDI4 NQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiA8PDw8PDw8PDw8PDw8PDw8PCBEdW1w IENhcmQgU3RhdGUgRW5kcyA+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4NCkZlYiAxNiAxMToxNzoxNiBkYXN0 ZXN0IGtlcm5lbDogKHByb2JlMTU6YWhkMTowOjA6MSk6IFNDQiAweGYgLSB0aW1lZCBvdXQNCkZl YiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogKHByb2JlMTU6YWhkMTowOjA6MSk6IFF1ZXVp bmcgYSBCRFIgU0NCDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IChwcm9iZTE1OmFo ZDE6MDowOjEpOiBCdXMgRGV2aWNlIFJlc2V0IE1lc3NhZ2UgU2VudA0KRmViIDE2IDExOjE3OjE2 IGRhc3Rlc3Qga2VybmVsOiAocHJvYmUxNTphaGQxOjA6MDoxKTogbm8gbG9uZ2VyIGluIHRpbWVv dXQsIHN0YXR1cyA9IDI0Yg0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBhaGQxOiBC dXMgRGV2aWNlIFJlc2V0IG9uIEE6MC4gMSBTQ0JzIGFib3J0ZWQNCkZlYiAxNiAxMToxNzoxNiBk YXN0ZXN0IGtlcm5lbDogQ29waWVkIDE4IGJ5dGVzIG9mIHNlbnNlIGRhdGEgb2Zmc2V0IDEyOiAw eDcwIDB4MCAweDYgMHgwIDB4MCAweDAgMHgwIDB4YSAweDAgMHgwIDB4MCAweDAgMHgyOSAweDAg MHgwIDB4MCAweDAgMHgwDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IENvcGllZCAx OCBieXRlcyBvZiBzZW5zZSBkYXRhIG9mZnNldCAxMjogMHg3MCAweDAgMHg2IDB4MCAweDAgMHgw IDB4MCAweGEgMHgwIDB4MCAweDAgMHgwIDB4MjkgMHgwIDB4MCAweDAgMHgwIDB4MA0KRmViIDE2 IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBDb3BpZWQgMTggYnl0ZXMgb2Ygc2Vuc2UgZGF0YSBv ZmZzZXQgMTI6IDB4NzAgMHgwIDB4NiAweDAgMHgwIDB4MCAweDAgMHhhIDB4MCAweDAgMHgwIDB4 MCAweDI5IDB4MCAweDAgMHgwIDB4MCAweDANCkZlYiAxNiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5l bDogQ29waWVkIDE4IGJ5dGVzIG9mIHNlbnNlIGRhdGEgb2Zmc2V0IDEyOiAweDcwIDB4MCAweDYg MHgwIDB4MCAweDAgMHgwIDB4YSAweDAgMHgwIDB4MCAweDAgMHgyOSAweDAgMHgwIDB4MCAweDAg MHgwDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IGRhMSBhdCBhaGQxIGJ1cyAwIHRh cmdldCAwIGx1biAxDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IGRhMTogPFRPWU9V IE5ldFN0b3IgREE3NTEwUyAzNDFCPiBGaXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMyBkZXZpY2Ug DQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IGRhMTogMzIwLjAwME1CL3MgdHJhbnNm ZXJzICgxNjAuMDAwTUh6LCBvZmZzZXQgMTI3LCAxNmJpdCksIFRhZ2dlZCBRdWV1ZWluZyBFbmFi bGVkDQpGZWIgMTYgMTE6MTc6MTYgZGFzdGVzdCBrZXJuZWw6IGRhMTogMTAwMDAwTUIgKDIwNDgw MDAwMCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDEyNzQ4QykNCkZlYiAxNiAxMToxNzox NiBkYXN0ZXN0IGtlcm5lbDogZGEwIGF0IGFoZDEgYnVzIDAgdGFyZ2V0IDAgbHVuIDANCkZlYiAx NiAxMToxNzoxNiBkYXN0ZXN0IGtlcm5lbDogZGEwOiA8VE9ZT1UgTmV0U3RvciBEQTc1MTBTIDM0 MUI+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0zIGRldmljZSANCkZlYiAxNiAxMToxNzoxNiBk YXN0ZXN0IGtlcm5lbDogZGEwOiAzMjAuMDAwTUIvcyB0cmFuc2ZlcnMgKDE2MC4wMDBNSHosIG9m ZnNldCAxMjcsIDE2Yml0KSwgVGFnZ2VkIFF1ZXVlaW5nIEVuYWJsZWQNCkZlYiAxNiAxMToxNzox NiBkYXN0ZXN0IGtlcm5lbDogZGEwOiAxMDAwMDBNQiAoMjA0ODAwMDAwIDUxMiBieXRlIHNlY3Rv cnM6IDI1NUggNjNTL1QgMTI3NDhDKQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBk YTIgYXQgYWhkMSBidXMgMCB0YXJnZXQgMSBsdW4gMA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qg a2VybmVsOiBkYTI6IDxUT1lPVSBOZXRTdG9yIERBNzUxMFMgMzQxQj4gRml4ZWQgRGlyZWN0IEFj Y2VzcyBTQ1NJLTMgZGV2aWNlIA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBkYTI6 IDMyMC4wMDBNQi9zIHRyYW5zZmVycyAoMTYwLjAwME1Ieiwgb2Zmc2V0IDEyNywgMTZiaXQpLCBU YWdnZWQgUXVldWVpbmcgRW5hYmxlZA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBk YTI6IDcyODQ1Nk1CICgxNDkxODc3ODg4IDUxMiBieXRlIHNlY3RvcnM6IDI1NUggNjNTL1QgOTI4 NjVDKQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBkYTMgYXQgYWhkMSBidXMgMCB0 YXJnZXQgMSBsdW4gMQ0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBkYTM6IDxUT1lP VSBOZXRTdG9yIERBNzUxMFMgMzQxQj4gRml4ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTMgZGV2aWNl IA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBkYTM6IDMyMC4wMDBNQi9zIHRyYW5z ZmVycyAoMTYwLjAwME1Ieiwgb2Zmc2V0IDEyNywgMTZiaXQpLCBUYWdnZWQgUXVldWVpbmcgRW5h YmxlZA0KRmViIDE2IDExOjE3OjE2IGRhc3Rlc3Qga2VybmVsOiBkYTM6IDEyMDAwMDBNQiAoMjQ1 NzYwMDAwMCA1MTIgYnl0ZSBzZWN0b3JzOiAyNTVIIDYzUy9UIDE1Mjk3OEMpDQpGZWIgMTYgMTE6 MTc6MTYgZGFzdGVzdCBrZXJuZWw6IE1vdW50aW5nIHJvb3QgZnJvbSB1ZnM6L2Rldi9hYWNkMHMx YQ0KRmViIDE2IDExOjE3OjE3IGRhc3Rlc3Qga2VybmVsOiBlbTA6IExpbmsgaXMgdXAgMTAwIE1i cHMgRnVsbCBEdXBsZXgNCkZlYiAxNiAxMToxNzo0NCBkYXN0ZXN0IGxvZ2luOiBST09UIExPR0lO IChyb290KSBPTiB0dHl2MA0K --=-Cy7OI+WGYBUP6PPaoT9T-- --=-5+NyQ6SWc3/wriYWGNNN Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8?= =?UTF-8?Q?=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCEsC4/cVsHxFZiIoRAvVLAJ99Zi5FFGyU9Y7Iglp5Fp4oqeQQegCffdg+ Yb6bTC8m/XIY/fEqYzuyLzs= =qwj4 -----END PGP SIGNATURE----- --=-5+NyQ6SWc3/wriYWGNNN-- From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 16 03:58:27 2005 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 034C716A4CE for ; Wed, 16 Feb 2005 03:58:27 +0000 (GMT) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 840A343D48 for ; Wed, 16 Feb 2005 03:58:26 +0000 (GMT) (envelope-from lydianconcepts@gmail.com) Received: by rproxy.gmail.com with SMTP id j1so26085rnf for ; Tue, 15 Feb 2005 19:58:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=MY3rmtj+vgIAmf8GULfDATZCE4ABClu/Xagl4fkieQn2GrmozYKiApuK8DelInfk5ZelAXDQAbr+7XZIGXQkKwsGKybcnx92eSrIV2zj6hNsw8WNCk99gZWGiuhYjlhHwSUc55KkmFKDzyX6QtgId3zsE7lOJyq5AyaBx8NvpHI= Received: by 10.38.101.54 with SMTP id y54mr113650rnb; Tue, 15 Feb 2005 19:58:25 -0800 (PST) Received: by 10.38.104.14 with HTTP; Tue, 15 Feb 2005 19:58:25 -0800 (PST) Message-ID: <7579f7fb050215195866fbecc1@mail.gmail.com> Date: Tue, 15 Feb 2005 19:58:25 -0800 From: Matthew Jacob To: Scott Long In-Reply-To: <42128E4A.8080101@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <20050215215908.GA1012@schweikhardt.net> <7579f7fb05021515227e7b8539@mail.gmail.com> <42128E4A.8080101@samsco.org> cc: FreeBSD SCSI cc: mjacob@freebsd.org Subject: Re: cam_xpt.c 1.147 makes system hang at boot X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Matthew Jacob List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2005 03:58:27 -0000 > > Well, my guess is that the U160 drives the posted has are going to have > a fairly high ANSI rev number already. No, they're SCSI-3, not SCSI-4. > Let's just dig in and fix this > for real. That's not going to happen this week. > > Btw, does anyone by change have access to a bus scanner to see what > Windows or Solaris does when scanning LUNs? I don't need one- I have target virtualization. Both Windows && Solaris use REPORT LUNS for Fibre Channel. I don't remember what either do for SPI- nothing really that interesting. From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 16 06:57:04 2005 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 4ECD116A4D0 for ; Wed, 16 Feb 2005 06:57:04 +0000 (GMT) Received: from cowbert.2y.net (d46h180.public.uconn.edu [137.99.46.180]) by mx1.FreeBSD.org (Postfix) with SMTP id 865DC43D5A for ; Wed, 16 Feb 2005 06:57:03 +0000 (GMT) (envelope-from sirmoo@cowbert.2y.net) Received: (qmail 21541 invoked by uid 1001); 16 Feb 2005 06:57:00 -0000 Date: Wed, 16 Feb 2005 01:57:00 -0500 From: "Peter C. Lai" To: freebsd-questions@freebsd.org Message-ID: <20050216065700.GB20992@cowbert.2y.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.6i cc: freebsd-hackers@freebsd.org cc: freebsd-scsi@freebsd.org cc: freebsd-hardware@freebsd.org Subject: vinum vs. DPT smartcacheIV raid 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, 16 Feb 2005 06:57:04 -0000 I have a box with DPT PM2044 SmartCacheIV UW-SCSI PCI cards which can do RAID-5 in hardware, but I'd have to use the DOS volume manager to set up the array. I have heard reports that vinum woudl be faster than using the native card. Is this true? Should I not bother with doing the hardware raid and just go with vinum? The rest of the system is a k6-2 400mhz with 256mb ram (amount might change). I will also have moderate network i/o on the pci bus (obviously). TIA, cowbert -- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/ From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 16 14:58:19 2005 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 ABFDA16A4CE for ; Wed, 16 Feb 2005 14:58:19 +0000 (GMT) Received: from cowbert.2y.net (d46h180.public.uconn.edu [137.99.46.180]) by mx1.FreeBSD.org (Postfix) with SMTP id 2BE8643D3F for ; Wed, 16 Feb 2005 14:58:17 +0000 (GMT) (envelope-from sirmoo@cowbert.2y.net) Received: (qmail 23591 invoked by uid 1001); 16 Feb 2005 14:58:16 -0000 Date: Wed, 16 Feb 2005 09:58:16 -0500 From: "Peter C. Lai" To: Matthew Jacob Message-ID: <20050216145816.GC20992@cowbert.2y.net> References: <20050216065700.GB20992@cowbert.2y.net> <7579f7fb050216000861d0959a@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7579f7fb050216000861d0959a@mail.gmail.com> User-Agent: Mutt/1.5.6i cc: freebsd-scsi@freebsd.org Subject: Re: vinum vs. DPT smartcacheIV raid 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, 16 Feb 2005 14:58:19 -0000 On Wed, Feb 16, 2005 at 12:08:42AM -0800, Matthew Jacob wrote: > I'd be more concerned about the age of these cards- they've got to be > at least 10 years old. They work and are hooked up to a bunch of IBM 9gb sca drives. Currently the first card boots gentoo or something (someone gave me the box; I don't have the root password so I haven't booted past the linux loader/grub/whatever). /stand/sysinstall sees all the drives fine. The cards actually are very forward-thinking, with a row of 15 blinkenlights reminiscent of Knight Rider, a design which has since firmly incorporated itself into the current bling-bling hardware. I know these cards are old, but fbsd supports them and I don't want to waste the drives on this rig. Also want to take a chance to play with RAID for free(tm). Hence the cc to freebsd-hackers. > > > On Wed, 16 Feb 2005 01:57:00 -0500, Peter C. Lai wrote: > > I have a box with DPT PM2044 SmartCacheIV UW-SCSI PCI cards which can do > > RAID-5 in hardware, but I'd have to use the DOS volume manager to set up > > the array. I have heard reports that vinum woudl be faster than using the > > native card. Is this true? Should I not bother with doing the hardware raid > > and just go with vinum? > > > > The rest of the system is a k6-2 400mhz with 256mb ram (amount might change). > > I will also have moderate network i/o on the pci bus (obviously). > > > > TIA, > > cowbert > > -- > > Peter C. Lai > > University of Connecticut > > Dept. of Molecular and Cell Biology > > Yale University School of Medicine > > SenseLab | Research Assistant > > http://cowbert.2y.net/ > > > > _______________________________________________ > > 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" > > -- Peter C. Lai University of Connecticut Dept. of Molecular and Cell Biology Yale University School of Medicine SenseLab | Research Assistant http://cowbert.2y.net/ From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 16 18:10:24 2005 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 C387E16A4CE; Wed, 16 Feb 2005 18:10:24 +0000 (GMT) Received: from aslan.scsiguy.com (mail.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1309E43D46; Wed, 16 Feb 2005 18:10:24 +0000 (GMT) (envelope-from gibbs@scsiguy.com) Received: from [10.0.0.90] (oriondc.dsl.frii.net [216.17.137.18]) (authenticated bits=0) by aslan.scsiguy.com (8.13.1/8.13.1) with ESMTP id j1GI9n1Y049743 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Feb 2005 11:10:11 -0700 (MST) (envelope-from gibbs@scsiguy.com) Date: Wed, 16 Feb 2005 11:09:39 -0700 From: "Justin T. Gibbs" To: Matthew Jacob , Jens Schweikhardt Message-ID: <62DFACAEF30DA6C81EF39A7F@[10.0.0.90]> In-Reply-To: <7579f7fb05021515227e7b8539@mail.gmail.com> References: <20050215215908.GA1012@schweikhardt.net> <7579f7fb05021515227e7b8539@mail.gmail.com> X-Mailer: Mulberry/3.1.6 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: FreeBSD SCSI cc: mjacob@freebsd.org Subject: Re: cam_xpt.c 1.147 makes system hang at boot X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Justin T. Gibbs" List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2005 18:10:24 -0000 Part of the problem may be that the current version of the aic79xx driver reports a max_lun of 255. This is correct once packetized protocol is negotiated, but problematic given CAMs current method of performing device probes. I've just checked in a change to drop the reported max_lun to the non-packetized limit of 63. -- Justin From owner-freebsd-scsi@FreeBSD.ORG Wed Feb 16 22:43:49 2005 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 EA36D16A4CE; Wed, 16 Feb 2005 22:43:49 +0000 (GMT) Received: from freebee.digiware.nl (dsl439.iae.nl [212.61.63.187]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A0D743D2D; Wed, 16 Feb 2005 22:43:48 +0000 (GMT) (envelope-from wjw@withagen.nl) Received: from [212.61.27.71] (dual.digiware.nl [212.61.27.71]) by freebee.digiware.nl (8.13.1/8.13.1) with ESMTP id j1GMhVc6085392; Wed, 16 Feb 2005 23:43:41 +0100 (CET) (envelope-from wjw@withagen.nl) Message-ID: <4213CC9E.20408@withagen.nl> Date: Wed, 16 Feb 2005 23:43:42 +0100 From: Willem Jan Withagen User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Peter C. Lai" References: <20050216065700.GB20992@cowbert.2y.net> In-Reply-To: <20050216065700.GB20992@cowbert.2y.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: freebsd-hardware@freebsd.org cc: freebsd-questions@freebsd.org cc: freebsd-scsi@freebsd.org Subject: Re: vinum vs. DPT smartcacheIV raid 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, 16 Feb 2005 22:43:50 -0000 Peter C. Lai wrote: > I have a box with DPT PM2044 SmartCacheIV UW-SCSI PCI cards which can do > RAID-5 in hardware, but I'd have to use the DOS volume manager to set up > the array. I have heard reports that vinum woudl be faster than using the > native card. Is this true? Should I not bother with doing the hardware raid > and just go with vinum? > > The rest of the system is a k6-2 400mhz with 256mb ram (amount might change). > I will also have moderate network i/o on the pci bus (obviously). I still have one here lingering around somewhere on a shelf. It ran a 4*1Gb diskarray RAID-5 when 1GB disk where still sort of big. So that is how old this card is. With that I did have some unplesant experiences with this card: - First and most major it seems that you need to have the right version firmware in it. Otherwise things might get seriously hossed at unexpected times. Just buffers timing out in the middle of the night. - The other issue was that my disk where in an external cabinet and once the cable came loose. It killed the raid as expected, but it took me a long time to find some tools to force the disk up the brute way. Just to see if I could recover some of the data. And like you say: Al these tools are DOS based. Currently I'm running a 4*60Gb ATA RAID5 with old vinum on a 233 MHZ P2, 256Mb with FBSD 5.1. This ATA just because ATA disk are so much cheaper per MB, and I do not need utmost dependability for my 6 PC office. I've ordered 4*250Gb ATA disks this week to build a new RAID5, and I'll go again for vinum. --WjW From owner-freebsd-scsi@FreeBSD.ORG Thu Feb 17 19:06:05 2005 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 4453816A4CE for ; Thu, 17 Feb 2005 19:06:05 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id D83D643D48 for ; Thu, 17 Feb 2005 19:05:58 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 61246 invoked by uid 0); 17 Feb 2005 18:57:10 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.99.7) by mail.freebsd.org.cn with SMTP; 17 Feb 2005 18:57:10 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id EAE88133F90; Fri, 18 Feb 2005 03:05:49 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29684-04; Fri, 18 Feb 2005 03:05:31 +0800 (CST) Received: from localhost.localdomain (unknown [221.216.127.104]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id 7D43C133FE4; Fri, 18 Feb 2005 03:05:16 +0800 (CST) From: Xin LI To: Rong-En Fan In-Reply-To: <20050204102558.GA2001@svm.csie.ntu.edu.tw> References: <20050204102558.GA2001@svm.csie.ntu.edu.tw> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VjeV5Xa4QTo0apQX6HEm" Organization: The FreeBSD Simplified Chinese Project Date: Fri, 18 Feb 2005 03:04:00 +0800 Message-Id: <1108667040.656.20.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at frontfree.net cc: ob@e-Gitt.NET cc: scsi@freebsd.org Subject: Re: Problem with mpt(4) and Infortrend RAID X-BeenThere: freebsd-scsi@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: delphij@delphij.net List-Id: SCSI subsystem List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2005 19:06:05 -0000 --=-VjeV5Xa4QTo0apQX6HEm Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Have you got a chance to test this, I have gotten some similar problem and got rid of them with the following patch applied (credit goes to gibbs@ who fixed this last November): http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c.diff?r1=3D1.142= &r2=3D1.142.2.2 This might be important since I think this has affected many users who wants to use multiple LUN's, and thus warrants a new errata candidate for 5.3-RELEASE. Thanks in advance! =E5=9C=A8 2005-02-04=E4=BA=94=E7=9A=84 18:25 +0800=EF=BC=8CRong-En Fan=E5= =86=99=E9=81=93=EF=BC=9A > If I map two 1.6T logical drive to the same channel > with different LUN, I got similar problem like yours > However, if I do ONE of following will solve: >=20 > 1. set the channel to 160MB/s (sync clock is 80Mhz) > 2. map 1 logical drive to 1 channel (I have two channels > on raid) >=20 > I'm using 2 now, but I just did a little io traffic > (< 5MB/s and < 30secs) then got following messages: Cheers, --=20 Xin LI http://www.delphij.net/ --=-VjeV5Xa4QTo0apQX6HEm Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8?= =?UTF-8?Q?=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCFOqg/cVsHxFZiIoRAjQ5AJ0fH9Sk31rBtjw/39sxJg4PWm4AzwCcDXF+ cwnBpBwCjmlYXz2zmPQEWwY= =3LQw -----END PGP SIGNATURE----- --=-VjeV5Xa4QTo0apQX6HEm-- From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 18 07:24:12 2005 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 42E6D16A4CE for ; Fri, 18 Feb 2005 07:24:12 +0000 (GMT) Received: from svm.csie.ntu.edu.tw (svm.csie.ntu.edu.tw [140.112.90.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 534DC43D45 for ; Fri, 18 Feb 2005 07:24:10 +0000 (GMT) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: from svm.csie.ntu.edu.tw (localhost [127.0.0.1]) by svm.csie.ntu.edu.tw (8.13.1/8.13.1) with ESMTP id j1I7HuOF041663; Fri, 18 Feb 2005 15:17:56 +0800 (CST) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: (from rafan@localhost) by svm.csie.ntu.edu.tw (8.13.1/8.13.1/Submit) id j1I7Hk3m041662; Fri, 18 Feb 2005 15:17:46 +0800 (CST) (envelope-from rafan) Date: Fri, 18 Feb 2005 15:17:46 +0800 From: Rong-En Fan To: delphij@delphij.net Message-ID: <20050218071746.GA41419@svm.csie.ntu.edu.tw> References: <20050204102558.GA2001@svm.csie.ntu.edu.tw> <1108667040.656.20.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1108667040.656.20.camel@spirit> User-Agent: Mutt/1.5.7i cc: Rong-En Fan cc: ob@e-Gitt.NET cc: scsi@freebsd.org Subject: Re: Problem with mpt(4) and Infortrend RAID 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: Fri, 18 Feb 2005 07:24:12 -0000 On Fri, Feb 18, 2005 at 03:04:00AM +0800, Xin LI wrote: > Have you got a chance to test this, I have gotten some similar problem > and got rid of them with the following patch applied (credit goes to > gibbs@ who fixed this last November): > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c.diff?r1=1.142&r2=1.142.2.2 > > This might be important since I think this has affected many users who > wants to use multiple LUN's, and thus warrants a new errata candidate > for 5.3-RELEASE. > > Thanks in advance! I have tested this with 5.3-p5: 1. 2 LD -> 1 channel, 320MB/s ok (with patch) 2. 2 LD -> 1 channel, 320MB/s failed (without patch) I simulate io by benchmark/blogbench Regards, Rong-En Fan From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 18 10:44:26 2005 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 B84E116A4CE for ; Fri, 18 Feb 2005 10:44:26 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 153DB43D46 for ; Fri, 18 Feb 2005 10:44:26 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1D25cV-0005qN-Rl; Fri, 18 Feb 2005 12:44:23 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: scsi@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Feb 2005 12:44:23 +0200 From: Danny Braniss Message-ID: Subject: iSCSI first steps! 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: Fri, 18 Feb 2005 10:44:26 -0000 shuttle-2# camcontrol devlist at scbus2 target 0 lun 0 (cd0,pass0) at scbus3 target 0 lun 0 (pass1,da0) shuttle-2# ls /dev/da* /dev/da0 shuttle-2# fdisk /dev/da0 ******* Working on device /dev/da0 ******* parameters extracted from in-core disklabel are: cylinders=8354 heads=255 sectors/track=63 (16065 blks/cyl) Figures below won't work with BIOS for partitions not in cyl 1 parameters to be used for BIOS calculations are: cylinders=8354 heads=255 sectors/track=63 (16065 blks/cyl) fdisk: invalid fdisk partition table found Media sector size is 512 Warning: BIOS sector numbering starts with sector 1 Information from DOS bootblock is: The data for partition 1 is: sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) start 63, size 134206947 (65530 Meg), flag 80 (active) beg: cyl 0/ head 1/ sector 1; end: cyl 161/ head 254/ sector 63 The data for partition 2 is: The data for partition 3 is: The data for partition 4 is: shuttle-2# From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 18 16:49:46 2005 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 0C12F16A4CE for ; Fri, 18 Feb 2005 16:49:46 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6468443D5E for ; Fri, 18 Feb 2005 16:49:45 +0000 (GMT) (envelope-from scottl@freebsd.org) Received: from pooker.samsco.org (localhost [127.0.0.1]) by pooker.samsco.org (8.13.1/8.13.1) with ESMTP id j1IGobje024980; Fri, 18 Feb 2005 09:50:37 -0700 (MST) (envelope-from scottl@freebsd.org) Received: from localhost (scottl@localhost)j1IGoaIn024977; Fri, 18 Feb 2005 09:50:37 -0700 (MST) (envelope-from scottl@freebsd.org) X-Authentication-Warning: pooker.samsco.org: scottl owned process doing -bs Date: Fri, 18 Feb 2005 09:50:36 -0700 (MST) From: Scott Long Sender: scottl@pooker.samsco.org To: Danny Braniss In-Reply-To: Message-ID: <20050218094946.I24964@pooker.samsco.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org cc: scsi@freebsd.org Subject: Re: iSCSI first steps! 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: Fri, 18 Feb 2005 16:49:46 -0000 On Fri, 18 Feb 2005, Danny Braniss wrote: Looks wonderful! What are your next steps for it? Scott > > shuttle-2# camcontrol devlist > at scbus2 target 0 lun 0 (cd0,pass0) > at scbus3 target 0 lun 0 (pass1,da0) > shuttle-2# ls /dev/da* > /dev/da0 > shuttle-2# fdisk /dev/da0 > ******* Working on device /dev/da0 ******* > parameters extracted from in-core disklabel are: > cylinders=8354 heads=255 sectors/track=63 (16065 blks/cyl) > > Figures below won't work with BIOS for partitions not in cyl 1 > parameters to be used for BIOS calculations are: > cylinders=8354 heads=255 sectors/track=63 (16065 blks/cyl) > > fdisk: invalid fdisk partition table found > Media sector size is 512 > Warning: BIOS sector numbering starts with sector 1 > Information from DOS bootblock is: > The data for partition 1 is: > sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD) > start 63, size 134206947 (65530 Meg), flag 80 (active) > beg: cyl 0/ head 1/ sector 1; > end: cyl 161/ head 254/ sector 63 > The data for partition 2 is: > > The data for partition 3 is: > > The data for partition 4 is: > > shuttle-2# > > > From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 18 20:30:52 2005 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 775C016A4CE for ; Fri, 18 Feb 2005 20:30:52 +0000 (GMT) Received: from svm.csie.ntu.edu.tw (svm.csie.ntu.edu.tw [140.112.90.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 721F743D2F for ; Fri, 18 Feb 2005 20:30:51 +0000 (GMT) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: from svm.csie.ntu.edu.tw (localhost [127.0.0.1]) by svm.csie.ntu.edu.tw (8.13.1/8.13.1) with ESMTP id j1IKTFpC071888; Sat, 19 Feb 2005 04:29:15 +0800 (CST) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: (from rafan@localhost) by svm.csie.ntu.edu.tw (8.13.1/8.13.1/Submit) id j1IKT1be071887; Sat, 19 Feb 2005 04:29:01 +0800 (CST) (envelope-from rafan) Date: Sat, 19 Feb 2005 04:29:01 +0800 From: Rong-En Fan To: Rong-En Fan Message-ID: <20050218202901.GA71842@svm.csie.ntu.edu.tw> References: <20050204102558.GA2001@svm.csie.ntu.edu.tw> <1108667040.656.20.camel@spirit> <20050218071746.GA41419@svm.csie.ntu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050218071746.GA41419@svm.csie.ntu.edu.tw> User-Agent: Mutt/1.5.7i cc: delphij@delphij.net cc: ob@e-Gitt.NET cc: scsi@freebsd.org Subject: Re: Problem with mpt(4) and Infortrend RAID 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: Fri, 18 Feb 2005 20:30:52 -0000 On Fri, Feb 18, 2005 at 03:17:46PM +0800, Rong-En Fan wrote: > On Fri, Feb 18, 2005 at 03:04:00AM +0800, Xin LI wrote: > > Have you got a chance to test this, I have gotten some similar problem > > and got rid of them with the following patch applied (credit goes to > > gibbs@ who fixed this last November): > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c.diff?r1=1.142&r2=1.142.2.2 > > > > This might be important since I think this has affected many users who > > wants to use multiple LUN's, and thus warrants a new errata candidate > > for 5.3-RELEASE. > > > > Thanks in advance! > > I have tested this with 5.3-p5: > > 1. 2 LD -> 1 channel, 320MB/s ok (with patch) > 2. 2 LD -> 1 channel, 320MB/s failed (without patch) > > I simulate io by benchmark/blogbench This box now serves as NFS server with 20 clients. and has some heavy io (about 30MB/s, lasting for 5 hours or so) with this patch works fine. (2 channels, each channel is 1 LD running at 320MB/s). Though you said this patch solves multiple LUN problem, I think this also solve my problem here. Please consider merge to RELENG_5_3. Thanks. Regards, Rong-En Fan From owner-freebsd-scsi@FreeBSD.ORG Fri Feb 18 20:36:59 2005 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 E1EFD16A4CE; Fri, 18 Feb 2005 20:36:59 +0000 (GMT) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 617D543D53; Fri, 18 Feb 2005 20:36:59 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1D2Erx-000HSG-CK; Fri, 18 Feb 2005 22:36:57 +0200 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: Scott Long In-Reply-To: Message from Scott Long <20050218094946.I24964@pooker.samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 18 Feb 2005 22:36:56 +0200 From: Danny Braniss Message-ID: cc: scsi@freebsd.org Subject: Re: iSCSI first steps! 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: Fri, 18 Feb 2005 20:37:00 -0000 > On Fri, 18 Feb 2005, Danny Braniss wrote: > > Looks wonderful! What are your next steps for it? > writing, of course :-), i mean scsi write, which, if i don't get stone walled, should be very soon (i was stuck for almost a week trying to figure out 'redirect connection' and NOP_IN/NOP_OUT). major things that need to be done: - real parameter negotiation - just coding, not much technology involved. - same with authentication - error recovery, a real PITA. i still have to do some experimentation with the CAM (and learn some) - the RESCAN should be triggered after the target is 'locacated', im using 'camcontrol rescan' at the moment because i still can't figure that one. - same when the connection is closed/dropped. i have three target to try it against, after that will probably need other candidates ... - task management, async events. (part of the RFC). and allot of fine tunning. danny From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 19 06:15:55 2005 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 093D516A4CE for ; Sat, 19 Feb 2005 06:15:55 +0000 (GMT) Received: from svm.csie.ntu.edu.tw (svm.csie.ntu.edu.tw [140.112.90.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67E5D43D46 for ; Sat, 19 Feb 2005 06:15:54 +0000 (GMT) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: from svm.csie.ntu.edu.tw (localhost [127.0.0.1]) by svm.csie.ntu.edu.tw (8.13.1/8.13.1) with ESMTP id j1J6FPLj092196; Sat, 19 Feb 2005 14:15:25 +0800 (CST) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: (from rafan@localhost) by svm.csie.ntu.edu.tw (8.13.1/8.13.1/Submit) id j1J6FHCl092195; Sat, 19 Feb 2005 14:15:17 +0800 (CST) (envelope-from rafan) Date: Sat, 19 Feb 2005 14:15:17 +0800 From: Rong-En Fan To: Rong-En Fan Message-ID: <20050219061517.GA92149@svm.csie.ntu.edu.tw> References: <20050204102558.GA2001@svm.csie.ntu.edu.tw> <1108667040.656.20.camel@spirit> <20050218071746.GA41419@svm.csie.ntu.edu.tw> <20050218202901.GA71842@svm.csie.ntu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050218202901.GA71842@svm.csie.ntu.edu.tw> User-Agent: Mutt/1.5.7i cc: delphij@delphij.net cc: ob@e-Gitt.NET cc: scsi@freebsd.org Subject: Re: Problem with mpt(4) and Infortrend RAID 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: Sat, 19 Feb 2005 06:15:55 -0000 On Sat, Feb 19, 2005 at 04:29:01AM +0800, Rong-En Fan wrote: > On Fri, Feb 18, 2005 at 03:17:46PM +0800, Rong-En Fan wrote: > > On Fri, Feb 18, 2005 at 03:04:00AM +0800, Xin LI wrote: > > > Have you got a chance to test this, I have gotten some similar problem > > > and got rid of them with the following patch applied (credit goes to > > > gibbs@ who fixed this last November): > > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/cam/cam_xpt.c.diff?r1=1.142&r2=1.142.2.2 > > > > > > This might be important since I think this has affected many users who > > > wants to use multiple LUN's, and thus warrants a new errata candidate > > > for 5.3-RELEASE. > > > > > > Thanks in advance! > > > > I have tested this with 5.3-p5: > > > > 1. 2 LD -> 1 channel, 320MB/s ok (with patch) > > 2. 2 LD -> 1 channel, 320MB/s failed (without patch) > > > > I simulate io by benchmark/blogbench > > This box now serves as NFS server with 20 clients. > and has some heavy io (about 30MB/s, lasting for 5 hours > or so) with this patch works fine. (2 channels, > each channel is 1 LD running at 320MB/s). Though you said > this patch solves multiple LUN problem, I think this > also solve my problem here. I was wrong, with patch, and 1 LD -> 1 channel, 320MB/s after 12hours, I got this: mpt0: time out on request index = 0xf6 sequence = 0x00246948 mpt0: Status 00000001; Mask 00000001; Doorbell 24000000 request state On Chip SCSI IO Request @ 0xe6489c20 Chain Offset 0x10 MsgFlags 0x00 MsgContext 0x000000f6 Bus: 0 TargetID 0 SenseBufferLength 32 LUN: 0x0 Control 0x01000000 WRITE SIMPLEQ DataLength 0x00010000 SenseBufAddr 0x7d610de0 CDB[0:10] 2a 00 6c 59 d7 50 00 00 80 00 SE32 0xe653dc30: Addr=0x3721e000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dc38: Addr=0x7a65f000 FlagsLength=0x94001000 HOST_TO_IOC LAST_ELEMENT CE32 0xe653dc40: Addr=0x7d610c48 NxtChnO=0x16 Flgs=0x30 Len=0x60 SE32 0xe653dc48: Addr=0x76380000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dc50: Addr=0xbae1000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dc58: Addr=0x559a2000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dc60: Addr=0x5343000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dc68: Addr=0x282c4000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dc70: Addr=0x41c5000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dc78: Addr=0x231c6000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dc80: Addr=0x5e9e7000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dc88: Addr=0x2ffa8000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dc90: Addr=0x6f09000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dc98: Addr=0x4c2aa000 FlagsLength=0x94001000 HOST_TO_IOC LAST_ELEMENT CE32 0xe653dca0: Addr=0x7d610ca8 NxtChnO=0x0 Flgs=0x30 Len=0x18 SE32 0xe653dca8: Addr=0x3294b000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dcb0: Addr=0x6e2ec000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe653dcb8: Addr=0x2d78d000 FlagsLength=0xd5001000 HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST mpt0: time out on request index = 0x36 sequence = 0x00246949 mpt0: Status 00000001; Mask 00000001; Doorbell 24000000 request state On Chip SCSI IO Request @ 0xe6489c20 Chain Offset 0x10 MsgFlags 0x00 MsgContext 0x00000036 Bus: 0 TargetID 0 SenseBufferLength 32 LUN: 0x0 Control 0x01000000 WRITE SIMPLEQ DataLength 0x00010000 SenseBufAddr 0x7d5f8de0 CDB[0:10] 2a 00 6c 59 d7 d0 00 00 80 00 SE32 0xe6525c30: Addr=0x878e000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525c38: Addr=0x7906f000 FlagsLength=0x94001000 HOST_TO_IOC LAST_ELEMENT CE32 0xe6525c40: Addr=0x7d5f8c48 NxtChnO=0x16 Flgs=0x30 Len=0x60 SE32 0xe6525c48: Addr=0x21170000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525c50: Addr=0x503f1000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525c58: Addr=0x58c92000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525c60: Addr=0x29a33000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525c68: Addr=0x181d4000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525c70: Addr=0x2875000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525c78: Addr=0x58c76000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525c80: Addr=0x4937000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525c88: Addr=0x5fc78000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525c90: Addr=0x7d019000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525c98: Addr=0x7915a000 FlagsLength=0x94001000 HOST_TO_IOC LAST_ELEMENT CE32 0xe6525ca0: Addr=0x7d5f8ca8 NxtChnO=0x0 Flgs=0x30 Len=0x18 SE32 0xe6525ca8: Addr=0x909b000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525cb0: Addr=0x27f9c000 FlagsLength=0x14001000 HOST_TO_IOC SE32 0xe6525cb8: Addr=0x65a1d000 FlagsLength=0xd5001000 HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST These are the only messages after that console hang. Regards, Rong-En Fan From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 19 08:57:15 2005 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 479A116A4CE for ; Sat, 19 Feb 2005 08:57:15 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id E901243D53 for ; Sat, 19 Feb 2005 08:57:07 +0000 (GMT) (envelope-from delphij@delphij.net) Received: (qmail 80467 invoked by uid 0); 19 Feb 2005 08:48:21 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.99.7) by mail.freebsd.org.cn with SMTP; 19 Feb 2005 08:48:21 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id A083E132D81; Sat, 19 Feb 2005 16:57:03 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18737-16; Sat, 19 Feb 2005 16:56:43 +0800 (CST) Received: from localhost.localdomain (unknown [221.217.208.47]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id 63511132B82; Sat, 19 Feb 2005 16:56:33 +0800 (CST) From: Xin LI To: Rong-En Fan In-Reply-To: <20050219061517.GA92149@svm.csie.ntu.edu.tw> References: <20050204102558.GA2001@svm.csie.ntu.edu.tw> <1108667040.656.20.camel@spirit> <20050218071746.GA41419@svm.csie.ntu.edu.tw> <20050218202901.GA71842@svm.csie.ntu.edu.tw> <20050219061517.GA92149@svm.csie.ntu.edu.tw> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-LNv+dMdhysRdwIobQWJV" Organization: The FreeBSD Simplified Chinese Project Date: Sat, 19 Feb 2005 16:55:17 +0800 Message-Id: <1108803317.602.13.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at frontfree.net cc: ob@e-Gitt.NET cc: scsi@freebsd.org Subject: Re: Problem with mpt(4) and Infortrend RAID 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: Sat, 19 Feb 2005 08:57:15 -0000 --=-LNv+dMdhysRdwIobQWJV Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is it possible to get the first error message? The first one is usually more useful. Another thing that is worthy to do is try to reduce the allowed tag depth, through camcontrol(8): camcontrol tags da0 -N 32 camcontrol tags da1 -N 32 =E5=9C=A8 2005-02-19=E5=85=AD=E7=9A=84 14:15 +0800=EF=BC=8CRong-En Fan=E5= =86=99=E9=81=93=EF=BC=9A > I was wrong, with patch, and 1 LD -> 1 channel, 320MB/s > after 12hours, I got this: >=20 > mpt0: time out on request index =3D 0xf6 sequence =3D 0x00246948 > mpt0: Status 00000001; Mask 00000001; Doorbell 24000000 > request state On Chip > SCSI IO Request @ 0xe6489c20 > Chain Offset 0x10 > MsgFlags 0x00 > MsgContext 0x000000f6 > Bus: 0 > TargetID 0 > SenseBufferLength 32 > LUN: 0x0 > Control 0x01000000 WRITE SIMPLEQ > DataLength 0x00010000 > SenseBufAddr 0x7d610de0 > CDB[0:10] 2a 00 6c 59 d7 50 00 00 80 00 > SE32 0xe653dc30: Addr=3D0x3721e000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dc38: Addr=3D0x7a65f000 FlagsLength=3D0x94001000 > HOST_TO_IOC LAST_ELEMENT > CE32 0xe653dc40: Addr=3D0x7d610c48 NxtChnO=3D0x16 Flgs=3D0x30 Len= =3D0x60 > SE32 0xe653dc48: Addr=3D0x76380000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dc50: Addr=3D0xbae1000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dc58: Addr=3D0x559a2000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dc60: Addr=3D0x5343000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dc68: Addr=3D0x282c4000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dc70: Addr=3D0x41c5000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dc78: Addr=3D0x231c6000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dc80: Addr=3D0x5e9e7000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dc88: Addr=3D0x2ffa8000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dc90: Addr=3D0x6f09000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dc98: Addr=3D0x4c2aa000 FlagsLength=3D0x94001000 > HOST_TO_IOC LAST_ELEMENT > CE32 0xe653dca0: Addr=3D0x7d610ca8 NxtChnO=3D0x0 Flgs=3D0x30 Len= =3D0x18 > SE32 0xe653dca8: Addr=3D0x3294b000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dcb0: Addr=3D0x6e2ec000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe653dcb8: Addr=3D0x2d78d000 FlagsLength=3D0xd5001000 > HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST > mpt0: time out on request index =3D 0x36 sequence =3D 0x00246949 > mpt0: Status 00000001; Mask 00000001; Doorbell 24000000 > request state On Chip > SCSI IO Request @ 0xe6489c20 > Chain Offset 0x10 > MsgFlags 0x00 > MsgContext 0x00000036 > Bus: 0 > TargetID 0 > SenseBufferLength 32 > LUN: 0x0 > Control 0x01000000 WRITE SIMPLEQ > DataLength 0x00010000 > SenseBufAddr 0x7d5f8de0 > CDB[0:10] 2a 00 6c 59 d7 d0 00 00 80 00 > SE32 0xe6525c30: Addr=3D0x878e000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525c38: Addr=3D0x7906f000 FlagsLength=3D0x94001000 > HOST_TO_IOC LAST_ELEMENT > CE32 0xe6525c40: Addr=3D0x7d5f8c48 NxtChnO=3D0x16 Flgs=3D0x30 Len= =3D0x60 > SE32 0xe6525c48: Addr=3D0x21170000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525c50: Addr=3D0x503f1000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525c58: Addr=3D0x58c92000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525c60: Addr=3D0x29a33000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525c68: Addr=3D0x181d4000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525c70: Addr=3D0x2875000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525c78: Addr=3D0x58c76000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525c80: Addr=3D0x4937000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525c88: Addr=3D0x5fc78000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525c90: Addr=3D0x7d019000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525c98: Addr=3D0x7915a000 FlagsLength=3D0x94001000 > HOST_TO_IOC LAST_ELEMENT > CE32 0xe6525ca0: Addr=3D0x7d5f8ca8 NxtChnO=3D0x0 Flgs=3D0x30 Len= =3D0x18 > SE32 0xe6525ca8: Addr=3D0x909b000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525cb0: Addr=3D0x27f9c000 FlagsLength=3D0x14001000 > HOST_TO_IOC > SE32 0xe6525cb8: Addr=3D0x65a1d000 FlagsLength=3D0xd5001000 > HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST Cheers, --=20 Xin LI http://www.delphij.net/ --=-LNv+dMdhysRdwIobQWJV Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8?= =?UTF-8?Q?=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCFv70/cVsHxFZiIoRAtDJAJwJy920wRZVZZ0Hmogqpwf6ygQeBQCghnUn VLxSV/+ezmz7CRkzj1HAfyM= =6fKY -----END PGP SIGNATURE----- --=-LNv+dMdhysRdwIobQWJV-- From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 19 09:23:46 2005 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 6C8F416A4CE for ; Sat, 19 Feb 2005 09:23:46 +0000 (GMT) Received: from svm.csie.ntu.edu.tw (svm.csie.ntu.edu.tw [140.112.90.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92B7943D54 for ; Sat, 19 Feb 2005 09:23:45 +0000 (GMT) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: from svm.csie.ntu.edu.tw (localhost [127.0.0.1]) by svm.csie.ntu.edu.tw (8.13.1/8.13.1) with ESMTP id j1J9N7PX095481; Sat, 19 Feb 2005 17:23:07 +0800 (CST) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: (from rafan@localhost) by svm.csie.ntu.edu.tw (8.13.1/8.13.1/Submit) id j1J9N0kG095464; Sat, 19 Feb 2005 17:23:00 +0800 (CST) (envelope-from rafan) Date: Sat, 19 Feb 2005 17:23:00 +0800 From: Rong-En Fan To: Xin LI Message-ID: <20050219092300.GA95182@svm.csie.ntu.edu.tw> References: <20050204102558.GA2001@svm.csie.ntu.edu.tw> <1108667040.656.20.camel@spirit> <20050218071746.GA41419@svm.csie.ntu.edu.tw> <20050218202901.GA71842@svm.csie.ntu.edu.tw> <20050219061517.GA92149@svm.csie.ntu.edu.tw> <1108803317.602.13.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1108803317.602.13.camel@spirit> User-Agent: Mutt/1.5.7i cc: Rong-En Fan cc: ob@e-Gitt.NET cc: scsi@freebsd.org Subject: Re: Problem with mpt(4) and Infortrend RAID 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: Sat, 19 Feb 2005 09:23:46 -0000 On Sat, Feb 19, 2005 at 04:55:17PM +0800, Xin LI wrote: > Is it possible to get the first error message? The first one is usually below is the first error message... :-( > more useful. Another thing that is worthy to do is try to reduce the > allowed tag depth, through camcontrol(8): > > camcontrol tags da0 -N 32 > camcontrol tags da1 -N 32 This server is now in production mode, and is in 160MB/s since crash few hours ago (see my previous mail). Unfortunately, I saw similar message when I'm trying newfs da1s1d (1024G): The first error message is: Feb 19 16:07:10 kernel: mpt1: time out on request index = 0xfd sequence = 0x00000af5 Feb 19 16:07:10 kernel: mpt1: Status 00000001; Mask 00000001; Doorbell 24000000 Feb 19 16:07:10 kernel: request state On Chip Feb 19 16:07:10 kernel: SCSI IO Request @ 0xe6489c20 Feb 19 16:07:10 kernel: Chain Offset 0x10 Feb 19 16:07:10 kernel: MsgFlags 0x00 Feb 19 16:07:10 kernel: MsgContext 0x000000fd Feb 19 16:07:10 kernel: Bus: 0 Feb 19 16:07:10 kernel: TargetID 0 Feb 19 16:07:10 kernel: SenseBufferLength 32 Feb 19 16:07:10 kernel: LUN: 0x0 Feb 19 16:07:10 kernel: Control 0x01000000 WRITE SIMPLEQ Feb 19 16:07:10 kernel: DataLength 0x00010000 Feb 19 16:07:10 kernel: SenseBufAddr 0x7d400be0 Feb 19 16:07:10 kernel: CDB[0:10] 2a 00 45 0a fb 5f 00 00 80 00 Feb 19 16:07:10 kernel: SE32 0xe676ea30: Addr=0x35f79000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676ea38: Addr=0x434ba000 FlagsLength=0x94001000 Feb 19 16:07:10 kernel: HOST_TO_IOC LAST_ELEMENT Feb 19 16:07:10 kernel: CE32 0xe676ea40: Addr=0x7d400a48 NxtChnO=0x16 Flgs=0x30 Len=0x60 Feb 19 16:07:10 kernel: SE32 0xe676ea48: Addr=0x44d3b000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676ea50: Addr=0x4551c000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676ea58: Addr=0x4595d000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676ea60: Addr=0x4367e000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676ea68: Addr=0x4585f000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676ea70: Addr=0x36f60000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676ea78: Addr=0x46581000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676ea80: Addr=0x428a2000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676ea88: Addr=0x45823000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676ea90: Addr=0x45aa4000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676ea98: Addr=0x43d05000 FlagsLength=0x94001000 Feb 19 16:07:10 kernel: HOST_TO_IOC LAST_ELEMENT Feb 19 16:07:10 kernel: CE32 0xe676eaa0: Addr=0x7d400aa8 NxtChnO=0x0 Flgs=0x30 Len=0x18 Feb 19 16:07:10 kernel: SE32 0xe676eaa8: Addr=0x43e86000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676eab0: Addr=0x35da7000 FlagsLength=0x14001000 Feb 19 16:07:10 kernel: HOST_TO_IOC Feb 19 16:07:10 kernel: SE32 0xe676eab8: Addr=0x450c8000 FlagsLength=0xd5001000 Feb 19 16:07:10 kernel: HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST If you need rest ones, I can mail you :-) I just noticed that in my RAID console, there are some parameters for host-side: Maximum Queued I/O Count - 256 LUNs per Host SCSI ID - 8 Max Number of Concurrent Host-LUN Connection - Def(4) Number of Tags Reserved for each Host-LUN Connection - Def(32) Peripheral Device Type Parameters Host Cylinder/Head/Sector Mapping Configuration I'm not that similar with SCSI, if it possible some parameters here need to tune? Regards, rafan > 在 2005-02-19六的 14:15 +0800，Rong-En Fan写道： > > I was wrong, with patch, and 1 LD -> 1 channel, 320MB/s > > after 12hours, I got this: > > > > mpt0: time out on request index = 0xf6 sequence = 0x00246948 > > mpt0: Status 00000001; Mask 00000001; Doorbell 24000000 > > request state On Chip > > SCSI IO Request @ 0xe6489c20 > > Chain Offset 0x10 > > MsgFlags 0x00 > > MsgContext 0x000000f6 > > Bus: 0 > > TargetID 0 > > SenseBufferLength 32 > > LUN: 0x0 > > Control 0x01000000 WRITE SIMPLEQ > > DataLength 0x00010000 > > SenseBufAddr 0x7d610de0 > > CDB[0:10] 2a 00 6c 59 d7 50 00 00 80 00 > > SE32 0xe653dc30: Addr=0x3721e000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dc38: Addr=0x7a65f000 FlagsLength=0x94001000 > > HOST_TO_IOC LAST_ELEMENT > > CE32 0xe653dc40: Addr=0x7d610c48 NxtChnO=0x16 Flgs=0x30 Len=0x60 > > SE32 0xe653dc48: Addr=0x76380000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dc50: Addr=0xbae1000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dc58: Addr=0x559a2000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dc60: Addr=0x5343000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dc68: Addr=0x282c4000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dc70: Addr=0x41c5000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dc78: Addr=0x231c6000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dc80: Addr=0x5e9e7000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dc88: Addr=0x2ffa8000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dc90: Addr=0x6f09000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dc98: Addr=0x4c2aa000 FlagsLength=0x94001000 > > HOST_TO_IOC LAST_ELEMENT > > CE32 0xe653dca0: Addr=0x7d610ca8 NxtChnO=0x0 Flgs=0x30 Len=0x18 > > SE32 0xe653dca8: Addr=0x3294b000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dcb0: Addr=0x6e2ec000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe653dcb8: Addr=0x2d78d000 FlagsLength=0xd5001000 > > HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST > > mpt0: time out on request index = 0x36 sequence = 0x00246949 > > mpt0: Status 00000001; Mask 00000001; Doorbell 24000000 > > request state On Chip > > SCSI IO Request @ 0xe6489c20 > > Chain Offset 0x10 > > MsgFlags 0x00 > > MsgContext 0x00000036 > > Bus: 0 > > TargetID 0 > > SenseBufferLength 32 > > LUN: 0x0 > > Control 0x01000000 WRITE SIMPLEQ > > DataLength 0x00010000 > > SenseBufAddr 0x7d5f8de0 > > CDB[0:10] 2a 00 6c 59 d7 d0 00 00 80 00 > > SE32 0xe6525c30: Addr=0x878e000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525c38: Addr=0x7906f000 FlagsLength=0x94001000 > > HOST_TO_IOC LAST_ELEMENT > > CE32 0xe6525c40: Addr=0x7d5f8c48 NxtChnO=0x16 Flgs=0x30 Len=0x60 > > SE32 0xe6525c48: Addr=0x21170000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525c50: Addr=0x503f1000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525c58: Addr=0x58c92000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525c60: Addr=0x29a33000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525c68: Addr=0x181d4000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525c70: Addr=0x2875000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525c78: Addr=0x58c76000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525c80: Addr=0x4937000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525c88: Addr=0x5fc78000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525c90: Addr=0x7d019000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525c98: Addr=0x7915a000 FlagsLength=0x94001000 > > HOST_TO_IOC LAST_ELEMENT > > CE32 0xe6525ca0: Addr=0x7d5f8ca8 NxtChnO=0x0 Flgs=0x30 Len=0x18 > > SE32 0xe6525ca8: Addr=0x909b000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525cb0: Addr=0x27f9c000 FlagsLength=0x14001000 > > HOST_TO_IOC > > SE32 0xe6525cb8: Addr=0x65a1d000 FlagsLength=0xd5001000 > > HOST_TO_IOC LAST_ELEMENT END_OF_BUFFER END_OF_LIST > > Cheers, > -- > Xin LI http://www.delphij.net/ From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 19 09:24:46 2005 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 1039216A4CE; Sat, 19 Feb 2005 09:24:46 +0000 (GMT) Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3FCC43D5C; Sat, 19 Feb 2005 09:24:44 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id D51903B8EC; Sat, 19 Feb 2005 10:24:42 +0100 (CET) Received: from hal9000.schweikhardt.net (localhost [127.0.0.1]) j1J9OT4u001116; Sat, 19 Feb 2005 10:24:29 +0100 (CET) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.13.1/8.13.1/Submit) id j1J9OTjN001115; Sat, 19 Feb 2005 10:24:29 +0100 (CET) (envelope-from schweikh) Date: Sat, 19 Feb 2005 10:24:29 +0100 From: Jens Schweikhardt To: "Justin T. Gibbs" Message-ID: <20050219092429.GA770@schweikhardt.net> References: <20050215215908.GA1012@schweikhardt.net> <7579f7fb05021515227e7b8539@mail.gmail.com> <62DFACAEF30DA6C81EF39A7F@[10.0.0.90]> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <62DFACAEF30DA6C81EF39A7F@[10.0.0.90]> User-Agent: Mutt/1.5.6i cc: mjacob@freebsd.org cc: FreeBSD SCSI Subject: SOLVED: cam_xpt.c 1.147 makes system hang at boot 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: Sat, 19 Feb 2005 09:24:46 -0000 Justin et al, On Wed, Feb 16, 2005 at 11:09:39AM -0700, Justin T. Gibbs wrote: # Part of the problem may be that the current version of the aic79xx # driver reports a max_lun of 255. This is correct once packetized # protocol is negotiated, but problematic given CAMs current method # of performing device probes. I've just checked in a change to drop # the reported max_lun to the non-packetized limit of 63. The latest commits appear to have solved the hang at boot (CURRENT as of February 18). Thanks! Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 19 09:47:16 2005 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 146E016A4CE for ; Sat, 19 Feb 2005 09:47:16 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 4C0D343D48 for ; Sat, 19 Feb 2005 09:47:03 +0000 (GMT) (envelope-from delphij@delphij.net) Received: (qmail 80636 invoked by uid 0); 19 Feb 2005 09:38:08 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.99.7) by mail.freebsd.org.cn with SMTP; 19 Feb 2005 09:38:08 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 16468132DD1; Sat, 19 Feb 2005 17:46:51 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20655-08; Sat, 19 Feb 2005 17:46:28 +0800 (CST) Received: from localhost.localdomain (unknown [221.217.208.47]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id B20E9132C9C; Sat, 19 Feb 2005 17:46:27 +0800 (CST) From: Xin LI To: Rong-En Fan In-Reply-To: <20050219092300.GA95182@svm.csie.ntu.edu.tw> References: <20050204102558.GA2001@svm.csie.ntu.edu.tw> <1108667040.656.20.camel@spirit> <20050218071746.GA41419@svm.csie.ntu.edu.tw> <20050218202901.GA71842@svm.csie.ntu.edu.tw> <20050219061517.GA92149@svm.csie.ntu.edu.tw> <1108803317.602.13.camel@spirit> <20050219092300.GA95182@svm.csie.ntu.edu.tw> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NcBKV70H48hOQqD1g/9T" Organization: The FreeBSD Simplified Chinese Project Date: Sat, 19 Feb 2005 17:45:12 +0800 Message-Id: <1108806312.602.17.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at frontfree.net cc: ob@e-Gitt.NET cc: scsi@freebsd.org Subject: Re: Problem with mpt(4) and Infortrend RAID 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: Sat, 19 Feb 2005 09:47:16 -0000 --=-NcBKV70H48hOQqD1g/9T Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Would you please try: camcontrol tags da1 To see how many tags are actually allowed for the device, at the host side? It comes to my mind that: =E5=9C=A8 2005-02-19=E5=85=AD=E7=9A=84 17:23 +0800=EF=BC=8CRong-En Fan=E5= =86=99=E9=81=93=EF=BC=9A > Maximum Queued I/O Count - 256 =20 > LUNs per Host SCSI ID - 8 =20 > Max Number of Concurrent Host-LUN Connection - Def(4) =20 > Number of Tags Reserved for each Host-LUN Connection - Def(32)=20 Here: You have allowed only 32, and if the host has exceeded the limitation, then something strange *may* happen. My bet is to decrease the tags allowed at host side, to something like 32: camcontrol tags da1 -N 32. It's also possible to modify cam_xpt.c to set the default number. > I'm not that similar with SCSI, if it possible some parameters > here need to tune? If you have a spare box, try to decrease the tag depth :-) Please be sure to decrease tag depth on every device. Cheers, --=20 Xin LI http://www.delphij.net/ --=-NcBKV70H48hOQqD1g/9T Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8?= =?UTF-8?Q?=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCFwqn/cVsHxFZiIoRAoDOAJ4hChNXsV6pxOS+zqQqXHrxP/RJmgCeKuRI 4HqG84LkJudWQ5pwOSbrh6U= =SNo3 -----END PGP SIGNATURE----- --=-NcBKV70H48hOQqD1g/9T-- From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 19 10:12:45 2005 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 A899916A4CE for ; Sat, 19 Feb 2005 10:12:45 +0000 (GMT) Received: from svm.csie.ntu.edu.tw (svm.csie.ntu.edu.tw [140.112.90.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B137A43D1F for ; Sat, 19 Feb 2005 10:12:44 +0000 (GMT) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: from svm.csie.ntu.edu.tw (localhost [127.0.0.1]) by svm.csie.ntu.edu.tw (8.13.1/8.13.1) with ESMTP id j1JACKbw096376; Sat, 19 Feb 2005 18:12:20 +0800 (CST) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: (from rafan@localhost) by svm.csie.ntu.edu.tw (8.13.1/8.13.1/Submit) id j1JACE2F096375; Sat, 19 Feb 2005 18:12:14 +0800 (CST) (envelope-from rafan) Date: Sat, 19 Feb 2005 18:12:14 +0800 From: Rong-En Fan To: Xin LI Message-ID: <20050219101214.GA96011@svm.csie.ntu.edu.tw> References: <20050204102558.GA2001@svm.csie.ntu.edu.tw> <1108667040.656.20.camel@spirit> <20050218071746.GA41419@svm.csie.ntu.edu.tw> <20050218202901.GA71842@svm.csie.ntu.edu.tw> <20050219061517.GA92149@svm.csie.ntu.edu.tw> <1108803317.602.13.camel@spirit> <20050219092300.GA95182@svm.csie.ntu.edu.tw> <1108806312.602.17.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1108806312.602.17.camel@spirit> User-Agent: Mutt/1.5.7i cc: Rong-En Fan cc: ob@e-Gitt.NET cc: scsi@freebsd.org Subject: Re: Problem with mpt(4) and Infortrend RAID 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: Sat, 19 Feb 2005 10:12:45 -0000 On Sat, Feb 19, 2005 at 05:45:12PM +0800, Xin LI wrote: > Would you please try: > camcontrol tags da1 > > To see how many tags are actually allowed for the device, at the host > side? It comes to my mind that: I have already done -N 32, I remembered that original is 25x. > 在 2005-02-19六的 17:23 +0800，Rong-En Fan写道： > > Maximum Queued I/O Count - 256 > > LUNs per Host SCSI ID - 8 > > Max Number of Concurrent Host-LUN Connection - Def(4) > > Number of Tags Reserved for each Host-LUN Connection - Def(32) > > Here: You have allowed only 32, and if the host has exceeded the > limitation, then something strange *may* happen. My bet is to decrease I just found the Infortrend's manual, it says that if hos exceeded this limit, the controller will not response and host *might* reduce the # later. Hmm, it seems match my situation. > the tags allowed at host side, to something like 32: > > camcontrol tags da1 -N 32. > > It's also possible to modify cam_xpt.c to set the default number. Hmm, seems ok for me. My system's disk is ips(4) which does not use CAM layer. So, I can put camcontrol to rc. > > I'm not that similar with SCSI, if it possible some parameters > > here need to tune? > > If you have a spare box, try to decrease the tag depth :-) Please be > sure to decrease tag depth on every device. I got no spare box here (to be precise, I can not find another 320 scsi card). So I directly decreast the tag depth on the main server. Hope there is no more timeout and thus I can have a good sleep. Thanks, Rong-En Fan From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 19 10:30:41 2005 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 09ABD16A566 for ; Sat, 19 Feb 2005 10:30:41 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id 6396143D66 for ; Sat, 19 Feb 2005 10:30:38 +0000 (GMT) (envelope-from delphij@delphij.net) Received: (qmail 80842 invoked by uid 0); 19 Feb 2005 10:21:51 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.99.7) by mail.freebsd.org.cn with SMTP; 19 Feb 2005 10:21:51 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 212F4132E07; Sat, 19 Feb 2005 18:30:34 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 20793-19; Sat, 19 Feb 2005 18:30:10 +0800 (CST) Received: from localhost.localdomain (unknown [221.217.208.47]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id 0FD5E132B82; Sat, 19 Feb 2005 18:30:09 +0800 (CST) From: Xin LI To: Rong-En Fan In-Reply-To: <20050219101214.GA96011@svm.csie.ntu.edu.tw> References: <20050204102558.GA2001@svm.csie.ntu.edu.tw> <1108667040.656.20.camel@spirit> <20050218071746.GA41419@svm.csie.ntu.edu.tw> <20050218202901.GA71842@svm.csie.ntu.edu.tw> <20050219061517.GA92149@svm.csie.ntu.edu.tw> <1108803317.602.13.camel@spirit> <20050219092300.GA95182@svm.csie.ntu.edu.tw> <1108806312.602.17.camel@spirit> <20050219101214.GA96011@svm.csie.ntu.edu.tw> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-BQcEHx9il67NZPIuqTCJ" Organization: The FreeBSD Simplified Chinese Project Date: Sat, 19 Feb 2005 18:28:46 +0800 Message-Id: <1108808926.602.25.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.0.3 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at frontfree.net cc: ob@e-Gitt.NET cc: scsi@freebsd.org Subject: Re: Problem with mpt(4) and Infortrend RAID 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: Sat, 19 Feb 2005 10:30:41 -0000 --=-BQcEHx9il67NZPIuqTCJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, =E5=9C=A8 2005-02-19=E5=85=AD=E7=9A=84 18:12 +0800=EF=BC=8CRong-En Fan=E5= =86=99=E9=81=93=EF=BC=9A > On Sat, Feb 19, 2005 at 05:45:12PM +0800, Xin LI wrote: > > Would you please try: > > camcontrol tags da1 > >=20 > > To see how many tags are actually allowed for the device, at the host > > side? It comes to my mind that: >=20 > I have already done -N 32, I remembered that original is 25x. Er... Pardon... You mean you have already done this before you got the error message, or just have done that? > > Here: You have allowed only 32, and if the host has exceeded the > > limitation, then something strange *may* happen. My bet is to decrease >=20 > I just found the Infortrend's manual, it says that if > hos exceeded this limit, the controller will not response > and host *might* reduce the # later. Hmm, it seems match > my situation. Yes, and this has generated problem for me, too. It should be good if there's someone can tell us how to obtain the maximum tag depth allowed by the infotrend device (I don't know if there is one, as I'm not a SCSI guru:-) > > the tags allowed at host side, to something like 32: > >=20 > > camcontrol tags da1 -N 32. > >=20 > > It's also possible to modify cam_xpt.c to set the default number. >=20 > Hmm, seems ok for me. My system's disk is ips(4) which does not > use CAM layer. So, I can put camcontrol to rc. It's also possible to add the disk array quirk to the cam_xpt.c, too. But that's of course too hacky IMO :-) > > > I'm not that similar with SCSI, if it possible some parameters > > > here need to tune? > >=20 > > If you have a spare box, try to decrease the tag depth :-) Please be > > sure to decrease tag depth on every device. >=20 > I got no spare box here (to be precise, I can not find another > 320 scsi card). So I directly decreast the tag depth on the > main server. Hope there is no more timeout and thus I can > have a good sleep. Good luck :-) Cheers, --=20 Xin LI http://www.delphij.net/ --=-BQcEHx9il67NZPIuqTCJ Content-Type: application/pgp-signature; name=signature.asc Content-Description: =?UTF-8?Q?=E8=BF=99=E6=98=AF=E4=BF=A1=E4=BB=B6=E7=9A=84=E6=95=B0?= =?UTF-8?Q?=E5=AD=97=E7=AD=BE=E5=90=8D=E9=83=A8?= =?UTF-8?Q?=E5=88=86?= -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCFxTe/cVsHxFZiIoRAoRpAJ4/IDVrwFCS7/nC5M3Qg0LPHnnPLgCeKgX0 oxdV76z5M3yhJqE8BwNPiFo= =5427 -----END PGP SIGNATURE----- --=-BQcEHx9il67NZPIuqTCJ-- From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 19 11:47:57 2005 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 9094A16A4CE for ; Sat, 19 Feb 2005 11:47:57 +0000 (GMT) Received: from svm.csie.ntu.edu.tw (svm.csie.ntu.edu.tw [140.112.90.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id D814B43D31 for ; Sat, 19 Feb 2005 11:47:56 +0000 (GMT) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: from svm.csie.ntu.edu.tw (localhost [127.0.0.1]) by svm.csie.ntu.edu.tw (8.13.1/8.13.1) with ESMTP id j1JBlbCa097931; Sat, 19 Feb 2005 19:47:37 +0800 (CST) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: (from rafan@localhost) by svm.csie.ntu.edu.tw (8.13.1/8.13.1/Submit) id j1JBlVeo097930; Sat, 19 Feb 2005 19:47:31 +0800 (CST) (envelope-from rafan) Date: Sat, 19 Feb 2005 19:47:31 +0800 From: Rong-En Fan To: Xin LI Message-ID: <20050219114731.GA97896@svm.csie.ntu.edu.tw> References: <20050204102558.GA2001@svm.csie.ntu.edu.tw> <1108667040.656.20.camel@spirit> <20050218071746.GA41419@svm.csie.ntu.edu.tw> <20050218202901.GA71842@svm.csie.ntu.edu.tw> <20050219061517.GA92149@svm.csie.ntu.edu.tw> <1108803317.602.13.camel@spirit> <20050219092300.GA95182@svm.csie.ntu.edu.tw> <1108806312.602.17.camel@spirit> <20050219101214.GA96011@svm.csie.ntu.edu.tw> <1108808926.602.25.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1108808926.602.25.camel@spirit> User-Agent: Mutt/1.5.7i cc: Rong-En Fan cc: ob@e-Gitt.NET cc: scsi@freebsd.org Subject: Re: Problem with mpt(4) and Infortrend RAID 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: Sat, 19 Feb 2005 11:47:57 -0000 On Sat, Feb 19, 2005 at 06:28:46PM +0800, Xin LI wrote: > Hi, > > 在 2005-02-19六的 18:12 +0800，Rong-En Fan写道： > > On Sat, Feb 19, 2005 at 05:45:12PM +0800, Xin LI wrote: > > > Would you please try: > > > camcontrol tags da1 > > > > > > To see how many tags are actually allowed for the device, at the host > > > side? It comes to my mind that: > > > > I have already done -N 32, I remembered that original is 25x. > > Er... Pardon... You mean you have already done this before you got the > error message, or just have done that? just have done that. > > > Here: You have allowed only 32, and if the host has exceeded the > > > limitation, then something strange *may* happen. My bet is to decrease > > > > I just found the Infortrend's manual, it says that if > > hos exceeded this limit, the controller will not response > > and host *might* reduce the # later. Hmm, it seems match > > my situation. > > Yes, and this has generated problem for me, too. It should be good if > there's someone can tell us how to obtain the maximum tag depth allowed > by the infotrend device (I don't know if there is one, as I'm not a SCSI > guru:-) > > > > the tags allowed at host side, to something like 32: > > > > > > camcontrol tags da1 -N 32. > > > > > > It's also possible to modify cam_xpt.c to set the default number. > > > > Hmm, seems ok for me. My system's disk is ips(4) which does not > > use CAM layer. So, I can put camcontrol to rc. > > It's also possible to add the disk array quirk to the cam_xpt.c, too. > But that's of course too hacky IMO :-) Ya, I think so :) Regards, Rong-En fan From owner-freebsd-scsi@FreeBSD.ORG Sat Feb 19 18:26:23 2005 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 6C7AC16A4CE for ; Sat, 19 Feb 2005 18:26:23 +0000 (GMT) Received: from svm.csie.ntu.edu.tw (svm.csie.ntu.edu.tw [140.112.90.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3E5D43D2F for ; Sat, 19 Feb 2005 18:26:22 +0000 (GMT) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: from svm.csie.ntu.edu.tw (localhost [127.0.0.1]) by svm.csie.ntu.edu.tw (8.13.1/8.13.1) with ESMTP id j1JIQ09Y009231; Sun, 20 Feb 2005 02:26:00 +0800 (CST) (envelope-from rafan@svm.csie.ntu.edu.tw) Received: (from rafan@localhost) by svm.csie.ntu.edu.tw (8.13.1/8.13.1/Submit) id j1JIPqIC009230; Sun, 20 Feb 2005 02:25:52 +0800 (CST) (envelope-from rafan) Date: Sun, 20 Feb 2005 02:25:52 +0800 From: Rong-En Fan To: Rong-En Fan Message-ID: <20050219182552.GA8727@svm.csie.ntu.edu.tw> References: <1108667040.656.20.camel@spirit> <20050218071746.GA41419@svm.csie.ntu.edu.tw> <20050218202901.GA71842@svm.csie.ntu.edu.tw> <20050219061517.GA92149@svm.csie.ntu.edu.tw> <1108803317.602.13.camel@spirit> <20050219092300.GA95182@svm.csie.ntu.edu.tw> <1108806312.602.17.camel@spirit> <20050219101214.GA96011@svm.csie.ntu.edu.tw> <1108808926.602.25.camel@spirit> <20050219114731.GA97896@svm.csie.ntu.edu.tw> Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050219114731.GA97896@svm.csie.ntu.edu.tw> User-Agent: Mutt/1.5.7i cc: Xin LI cc: ob@e-Gitt.NET cc: scsi@freebsd.org Subject: Re: Problem with mpt(4) and Infortrend RAID 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: Sat, 19 Feb 2005 18:26:23 -0000 On Sat, Feb 19, 2005 at 07:47:31PM +0800, Rong-En Fan wrote: > On Sat, Feb 19, 2005 at 06:28:46PM +0800, Xin LI wrote: > > Hi, > > > > 在 2005-02-19六的 18:12 +0800，Rong-En Fan写道： > > > On Sat, Feb 19, 2005 at 05:45:12PM +0800, Xin LI wrote: > > > > Would you please try: > > > > camcontrol tags da1 > > > > > > > > To see how many tags are actually allowed for the device, at the host > > > > side? It comes to my mind that: > > > > > > I have already done -N 32, I remembered that original is 25x. > > > > Er... Pardon... You mean you have already done this before you got the > > error message, or just have done that? > > just have done that. I got similar messages when I doing rsync 4M files (800G) to da1s1d from another machine via nfs (-N 32). The box configuration is that there are total 12 slices on da0 and exported to 20 clients via nfs. Both da0 and da1 are setted with tag depth = 32. The hardware RAID has 16 drives and configurated as 2 RAID5 logical drive, each has 8 drives. These two RAID5 LD are mapped to two channels, respectively. It is strange to me that since last two weeks ago, I'm doing rsync all the times from another machine to da0 (running at 160MB/s on mpt0, da1 is 160MB/s on mpt1). And no io on da1. I didn't set tag depth that time, but seems it works fine. I wonder if it is caused the raid controller which might not handle two concurrent host-lun access well. I'm looking for opportunity to do this experiment. Regards, Rong-En Fan