From owner-freebsd-scsi Sun Apr 7 1:55:21 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from hotmail.com (f214.law11.hotmail.com [64.4.17.214]) by hub.freebsd.org (Postfix) with ESMTP id 8CDA437B419 for ; Sun, 7 Apr 2002 01:55:15 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 7 Apr 2002 01:55:15 -0800 Received: from 208.151.119.232 by lw11fd.law11.hotmail.msn.com with HTTP; Sun, 07 Apr 2002 09:55:15 GMT X-Originating-IP: [208.151.119.232] From: "Chad Kline" To: freebsd-scsi@freebsd.org Subject: usb mass storage driver - umass Date: Sun, 07 Apr 2002 09:55:15 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 07 Apr 2002 09:55:15.0399 (UTC) FILETIME=[5115E570:01C1DE1A] Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org since usb mass storage driver (umass.c) is tied to scsi stuff, i am posting to see if anyone may be able to direct me to bring about a solution to this problem. from the following, i assume i the link/controller/camera are operational to some extent - as the camera ID is detected just fine by the driver as well as userland programs. $ dmesg (kernel/driver detection, QUIRK=command status signature fix, 0x5343->0x5542) for OLYMPUS C-1's) FreeBSD 4.5-RELEASE #3: Sat Apr 6 22:12:40 AKST 2002 ohci0: mem 0xe1000000-0xe1000fff irq 10 at device 19.0 on pci0 usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: OPTi OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered OLYMPUS - APPLYING CSS QUIRK! OLYMPUS - APPLYING CSS QUIRK! OLYMPUS - APPLYING CSS QUIRK! umass0: OLYMPUS C-1Z,D-150Z, rev 1.10/10.15, addr 2 OLYMPUS - case TSTATE_BBB_RESET1: umass0: BBB reset failed, TIMEOUT OLYMPUS - case TSTATE_BBB_RESET2: umass0: BBB bulk-in clear stall failed, TIMEOUT OLYMPUS - case TSTATE_BBB_RESET3: umass0: BBB bulk-out clear stall failed, TIMEOUT $ usbdevs (userland program) Controller /dev/usb0: addr 1: self powered, config 1, OHCI root hub(0x0000), OPTi(0x0000), rev 0x0100 port 1 addr 2: self powered, config 1, C-1 Digital Camera(0x0102), Olympus(0x07b4), rev 0x1015 port 2 powered without umass0 (USB mass storage driver) being able to complete it's task, i cannot mount the camera's smartmedia disk. supposedly this camera supposedly has "the convenient Auto Connect USB feature lets your computer automatically recognize your Brio Zoom D-150 so you don't have to install any additional software". so i think i should be able to mount this camera. i don't have windows, and don't know of bsd/unix USB snoop software. the failure is in this function - a status state machine. i can't find a calling function, so i assume it's installed as an interrupt handler (i don't know too much about how unix installs handlers/remaps interrupt signals). umass.c: Static void umass_bbb_state(usbd_xfer_handle xfer, usbd_private_handle priv, usbd_status err) { /***** Bulk Reset *****/ case TSTATE_BBB_RESET1: if (err) { printf("OLYMPUS - TSTATE_BBB_RESET1\n"); printf("%s: BBB reset failed, %s\n", USBDEVNAME(sc->sc_dev), usbd_errstr(err)); } umass_clear_endpoint_stall(sc, sc->bulkin, sc->bulkin_pipe, TSTATE_BBB_RESET2, sc->transfer_xfer[XFER_BBB_RESET2]); return; case TSTATE_BBB_RESET2: if (err) { /* should not occur */ printf("OLYMPUS - TSTATE_BBB_RESET2!\n"); printf("%s: BBB bulk-in clear stall failed, %s\n", USBDEVNAME(sc->sc_dev), usbd_errstr(err)); /* no error recovery, otherwise we end up in a loop */ } umass_clear_endpoint_stall(sc, sc->bulkout, sc->bulkout_pipe, TSTATE_BBB_RESET3, sc->transfer_xfer[XFER_BBB_RESET3]); return; case TSTATE_BBB_RESET3: if (err) { /* should not occur */ printf("OLYMPUS - TSTATE_BBB_RESET3!\n"); printf("%s: BBB bulk-out clear stall failed, %s\n", USBDEVNAME(sc->sc_dev), usbd_errstr(err)); /* no error recovery, otherwise we end up in a loop */ } sc->transfer_state = TSTATE_IDLE; if (sc->transfer_priv) { sc->transfer_cb(sc, sc->transfer_priv, sc->transfer_datalen, sc->transfer_status); } return; /***** Default *****/ default: panic("%s: Unknown state %d\n", USBDEVNAME(sc->sc_dev), sc->transfer_state); } _________________________________________________________________ MSN Photos is the easiest way to share and print your photos: http://photos.msn.com/support/worldwide.aspx To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sun Apr 7 10:16:27 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mail1a.webmessenger.it (mail1.webmessenger.it [193.70.193.50]) by hub.freebsd.org (Postfix) with ESMTP id A64CB37B416 for ; Sun, 7 Apr 2002 10:16:22 -0700 (PDT) Received: from practive.org (151.36.176.69) by mail1a.webmessenger.it (6.5.015) (authenticated as andrea@iknight.it) id 3C9B14A4001C24ED for freebsd-scsi@freebsd.org; Sun, 7 Apr 2002 19:15:57 +0200 Message-ID: <3CB08CBE.B033301E@practive.org> Date: Sun, 07 Apr 2002 18:15:26 +0000 From: andrea X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Subject: Troubles with Advansys controller. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi All! I'm trying to build up a redundant architecture based upon FreeBSD. So i bought a diskarray with room for 8 SCSI disks (SCA) and a couple of PCs with LVD SCSI controller (ASB3940U2W-00). I installed FreeBSD4.5 on both the PCs and connected the diskarray trough a external SCSI3 (68pin) cable. But ,as soon as i boot up the first PC, the kernel stopped at the very beginning of SCSI scan ,and after a while ,it comes up with the following message: (probe0:adw0:0:8:0) ACB 0xcb781074 - timed out and few minutes after that it panic. No disk were probed at all. I tried with many configuration even with a single disk on the array ,but without results. Any clue about this? Is it possible that the problem is somewhat cabling-related? +----------------------+ | | | +---+ +---+ +---+ | | | 1 | | 2 | | 3 | | | | | | | | | | <--SCSI DRIVES | ++-++ ++-++ ++-++ | | | | | | | | | | | +----+ +----+ | | | | | | <--LVD CABLES | +---------+ | | | | | | +------------|-----+---+ <---|---------SCSI SE terminator or second PC... | <-- 68 Pin SCSI3 External Cable | +------------------+----+ | FreeBSD + ASB3940U2W | +-----------------------+ Bye! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 9 0:45:21 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from melchior.cuivre.fr.eu.org (melchior.enst.fr [137.194.161.6]) by hub.freebsd.org (Postfix) with ESMTP id 4B05F37B41A for ; Tue, 9 Apr 2002 00:45:16 -0700 (PDT) Received: from melusine.cuivre.fr.eu.org (melusine.enst.fr [137.194.160.34]) by melchior.cuivre.fr.eu.org (Postfix) with ESMTP id 54767762D for ; Tue, 9 Apr 2002 09:45:10 +0200 (CEST) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id A0B4F2C3D1; Tue, 9 Apr 2002 09:45:09 +0200 (CEST) Date: Tue, 9 Apr 2002 09:45:09 +0200 From: Thomas Quinot To: freebsd-scsi@freebsd.org Subject: xpt_bus_deregister Message-ID: <20020409094509.A4569@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Folks, Trying to get bus detach code for ATAPI/CAM(*) to work, I have a problem with xpt_bus_deregister. Apparently, there is one reference to the bus which is counted but never released. As a consequence, a call to xpt_bus_deregister(cam_sim_path(scp->sim)) will not actually remove the bus from xpt_busses, and of course a subsequent cam_sim_free destroys the SIM with extreme prejudice. Any idea where I should start looking for this reference leak? Thomas. (*) http://www.cuivre.fr.eu.org/~thomas/atapicam/patches/atapicam-20020406.diff -- Thomas.Quinot@Cuivre.FR.EU.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 9 7:12:39 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from bosvwl01.infy.com (bosvwl01.infy.com [216.52.49.35]) by hub.freebsd.org (Postfix) with SMTP id 6C7EC37B400 for ; Tue, 9 Apr 2002 07:12:35 -0700 (PDT) Received: from 192.168.200.81 by bosvwl01.infy.com (InterScan E-Mail VirusWall NT); Tue, 09 Apr 2002 10:09:30 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Apr 2002 19:41:49 +0530 Received: from kecmsg02.ad.infosys.com ([192.168.18.90]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Apr 2002 19:41:48 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: SCSI Callback function not getting called Date: Tue, 9 Apr 2002 19:40:49 +0530 Message-ID: <755FA95DB839D211856B0008C7287D930F3286E7@kecmsg02.ad.infosys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCSI Callback function not getting called Thread-Index: AcHbnXu6qwUvAHSaTo2vsyBcKBRJlwEMoUbQ From: "Yassar S" To: "Kenneth D. Merry" Cc: X-OriginalArrivalTime: 09 Apr 2002 14:11:48.0848 (UTC) FILETIME=[7D1F4F00:01C1DFD0] Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >>On Thu, Apr 04, 2002 at 09:15:25 +0530, Yassar S wrote: > >I'm not writing a driver. I'm writing an application which uses > >the SIM calls like scsi_read_write etc. >Those aren't SIM calls. Are these functions exposed by the kernel? What are these functions if they are not SIM calls? I'm able to call these functions from my app without linking to any other library!! Thanks -Yassar. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 9 8:48:55 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from bosvwl02.infy.com (bosvwl02.infy.com [216.52.49.36]) by hub.freebsd.org (Postfix) with SMTP id 0F22A37B400 for ; Tue, 9 Apr 2002 08:48:50 -0700 (PDT) Received: from 192.168.200.81 by bosvwl02.infy.com (InterScan E-Mail VirusWall NT); Tue, 09 Apr 2002 11:48:03 -0400 Received: from BLRKECIMR01.ad.infosys.com ([192.168.200.58]) by indhubbhs01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Apr 2002 21:18:00 +0530 Received: from kecmsg02.ad.infosys.com ([192.168.18.90]) by BLRKECIMR01.ad.infosys.com with Microsoft SMTPSVC(5.0.2195.4905); Tue, 9 Apr 2002 21:18:00 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: SCSI Callback function not getting called Date: Tue, 9 Apr 2002 21:08:16 +0530 Message-ID: <755FA95DB839D211856B0008C7287D930F3286E8@kecmsg02.ad.infosys.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SCSI Callback function not getting called Thread-Index: AcHbnXu6qwUvAHSaTo2vsyBcKBRJlwEPr+hg From: "Yassar S" To: "Kenneth D. Merry" Cc: X-OriginalArrivalTime: 09 Apr 2002 15:48:00.0500 (UTC) FILETIME=[ED4B8340:01C1DFDD] Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I'm currently developing an application on FreeBSD3.1 to test the SCSI devices (hard disks). Whenever I do read/write on the SCSI disks, I'm not able read or write more than 126 blocks in a single operation. Any pointers what could be the reason? How can I ovecome this limitation? Thanks Yassar. -----Original Message----- From: Kenneth D. Merry [mailto:ken@kdm.org] Sent: Thursday, April 04, 2002 11:19 AM To: Yassar S Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI Callback function not getting called On Thu, Apr 04, 2002 at 09:15:25 +0530, Yassar S wrote: > I'm not writing a driver. I'm writing an application which uses > the SIM calls like scsi_read_write etc. Those aren't SIM calls. The SIM layer (SIM =3D=3D System Interface Module) is the layer where = the various SCSI and FC drivers live. Functions like scsi_read_write() fill CCBs, they don't actually execute = any I/O. You probably want to look at the cam(3) man page, and in particular = you'll want to look at the camcontrol(8) source, located in = src/sbin/camcontrol. That's probably the best example of how to issue SCSI commands from userland. The short answer to your original question is: scsi_read_write() and = the other commands like it just fill CCBs, they don't actually execute I/O. = In addition, the callback function pointer is only used in the kernel, not = in userland. In userland, CCBs are currently issued synchronously, so = there is no need for a callback function anyway. Ken --=20 Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 9 9:34:39 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id 39AC337B419 for ; Tue, 9 Apr 2002 09:34:34 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g39GYVv21347; Tue, 9 Apr 2002 10:34:31 -0600 (MDT) (envelope-from ken) Date: Tue, 9 Apr 2002 10:34:31 -0600 From: "Kenneth D. Merry" To: Yassar S Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI Callback function not getting called Message-ID: <20020409103431.A21330@panzer.kdm.org> References: <755FA95DB839D211856B0008C7287D930F3286E7@kecmsg02.ad.infosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <755FA95DB839D211856B0008C7287D930F3286E7@kecmsg02.ad.infosys.com>; from yassars@infy.com on Tue, Apr 09, 2002 at 07:40:49PM +0530 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Apr 09, 2002 at 19:40:49 +0530, Yassar S wrote: > > >>On Thu, Apr 04, 2002 at 09:15:25 +0530, Yassar S wrote: > > >I'm not writing a driver. I'm writing an application which uses > > >the SIM calls like scsi_read_write etc. > > >Those aren't SIM calls. > Are these functions exposed by the kernel? > What are these functions if they are not SIM calls? > I'm able to call these functions from my app without linking > to any other library!! They are CDB/CCB building functions. They aren't "exposed" by the kernel, but are compiled into the kernel and into libcam. You're able to call those functions because they are compiled into libcam. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 9 9:45:32 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id C045537B400 for ; Tue, 9 Apr 2002 09:45:23 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g39GjCg21452; Tue, 9 Apr 2002 10:45:12 -0600 (MDT) (envelope-from ken) Date: Tue, 9 Apr 2002 10:45:12 -0600 From: "Kenneth D. Merry" To: Yassar S Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: SCSI Callback function not getting called Message-ID: <20020409104512.B21330@panzer.kdm.org> References: <755FA95DB839D211856B0008C7287D930F3286E8@kecmsg02.ad.infosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <755FA95DB839D211856B0008C7287D930F3286E8@kecmsg02.ad.infosys.com>; from yassars@infy.com on Tue, Apr 09, 2002 at 09:08:16PM +0530 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Apr 09, 2002 at 21:08:16 +0530, Yassar S wrote: > I'm currently developing an application on FreeBSD3.1 > to test the SCSI devices (hard disks). Hmm, FreeBSD 3.1, and you work for Infosys, 'eh? I might just know something about that product. :) (could be something different, though.) > Whenever I do read/write on the SCSI disks, I'm not able > read or write more than 126 blocks in a single operation. > > Any pointers what could be the reason? How can I ovecome this > limitation? We limit things to 64K, because that is the maximum transfer size that some SCSI controllers (e.g. Adaptec 1542) can handle. There's more or less a hard limit of MAXPHYS (128K), since we're using vmapbuf() and vunmapbuf() to map buffers into and out of the kernel. You can go into cam_periph_mapmem() and change the comparison to DFLTPHYS to MAXPHYS, and that should give you a 128K limit on what you can send. The reason you're limited to 126 blocks is probably because your buffer doesn't start on a page boundary. If you start on a page boundary, you should be limited to 128 512 byte blocks, or 64K. The alternative, if you want to send more, is to use physical addresses in the CCB and set the CAM_DATA_PHYS flag. If this is the product I'm thinking of, it makes extensive use of that feature. :) Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 9 14:24:51 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from nkuaxp.nku.edu (axp1.nku.edu [192.122.237.2]) by hub.freebsd.org (Postfix) with ESMTP id 172F937B416 for ; Tue, 9 Apr 2002 14:24:35 -0700 (PDT) Received: from conversion.NKU.EDU by NKU.EDU (PMDF V6.1 #37499) id <01KGD8YFNBQ8007PQ2@NKU.EDU> for freebsd-scsi@freebsd.org; Tue, 09 Apr 2002 17:24:33 -0500 (EST) Received: from [172.25.32.7] by NKU.EDU (PMDF V6.1 #37499) with ESMTP id <01KGD8YF9FM0007YVW@NKU.EDU> for freebsd-scsi@freebsd.org; Tue, 09 Apr 2002 17:24:33 -0500 (EST) Date: Tue, 09 Apr 2002 17:24:32 -0400 From: Shawn Walker Subject: Bus Error To: freebsd-scsi@freebsd.org Message-id: MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit User-Agent: Microsoft-Entourage/10.0.0.1309 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, I have been having a problem with a server that is currently running FreeBSD 4.1. Last night the box locked up with the following error messages appearing on the console: (da0:ahc0:0:1:0): SCB 0x49 - timed out while idle. (da0:ahc0:0:1:0): SEQADDR=0x9 (da0:ahc0:0:1:0): Queuing a BDR SCB (da0:ahc0:0:1:0): no longer in timeout, status = 34a About one month ago, it locked up with the same error messages. The controller is an Adaptec aic7896/97 Ultra2. Any ideas? I am not sure if this is a driver error that could be solved with an upgrade or the sign of some impending hardware fault. Thanks for your time in advance. Shawn Walker shawn@eblend.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Tue Apr 9 14:50:32 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from melchior.cuivre.fr.eu.org (melchior.enst.fr [137.194.161.6]) by hub.freebsd.org (Postfix) with ESMTP id 591E437B400 for ; Tue, 9 Apr 2002 14:50:25 -0700 (PDT) Received: from melusine.cuivre.fr.eu.org (melusine.enst.fr [137.194.160.34]) by melchior.cuivre.fr.eu.org (Postfix) with ESMTP id B9DFE8D8A for ; Tue, 9 Apr 2002 23:50:22 +0200 (CEST) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 749202C3D2; Tue, 9 Apr 2002 23:50:20 +0200 (CEST) Date: Tue, 9 Apr 2002 23:50:20 +0200 From: Thomas Quinot To: freebsd-scsi@freebsd.org Subject: Re: xpt_bus_deregister Message-ID: <20020409235020.A2397@melusine.cuivre.fr.eu.org> Reply-To: thomas@cuivre.fr.eu.org References: <20020409094509.A4569@melusine.cuivre.fr.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20020409094509.A4569@melusine.cuivre.fr.eu.org>; from thomas@melusine.cuivre.fr.eu.org on Tue, Apr 09, 2002 at 09:45:09AM +0200 X-message-flag: WARNING! Using Outlook can damage your computer. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Le 2002-04-09, Thomas Quinot écrivait : > problem with xpt_bus_deregister. Apparently, there is one reference > to the bus which is counted but never released. As a consequence, > a call to xpt_bus_deregister(cam_sim_path(scp->sim)) will not actually > remove the bus from xpt_busses, and of course a subsequent cam_sim_free > destroys the SIM with extreme prejudice. > > Any idea where I should start looking for this reference leak? OK, I think I found it. When attaching the SIM, I setup an async callback on AC_LOST_DEVICE. This callback counts as a reference to the wildcard device, which prevents the release of the wildcard target, and therefore of the bus. Disabling the callback before calling xpt_bus_deregister & al. resolved the problem. I suspect that this problem is dormant in many other SCSI host adapter drivers. Do others have experience with removing a SIM from a running system? Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 10 12:31:49 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from van-laarhoven.org (ap-z-5ab8.adsl.wanadoo.nl [212.129.218.184]) by hub.freebsd.org (Postfix) with SMTP id A1B8437B420 for ; Wed, 10 Apr 2002 12:31:13 -0700 (PDT) Received: (qmail 28764 invoked from network); 10 Apr 2002 19:31:12 -0000 Received: from heather.van-laarhoven.org (10.66.0.2) by uitsmijter.van-laarhoven.org with SMTP; 10 Apr 2002 19:31:12 -0000 Date: Wed, 10 Apr 2002 21:31:12 +0200 (CEST) From: Nick Hibma To: Tomas Pluskal Cc: "freebsd-scsi@freebsd.org" , "freebsd-hardware@freebsd.org" Subject: Re: umass0: BBB reset failed, TIMEOUT In-Reply-To: <20020405104357.K305-100000@s096-n062.tele2.cz> Message-ID: <20020410212511.K27956-100000@heather.van-laarhoven.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org For the record: The problem is the fact that the device gets confused when a command is sent to it on the control pipe while at the same time it is working on a BBB command that came in on the bulk pipe earlier. This happens during attach. The solution is to postpone the inquiry command that CAM sends until attach has finished completely (including sending the attach event to userland (it requests string descriptors from the device after umass_attach has finished)). The change I committed earlier today doesn't work as CAM does XPT actions synchroneously. I expected them to be asynchroneous, especially when a SCSI_BUSY error is returned. Nevertheless that change is a correct one as we do not want anything to happen until we are completely finished with initialising the device. Tomas is testing changes I proposed at the moment. Nick On Fri, 5 Apr 2002, Tomas Pluskal wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > Hello, > > I am trying to connect a nikon 775 camera via USB. When I plug it in > BEFORE I boot the kernel, it works ok (it detects da0 and I can mount it). > When I plug it when system is already up, it doesn't work. It detects > umass0 (umass0: NIKON NIKON DSC E775, rev 1.10/1.00, addr 2), but it > doesn't attach it to da0 and in dmesg I see: > umass0: BBB reset failed, TIMEOUT > umass0: BBB bulk-in clear stall failed, IOERROR > umass0: BBB bulk-out clear stall failed, IOERROR > about 10 times... > > I have all drivers compiled in kernel (no modules), > > I've been searching throught lists, but I found only similar problem > reports (with different USB devices), but no solution. Is there any ? > > Thanks > > Tomas Pluskal > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.0.6 (FreeBSD) > Comment: For info see http://www.gnupg.org > > iD8DBQE8rWWkqlO9Q2aZisoRAr1tAJ9DyAw2eaYP+7390ALLSZpW062DEACfTIwf > GLZu0RxwOFE5KcELlKlLelg= > =3hJh > -----END PGP SIGNATURE----- > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-hardware" in the body of the message > -- n_hibma@van-laarhoven.org http://www.van-laarhoven.org/ n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 10 13:41:21 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169]) by hub.freebsd.org (Postfix) with ESMTP id B7D6C37B400 for ; Wed, 10 Apr 2002 13:41:16 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.11.6/8.9.1) id g3AKf5X31350; Wed, 10 Apr 2002 14:41:05 -0600 (MDT) (envelope-from ken) Date: Wed, 10 Apr 2002 14:41:05 -0600 From: "Kenneth D. Merry" To: Shawn Walker Cc: freebsd-scsi@FreeBSD.ORG Subject: Re: Bus Error Message-ID: <20020410144105.A31326@panzer.kdm.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: ; from shawn@eblend.org on Tue, Apr 09, 2002 at 05:24:32PM -0400 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Apr 09, 2002 at 17:24:32 -0400, Shawn Walker wrote: > Hi, > > I have been having a problem with a server that is currently > running FreeBSD 4.1. Last night the box locked up with the following error > messages appearing on the console: > > (da0:ahc0:0:1:0): SCB 0x49 - timed out while idle. > (da0:ahc0:0:1:0): SEQADDR=0x9 > (da0:ahc0:0:1:0): Queuing a BDR SCB > (da0:ahc0:0:1:0): no longer in timeout, status = 34a > > About one month ago, it locked up with the same error messages. The > controller is an Adaptec aic7896/97 Ultra2. Any ideas? I am not sure if > this is a driver error that could be solved with an upgrade or the sign of > some impending hardware fault. Typically a "timed out while idle" error means that the drive went out to lunch and never came back. In the case of the da(4) driver, it means the drive didn't come back after 60 seconds. What sort of drive is this (dmesg would work)? You can try upgrading to a newer -stable, but there are no guarantees that that would fix your problem. Ken -- Kenneth Merry ken@kdm.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 10 23:32: 7 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from van-laarhoven.org (ap-z-5ab8.adsl.wanadoo.nl [212.129.218.184]) by hub.freebsd.org (Postfix) with SMTP id 5E53637B41D for ; Wed, 10 Apr 2002 23:31:48 -0700 (PDT) Received: (qmail 31175 invoked from network); 11 Apr 2002 06:31:47 -0000 Received: from heather.van-laarhoven.org (10.66.0.2) by uitsmijter.van-laarhoven.org with SMTP; 11 Apr 2002 06:31:47 -0000 Date: Thu, 11 Apr 2002 08:31:47 +0200 (CEST) From: Nick Hibma To: Kenneth W Cochran Cc: "freebsd-stable@FreeBSD.ORG" , "freebsd-scsi@FreeBSD.ORG" Subject: Re: Status, USB/Olympus E-10 In-Reply-To: <200201062245.RAA7577679@shell.TheWorld.com> Message-ID: <20020411083020.G31033-100000@heather.van-laarhoven.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Compile a kernel with UMASS_DEBUG (or load the module compile with CFLAGS+=-DUMASS_DEBUG) and send me the output of an attach. It should be possible to make it work. The fact that it reboots without reason is very very strange indeed. If that is the case, check that your machine is grounded properly. Static electricity nuked my Win2k box every once in a while when I did a sync with my Palm. Nick On Sun, 6 Jan 2002, Kenneth W Cochran wrote: > (cc'ed to -scsi) > > Hello, > > A couple of committers & I were working last July (2001) with > support for the Olympus E-10 digital camera in FreeBSD. This > is a USB device. > > I just saw some commits in cam/scsi_da for Nikon & I'm wondering > what the situation is wrt Olympus? > > The problem I was having was that even though FreeBSD (then > 4.3-stable) would recognise the camera, if I tried to mount() > it the os would reboot(!) :(( No panic, no nothing, just a > hard freeze & rebooting. Obviously, this is Very Very Bad. > > I've seen Linux (2.4-something) working with this just fine. > Linux sees this camera as a SCSI device with a MS-DOS filesystem. > > I'm now running a 4.5-PRERELEASE & wonder if, assuming this > hasn't been fixed since 4.3, that this might be fixed in 4.5? > At least if the camera isn't/can't be supported in time (for > 4.5), is there some way we could at least protect the system > from the rebooting? I can probably help test. > > I'm thinking of filing a PR, but seek advice before doing that. > > Many thanks, > > -kc > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > > -- n_hibma@van-laarhoven.org http://www.van-laarhoven.org/ n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 10 23:34:19 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from van-laarhoven.org (ap-z-5ab8.adsl.wanadoo.nl [212.129.218.184]) by hub.freebsd.org (Postfix) with SMTP id 7376337B419 for ; Wed, 10 Apr 2002 23:33:51 -0700 (PDT) Received: (qmail 31187 invoked from network); 11 Apr 2002 06:33:50 -0000 Received: from heather.van-laarhoven.org (10.66.0.2) by uitsmijter.van-laarhoven.org with SMTP; 11 Apr 2002 06:33:50 -0000 Date: Thu, 11 Apr 2002 08:33:50 +0200 (CEST) From: Nick Hibma To: Kenneth W Cochran Cc: Kelly Yancey , "freebsd-scsi@FreeBSD.ORG" , "freebsd-stable@FreeBSD.ORG" Subject: Re: Status, USB/Olympus E-10 In-Reply-To: <200201101435.JAA7965305@shell.TheWorld.com> Message-ID: <20020411083227.J31033-100000@heather.van-laarhoven.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Then a panic & reboot. I guess it's better than "before" - > previously I got no message whatsoever; the OS just froze & > rebooted. At the same time I'd think a panic/reboot is Very > Very Bad; at least if something is "wrong" shouldn't the OS > "just say no?" Well, perhaps you could consider a panic an exceptional condition. One which has not been taken into account Could you compile a kernel with debugging and with DDB and then do a backtrace ('trace') when the kernel hits the debugger on the divide panic? To know _where_ the divide by zero happens is crucial. Cheers, Nick > > Here are the related pices of the kernel config: > > # SCSI peripherals > device scbus # SCSI bus (required) > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI access) > . > . > . > # USB support > device uhci # UHCI PCI->USB interface > # device ohci # OHCI PCI->USB interface > device usb # USB Bus (required) > # device ugen # Generic > # device uhid # "Human Interface Devices" > # device ukbd # Keyboard > # device ulpt # Printer > device umass # Disks/Mass storage - Requires scbus and da > > I think the kernel config is ok, because everything works fine > with a USB Zip drive. Any other ideas > > -kc > > >Date: Sun, 6 Jan 2002 18:15:52 -0800 (PST) > >From: Kelly Yancey > >To: Kenneth W Cochran > >cc: freebsd-stable@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG > >Subject: Re: Status, USB/Olympus E-10 > > > >On Sun, 6 Jan 2002, Kenneth W Cochran wrote: > > > >> (cc'ed to -scsi) > >> > >> Hello, > >> > >> A couple of committers & I were working last July (2001) with > >> support for the Olympus E-10 digital camera in FreeBSD. This > >> is a USB device. > >> > >> I just saw some commits in cam/scsi_da for Nikon & I'm wondering > >> what the situation is wrt Olympus? > > > > Bernd Walter submitted a quirk that fixed the problem for E-100RS digital > >cameras a while back. I committed the quirk, but I have not MFC'ed it to > >-stable. Besides, without other reports the quirk entry I added was specific > >to the E-100RS. I'll extend the quirk to the entire E-* seriese and ask RE if > >it's OK to MFC in time for 4.5. > > > > Kelly > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > > -- n_hibma@van-laarhoven.org http://www.van-laarhoven.org/ n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 10 23:35:25 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from van-laarhoven.org (ap-z-5ab8.adsl.wanadoo.nl [212.129.218.184]) by hub.freebsd.org (Postfix) with SMTP id E65B837B416 for ; Wed, 10 Apr 2002 23:35:15 -0700 (PDT) Received: (qmail 31217 invoked from network); 11 Apr 2002 06:35:15 -0000 Received: from heather.van-laarhoven.org (10.66.0.2) by uitsmijter.van-laarhoven.org with SMTP; 11 Apr 2002 06:35:15 -0000 Date: Thu, 11 Apr 2002 08:35:15 +0200 (CEST) From: Nick Hibma To: Len Conrad Cc: "freebsd-scsi@freebsd.org" Subject: Re: USB "Memorybird" quirks In-Reply-To: <5.1.0.14.2.20020209080221.057c9ec0@mail.Go2France.com> Message-ID: <20020411083427.F31033-100000@heather.van-laarhoven.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org That requires BIOS support for booting from USB and that already is available. The problem then is to make the kernel switch from booting from /dev/fd0 to /dev/da0, because that is what the 'real' device will appear at. Good luck :-) Nick On Sat, 9 Feb 2002, Len Conrad wrote: > > >I think that would be a very good idea. The boot software > >issue is negligible, because there aren't any USB devices > >you can boot from. > > Is booting from a USB device planned? For diskless routers, we had the > idea of using one of the USB "key fob" devices as emergency boot > device. The OS and ipfilter + rules would be on CF, and if that every got > compromised, plug in the CF-in-a-key-fob device to the USB port and re-boot. > > Len > > > http://MenAndMice.com/DNS-training > http://BIND8NT.MEIway.com : ISC BIND 8.2.4 for NT4 & W2K > http://IMGate.MEIway.com : Build free, hi-perf, anti-abuse mail gateways > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > -- n_hibma@van-laarhoven.org http://www.van-laarhoven.org/ n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Wed Apr 10 23:37:46 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from van-laarhoven.org (ap-z-5ab8.adsl.wanadoo.nl [212.129.218.184]) by hub.freebsd.org (Postfix) with SMTP id E941B37B400 for ; Wed, 10 Apr 2002 23:37:35 -0700 (PDT) Received: (qmail 31249 invoked from network); 11 Apr 2002 06:37:35 -0000 Received: from heather.van-laarhoven.org (10.66.0.2) by uitsmijter.van-laarhoven.org with SMTP; 11 Apr 2002 06:37:35 -0000 Date: Thu, 11 Apr 2002 08:37:35 +0200 (CEST) From: Nick Hibma To: "jstocker@tzi.de" Cc: "freebsd-scsi@FreeBSD. ORG" Subject: Re: USB / wrong disklabel params In-Reply-To: <000c01c19763$1e3c2860$fe02010a@twoflower.liebende.de> Message-ID: <20020411083549.T31033-100000@heather.van-laarhoven.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is strange: 0MB (1441 512 byte sectors: 2H 9S/T 80C) It thinks the device is a floppy drive. The 0Mb should be correct because that comes from inquiry data if I am not mistaken. The geometry calculation is a botch because I haven't bothered to find a way to get that correct. See 'XXX' in the /sys/dev/umass driver. Nick On Mon, 7 Jan 2002, Jan Stocker wrote: > Hi boys n girls, > ive discussed the following stuff with Ed Hudson, who owns a RICOH-RDC5000 > digital cam. This cam doesn't know the 6-byte commands (like the most), so a > quirk was added. > > But some disk information is wrong... lets have a look > > Dec 29 14:17:17 m3 /kernel: umass0: RICOH RDC-5000, rev 1.00/1.05, addr 2 > Dec 29 14:17:17 m3 /kernel: da0 at umass-sim0 bus 0 target 0 lun 0 > Dec 29 14:17:17 m3 /kernel: da0: Removable > Dire > Access SCSI-0 device > Dec 29 14:17:17 m3 /kernel: da0: 20KB/s transfers > Dec 29 14:17:17 m3 /kernel: da0: 0MB (1441 512 byte sectors: 2H 9S/T 80C) > > The cam has a 8 MB card in it, so here !!! 0MB !!! is totally wrong. > (Also i think the speed is very low) > Another look to the partition table with fdisk shows more: > > root@m3 101 % fdisk da0 > ******* Working on device /dev/da0 ******* > parameters extracted from in-core disklabel are: > cylinders=22 heads=4 sectors/track=16 (64 blks/cyl) > > We have 22*4*16*512 = 704 KB! > > parameters to be used for BIOS calculations are: > cylinders=22 heads=4 sectors/track=16 (64 blks/cyl) > > 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 1,(Primary DOS with 12 bit FAT) > start 25, size 15975 (7 Meg), flag 80 (active) > beg: cyl 0/ head 1/ sector 10; > end: cyl 249/ head 3/ sector 16 > The data for partition 2 is: > > The data for partition 3 is: > > The data for partition 4 is: > > > > But the partition table is correct and gives us a 8 MB slice. So mounting > fails (cuts the partition) cause BSD thinks the slice exceeds the available > space. > > Any idea ? > > Jan > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > > -- n_hibma@van-laarhoven.org http://www.van-laarhoven.org/ n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 11 2:19:37 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id C1DE137B405 for ; Thu, 11 Apr 2002 02:19:35 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1000) id A332FAE1D7; Thu, 11 Apr 2002 02:19:35 -0700 (PDT) Date: Thu, 11 Apr 2002 02:19:35 -0700 From: Paul Saab To: Lukas Ertl Cc: freebsd-scsi@freebsd.org Subject: Re: ciss driver and tagged queuing Message-ID: <20020411091935.GA99318@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="VbJkn9YxBvnuCH5J" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Can you try this patch? It should fix the performance problems you are having. --VbJkn9YxBvnuCH5J Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ciss.diff" Index: ciss.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ciss/ciss.c,v retrieving revision 1.3 diff -u -I$PMS -I$FreeBSD -I$Id -u -r1.3 ciss.c --- ciss.c 2001/12/18 08:01:48 1.3 +++ ciss.c 2002/04/11 09:18:42 @@ -1999,8 +1999,9 @@ * Create a SIM. */ if ((sc->ciss_cam_sim = cam_sim_alloc(ciss_cam_action, ciss_cam_poll, "ciss", sc, - device_get_unit(sc->ciss_dev), 1, + device_get_unit(sc->ciss_dev), sc->ciss_cfg->max_outstanding_commands, + 1, sc->ciss_cam_devq)) == NULL) { ciss_printf(sc, "can't allocate CAM SIM\n"); return(ENOMEM); --VbJkn9YxBvnuCH5J-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 11 2:36:57 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mailbox.univie.ac.at (mailbox.univie.ac.at [131.130.1.27]) by hub.freebsd.org (Postfix) with ESMTP id BBF2237B41A for ; Thu, 11 Apr 2002 02:36:54 -0700 (PDT) Received: from adslle.cc.univie.ac.at (adslle.cc.univie.ac.at [131.130.102.11]) by mailbox.univie.ac.at (8.12.2/8.12.2) with ESMTP id g3B9aiSA1754494; Thu, 11 Apr 2002 11:36:46 +0200 Date: Thu, 11 Apr 2002 11:36:44 +0200 (CEST) From: Lukas Ertl X-X-Sender: le@leelou.in.tern To: Paul Saab Cc: freebsd-scsi@freebsd.org Subject: Re: ciss driver and tagged queuing In-Reply-To: <20020411091935.GA99318@elvis.mu.org> Message-ID: <20020411113606.H467-100000@leelou.in.tern> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-DCC-sackHeads-Metrics: mailbox 1012; Body=2 Fuz1=2 Fuz2=2 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 11 Apr 2002, Paul Saab wrote: > Can you try this patch? It should fix the performance problems you > are having. Thanks for the patch, I'll try it next week and will report then if it helped! regards, le --=20 Lukas Ertl eMail: l.ertl@univie.ac.at UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universit=E4t Wien http://mailbox.univie.ac.at/~le/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 11 4:13:35 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from van-laarhoven.org (ap-z-5ab8.adsl.wanadoo.nl [212.129.218.184]) by hub.freebsd.org (Postfix) with SMTP id C473E37B42B for ; Thu, 11 Apr 2002 04:13:26 -0700 (PDT) Received: (qmail 32216 invoked from network); 11 Apr 2002 11:13:25 -0000 Received: from heather.van-laarhoven.org (10.66.0.2) by uitsmijter.van-laarhoven.org with SMTP; 11 Apr 2002 11:13:25 -0000 Date: Thu, 11 Apr 2002 13:13:25 +0200 (CEST) From: Nick Hibma To: Thomas Quinot Cc: "freebsd-scsi@freebsd.org" Subject: Re: xpt_bus_deregister In-Reply-To: <20020409235020.A2397@melusine.cuivre.fr.eu.org> Message-ID: <20020411124923.F31033-100000@heather.van-laarhoven.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Don't you have a loop in there now? The AC_LOST_DEVICE event is generated by the SIM on detachment of a device, so you don't have to wait for the event to be delivered to you. In your SIM you should not create a async andler for async events for the devices attached to your SIM. Instead you should deliver the AC_LOST_DEVICE event to CAM on seeing a detach. Or am I misunderstanding your driver by chance? Nick On Tue, 9 Apr 2002, Thomas Quinot wrote: > Le 2002-04-09, Thomas Quinot =E9crivait : > > > problem with xpt_bus_deregister. Apparently, there is one reference > > to the bus which is counted but never released. As a consequence, > > a call to xpt_bus_deregister(cam_sim_path(scp->sim)) will not actually > > remove the bus from xpt_busses, and of course a subsequent cam_sim_free > > destroys the SIM with extreme prejudice. > > > > Any idea where I should start looking for this reference leak? > > OK, I think I found it. When attaching the SIM, I setup an > async callback on AC_LOST_DEVICE. This callback counts as > a reference to the wildcard device, which prevents the release > of the wildcard target, and therefore of the bus. Disabling > the callback before calling xpt_bus_deregister & al. resolved > the problem. > > I suspect that this problem is dormant in many other SCSI > host adapter drivers. Do others have experience with removing > a SIM from a running system? > > Thomas. > > --=20 n_hibma@van-laarhoven.org http://www.van-laarhoven.org/ n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 11 4:17:11 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from borja.sarenet.es (borja.sarenet.es [192.148.167.77]) by hub.freebsd.org (Postfix) with ESMTP id ADC7A37B417 for ; Thu, 11 Apr 2002 04:17:07 -0700 (PDT) Received: from there (localhost [127.0.0.1]) by borja.sarenet.es (8.11.6/8.11.6) with SMTP id g3BBH5249710 for ; Thu, 11 Apr 2002 13:17:06 +0200 (CEST) (envelope-from borjam@sarenet.es) Message-Id: <200204111117.g3BBH5249710@borja.sarenet.es> Content-Type: text/plain; charset="iso-8859-1" From: Borja Marcos Organization: Sarenet S.A. To: freebsd-scsi@freebsd.org Subject: Dell PERC3/DC and FreeBSD Date: Thu, 11 Apr 2002 13:17:05 +0200 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org =09Hello, =09I need to perform a firmware upgrade on a Dell PERC3/DC RAID card. I h= ave=20 read that the latest versions of the amr driver support the Linux managem= ent=20 utilities. Is this correct? =09The FreeBSD version I am running is... FreeBSD backend.sarenet.es 4.5-RELEASE-p2 FreeBSD 4.5-RELEASE-p2 #0: Mon=20 Mar 18 13:06:24 CET 2002 =20 root@backend.sarenet.es:/usr/obj/usr/src/sys/BACKEND i386 =09Thank you, =09Borja. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 11 4:34: 6 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from melchior.cuivre.fr.eu.org (melchior.enst.fr [137.194.161.6]) by hub.freebsd.org (Postfix) with ESMTP id D7EA037B404 for ; Thu, 11 Apr 2002 04:34:01 -0700 (PDT) Received: from melusine.cuivre.fr.eu.org (melusine.enst.fr [137.194.160.34]) by melchior.cuivre.fr.eu.org (Postfix) with ESMTP id 5DEF37EB5; Thu, 11 Apr 2002 13:33:59 +0200 (CEST) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 7D5D72C3D1; Thu, 11 Apr 2002 13:33:49 +0200 (CEST) Date: Thu, 11 Apr 2002 13:33:49 +0200 From: Thomas Quinot To: Nick Hibma Cc: "freebsd-scsi@freebsd.org" Subject: Re: xpt_bus_deregister Message-ID: <20020411133349.B59054@melusine.cuivre.fr.eu.org> Reply-To: thomas@cuivre.fr.eu.org References: <20020409235020.A2397@melusine.cuivre.fr.eu.org> <20020411124923.F31033-100000@heather.van-laarhoven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <20020411124923.F31033-100000@heather.van-laarhoven.org>; from n_hibma@van-laarhoven.org on Thu, Apr 11, 2002 at 01:13:25PM +0200 X-message-flag: WARNING! Using Outlook can damage your computer. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Le 2002-04-11, Nick Hibma écrivait : > Don't you have a loop in there now? Not AFAIK. > The AC_LOST_DEVICE event is > generated by the SIM on detachment of a device, so you don't have to > wait for the event to be delivered to you. In your SIM you should not > create a async andler for async events for the devices attached to your > SIM. Hum, then maybe there is something that I did not understand in the documentation. According to the developer's handbook, section 24.2, the SIM is supposed to set up a callback for such events. > Instead you should deliver the AC_LOST_DEVICE event to CAM on > seeing a detach. If I understand the code correctly, xpt_bus_deregister takes care of delivering AC_LOST_DEVICE and AC_PATH_DEREGISTERED to CAM. > Or am I misunderstanding your driver by chance? Well if you'd like to see for yourself, the code is at http://www.cuivre.fr.eu.org/~thomas/atapicam/patches/atapicam-20020409.diff Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 11 6:16:53 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) by hub.freebsd.org (Postfix) with ESMTP id 5F7CE37B400 for ; Thu, 11 Apr 2002 06:16:50 -0700 (PDT) Received: from scsiguy.com (localhost [127.0.0.1]) by aslan.scsiguy.com (8.11.6/8.11.5) with ESMTP id g3BDG8939967; Thu, 11 Apr 2002 07:16:08 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Message-Id: <200204111316.g3BDG8939967@aslan.scsiguy.com> To: Nick Hibma Cc: Thomas Quinot , "freebsd-scsi@freebsd.org" Subject: Re: xpt_bus_deregister In-Reply-To: Your message of "Thu, 11 Apr 2002 13:13:25 +0200." <20020411124923.F31033-100000@heather.van-laarhoven.org> Date: Thu, 11 Apr 2002 07:16:08 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > >Don't you have a loop in there now? The AC_LOST_DEVICE event is >generated by the SIM on detachment of a device, so you don't have to >wait for the event to be delivered to you. In your SIM you should not >create a async andler for async events for the devices attached to your >SIM. Instead you should deliver the AC_LOST_DEVICE event to CAM on >seeing a detach. This depends on how the device is lost. Layers above the SIM can decide when a device is considered lost based on the types of status your SIM reports. For example, in parallel SCSI, a single selection timeout may not indicate that the device is lost, but several in a row may. The SIM cannot just assume the device is lost after a single selection timeout. Many drivers use this event to reset their negotiation table so that they will renegotiate the next time the system attempts to talk to the "lost device". This can happen in hot-plug situations. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 11 6:42:20 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from van-laarhoven.org (ap-z-5ab8.adsl.wanadoo.nl [212.129.218.184]) by hub.freebsd.org (Postfix) with SMTP id 827E237B400 for ; Thu, 11 Apr 2002 06:42:16 -0700 (PDT) Received: (qmail 32709 invoked from network); 11 Apr 2002 13:42:15 -0000 Received: from dhcp0-120.van-laarhoven.org (HELO cecile) (10.66.0.120) by uitsmijter.van-laarhoven.org with SMTP; 11 Apr 2002 13:42:14 -0000 Message-ID: <004501c1e15e$fdbbc000$7800420a@vanlaarhoven.org> From: "Nick Hibma" To: "Justin T. Gibbs" Cc: "Thomas Quinot" , "freebsd-scsi@freebsd.org" References: <200204111316.g3BDG8939967@aslan.scsiguy.com> Subject: Re: xpt_bus_deregister Date: Thu, 11 Apr 2002 15:44:24 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > This depends on how the device is lost. Layers above the SIM > can decide when a device is considered lost based on the types > of status your SIM reports. For example, in parallel SCSI, > a single selection timeout may not indicate that the device is > lost, but several in a row may. The SIM cannot just assume the > device is lost after a single selection timeout. > > Many drivers use this event to reset their negotiation table so > that they will renegotiate the next time the system attempts to > talk to the "lost device". This can happen in hot-plug situations. I presume that with this you are trying to say that AC_LOST_DEVICE could come from different sources, outside the SIM and the SIM might want to reset is internal state on the device. I understand that. But in the case of the ATAPI/CAM layer he wants to use it to detach the SIM. That sounds a bit odd to me because the only sources of a SIM disconnect I can think of are: - hardware, e.g. disconnection of PCMCIA card - unloading of the driver And in both cases the driver that created the SIM initiates the removal of the SIM. Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 11 6:46:27 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from melchior.cuivre.fr.eu.org (melchior.enst.fr [137.194.161.6]) by hub.freebsd.org (Postfix) with ESMTP id B6C0B37B417 for ; Thu, 11 Apr 2002 06:46:23 -0700 (PDT) Received: from melusine.cuivre.fr.eu.org (melusine.enst.fr [137.194.160.34]) by melchior.cuivre.fr.eu.org (Postfix) with ESMTP id DA5BB83F0; Thu, 11 Apr 2002 15:46:20 +0200 (CEST) Received: by melusine.cuivre.fr.eu.org (Postfix, from userid 1000) id 3F2B02C3D1; Thu, 11 Apr 2002 15:46:13 +0200 (CEST) Date: Thu, 11 Apr 2002 15:46:13 +0200 From: Thomas Quinot To: Nick Hibma Cc: "Justin T. Gibbs" , Thomas Quinot , "freebsd-scsi@freebsd.org" Subject: Re: xpt_bus_deregister Message-ID: <20020411154613.A84638@melusine.cuivre.fr.eu.org> Reply-To: thomas@cuivre.fr.eu.org References: <200204111316.g3BDG8939967@aslan.scsiguy.com> <004501c1e15e$fdbbc000$7800420a@vanlaarhoven.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <004501c1e15e$fdbbc000$7800420a@vanlaarhoven.org>; from n_hibma@van-laarhoven.org on Thu, Apr 11, 2002 at 03:44:24PM +0200 X-message-flag: WARNING! Using Outlook can damage your computer. Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Le 2002-04-11, Nick Hibma écrivait : > But in the case of the ATAPI/CAM layer he wants to use it to detach the SIM. No no, I think there is some confusion here. The SIM detach function is called by the underlying ATAPI code, /not/ by the async callback. The issue is that before calling xpt_bus_deregister in the detach function, I also need to /remove/ the async callback for the ref count to correctly drop to 0. Thomas. -- Thomas.Quinot@Cuivre.FR.EU.ORG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 11 15:49: 6 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from hotmail.com (f32.law11.hotmail.com [64.4.17.32]) by hub.freebsd.org (Postfix) with ESMTP id 0901B37B404 for ; Thu, 11 Apr 2002 15:49:00 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 11 Apr 2002 15:48:59 -0700 Received: from 208.151.119.232 by lw11fd.law11.hotmail.msn.com with HTTP; Thu, 11 Apr 2002 22:48:59 GMT X-Originating-IP: [208.151.119.232] From: "Chad Kline" To: n_hibma@van-laarhoven.org Cc: freebsd-scsi@freebsd.org Subject: Re: usb mass storage driver - umass Date: Thu, 11 Apr 2002 22:48:59 +0000 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Apr 2002 22:48:59.0867 (UTC) FILETIME=[11E08AB0:01C1E1AB] Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org i see the problems: (camera always plugged in at boot) 1. in computerA (messages below) all the time. 2. in computerB, camera functions, but if unplugged/replugged, the same problems occur upon "camcontrol rescan 0". (BBB failures, therefore, mount errors). so i tried commenting out the rescan call in umass.c after the "if (!cold)" statement, cuz of a possible bug there, but that didn't change anything i could see. thanks for your help. >Do you see these problems during boot or during attach after boot? > >The state machine is a nifty mechanism where you start a USB transfer >and when it completes you handle the return value and start the next >one. Because the umass USB protocol requires multiple steps there are >many states that it goes through, including recovery. > >I presume that you added those 'OLYMPUS - ...' messages? > >Try the attached umass driver. Maybe that it solves your problem: > >Nick > >On Sun, 7 Apr 2002, Chad Kline wrote: > > > > > since usb mass storage driver (umass.c) > > is tied to scsi stuff, i am posting to > > see if anyone may be able to direct > > me to bring about a solution to this problem. > > > > from the following, i assume i the link/controller/camera > > are operational to some extent - as the camera ID is > > detected just fine by the driver as well as > > userland programs. > > > > $ dmesg (kernel/driver detection, > > QUIRK=command status signature fix, 0x5343->0x5542) > > for OLYMPUS C-1's) > > > > FreeBSD 4.5-RELEASE #3: Sat Apr 6 22:12:40 AKST 2002 > > ohci0: mem 0xe1000000-0xe1000fff >irq > > 10 at device 19.0 on pci0 > > usb0: OHCI version 1.0, legacy support > > usb0: on ohci0 > > usb0: USB revision 1.0 > > uhub0: OPTi OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > > uhub0: 2 ports with 2 removable, self powered > > OLYMPUS - APPLYING CSS QUIRK! > > OLYMPUS - APPLYING CSS QUIRK! > > OLYMPUS - APPLYING CSS QUIRK! > > umass0: OLYMPUS C-1Z,D-150Z, rev 1.10/10.15, addr 2 > > OLYMPUS - case TSTATE_BBB_RESET1: > > umass0: BBB reset failed, TIMEOUT > > OLYMPUS - case TSTATE_BBB_RESET2: > > umass0: BBB bulk-in clear stall failed, TIMEOUT > > OLYMPUS - case TSTATE_BBB_RESET3: > > umass0: BBB bulk-out clear stall failed, TIMEOUT > > > > $ usbdevs (userland program) > > > > Controller /dev/usb0: > > addr 1: self powered, config 1, OHCI root hub(0x0000), > > OPTi(0x0000), rev 0x0100 port 1 > > addr 2: self powered, config 1, C-1 Digital Camera(0x0102), > > Olympus(0x07b4), rev 0x1015 port 2 powered > > > > without umass0 (USB mass storage driver) being able to > > complete it's task, i cannot mount the camera's smartmedia > > disk. supposedly this camera supposedly has "the convenient > > Auto Connect USB feature lets your computer automatically recognize > > your Brio Zoom D-150 so you don't have to install any additional > > software". so i think i should be able to mount this camera. > > i don't have windows, and don't know of bsd/unix USB snoop software. > > > > the failure is in this function - a status state machine. > > i can't find a calling function, so i assume it's installed > > as an interrupt handler (i don't know too much about how > > unix installs handlers/remaps interrupt signals). > > > > umass.c: > > > > Static void > > umass_bbb_state(usbd_xfer_handle xfer, usbd_private_handle priv, > > usbd_status err) > > { > > /***** Bulk Reset *****/ > > case TSTATE_BBB_RESET1: > > if (err) { > > printf("OLYMPUS - TSTATE_BBB_RESET1\n"); > > printf("%s: BBB reset failed, %s\n", > > USBDEVNAME(sc->sc_dev), usbd_errstr(err)); > > } > > umass_clear_endpoint_stall(sc, > > sc->bulkin, sc->bulkin_pipe, TSTATE_BBB_RESET2, > > sc->transfer_xfer[XFER_BBB_RESET2]); > > > > return; > > case TSTATE_BBB_RESET2: > > if (err) { /* should not occur */ > > printf("OLYMPUS - TSTATE_BBB_RESET2!\n"); > > printf("%s: BBB bulk-in clear stall failed, %s\n", > > USBDEVNAME(sc->sc_dev), usbd_errstr(err)); > > /* no error recovery, otherwise we end up in a loop */ > > } > > umass_clear_endpoint_stall(sc, > > sc->bulkout, sc->bulkout_pipe, TSTATE_BBB_RESET3, > > sc->transfer_xfer[XFER_BBB_RESET3]); > > > > return; > > case TSTATE_BBB_RESET3: > > if (err) { /* should not occur */ > > printf("OLYMPUS - TSTATE_BBB_RESET3!\n"); > > printf("%s: BBB bulk-out clear stall failed, %s\n", > > USBDEVNAME(sc->sc_dev), usbd_errstr(err)); > > /* no error recovery, otherwise we end up in a loop */ > > } > > sc->transfer_state = TSTATE_IDLE; > > if (sc->transfer_priv) { > > sc->transfer_cb(sc, sc->transfer_priv, > > sc->transfer_datalen, > > sc->transfer_status); > > } > > > > return; > > > > /***** Default *****/ > > default: > > panic("%s: Unknown state %d\n", > > USBDEVNAME(sc->sc_dev), sc->transfer_state); > > } > > > > > > > > _________________________________________________________________ > > MSN Photos is the easiest way to share and print your photos: > > http://photos.msn.com/support/worldwide.aspx > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-scsi" in the body of the message > > > >-- >n_hibma@van-laarhoven.org http://www.van-laarhoven.org/ >n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/ ><< umass.c >> _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Apr 11 22:54:31 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from van-laarhoven.org (ap-z-5ab8.adsl.wanadoo.nl [212.129.218.184]) by hub.freebsd.org (Postfix) with SMTP id 3931B37B416 for ; Thu, 11 Apr 2002 22:53:50 -0700 (PDT) Received: (qmail 36108 invoked from network); 12 Apr 2002 05:53:48 -0000 Received: from heather.van-laarhoven.org (10.66.0.2) by uitsmijter.van-laarhoven.org with SMTP; 12 Apr 2002 05:53:48 -0000 Date: Fri, 12 Apr 2002 07:53:48 +0200 (CEST) From: Nick Hibma To: Chad Kline Cc: "freebsd-scsi@freebsd.org" Subject: Re: usb mass storage driver - umass In-Reply-To: Message-ID: <20020412075211.Y31033-100000@heather.van-laarhoven.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Could you compile your umass driver with the UMASS_DEBUG flag set? Add CFLAGS+= -DUMASS_DEBUG to /sys/modules/umass/Makefile, do a make clean make obj make clean make make install kldload umass Or if you have compiled the module into the kernel add a options UMASS_DEBUG to your kernel config. Nick On Thu, 11 Apr 2002, Chad Kline wrote: > > i see the problems: (camera always plugged in at boot) > > 1. in computerA (messages below) all the time. > 2. in computerB, camera functions, but if unplugged/replugged, > the same problems occur upon "camcontrol rescan 0". > (BBB failures, therefore, mount errors). > > so i tried commenting out the rescan call in umass.c > after the "if (!cold)" statement, cuz of a possible > bug there, but that didn't change anything i could see. > > thanks for your help. > > >Do you see these problems during boot or during attach after boot? > > > >The state machine is a nifty mechanism where you start a USB transfer > >and when it completes you handle the return value and start the next > >one. Because the umass USB protocol requires multiple steps there are > >many states that it goes through, including recovery. > > > >I presume that you added those 'OLYMPUS - ...' messages? > > > >Try the attached umass driver. Maybe that it solves your problem: > > > >Nick > > > >On Sun, 7 Apr 2002, Chad Kline wrote: > > > > > > > > since usb mass storage driver (umass.c) > > > is tied to scsi stuff, i am posting to > > > see if anyone may be able to direct > > > me to bring about a solution to this problem. > > > > > > from the following, i assume i the link/controller/camera > > > are operational to some extent - as the camera ID is > > > detected just fine by the driver as well as > > > userland programs. > > > > > > $ dmesg (kernel/driver detection, > > > QUIRK=command status signature fix, 0x5343->0x5542) > > > for OLYMPUS C-1's) > > > > > > FreeBSD 4.5-RELEASE #3: Sat Apr 6 22:12:40 AKST 2002 > > > ohci0: mem 0xe1000000-0xe1000fff > >irq > > > 10 at device 19.0 on pci0 > > > usb0: OHCI version 1.0, legacy support > > > usb0: on ohci0 > > > usb0: USB revision 1.0 > > > uhub0: OPTi OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 > > > uhub0: 2 ports with 2 removable, self powered > > > OLYMPUS - APPLYING CSS QUIRK! > > > OLYMPUS - APPLYING CSS QUIRK! > > > OLYMPUS - APPLYING CSS QUIRK! > > > umass0: OLYMPUS C-1Z,D-150Z, rev 1.10/10.15, addr 2 > > > OLYMPUS - case TSTATE_BBB_RESET1: > > > umass0: BBB reset failed, TIMEOUT > > > OLYMPUS - case TSTATE_BBB_RESET2: > > > umass0: BBB bulk-in clear stall failed, TIMEOUT > > > OLYMPUS - case TSTATE_BBB_RESET3: > > > umass0: BBB bulk-out clear stall failed, TIMEOUT > > > > > > $ usbdevs (userland program) > > > > > > Controller /dev/usb0: > > > addr 1: self powered, config 1, OHCI root hub(0x0000), > > > OPTi(0x0000), rev 0x0100 port 1 > > > addr 2: self powered, config 1, C-1 Digital Camera(0x0102), > > > Olympus(0x07b4), rev 0x1015 port 2 powered > > > > > > without umass0 (USB mass storage driver) being able to > > > complete it's task, i cannot mount the camera's smartmedia > > > disk. supposedly this camera supposedly has "the convenient > > > Auto Connect USB feature lets your computer automatically recognize > > > your Brio Zoom D-150 so you don't have to install any additional > > > software". so i think i should be able to mount this camera. > > > i don't have windows, and don't know of bsd/unix USB snoop software. > > > > > > the failure is in this function - a status state machine. > > > i can't find a calling function, so i assume it's installed > > > as an interrupt handler (i don't know too much about how > > > unix installs handlers/remaps interrupt signals). > > > > > > umass.c: > > > > > > Static void > > > umass_bbb_state(usbd_xfer_handle xfer, usbd_private_handle priv, > > > usbd_status err) > > > { > > > /***** Bulk Reset *****/ > > > case TSTATE_BBB_RESET1: > > > if (err) { > > > printf("OLYMPUS - TSTATE_BBB_RESET1\n"); > > > printf("%s: BBB reset failed, %s\n", > > > USBDEVNAME(sc->sc_dev), usbd_errstr(err)); > > > } > > > umass_clear_endpoint_stall(sc, > > > sc->bulkin, sc->bulkin_pipe, TSTATE_BBB_RESET2, > > > sc->transfer_xfer[XFER_BBB_RESET2]); > > > > > > return; > > > case TSTATE_BBB_RESET2: > > > if (err) { /* should not occur */ > > > printf("OLYMPUS - TSTATE_BBB_RESET2!\n"); > > > printf("%s: BBB bulk-in clear stall failed, %s\n", > > > USBDEVNAME(sc->sc_dev), usbd_errstr(err)); > > > /* no error recovery, otherwise we end up in a loop */ > > > } > > > umass_clear_endpoint_stall(sc, > > > sc->bulkout, sc->bulkout_pipe, TSTATE_BBB_RESET3, > > > sc->transfer_xfer[XFER_BBB_RESET3]); > > > > > > return; > > > case TSTATE_BBB_RESET3: > > > if (err) { /* should not occur */ > > > printf("OLYMPUS - TSTATE_BBB_RESET3!\n"); > > > printf("%s: BBB bulk-out clear stall failed, %s\n", > > > USBDEVNAME(sc->sc_dev), usbd_errstr(err)); > > > /* no error recovery, otherwise we end up in a loop */ > > > } > > > sc->transfer_state = TSTATE_IDLE; > > > if (sc->transfer_priv) { > > > sc->transfer_cb(sc, sc->transfer_priv, > > > sc->transfer_datalen, > > > sc->transfer_status); > > > } > > > > > > return; > > > > > > /***** Default *****/ > > > default: > > > panic("%s: Unknown state %d\n", > > > USBDEVNAME(sc->sc_dev), sc->transfer_state); > > > } > > > > > > > > > > > > _________________________________________________________________ > > > MSN Photos is the easiest way to share and print your photos: > > > http://photos.msn.com/support/worldwide.aspx > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-scsi" in the body of the message > > > > > > >-- > >n_hibma@van-laarhoven.org http://www.van-laarhoven.org/ > >n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/ > ><< umass.c >> > > > > > _________________________________________________________________ > Chat with friends online, try MSN Messenger: http://messenger.msn.com > > -- n_hibma@van-laarhoven.org http://www.van-laarhoven.org/ n_hibma@FreeBSD.org http://www.etla.net/~n_hibma/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 12 14:34:33 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from smgwisys.intersys.com.mx (smgwisys.intersys.com.mx [206.65.32.41]) by hub.freebsd.org (Postfix) with SMTP id B2E9D37B400 for ; Fri, 12 Apr 2002 14:34:30 -0700 (PDT) Received: by smgwisys.intersys.com.mx(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 06256B99.007C147F ; Fri, 12 Apr 2002 16:35:17 -0600 X-Lotus-FromDomain: INTERSYS@ISYS From: rrios@intersys.com.mx To: scsi@freebsd.org Message-ID: <06256B99.007C12BA.00@smgwisys.intersys.com.mx> Date: Fri, 12 Apr 2002 16:28:01 -0600 Subject: IBM SCSI Server RAID 3H, 3L, II supported????? Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Has any body know if this scsi card is supported by FreeBSD 4.4-R or 4.5-R ? already search in the hardware suppord and I not found some. RRV. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 12 15:10:24 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from magic.adaptec.com (magic.adaptec.com [208.236.45.80]) by hub.freebsd.org (Postfix) with ESMTP id 2477437B400 for ; Fri, 12 Apr 2002 15:10:22 -0700 (PDT) Received: from redfish.adaptec.com (redfish.adaptec.com [162.62.50.11]) by magic.adaptec.com (8.10.2+Sun/8.10.2) with ESMTP id g3CMA8j17981; Fri, 12 Apr 2002 15:10:08 -0700 (PDT) Received: from btc.btc.adaptec.com (btc.btc.adaptec.com [10.100.0.52]) by redfish.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id PAA07536; Fri, 12 Apr 2002 15:10:08 -0700 (PDT) Received: from btcexc01.btc.adaptec.com (btcexc01 [162.62.147.10]) by btc.btc.adaptec.com (8.8.8+Sun/8.8.8) with ESMTP id QAA10435; Fri, 12 Apr 2002 16:08:46 -0600 (MDT) Received: by btcexc01.btc.adaptec.com with Internet Mail Service (5.5.2653.19) id <2ZMN0DYN>; Fri, 12 Apr 2002 16:08:47 -0600 Message-ID: From: "Long, Scott" To: "'rrios@intersys.com.mx'" , scsi@freebsd.org Subject: RE: IBM SCSI Server RAID 3H, 3L, II supported????? Date: Fri, 12 Apr 2002 16:08:46 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org > Has any body know if this scsi card is supported by FreeBSD > 4.4-R or 4.5-R ? > already search in the hardware suppord and I not found some. > > > RRV. No, they are not supported. This may change in the future, but not before FreeBSD 4.6 is released. Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Apr 12 18:47:45 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from hotmail.com (f44.law11.hotmail.com [64.4.17.44]) by hub.freebsd.org (Postfix) with ESMTP id 7986937B400 for ; Fri, 12 Apr 2002 18:47:22 -0700 (PDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 12 Apr 2002 18:47:22 -0700 Received: from 208.151.119.232 by lw11fd.law11.hotmail.msn.com with HTTP; Sat, 13 Apr 2002 01:47:22 GMT X-Originating-IP: [208.151.119.232] From: "Chad Kline" To: n_hibma@van-laarhoven.org Cc: freebsd-scsi@freebsd.org Subject: Re: usb mass storage driver - umass Date: Sat, 13 Apr 2002 01:47:22 +0000 Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_7db4_3641_2ff1" Message-ID: X-OriginalArrivalTime: 13 Apr 2002 01:47:22.0421 (UTC) FILETIME=[27826E50:01C1E28D] Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_7db4_3641_2ff1 Content-Type: text/plain; format=flowed >Could you compile your umass driver with the UMASS_DEBUG flag set? yes, and i must include the data as an attachment, because it is too much data to include inline ... please Cc off list, thank you. _________________________________________________________________ Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com ------=_NextPart_000_7db4_3641_2ff1 Content-Type: application/octet-stream; name="xxx" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="xxx" Cj4gQ291bGQgeW91IGNvbXBpbGUgeW91ciB1bWFzcyBkcml2ZXIgd2l0aCB0 aGUgVU1BU1NfREVCVUcgZmxhZyBzZXQ/Cgpwcm9ibGVtczogKGNhbWVyYSBh bHdheXMgcGx1Z2dlZCBpbiBhdCBib290IC0gcGxlYXNlIENjIG9mZiBsaXN0 ISkKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0KQ09NUFVURVItQToKCmkgYW0gaGF2aW5nIHRy b3VibGUgd2l0aCBhIHN0b3JhZ2UgY2xhc3MgVVNCIGRldmljZS4KdGhlIGRl dmljZSBpcyBhIE9seW1wdXMgQy0xL0QtMTUwIGNhbWVyYSB3aXRoCmEgU21h cnRNZWRpYSBkaXNrIGFuZCBhIFVTQiBsaW5rLgoKaSBoYXZlIHRyaWVkIGNo YW5naW5nICJPTFlNUFVTIiB0byAiT2x5bXB1cyIKaW4gdGhlIGtlcm5lbCBz b3VyY2UgYW5kIHZhcmlvdXMgb3RoZXIgdGhpbmdzLApidXQgaGF2ZSBoYWQg bm8gc3VjY2VzcyBtb3VudGluZyB0aGUgU21hcnRNZWRpYSBkaXNrCmluIGFu eSB3YXksIHNoYXBlIG9yIGZvcm0uCgpPdXRlciBDb25uZWN0b3JzOiBVU0Ig aW50ZXJmYWNlIChzdG9yYWdlIGNsYXNzKSAKQXV0by1jb25uZWN0IFVTQjog WWVzCgo+ID4gZnJvbSB0aGUgZm9sbG93aW5nLCBpIGFzc3VtZSBpIHRoZSBs aW5rL2NvbnRyb2xsZXIvY2FtZXJhCj4gPiBhcmUgb3BlcmF0aW9uYWwgdG8g c29tZSBleHRlbnQgLSBhcyB0aGUgY2FtZXJhIElEIGlzCj4gPiBkZXRlY3Rl ZCBqdXN0IGZpbmUgYnkgdGhlIGRyaXZlciBhcyB3ZWxsIGFzCj4gPiB1c2Vy bGFuZCBwcm9ncmFtcy4KPiA+Cj4gPiAkIGRtZXNnIChrZXJuZWwvZHJpdmVy IGRldGVjdGlvbiwKPiA+ICAgICAgICAgIFFVSVJLPWNvbW1hbmQgc3RhdHVz IHNpZ25hdHVyZSBmaXgsIDB4NTM0My0+MHg1NTQyKQo+ID4gICAgICAgICAg Zm9yIE9MWU1QVVMgQy0xJ3MpCj4gPgo+ID4gRnJlZUJTRCA0LjUtUkVMRUFT RSAjMzogU2F0IEFwciAgNiAyMjoxMjo0MCBBS1NUIDIwMDIKPiA+IC4uLgo+ ID4gb2hjaTA6IDxPUFRpIDgyQzg2MSAoRmlyZUxpbmspIFVTQiBjb250cm9s bGVyPiBtZW0gMHhlMTAwMDAwMC0weGUxMDAwZmZmIGlycSAxMCBhdCBkZXZp Y2UgMTkuMCBvbiBwY2kwCj4gPiB1c2IwOiBPSENJIHZlcnNpb24gMS4wLCBs ZWdhY3kgc3VwcG9ydAo+ID4gdXNiMDogPE9QVGkgODJDODYxIChGaXJlTGlu aykgVVNCIGNvbnRyb2xsZXI+IG9uIG9oY2kwCj4gPiB1c2IwOiBVU0IgcmV2 aXNpb24gMS4wCj4gPiB1aHViMDogT1BUaSBPSENJIHJvb3QgaHViLCBjbGFz cyA5LzAsIHJldiAxLjAwLzEuMDAsIGFkZHIgMQo+ID4gdWh1YjA6IDIgcG9y dHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkCj4gPiBPTFlNUFVT IC0gQVBQTFlJTkcgQ1NTIFFVSVJLIQo+ID4gT0xZTVBVUyAtIEFQUExZSU5H IENTUyBRVUlSSyEKPiA+IE9MWU1QVVMgLSBBUFBMWUlORyBDU1MgUVVJUksh Cj4gPiB1bWFzczA6IE9MWU1QVVMgQy0xWixELTE1MFosIHJldiAxLjEwLzEw LjE1LCBhZGRyIDIKPiA+IE9MWU1QVVMgLSBjYXNlIFRTVEFURV9CQkJfUkVT RVQxOgo+ID4gdW1hc3MwOiBCQkIgcmVzZXQgZmFpbGVkLCBUSU1FT1VUCj4g PiBPTFlNUFVTIC0gY2FzZSBUU1RBVEVfQkJCX1JFU0VUMjoKPiA+IHVtYXNz MDogQkJCIGJ1bGstaW4gY2xlYXIgc3RhbGwgZmFpbGVkLCBUSU1FT1VUCj4g PiBPTFlNUFVTIC0gY2FzZSBUU1RBVEVfQkJCX1JFU0VUMzoKPiA+IHVtYXNz MDogQkJCIGJ1bGstb3V0IGNsZWFyIHN0YWxsIGZhaWxlZCwgVElNRU9VVAo+ ID4KPiA+ICQgdXNiZGV2cyAodXNlcmxhbmQgcHJvZ3JhbSkKPiA+Cj4gPiBD b250cm9sbGVyIC9kZXYvdXNiMDoKPiA+IGFkZHIgMTogc2VsZiBwb3dlcmVk LCBjb25maWcgMSwgT0hDSSByb290IGh1YigweDAwMDApLAo+ID4gICAgICAg ICBPUFRpKDB4MDAwMCksIHJldiAweDAxMDAgcG9ydCAxCj4gPiBhZGRyIDI6 IHNlbGYgcG93ZXJlZCwgY29uZmlnIDEsIEMtMSBEaWdpdGFsIENhbWVyYSgw eDAxMDIpLAo+ID4gICAgICAgICBPbHltcHVzKDB4MDdiNCksIHJldiAweDEw MTUgcG9ydCAyIHBvd2VyZWQKPiA+Cj4gPiB3aXRob3V0IHVtYXNzMCAoVVNC IG1hc3Mgc3RvcmFnZSBkcml2ZXIpIGJlaW5nIGFibGUgdG8KPiA+IGNvbXBs ZXRlIGl0J3MgdGFzaywgaSBjYW5ub3QgbW91bnQgdGhlIGNhbWVyYSdzIHNt YXJ0bWVkaWEKPiA+IGRpc2suIHN1cHBvc2VkbHkgdGhpcyBjYW1lcmEgc3Vw cG9zZWRseSBoYXMgInRoZSBjb252ZW5pZW50Cj4gPiBBdXRvIENvbm5lY3Qg VVNCIGZlYXR1cmUgbGV0cyB5b3VyIGNvbXB1dGVyIGF1dG9tYXRpY2FsbHkg cmVjb2duaXplCj4gPiB5b3VyIEJyaW8gWm9vbSBELTE1MCBzbyB5b3UgZG9u J3QgaGF2ZSB0byBpbnN0YWxsIGFueSBhZGRpdGlvbmFsCj4gPiBzb2Z0d2Fy ZSIuICBzbyBpIHRoaW5rIGkgc2hvdWxkIGJlIGFibGUgdG8gbW91bnQgdGhp cyBjYW1lcmEuCgokIGRtZXNnICh1bWFzczAgZXJyb3JzIHVwb24gYm9vdCwg c2FtZSBtc2cncyBhcyAiY2FtY29udHJvbCByZXNjYW4gMCIpLgouLi4Kb2hj aTA6IDxPUFRpIDgyQzg2MSAoRmlyZUxpbmspIFVTQiBjb250cm9sbGVyPiBt ZW0gMHhlMTAwMDAwMC0weGUxMDAwZmZmIGlycSAxMCAKYXQgZGV2aWNlIDE5 LjAgb24gcGNpMAp1c2IwOiBPSENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3Vw cG9ydAp1c2IwOiA8T1BUaSA4MkM4NjEgKEZpcmVMaW5rKSBVU0IgY29udHJv bGxlcj4gb24gb2hjaTAKdXNiMDogVVNCIHJldmlzaW9uIDEuMAp1aHViMDog T1BUaSBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMQp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxm IHBvd2VyZWQKdW1hc3MwOiBPTFlNUFVTIEMtMVosRC0xNTBaLCByZXYgMS4x MC8xMC4xNSwgYWRkciAyLCBTQ1NJIG92ZXIgQnVsay1Pbmx5CnVtYXNzMDog TWF4IEx1biBpcyAwCnVtYXNzLXNpbTowOi0xOi0xOlhQVF9QQVRIX0lOUTou CnVtYXNzMDowOjA6LTE6IEF0dGFjaGVkIHRvIHNjYnVzMCBhcyBkZXZpY2Ug MAp1bWFzczA6IEF0dGFjaCBmaW5pc2hlZAouLi4KdW1hc3Mtc2ltOjA6LTE6 LTE6WFBUX1BBVEhfSU5ROi4KdW1hc3Mtc2ltOjA6LTE6LTE6WFBUX1BBVEhf SU5ROi4KdW1hc3Mtc2ltOjA6LTE6LTE6WFBUX1BBVEhfSU5ROi4KdW1hc3Mw OjA6MDowOlhQVF9QQVRIX0lOUTouCnVtYXNzMDowOjA6MDpYUFRfUEFUSF9J TlE6Lgp1bWFzczA6MDowOjA6WFBUX1NDU0lfSU86IGNtZDogMHgxMiwgZmxh Z3M6IDB4NDAsIDZiIGNtZC8zNmIgZGF0YS8xOGIgc2Vuc2UKdW1hc3MwOiBD QlcgMTogY21kID0gNmIgKDB4MTIwMDAwMDAyNDAwKSwgZGF0YSA9IDM2IGJ5 dGVzLCBkaXIgPSBpbgp1bWFzcy1zaW06MDoxOjA6ZnVuY19jb2RlIDB4MDAw NDogSW52YWxpZCB0YXJnZXQgKG5vIHdpbGRjYXJkKQp1bWFzcy1zaW06MDoy OjA6ZnVuY19jb2RlIDB4MDAwNDogSW52YWxpZCB0YXJnZXQgKG5vIHdpbGRj YXJkKQp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSAxIChCQkIgQ0JXKSwg eGZlcj0weGMwN2YxMzAwLCBUSU1FT1VUCnVtYXNzMDogZmFpbGVkIHRvIHNl bmQgQ0JXCnVtYXNzMDogQnVsayBSZXNldAp1bWFzczA6IEhhbmRsaW5nIEJC QiBzdGF0ZSA3IChCQkIgUmVzZXQpLCB4ZmVyPTB4YzA3ZjdkODAsIFRJTUVP VVQKdW1hc3MwOiBCQkIgcmVzZXQgZmFpbGVkLCBUSU1FT1VUCnVtYXNzMDog Q2xlYXIgZW5kcG9pbnQgMHg4MiBzdGFsbAp1bWFzczA6IEhhbmRsaW5nIEJC QiBzdGF0ZSA4IChCQkIgYnVsay1pbiBjbGVhciBzdGFsbCksIHhmZXI9MHhj MDdmN2QwMCwgVElNRU9VVAp1bWFzczA6IEJCQiBidWxrLWluIGNsZWFyIHN0 YWxsIGZhaWxlZCwgVElNRU9VVAotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpDT01QVVRFUi1C OgoKaW4gY29tcHV0ZXJCLCBjYW1lcmEgZnVuY3Rpb25zIHdoZW4gcGx1Z2dl ZCBpbiBhdCBib290IHRpbWUuCmJ1dCBpZiB1bnBsdWdnZWQvcmVwbHVnZ2Vk LCB0aGUgc2FtZSBwcm9ibGVtcyBvY2N1ciB1cG9uCiJjYW1jb250cm9sIHJl c2NhbiAwIi4gIChCQkIgZmFpbHVyZXMsIHRoZXJlZm9yZSwgbW91bnQgZXJy b3JzKS4Kc28gaSB0cmllZCBjb21tZW50aW5nIG91dCB0aGUgcmVzY2FuIGNh bGwgaW4gdW1hc3MuYwphZnRlciB0aGUgImlmICghY29sZCkiIHN0YXRlbWVu dCwgY3V6IG9mIGEgcG9zc2libGUKYnVnIHRoZXJlLCBidXQgdGhhdCBkaWRu J3QgY2hhbmdlIGFueXRoaW5nIGkgY291bGQgc2VlLgoKPkRvIHlvdSBzZWUg dGhlc2UgcHJvYmxlbXMgZHVyaW5nIGJvb3Qgb3IgZHVyaW5nIGF0dGFjaCBh ZnRlciBib290PwoKYW55dGltZSB0aGUgY2FtZXJhIGlzIHBsdWdnZWQgaW4g KmFmdGVyKiBib290LCB3aGV0aGVyIGZyb20KYSAxc3QgdGltZSBjb25uZWN0 aW9uLCBvciB1bnBsdWdnaW5nLXJlcGx1Z2dpbmcgYWZ0ZXIgYm9vdAood2hl cmUgaXQgaXMgaW5pdGlhbGx5IHBsdWdnZWQgaW4pLgoKPkkgcHJlc3VtZSB0 aGF0IHlvdSBhZGRlZCB0aG9zZSAnT0xZTVBVUyAtIC4uLicgbWVzc2FnZXM/ CgppIHRyaWVkIGFsbCBzdWdnZXN0aW9ucyBmcm9tIG1hbnkgcGVvcGxlIGlu IENPTVBVVEVSLUEgd2l0aG91dAphbnkgc3VjY2VzcywgYW5kIG9ubHkgdGhl ICIoIWNvbGQpIiBmaXggYWJvdmUgaW4gQ09NUFVURVItQi4KKHNpbmNlIGNv bXB1dGVyQiB3b3JrcyBmaW5lIGlmIGNhbWVyYSBpcyBwbHVnZ2VkIGluIGF0 CiBib290IHRpbWUgYW5kIG5ldmVyIGRpc2Nvbm5lY3RlZCkuCgojIGRtZXNn CgpGcmVlQlNEIDQuNS1SRUxFQVNFICMyOiBGcmkgQXByIDEyIDE2OjIxOjU3 IEFLRFQgMjAwMgouLi4Kb2hjaTA6IDxPUFRpIDgyQzg2MSAoRmlyZUxpbmsp IFVTQiBjb250cm9sbGVyPiBtZW0gMHhlNDAwMDAwMC0weGU0MDAwZmZmIGly cSAxMCBhdCBkZXZpY2UgMTguMCBvbiBwY2kwCnVzYjA6IE9IQ0kgdmVyc2lv biAxLjAsIGxlZ2FjeSBzdXBwb3J0CnVzYjA6IDxPUFRpIDgyQzg2MSAoRmly ZUxpbmspIFVTQiBjb250cm9sbGVyPiBvbiBvaGNpMAp1c2IwOiBVU0IgcmV2 aXNpb24gMS4wCnVodWIwOiBPUFRpIE9IQ0kgcm9vdCBodWIsIGNsYXNzIDkv MCwgcmV2IDEuMDAvMS4wMCwgYWRkciAxCnVodWIwOiAyIHBvcnRzIHdpdGgg MiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZAp1bWFzczA6IE9MWU1QVVMgQy0x WixELTE1MFosIHJldiAxLjEwLzEwLjE1LCBhZGRyIDIsIFNDU0kgb3ZlciBC dWxrLU9ubHkKdW1hc3MwOiBNYXggTHVuIGlzIDAKdW1hc3Mtc2ltOjA6LTE6 LTE6WFBUX1BBVEhfSU5ROi4KdW1hc3MwOjA6MDotMTogQXR0YWNoZWQgdG8g c2NidXMwIGFzIGRldmljZSAwCnVtYXNzMDogQXR0YWNoIGZpbmlzaGVkCi4u Lgp1bWFzcy1zaW06MDotMTotMTpYUFRfUEFUSF9JTlE6Lgp1bWFzcy1zaW06 MDotMTotMTpYUFRfUEFUSF9JTlE6Lgp1bWFzcy1zaW06MDotMTotMTpYUFRf UEFUSF9JTlE6Lgp1bWFzczA6MDowOjA6WFBUX1BBVEhfSU5ROi4KdW1hc3Mw OjA6MDowOlhQVF9QQVRIX0lOUTouCnVtYXNzLXNpbTowOjE6MDpmdW5jX2Nv ZGUgMHgwMDA0OiBJbnZhbGlkIHRhcmdldCAobm8gd2lsZGNhcmQpCnVtYXNz LXNpbTowOjI6MDpmdW5jX2NvZGUgMHgwMDA0OiBJbnZhbGlkIHRhcmdldCAo bm8gd2lsZGNhcmQpCnVtYXNzMDowOjA6MDpYUFRfU0NTSV9JTzogY21kOiAw eDEyLCBmbGFnczogMHg0MCwgNmIgY21kLzM2YiBkYXRhLzE4YiBzZW5zZQp1 bWFzczA6IENCVyAxOiBjbWQgPSA2YiAoMHgxMjAwMDAwMDI0MDApLCBkYXRh ID0gMzYgYnl0ZXMsIGRpciA9IGluCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0 YXRlIDEgKEJCQiBDQlcpLCB4ZmVyPTB4YzA2YzkxODAsIE5PUk1BTF9DT01Q TEVUSU9OCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDIgKEJCQiBEYXRh KSwgeGZlcj0weGMwNmNmZTgwLCBOT1JNQUxfQ09NUExFVElPTgp1bWFzczA6 IDB4IDAwODAwMjAyMWYwMDAwMDA0ZjRjNTk0ZDUwNTU1MzIwIGJ1ZmZlcj0w eGMwNmYxYTg0LCBidWZsZW49MzYKdW1hc3MwOiAweCA0MzJkMzE1YTJjNDQy ZDMxMzUzMDVhMjAyMDIwMjAyMAp1bWFzczA6IDB4IDMxMzAzMTM1CnVtYXNz MDogSGFuZGxpbmcgQkJCIHN0YXRlIDQgKEJCQiBDU1csIDFzdCBhdHRlbXB0 KSwgeGZlcj0weGMwNmNmZDgwLCBOT1JNQUxfQ09NUExFVElPTgp1bWFzczA6 IENTVyAxOiBzaWcgPSAweDU1NDI1MzU1IChpbnZhbGlkKSwgdGFnID0gMSwg cmVzID0gMCwgc3RhdHVzID0gMHgwMCAoZ29vZCkKdW1hc3MwOjA6MDowOlhQ VF9TQ1NJX0lPOiBjbWQ6IDB4MTIsIGZsYWdzOiAweDQwLCA2YiBjbWQvMjU1 YiBkYXRhLzE4YiBzZW5zZQp1bWFzczA6IENCVyAyOiBjbWQgPSA2YiAoMHgx MjAxODAwMGZmMDApLCBkYXRhID0gMjU1IGJ5dGVzLCBkaXIgPSBpbgp1bWFz czA6IEhhbmRsaW5nIEJCQiBzdGF0ZSAxIChCQkIgQ0JXKSwgeGZlcj0weGMw NmM5MTgwLCBOT1JNQUxfQ09NUExFVElPTgp1bWFzczA6IEhhbmRsaW5nIEJC QiBzdGF0ZSAyIChCQkIgRGF0YSksIHhmZXI9MHhjMDZjZmU4MCwgTk9STUFM X0NPTVBMRVRJT04KdW1hc3MwOiAweCAwMDgwMDIwMjFmMDAwMDAwNGY0YzU5 NGQ1MDU1NTMyMCBidWZmZXI9MHhjMDZkODcwMCwgYnVmbGVuPTI1NQp1bWFz czA6IDB4IDQzMmQzMTVhMmM0NDJkMzEzNTMwNWEyMDIwMjAyMDIwCnVtYXNz MDogMHggMzEzMDMxMzUwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAgLi4uCnVt YXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDQgKEJCQiBDU1csIDFzdCBhdHRl bXB0KSwgeGZlcj0weGMwNmNmZDgwLCBTVEFMTEVECnVtYXNzMDogRmFpbGVk IHRvIHJlYWQgQ1NXLCBTVEFMTEVELCByZXRyeWluZwp1bWFzczA6IENsZWFy IGVuZHBvaW50IDB4ODIgc3RhbGwKdW1hc3MwOiBIYW5kbGluZyBCQkIgc3Rh dGUgNSAoQkJCIENTVyBidWxrLWluIGNsZWFyIHN0YWxsKSwgeGZlcj0weGMw NmNmYzgwLCBOT1JNQUxfQ09NUExFVElPTgp1bWFzczA6IEhhbmRsaW5nIEJC QiBzdGF0ZSA2IChCQkIgQ1NXLCAybmQgYXR0ZW1wdCksIHhmZXI9MHhjMDZj ZmQwMCwgTk9STUFMX0NPTVBMRVRJT04KdW1hc3MwOiBDU1cgMjogc2lnID0g MHg1NTQyNTM1NSAoaW52YWxpZCksIHRhZyA9IDIsIHJlcyA9IDIxOSwgc3Rh dHVzID0gMHgwMCAoZ29vZCkKdW1hc3MwOjA6MDowOlhQVF9HRVRfVFJBTl9T RVRUSU5HUzouCnVtYXNzMDowOjA6MDpYUFRfUEFUSF9JTlE6Lgp1bWFzczA6 MDowOjA6WFBUX0dFVF9UUkFOX1NFVFRJTkdTOi4KdW1hc3MwOjA6MDowOlhQ VF9TRVRfVFJBTl9TRVRUSU5HUzouCnVtYXNzMDowOjA6MDpYUFRfU0NTSV9J TzogY21kOiAweDAwLCBmbGFnczogMHhjMCwgNmIgY21kLzBiIGRhdGEvMzJi IHNlbnNlCnVtYXNzMDogQ29udmVydGVkIFRFU1RfVU5JVF9SRUFEWSB0byBT VEFSVF9VTklUCnVtYXNzMDogQ0JXIDM6IGNtZCA9IDE2YiAoMHgxYjAwMDAw MDAxMDAuLi4pLCBkYXRhID0gMCBieXRlcywgZGlyID0gb3V0CnVtYXNzMDog SGFuZGxpbmcgQkJCIHN0YXRlIDEgKEJCQiBDQlcpLCB4ZmVyPTB4YzA2Yzkx ODAsIE5PUk1BTF9DT01QTEVUSU9OCnVtYXNzMDogbm8gZGF0YSBwaGFzZQp1 bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSA0IChCQkIgQ1NXLCAxc3QgYXR0 ZW1wdCksIHhmZXI9MHhjMDZjZmQ4MCwgTk9STUFMX0NPTVBMRVRJT04KdW1h c3MwOiBDU1cgMzogc2lnID0gMHg1NTQyNTM1NSAoaW52YWxpZCksIHRhZyA9 IDMsIHJlcyA9IDAsIHN0YXR1cyA9IDB4MDAgKGdvb2QpCnVtYXNzMDowOjA6 MDpYUFRfU0NTSV9JTzogY21kOiAweDI1LCBmbGFnczogMHg0MCwgMTBiIGNt ZC84YiBkYXRhLzMyYiBzZW5zZQp1bWFzczA6IENCVyA0OiBjbWQgPSAxMGIg KDB4MjUwMDAwMDAwMDAwLi4uKSwgZGF0YSA9IDggYnl0ZXMsIGRpciA9IGlu Ck1vdW50aW5nIHJvb3QgZnJvbSB1ZnM6L2Rldi9hZDBhCnVtYXNzMDogSGFu ZGxpbmcgQkJCIHN0YXRlIDEgKEJCQiBDQlcpLCB4ZmVyPTB4YzA2YzkxODAs IE5PUk1BTF9DT01QTEVUSU9OCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRl IDIgKEJCQiBEYXRhKSwgeGZlcj0weGMwNmNmZTgwLCBOT1JNQUxfQ09NUExF VElPTgp1bWFzczA6IDB4IDAwMDAzZTdmMDAwMDAyMDAgYnVmZmVyPTB4YzAz YmYxYTAsIGJ1Zmxlbj04CnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDQg KEJCQiBDU1csIDFzdCBhdHRlbXB0KSwgeGZlcj0weGMwNmNmZDgwLCBOT1JN QUxfQ09NUExFVElPTgp1bWFzczA6IENTVyA0OiBzaWcgPSAweDU1NDI1MzU1 IChpbnZhbGlkKSwgdGFnID0gNCwgcmVzID0gMCwgc3RhdHVzID0gMHgwMCAo Z29vZCkKdW1hc3MwOjA6MDowOlhQVF9DQUxDX0dFT01FVFJZOiBWb2x1bWUg c2l6ZSA9IDE2MDAwCmRhMCBhdCB1bWFzcy1zaW0wIGJ1cyAwIHRhcmdldCAw IGx1biAwCmRhMDogPE9MWU1QVVMgQy0xWixELTE1MFogMTAxNT4gUmVtb3Zh YmxlIERpcmVjdCBBY2Nlc3MgU0NTSS0yIGRldmljZQp1bWFzczA6MDowOjA6 WFBUX0dFVF9UUkFOX1NFVFRJTkdTOi4KdW1hc3MwOjA6MDowOlhQVF9QQVRI X0lOUTouCmRhMDogNjUwS0IvcyB0cmFuc2ZlcnMKZGEwOiA3TUIgKDE2MDAw IDUxMiBieXRlIHNlY3RvcnM6IDY0SCAzMlMvVCA3QykKCiMgY2F0IC9ldGMv ZnN0YWIKCiMgRGV2aWNlICAgICAgICBNb3VudCAgIEZTdHlwZSAgT3B0aW9u cyAgICAgRHVtcCAgICBQYXNzIwoKL2Rldi9hZDBhICAgICAgIC8gICAgICAg dWZzICAgICBydyAgICAgICAgICAxICAgICAgIDEKL2Rldi9hZDBiICAgICAg IG5vbmUgICAgc3dhcCAgICBzdyAgICAgICAgICAwICAgICAgIDAKIy9kZXYv YWQwZSAgICAgIC9ic2QgICAgdWZzICAgICBydyAgICAgICAgICAyICAgICAg IDIKL2Rldi9hZDBlICAgICAgIC92YXIgICAgdWZzICAgICBydyAgICAgICAg ICAyICAgICAgIDIKL2Rldi9hZDBmICAgICAgIC91c3IgICAgdWZzICAgICBy dyAgICAgICAgICAyICAgICAgIDIKcHJvYyAgICAgICAgICAgIC9wcm9jICAg cHJvY2ZzICBydyAgICAgICAgICAwICAgICAgIDAKCi9kZXYvZmQwLjE0NDAg ICAvZmxwICAgIHVmcyAgICAgcncsbm9hdXRvICAgMCAgICAgICAwCi9kZXYv ZmQwLjE3MjAgICAvZmxweCAgIHVmcyAgICAgcncsbm9hdXRvICAgMCAgICAg ICAwCi9kZXYvY2Ryb20gICAgICAvY2Ryb20gIGNkOTY2MCAgcncsbm9hdXRv ICAgMCAgICAgICAwCi9kZXYvZGEwczEgICAgICAvdW1hc3MgIG1zZG9zICAg cncsbm9hdXRvICAgMCAgICAgICAwCgojIGNkIC8KIyBsIHVtYXNzCgpGcmkg QXByIDEyIDE2OjI2OjUwIEFLRFQgMjAwMiBAIGVuMjcuZ3JvZ2d5LmFuYy5h Y3NhbGFza2EubmV0CnJvb3QgT04gL2Rldi90dHlwMSBJTiAvCnVtYXNzOgp0 b3RhbCA0CjggMiBkcnd4cnd4LS0tICAgMiByb290ICBvcGVyYXRvciAgLSA1 MTIgLi8KMiAyIGRyd3hyLXhyLXggIDIwIHJvb3QgIHdoZWVsICAgICAtIDUx MiAuLi8KCiMgbW91bnQgL3VtYXNzCiMgbCB1bWFzcwoKRnJpIEFwciAxMiAx NjoyNzoxMiBBS0RUIDIwMDIgQCBlbjI3Lmdyb2dneS5hbmMuYWNzYWxhc2th Lm5ldApyb290IE9OIC9kZXYvdHR5cDEgSU4gLwp1bWFzczoKdG90YWwgMjYK ICAxICA4IGRyd3hyd3gtLS0gICAxIHJvb3QgIG9wZXJhdG9yICBhcmNoIDgx OTIgLi8KICAyICAyIGRyd3hyLXhyLXggIDIwIHJvb3QgIHdoZWVsICAgICAt ICAgICA1MTIgLi4vCjYyNCAgOCBkcnd4cnd4LS0tICAgMSByb290ICBvcGVy YXRvciAgYXJjaCA4MTkyIGRjaW0vCjM2OCAgOCBkcnd4cnd4LS0tICAgMSBy b290ICBvcGVyYXRvciAgYXJjaCA4MTkyIGltb2x5bS8KCiMgdW1vdW50IHVt YXNzCiMgbCB1bWFzcwoKRnJpIEFwciAxMiAxNjoyNzoyOCBBS0RUIDIwMDIg QCBlbjI3Lmdyb2dneS5hbmMuYWNzYWxhc2thLm5ldApyb290IE9OIC9kZXYv dHR5cDEgSU4gLwp1bWFzczoKdG90YWwgNAo4IDIgZHJ3eHJ3eC0tLSAgIDIg cm9vdCAgb3BlcmF0b3IgIC0gNTEyIC4vCjIgMiBkcnd4ci14ci14ICAyMCBy b290ICB3aGVlbCAgICAgLSA1MTIgLi4vCgojIHVucGx1Z2dpbmcgY2FtZXJh OyB0aGVuIHJlcGx1Z2dpbmcKIyBtb3VudCAvdW1hc3MKbXNkb3M6IC9kZXYv ZGEwczE6IElucHV0L291dHB1dCBlcnJvcgoKIyBkbWVzZwoKRnJlZUJTRCA0 LjUtUkVMRUFTRSAjMjogRnJpIEFwciAxMiAxNjoyMTo1NyBBS0RUIDIwMDIK Li4uCm9oY2kwOiA8T1BUaSA4MkM4NjEgKEZpcmVMaW5rKSBVU0IgY29udHJv bGxlcj4gbWVtIDB4ZTQwMDAwMDAtMHhlNDAwMGZmZiBpcnEgMTAgYXQgZGV2 aWNlIDE4LjAgb24gcGNpMAp1c2IwOiBPSENJIHZlcnNpb24gMS4wLCBsZWdh Y3kgc3VwcG9ydAp1c2IwOiA8T1BUaSA4MkM4NjEgKEZpcmVMaW5rKSBVU0Ig Y29udHJvbGxlcj4gb24gb2hjaTAKdXNiMDogVVNCIHJldmlzaW9uIDEuMAp1 aHViMDogT1BUaSBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAw LzEuMDAsIGFkZHIgMQp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxl LCBzZWxmIHBvd2VyZWQKdW1hc3MwOiBPTFlNUFVTIEMtMVosRC0xNTBaLCBy ZXYgMS4xMC8xMC4xNSwgYWRkciAyLCBTQ1NJIG92ZXIgQnVsay1Pbmx5CnVt YXNzMDogTWF4IEx1biBpcyAwCnVtYXNzLXNpbTowOi0xOi0xOlhQVF9QQVRI X0lOUTouCnVtYXNzMDowOjA6LTE6IEF0dGFjaGVkIHRvIHNjYnVzMCBhcyBk ZXZpY2UgMAp1bWFzczA6IEF0dGFjaCBmaW5pc2hlZAouLi4KdW1hc3Mtc2lt OjA6LTE6LTE6WFBUX1BBVEhfSU5ROi4KdW1hc3Mtc2ltOjA6LTE6LTE6WFBU X1BBVEhfSU5ROi4KdW1hc3Mtc2ltOjA6LTE6LTE6WFBUX1BBVEhfSU5ROi4K dW1hc3MwOjA6MDowOlhQVF9QQVRIX0lOUTouCnVtYXNzMDowOjA6MDpYUFRf UEFUSF9JTlE6Lgp1bWFzcy1zaW06MDoxOjA6ZnVuY19jb2RlIDB4MDAwNDog SW52YWxpZCB0YXJnZXQgKG5vIHdpbGRjYXJkKQp1bWFzcy1zaW06MDoyOjA6 ZnVuY19jb2RlIDB4MDAwNDogSW52YWxpZCB0YXJnZXQgKG5vIHdpbGRjYXJk KQp1bWFzczA6MDowOjA6WFBUX1NDU0lfSU86IGNtZDogMHgxMiwgZmxhZ3M6 IDB4NDAsIDZiIGNtZC8zNmIgZGF0YS8xOGIgc2Vuc2UKdW1hc3MwOiBDQlcg MTogY21kID0gNmIgKDB4MTIwMDAwMDAyNDAwKSwgZGF0YSA9IDM2IGJ5dGVz LCBkaXIgPSBpbgp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSAxIChCQkIg Q0JXKSwgeGZlcj0weGMwNmM5MTgwLCBOT1JNQUxfQ09NUExFVElPTgp1bWFz czA6IEhhbmRsaW5nIEJCQiBzdGF0ZSAyIChCQkIgRGF0YSksIHhmZXI9MHhj MDZjZmU4MCwgTk9STUFMX0NPTVBMRVRJT04KdW1hc3MwOiAweCAwMDgwMDIw MjFmMDAwMDAwNGY0YzU5NGQ1MDU1NTMyMCBidWZmZXI9MHhjMDZmMWE4NCwg YnVmbGVuPTM2CnVtYXNzMDogMHggNDMyZDMxNWEyYzQ0MmQzMTM1MzA1YTIw MjAyMDIwMjAKdW1hc3MwOiAweCAzMTMwMzEzNQp1bWFzczA6IEhhbmRsaW5n IEJCQiBzdGF0ZSA0IChCQkIgQ1NXLCAxc3QgYXR0ZW1wdCksIHhmZXI9MHhj MDZjZmQ4MCwgTk9STUFMX0NPTVBMRVRJT04KdW1hc3MwOiBDU1cgMTogc2ln ID0gMHg1NTQyNTM1NSAoaW52YWxpZCksIHRhZyA9IDEsIHJlcyA9IDAsIHN0 YXR1cyA9IDB4MDAgKGdvb2QpCnVtYXNzMDowOjA6MDpYUFRfU0NTSV9JTzog Y21kOiAweDEyLCBmbGFnczogMHg0MCwgNmIgY21kLzI1NWIgZGF0YS8xOGIg c2Vuc2UKdW1hc3MwOiBDQlcgMjogY21kID0gNmIgKDB4MTIwMTgwMDBmZjAw KSwgZGF0YSA9IDI1NSBieXRlcywgZGlyID0gaW4KdW1hc3MwOiBIYW5kbGlu ZyBCQkIgc3RhdGUgMSAoQkJCIENCVyksIHhmZXI9MHhjMDZjOTE4MCwgTk9S TUFMX0NPTVBMRVRJT04KdW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgMiAo QkJCIERhdGEpLCB4ZmVyPTB4YzA2Y2ZlODAsIE5PUk1BTF9DT01QTEVUSU9O CnVtYXNzMDogMHggMDA4MDAyMDIxZjAwMDAwMDRmNGM1OTRkNTA1NTUzMjAg YnVmZmVyPTB4YzA2ZDg3MDAsIGJ1Zmxlbj0yNTUKdW1hc3MwOiAweCA0MzJk MzE1YTJjNDQyZDMxMzUzMDVhMjAyMDIwMjAyMAp1bWFzczA6IDB4IDMxMzAz MTM1MDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwIC4uLgp1bWFzczA6IEhhbmRs aW5nIEJCQiBzdGF0ZSA0IChCQkIgQ1NXLCAxc3QgYXR0ZW1wdCksIHhmZXI9 MHhjMDZjZmQ4MCwgU1RBTExFRAp1bWFzczA6IEZhaWxlZCB0byByZWFkIENT VywgU1RBTExFRCwgcmV0cnlpbmcKdW1hc3MwOiBDbGVhciBlbmRwb2ludCAw eDgyIHN0YWxsCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDUgKEJCQiBD U1cgYnVsay1pbiBjbGVhciBzdGFsbCksIHhmZXI9MHhjMDZjZmM4MCwgTk9S TUFMX0NPTVBMRVRJT04KdW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgNiAo QkJCIENTVywgMm5kIGF0dGVtcHQpLCB4ZmVyPTB4YzA2Y2ZkMDAsIE5PUk1B TF9DT01QTEVUSU9OCnVtYXNzMDogQ1NXIDI6IHNpZyA9IDB4NTU0MjUzNTUg KGludmFsaWQpLCB0YWcgPSAyLCByZXMgPSAyMTksIHN0YXR1cyA9IDB4MDAg KGdvb2QpCnVtYXNzMDowOjA6MDpYUFRfR0VUX1RSQU5fU0VUVElOR1M6Lgp1 bWFzczA6MDowOjA6WFBUX1BBVEhfSU5ROi4KdW1hc3MwOjA6MDowOlhQVF9H RVRfVFJBTl9TRVRUSU5HUzouCnVtYXNzMDowOjA6MDpYUFRfU0VUX1RSQU5f U0VUVElOR1M6Lgp1bWFzczA6MDowOjA6WFBUX1NDU0lfSU86IGNtZDogMHgw MCwgZmxhZ3M6IDB4YzAsIDZiIGNtZC8wYiBkYXRhLzMyYiBzZW5zZQp1bWFz czA6IENvbnZlcnRlZCBURVNUX1VOSVRfUkVBRFkgdG8gU1RBUlRfVU5JVAp1 bWFzczA6IENCVyAzOiBjbWQgPSAxNmIgKDB4MWIwMDAwMDAwMTAwLi4uKSwg ZGF0YSA9IDAgYnl0ZXMsIGRpciA9IG91dAp1bWFzczA6IEhhbmRsaW5nIEJC QiBzdGF0ZSAxIChCQkIgQ0JXKSwgeGZlcj0weGMwNmM5MTgwLCBOT1JNQUxf Q09NUExFVElPTgp1bWFzczA6IG5vIGRhdGEgcGhhc2UKdW1hc3MwOiBIYW5k bGluZyBCQkIgc3RhdGUgNCAoQkJCIENTVywgMXN0IGF0dGVtcHQpLCB4ZmVy PTB4YzA2Y2ZkODAsIE5PUk1BTF9DT01QTEVUSU9OCnVtYXNzMDogQ1NXIDM6 IHNpZyA9IDB4NTU0MjUzNTUgKGludmFsaWQpLCB0YWcgPSAzLCByZXMgPSAw LCBzdGF0dXMgPSAweDAwIChnb29kKQp1bWFzczA6MDowOjA6WFBUX1NDU0lf SU86IGNtZDogMHgyNSwgZmxhZ3M6IDB4NDAsIDEwYiBjbWQvOGIgZGF0YS8z MmIgc2Vuc2UKdW1hc3MwOiBDQlcgNDogY21kID0gMTBiICgweDI1MDAwMDAw MDAwMC4uLiksIGRhdGEgPSA4IGJ5dGVzLCBkaXIgPSBpbgpNb3VudGluZyBy b290IGZyb20gdWZzOi9kZXYvYWQwYQp1bWFzczA6IEhhbmRsaW5nIEJCQiBz dGF0ZSAxIChCQkIgQ0JXKSwgeGZlcj0weGMwNmM5MTgwLCBOT1JNQUxfQ09N UExFVElPTgp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSAyIChCQkIgRGF0 YSksIHhmZXI9MHhjMDZjZmU4MCwgTk9STUFMX0NPTVBMRVRJT04KdW1hc3Mw OiAweCAwMDAwM2U3ZjAwMDAwMjAwIGJ1ZmZlcj0weGMwM2JmMWEwLCBidWZs ZW49OAp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSA0IChCQkIgQ1NXLCAx c3QgYXR0ZW1wdCksIHhmZXI9MHhjMDZjZmQ4MCwgTk9STUFMX0NPTVBMRVRJ T04KdW1hc3MwOiBDU1cgNDogc2lnID0gMHg1NTQyNTM1NSAoaW52YWxpZCks IHRhZyA9IDQsIHJlcyA9IDAsIHN0YXR1cyA9IDB4MDAgKGdvb2QpCnVtYXNz MDowOjA6MDpYUFRfQ0FMQ19HRU9NRVRSWTogVm9sdW1lIHNpemUgPSAxNjAw MApkYTAgYXQgdW1hc3Mtc2ltMCBidXMgMCB0YXJnZXQgMCBsdW4gMApkYTA6 IDxPTFlNUFVTIEMtMVosRC0xNTBaIDEwMTU+IFJlbW92YWJsZSBEaXJlY3Qg QWNjZXNzIFNDU0ktMiBkZXZpY2UKdW1hc3MwOjA6MDowOlhQVF9HRVRfVFJB Tl9TRVRUSU5HUzouCnVtYXNzMDowOjA6MDpYUFRfUEFUSF9JTlE6LgpkYTA6 IDY1MEtCL3MgdHJhbnNmZXJzCmRhMDogN01CICgxNjAwMCA1MTIgYnl0ZSBz ZWN0b3JzOiA2NEggMzJTL1QgN0MpCnVtYXNzMDowOjA6MDpYUFRfU0NTSV9J TzogY21kOiAweDI1LCBmbGFnczogMHg0MCwgMTBiIGNtZC84YiBkYXRhLzMy YiBzZW5zZQp1bWFzczA6IENCVyA1OiBjbWQgPSAxMGIgKDB4MjUwMDAwMDAw MDAwLi4uKSwgZGF0YSA9IDggYnl0ZXMsIGRpciA9IGluCnVtYXNzMDogSGFu ZGxpbmcgQkJCIHN0YXRlIDEgKEJCQiBDQlcpLCB4ZmVyPTB4YzA2YzkxODAs IE5PUk1BTF9DT01QTEVUSU9OCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRl IDIgKEJCQiBEYXRhKSwgeGZlcj0weGMwNmNmZTgwLCBOT1JNQUxfQ09NUExF VElPTgp1bWFzczA6IDB4IDAwMDAzZTdmMDAwMDAyMDAgYnVmZmVyPTB4YzA3 OGFmNzAsIGJ1Zmxlbj04CnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDQg KEJCQiBDU1csIDFzdCBhdHRlbXB0KSwgeGZlcj0weGMwNmNmZDgwLCBOT1JN QUxfQ09NUExFVElPTgp1bWFzczA6IENTVyA1OiBzaWcgPSAweDU1NDI1MzU1 IChpbnZhbGlkKSwgdGFnID0gNSwgcmVzID0gMCwgc3RhdHVzID0gMHgwMCAo Z29vZCkKdW1hc3MwOjA6MDowOlhQVF9DQUxDX0dFT01FVFJZOiBWb2x1bWUg c2l6ZSA9IDE2MDAwCnVtYXNzMDowOjA6MDpYUFRfU0NTSV9JTzogY21kOiAw eDFlLCBmbGFnczogMHhjMCwgNmIgY21kLzBiIGRhdGEvMzJiIHNlbnNlCnVt YXNzMDogQ0JXIDY6IGNtZCA9IDZiICgweDFlMDAwMDAwMDEwMCksIGRhdGEg PSAwIGJ5dGVzLCBkaXIgPSBvdXQKdW1hc3MwOiBIYW5kbGluZyBCQkIgc3Rh dGUgMSAoQkJCIENCVyksIHhmZXI9MHhjMDZjOTE4MCwgTk9STUFMX0NPTVBM RVRJT04KdW1hc3MwOiBubyBkYXRhIHBoYXNlCnVtYXNzMDogSGFuZGxpbmcg QkJCIHN0YXRlIDQgKEJCQiBDU1csIDFzdCBhdHRlbXB0KSwgeGZlcj0weGMw NmNmZDgwLCBOT1JNQUxfQ09NUExFVElPTgp1bWFzczA6IENTVyA2OiBzaWcg PSAweDU1NDI1MzU1IChpbnZhbGlkKSwgdGFnID0gNiwgcmVzID0gMCwgc3Rh dHVzID0gMHgwMSAoZmFpbGVkKQp1bWFzczA6IENvbW1hbmQgRmFpbGVkLCBy ZXMgPSAwCnVtYXNzMDogRmV0Y2hpbmcgMGIgc2Vuc2UgZGF0YQp1bWFzczA6 IENCVyA3OiBjbWQgPSA2YiAoMHgwMzAwMDAwMDIwMDApLCBkYXRhID0gMzIg Ynl0ZXMsIGRpciA9IGluCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDEg KEJCQiBDQlcpLCB4ZmVyPTB4YzA2YzkxODAsIE5PUk1BTF9DT01QTEVUSU9O CnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDIgKEJCQiBEYXRhKSwgeGZl cj0weGMwNmNmZTgwLCBOT1JNQUxfQ09NUExFVElPTgp1bWFzczA6IDB4IDcw MDAwNTAwMDAwMDAwMGEwMDAwMDAwMDI0MDAwMDAwIGJ1ZmZlcj0weGMwNmYy MDcwLCBidWZsZW49MzIKdW1hc3MwOiAweCAwMDAwMDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMAp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSA0IChC QkIgQ1NXLCAxc3QgYXR0ZW1wdCksIHhmZXI9MHhjMDZjZmQ4MCwgU1RBTExF RAp1bWFzczA6IEZhaWxlZCB0byByZWFkIENTVywgU1RBTExFRCwgcmV0cnlp bmcKdW1hc3MwOiBDbGVhciBlbmRwb2ludCAweDgyIHN0YWxsCnVtYXNzMDog SGFuZGxpbmcgQkJCIHN0YXRlIDUgKEJCQiBDU1cgYnVsay1pbiBjbGVhciBz dGFsbCksIHhmZXI9MHhjMDZjZmM4MCwgTk9STUFMX0NPTVBMRVRJT04KdW1h c3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgNiAoQkJCIENTVywgMm5kIGF0dGVt cHQpLCB4ZmVyPTB4YzA2Y2ZkMDAsIE5PUk1BTF9DT01QTEVUSU9OCnVtYXNz MDogQ1NXIDc6IHNpZyA9IDB4NTU0MjUzNTUgKGludmFsaWQpLCB0YWcgPSA3 LCByZXMgPSAxNCwgc3RhdHVzID0gMHgwMCAoZ29vZCkKdW1hc3MwOjA6MDow OlhQVF9TQ1NJX0lPOiBjbWQ6IDB4MjgsIGZsYWdzOiAweDQwLCAxMGIgY21k LzUxMmIgZGF0YS8zMmIgc2Vuc2UKdW1hc3MwOiBDQlcgODogY21kID0gMTBi ICgweDI4MDAwMDAwMDAwMC4uLiksIGRhdGEgPSA1MTIgYnl0ZXMsIGRpciA9 IGluCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDEgKEJCQiBDQlcpLCB4 ZmVyPTB4YzA2YzkxODAsIE5PUk1BTF9DT01QTEVUSU9OCnVtYXNzMDogSGFu ZGxpbmcgQkJCIHN0YXRlIDIgKEJCQiBEYXRhKSwgeGZlcj0weGMwNmNmZTgw LCBOT1JNQUxfQ09NUExFVElPTgp1bWFzczA6IDB4IDAwMDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwIGJ1ZmZlcj0weGMwNzBjNDAwLCBidWZsZW49 NTEyCnVtYXNzMDogMHggMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MDAKdW1hc3MwOiAweCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MCAuLi4KdW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgNCAoQkJCIENTVywg MXN0IGF0dGVtcHQpLCB4ZmVyPTB4YzA2Y2ZkODAsIE5PUk1BTF9DT01QTEVU SU9OCnVtYXNzMDogQ1NXIDg6IHNpZyA9IDB4NTU0MjUzNTUgKGludmFsaWQp LCB0YWcgPSA4LCByZXMgPSAwLCBzdGF0dXMgPSAweDAwIChnb29kKQp1bWFz czA6MDowOjA6WFBUX1NDU0lfSU86IGNtZDogMHgyOCwgZmxhZ3M6IDB4NDAs IDEwYiBjbWQvNTEyYiBkYXRhLzMyYiBzZW5zZQp1bWFzczA6IENCVyA5OiBj bWQgPSAxMGIgKDB4MjgwMDAwMDAwMDFhLi4uKSwgZGF0YSA9IDUxMiBieXRl cywgZGlyID0gaW4KdW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgMSAoQkJC IENCVyksIHhmZXI9MHhjMDZjOTE4MCwgTk9STUFMX0NPTVBMRVRJT04KdW1h c3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgMiAoQkJCIERhdGEpLCB4ZmVyPTB4 YzA2Y2ZlODAsIE5PUk1BTF9DT01QTEVUSU9OCnVtYXNzMDogMHggZjhmZmZm ZmZmZmZmZmY2ZjAwMDc4MDAwMDlhMDAwMGIgYnVmZmVyPTB4YzA3YjNjMDAs IGJ1Zmxlbj01MTIKdW1hc3MwOiAweCBjMDAwMGRlMDAwMGYwMDAxMTEyMDAx MTM0MDAxMTU2MAp1bWFzczA6IDB4IDAxMTc4MDAxMTlhMDAxMWJjMDAxMWRl MDAxMWYwMDAyIC4uLgp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSA0IChC QkIgQ1NXLCAxc3QgYXR0ZW1wdCksIHhmZXI9MHhjMDZjZmQ4MCwgTk9STUFM X0NPTVBMRVRJT04KdW1hc3MwOiBDU1cgOTogc2lnID0gMHg1NTQyNTM1NSAo aW52YWxpZCksIHRhZyA9IDksIHJlcyA9IDAsIHN0YXR1cyA9IDB4MDAgKGdv b2QpCnVtYXNzMDowOjA6MDpYUFRfU0NTSV9JTzogY21kOiAweDI4LCBmbGFn czogMHg0MCwgMTBiIGNtZC8yMDQ4YiBkYXRhLzMyYiBzZW5zZQp1bWFzczA6 IENCVyAxMDogY21kID0gMTBiICgweDI4MDAwMDAwMDAxOS4uLiksIGRhdGEg PSAyMDQ4IGJ5dGVzLCBkaXIgPSBpbgp1bWFzczA6IEhhbmRsaW5nIEJCQiBz dGF0ZSAxIChCQkIgQ0JXKSwgeGZlcj0weGMwNmM5MTgwLCBOT1JNQUxfQ09N UExFVElPTgp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSAyIChCQkIgRGF0 YSksIHhmZXI9MHhjMDZjZmU4MCwgTk9STUFMX0NPTVBMRVRJT04KdW1hc3Mw OiAweCBlOTAwMDAyYTU2NTE0YjQ4NDk0ODQzMDAwMjEwMDEwMCBidWZmZXI9 MHhjMDdkODAwMCwgYnVmbGVuPTIwNDgKdW1hc3MwOiAweCAwMjAwMDE2NzNl ZjgwMzAwMTAwMDA0MDAxOTAwMDAwMAp1bWFzczA6IDB4IDAwMDAwMDAwMDAw MDAwMDAwMDAwMDAwMDAwMDAwMDAwIC4uLgp1bWFzczA6IEhhbmRsaW5nIEJC QiBzdGF0ZSA0IChCQkIgQ1NXLCAxc3QgYXR0ZW1wdCksIHhmZXI9MHhjMDZj ZmQ4MCwgTk9STUFMX0NPTVBMRVRJT04KdW1hc3MwOiBDU1cgMTA6IHNpZyA9 IDB4NTU0MjUzNTUgKGludmFsaWQpLCB0YWcgPSAxMCwgcmVzID0gMCwgc3Rh dHVzID0gMHgwMCAoZ29vZCkKdW1hc3MwOjA6MDowOlhQVF9TQ1NJX0lPOiBj bWQ6IDB4MjgsIGZsYWdzOiAweDQwLCAxMGIgY21kLzE1MzZiIGRhdGEvMzJi IHNlbnNlCnVtYXNzMDogQ0JXIDExOiBjbWQgPSAxMGIgKDB4MjgwMDAwMDAw MDFhLi4uKSwgZGF0YSA9IDE1MzYgYnl0ZXMsIGRpciA9IGluCnVtYXNzMDog SGFuZGxpbmcgQkJCIHN0YXRlIDEgKEJCQiBDQlcpLCB4ZmVyPTB4YzA2Yzkx ODAsIE5PUk1BTF9DT01QTEVUSU9OCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0 YXRlIDIgKEJCQiBEYXRhKSwgeGZlcj0weGMwNmNmZTgwLCBOT1JNQUxfQ09N UExFVElPTgp1bWFzczA6IDB4IGY4ZmZmZmZmZmZmZmZmNmYwMDA3ODAwMDA5 YTAwMDBiIGJ1ZmZlcj0weGMwN2Q5MDAwLCBidWZsZW49MTUzNgp1bWFzczA6 IDB4IGMwMDAwZGUwMDAwZjAwMDExMTIwMDExMzQwMDExNTYwCnVtYXNzMDog MHggMDExNzgwMDExOWEwMDExYmMwMDExZGUwMDExZjAwMDIgLi4uCnVtYXNz MDogSGFuZGxpbmcgQkJCIHN0YXRlIDQgKEJCQiBDU1csIDFzdCBhdHRlbXB0 KSwgeGZlcj0weGMwNmNmZDgwLCBOT1JNQUxfQ09NUExFVElPTgp1bWFzczA6 IENTVyAxMTogc2lnID0gMHg1NTQyNTM1NSAoaW52YWxpZCksIHRhZyA9IDEx LCByZXMgPSAwLCBzdGF0dXMgPSAweDAwIChnb29kKQp1bWFzczA6MDowOjA6 WFBUX1NDU0lfSU86IGNtZDogMHgyOCwgZmxhZ3M6IDB4NDAsIDEwYiBjbWQv ODE5MmIgZGF0YS8zMmIgc2Vuc2UKdW1hc3MwOiBDQlcgMTI6IGNtZCA9IDEw YiAoMHgyODAwMDAwMDAwMjAuLi4pLCBkYXRhID0gODE5MiBieXRlcywgZGly ID0gaW4KdW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgMSAoQkJCIENCVyks IHhmZXI9MHhjMDZjOTE4MCwgTk9STUFMX0NPTVBMRVRJT04KdW1hc3MwOiBI YW5kbGluZyBCQkIgc3RhdGUgMiAoQkJCIERhdGEpLCB4ZmVyPTB4YzA2Y2Zl ODAsIE5PUk1BTF9DT01QTEVUSU9OCnVtYXNzMDogMHggNDk0ZDRmNGM1OTRk MjAyMDIwMjAyMDEwMDAwMDAwMDAgYnVmZmVyPTB4YzE3N2QwMDAsIGJ1Zmxl bj04MTkyCnVtYXNzMDogMHggMDAwMDAwMDAwMDAwMDAwMDIxMDAwMjAwMDAw MDAwMDAKdW1hc3MwOiAweCA0NDQzNDk0ZDIwMjAyMDIwMjAyMDIwMTAwMDAw MDAwMCAuLi4KdW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgNCAoQkJCIENT VywgMXN0IGF0dGVtcHQpLCB4ZmVyPTB4YzA2Y2ZkODAsIE5PUk1BTF9DT01Q TEVUSU9OCnVtYXNzMDogQ1NXIDEyOiBzaWcgPSAweDU1NDI1MzU1IChpbnZh bGlkKSwgdGFnID0gMTIsIHJlcyA9IDAsIHN0YXR1cyA9IDB4MDAgKGdvb2Qp CnVtYXNzMDowOjA6MDpYUFRfU0NTSV9JTzogY21kOiAweDI4LCBmbGFnczog MHg0MCwgMTBiIGNtZC84MTkyYiBkYXRhLzMyYiBzZW5zZQp1bWFzczA6IENC VyAxMzogY21kID0gMTBiICgweDI4MDAwMDAwMDAzMC4uLiksIGRhdGEgPSA4 MTkyIGJ5dGVzLCBkaXIgPSBpbgp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0 ZSAxIChCQkIgQ0JXKSwgeGZlcj0weGMwNmM5MTgwLCBOT1JNQUxfQ09NUExF VElPTgp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSAyIChCQkIgRGF0YSks IHhmZXI9MHhjMDZjZmU4MCwgTk9STUFMX0NPTVBMRVRJT04KdW1hc3MwOiAw eCAyZTIwMjAyMDIwMjAyMDIwMjAyMDIwMTAwMDAwMDAwMCBidWZmZXI9MHhj MTc4NTAwMCwgYnVmbGVuPTgxOTIKdW1hc3MwOiAweCAwMDAwMDAwMDAwMDAw MDAwMjEwMDAyMDAwMDAwMDAwMAp1bWFzczA6IDB4IDJlMmUyMDIwMjAyMDIw MjAyMDIwMjAxMDAwMDAwMDAwIC4uLgp1bWFzczA6IEhhbmRsaW5nIEJCQiBz dGF0ZSA0IChCQkIgQ1NXLCAxc3QgYXR0ZW1wdCksIHhmZXI9MHhjMDZjZmQ4 MCwgTk9STUFMX0NPTVBMRVRJT04KdW1hc3MwOiBDU1cgMTM6IHNpZyA9IDB4 NTU0MjUzNTUgKGludmFsaWQpLCB0YWcgPSAxMywgcmVzID0gMCwgc3RhdHVz ID0gMHgwMCAoZ29vZCkKdW1hc3MwOjA6MDowOlhQVF9TQ1NJX0lPOiBjbWQ6 IDB4MjgsIGZsYWdzOiAweDQwLCAxMGIgY21kLzgxOTJiIGRhdGEvMzJiIHNl bnNlCnVtYXNzMDogQ0JXIDE0OiBjbWQgPSAxMGIgKDB4MjgwMDAwMDAwMDQw Li4uKSwgZGF0YSA9IDgxOTIgYnl0ZXMsIGRpciA9IGluCnVtYXNzMDogSGFu ZGxpbmcgQkJCIHN0YXRlIDEgKEJCQiBDQlcpLCB4ZmVyPTB4YzA2YzkxODAs IE5PUk1BTF9DT01QTEVUSU9OCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRl IDIgKEJCQiBEYXRhKSwgeGZlcj0weGMwNmNmZTgwLCBOT1JNQUxfQ09NUExF VElPTgp1bWFzczA6IDB4IDJlMjAyMDIwMjAyMDIwMjAyMDIwMjAxMDAwMDAw MDAwIGJ1ZmZlcj0weGMxNzg5MDAwLCBidWZsZW49ODE5Mgp1bWFzczA6IDB4 IDAwMDAwMDAwMDAwMGM0MjY0OTJjMDMwMDAwMDAwMDAwCnVtYXNzMDogMHgg MmUyZTIwMjAyMDIwMjAyMDIwMjAyMDEwMDAwMDAwMDAgLi4uCnVtYXNzMDog SGFuZGxpbmcgQkJCIHN0YXRlIDQgKEJCQiBDU1csIDFzdCBhdHRlbXB0KSwg eGZlcj0weGMwNmNmZDgwLCBOT1JNQUxfQ09NUExFVElPTgp1bWFzczA6IENT VyAxNDogc2lnID0gMHg1NTQyNTM1NSAoaW52YWxpZCksIHRhZyA9IDE0LCBy ZXMgPSAwLCBzdGF0dXMgPSAweDAwIChnb29kKQp1bWFzczA6MDowOjA6WFBU X1NDU0lfSU86IGNtZDogMHgxZSwgZmxhZ3M6IDB4YzAsIDZiIGNtZC8wYiBk YXRhLzMyYiBzZW5zZQp1bWFzczA6IENCVyAxNTogY21kID0gNmIgKDB4MWUw MDAwMDAwMDAwKSwgZGF0YSA9IDAgYnl0ZXMsIGRpciA9IG91dAp1bWFzczA6 IEhhbmRsaW5nIEJCQiBzdGF0ZSAxIChCQkIgQ0JXKSwgeGZlcj0weGMwNmM5 MTgwLCBOT1JNQUxfQ09NUExFVElPTgp1bWFzczA6IG5vIGRhdGEgcGhhc2UK dW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgNCAoQkJCIENTVywgMXN0IGF0 dGVtcHQpLCB4ZmVyPTB4YzA2Y2ZkODAsIE5PUk1BTF9DT01QTEVUSU9OCnVt YXNzMDogQ1NXIDE1OiBzaWcgPSAweDU1NDI1MzU1IChpbnZhbGlkKSwgdGFn ID0gMTUsIHJlcyA9IDAsIHN0YXR1cyA9IDB4MDAgKGdvb2QpCnVtYXNzMDow OjA6MDpYUFRfU0NTSV9JTzogY21kOiAweDI1LCBmbGFnczogMHg0MCwgMTBi IGNtZC84YiBkYXRhLzMyYiBzZW5zZQp1bWFzczA6IENCVyAxNjogY21kID0g MTBiICgweDI1MDAwMDAwMDAwMC4uLiksIGRhdGEgPSA4IGJ5dGVzLCBkaXIg PSBpbgoKIyAjIHVucGx1Z2dpbmcsIGFuZCByZS1wbHVnZ2luZy4KIyBjYW1j b250cm9sIHJlc2NhbiAwCgp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSAx IChCQkIgQ0JXKSwgeGZlcj0weGMwNmM5MTgwLCBJT0VSUk9SCnVtYXNzMDog ZmFpbGVkIHRvIHNlbmQgQ0JXCnVtYXNzMDogQnVsayBSZXNldAp1bWFzczA6 IEhhbmRsaW5nIEJCQiBzdGF0ZSA3IChCQkIgUmVzZXQpLCB4ZmVyPTB4YzA2 Y2ZjMDAsIElPRVJST1IKdW1hc3MwOiBCQkIgcmVzZXQgZmFpbGVkLCBJT0VS Uk9SCnVtYXNzMDogQ2xlYXIgZW5kcG9pbnQgMHg4MiBzdGFsbAp1bWFzczA6 IEhhbmRsaW5nIEJCQiBzdGF0ZSA4IChCQkIgYnVsay1pbiBjbGVhciBzdGFs bCksIHhmZXI9MHhjMDZjZmI4MCwgSU9FUlJPUgp1bWFzczA6IEJCQiBidWxr LWluIGNsZWFyIHN0YWxsIGZhaWxlZCwgSU9FUlJPUgp1bWFzczA6IENsZWFy IGVuZHBvaW50IDB4MDEgc3RhbGwKdW1hc3MwOiBIYW5kbGluZyBCQkIgc3Rh dGUgOSAoQkJCIGJ1bGstb3V0IGNsZWFyIHN0YWxsKSwgeGZlcj0weGMwNmNm YjAwLCBJT0VSUk9SCnVtYXNzMDogQkJCIGJ1bGstb3V0IGNsZWFyIHN0YWxs IGZhaWxlZCwgSU9FUlJPUgp1bWFzczA6MDowOjA6WFBUX1NDU0lfSU86IGNt ZDogMHgyNSwgZmxhZ3M6IDB4NDAsIDEwYiBjbWQvOGIgZGF0YS8zMmIgc2Vu c2UKdW1hc3MwOiBDQlcgMTc6IGNtZCA9IDEwYiAoMHgyNTAwMDAwMDAwMDAu Li4pLCBkYXRhID0gOCBieXRlcywgZGlyID0gaW4KdW1hc3MwOiBIYW5kbGlu ZyBCQkIgc3RhdGUgMSAoQkJCIENCVyksIHhmZXI9MHhjMDZjOTE4MCwgSU9F UlJPUgp1bWFzczA6IGZhaWxlZCB0byBzZW5kIENCVwp1bWFzczA6IEJ1bGsg UmVzZXQKdW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgNyAoQkJCIFJlc2V0 KSwgeGZlcj0weGMwNmNmYzAwLCBJT0VSUk9SCnh1bWFzczA6IEJCQiByZXNl dCBmYWlsZWQsIElPRVJST1IKdW1hc3MwOiBDbGVhciBlbmRwb2ludCAweDgy IHN0YWxsCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDggKEJCQiBidWxr LWluIGNsZWFyIHN0YWxsKSwgeGZlcj0weGMwNmNmYjgwLCBJT0VSUk9SCnVt YXNzMDogQkJCIGJ1bGstaW4gY2xlYXIgc3RhbGwgZmFpbGVkLCBJT0VSUk9S CnVtYXNzMDogQ2xlYXIgZW5kcG9pbnQgMHgwMSBzdGFsbAp1bWFzczA6IEhh bmRsaW5nIEJCQiBzdGF0ZSA5IChCQkIgYnVsay1vdXQgY2xlYXIgc3RhbGwp LCB4ZmVyPTB4YzA2Y2ZiMDAsIElPRVJST1IKdW1hc3MwOiBCQkIgYnVsay1v dXQgY2xlYXIgc3RhbGwgZmFpbGVkLCBJT0VSUk9SCnVtYXNzLXNpbTowOi0x Oi0xOlhQVF9QQVRIX0lOUTouCnVtYXNzMDowOjA6MDpYUFRfUEFUSF9JTlE6 Lgp1bWFzczA6MDowOjA6WFBUX1BBVEhfSU5ROi4KdW1hc3MwOjA6MDowOlhQ VF9TQ1NJX0lPOiBjbWQ6IDB4MDAsIGZsYWdzOiAweGMwLCA2YiBjbWQvMGIg ZGF0YS8zMmIgc2Vuc2UKdW1hc3MwOiBDb252ZXJ0ZWQgVEVTVF9VTklUX1JF QURZIHRvIFNUQVJUX1VOSVQKdW1hc3MwOiBDQlcgMTg6IGNtZCA9IDE2YiAo MHgxYjAwMDAwMDAxMDAuLi4pLCBkYXRhID0gMCBieXRlcywgZGlyID0gb3V0 CnVtYXNzLXNpbTowOjE6MDpmdW5jX2NvZHVtYXNzMDogSGFuZGxpbmcgQkJC IHN0YXRlIDEgKEJCQiBDQlcpLCB4ZmVyPTB4YzA2YzkxODAsIElPRVJST1IK dW1hc3MwOiBmYWlsZWQgdG8gc2VuZCBDQlcKdW1hc3MwOiBCdWxrIFJlc2V0 CmUgMHgwMDA0OiBJbnZhbGlkIHRhcmdldCAobm8gd2lsZGNhcmQpCnVtYXNz MDogSGFuZGxpbmcgQkJCIHN0YXRlIDcgKEJCQiBSZXNldCksIHhmZXI9MHhj MDZjZmMwMCwgSU9FUlJPUgp1bWFzczA6IEJCQiByZXNldCBmYWlsZWQsIElP RVJST1IKdW1hc3MwOiBDbGVhciBlbmRwb2ludCAweDgyIHN0YWxsCnVtYXNz LXNpbTowOjI6MDpmdW5jX2NvZGUgMHgwMDA0OiBJbnZhdW1hc3MwOiBIYW5k bGluZyBCQkIgc3RhdGUgOCAoQkJCIGJ1bGstaW4gY2xlYXIgc3RhbGwpLCB4 ZmVyPTB4YzA2Y2ZiODAsIElPRVJST1IKdW1hc3MwOiBCQkIgYnVsay1pbiBj bGVhciBzdGFsbCBmYWlsZWQsIElPRVJST1IKdW1hc3MwOiBDbGVhciBlbmRw b2ludCAweDAxIHN0YWxsCmxpZCB0YXJnZXQgKG5vIHdpbGRjYXJkKQp1bWFz czA6IEhhbmRsaW5nIEJCQiBzdGF0ZSA5IChCQkIgYnVsay1vdXQgY2xlYXIg c3RhbGwpLCB4ZmVyPTB4YzA2Y2ZiMDAsIElPRVJST1IKdW1hc3MwOiBCQkIg YnVsay1vdXQgY2xlYXIgc3RhbGwgZmFpbGVkLCBJT0VSUk9SCnVtYXNzMDow OjA6MDpYUFRfU0NTSV9JTzogY21kOiAweDAwLCBmbGFnczogMHhjMCwgNmIg Y21kLzBiIGRhdGEvMzJiIHNlbnNlCnVtYXNzMDogQ29udmVydGVkIFRFU1Rf VU5JVF9SRUFEWSB0byBTVEFSVF9VTklUCnVtYXNzMDogQ0JXIDE5OiBjbWQg PSAxNmIgKDB4MWIwMDAwMDAwMTAwLi4uKSwgZGF0YSA9IDAgYnl0ZXMsIGRp ciA9IG91dAp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSAxIChCQkIgQ0JX KSwgeGZlcj0weGMwNmM5MTgwLCBJT0VSUk9SCnVtYXNzMDogZmFpbGVkIHRv IHNlbmQgQ0JXCnVtYXNzMDogQnVsayBSZXNldAp1bWFzczA6IEhhbmRsaW5n IEJCQiBzdGF0ZSA3IChCQkIgUmVzZXQpLCB4ZmVyPTB4YzA2Y2ZjMDAsIElP RVJST1IKdW1hc3MwOiBCQkIgcmVzZXQgZmFpbGVkLCBJT0VSUk9SCnVtYXNz MDogQ2xlYXIgZW5kcG9pbnQgMHg4MiBzdGFsbAp1bWFzczA6IEhhbmRsaW5n IEJCQiBzdGF0ZSA4IChCQkIgYnVsay1pbiBjbGVhciBzdGFsbCksIHhmZXI9 MHhjMDZjZmI4MCwgSU9FUlJPUgp1bWFzczA6IEJCQiBidWxrLWluIGNsZWFy IHN0YWxsIGZhaWxlZCwgSU9FUlJPUgp1bWFzczA6IENsZWFyIGVuZHBvaW50 IDB4MDEgc3RhbGwKdW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgOSAoQkJC IGJ1bGstb3V0IGNsZWFyIHN0YWxsKSwgeGZlcj0weGMwNmNmYjAwLCBJT0VS Uk9SCnVtYXNzMDogQkJCIGJ1bGstb3V0IGNsZWFyIHN0YWxsIGZhaWxlZCwg SU9FUlJPUgp1bWFzczA6MDowOjA6WFBUX1NDU0lfSU86IGNtZDogMHgwMCwg ZmxhZ3M6IDB4YzAsIDZiIGNtZC8wYiBkYXRhLzMyYiBzZW5zZQp1bWFzczA6 IENvbnZlcnRlZCBURVNUX1VOSVRfUkVBRFkgdG8gU1RBUlRfVU5JVAp1bWFz czA6IENCVyAyMDogY21kID0gMTZiICgweDFiMDAwMDAwMDEwMC4uLiksIGRh dGEgPSAwIGJ5dGVzLCBkaXIgPSBvdXQKdW1hc3MwOiBIYW5kbGluZyBCQkIg c3RhdGUgMSAoQkJCIENCVyksIHhmZXI9MHhjMDZjOTE4MCwgSU9FUlJPUgp1 bWFzczA6IGZhaWxlZCB0byBzZW5kIENCVwp1bWFzczA6IEJ1bGsgUmVzZXQK dW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgNyAoQkJCIFJlc2V0KSwgeGZl cj0weGMwNmNmYzAwLCBJT0VSUk9SCnVtYXNzMDogQkJCIHJlc2V0IGZhaWxl ZCwgSU9FUlJPUgp1bWFzczA6IENsZWFyIGVuZHBvaW50IDB4ODIgc3RhbGwK dW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgOCAoQkJCIGJ1bGstaW4gY2xl YXIgc3RhbGwpLCB4ZmVyPTB4YzA2Y2ZiODAsIElPRVJST1IKdW1hc3MwOiBC QkIgYnVsay1pbiBjbGVhciBzdGFsbCBmYWlsZWQsIElPRVJST1IKdW1hc3Mw OiBDbGVhciBlbmRwb2ludCAweDAxIHN0YWxsCnVtYXNzMDogSGFuZGxpbmcg QkJCIHN0YXRlIDkgKEJCQiBidWxrLW91dCBjbGVhciBzdGFsbCksIHhmZXI9 MHhjMDZjZmIwMCwgSU9FUlJPUgp1bWFzczA6IEJCQiBidWxrLW91dCBjbGVh ciBzdGFsbCBmYWlsZWQsIElPRVJST1IKdW1hc3MwOjA6MDowOlhQVF9TQ1NJ X0lPOiBjbWQ6IDB4MDAsIGZsYWdzOiAweGMwLCA2YiBjbWQvMGIgZGF0YS8z MmIgc2Vuc2UKdW1hc3MwOiBDb252ZXJ0ZWQgVEVTVF9VTklUX1JFQURZIHRv IFNUQVJUX1VOSVQKdW1hc3MwOiBDQlcgMjE6IGNtZCA9IDE2YiAoMHgxYjAw MDAwMDAxMDAuLi4pLCBkYXRhID0gMCBieXRlcywgZGlyID0gb3V0CnVtYXNz MDogSGFuZGxpbmcgQkJCIHN0YXRlIDEgKEJCQiBDQlcpLCB4ZmVyPTB4YzA2 YzkxODAsIElPRVJST1IKdW1hc3MwOiBmYWlsZWQgdG8gc2VuZCBDQlcKdW1h c3MwOiBCdWxrIFJlc2V0CnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDcg KEJCQiBSZXNldCksIHhmZXI9MHhjMDZjZmMwMCwgSU9FUlJPUgp1bWFzczA6 IEJCQiByZXNldCBmYWlsZWQsIElPRVJST1IKdW1hc3MwOiBDbGVhciBlbmRw b2ludCAweDgyIHN0YWxsCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDgg KEJCQiBidWxrLWluIGNsZWFyIHN0YWxsKSwgeGZlcj0weGMwNmNmYjgwLCBJ T0VSUk9SCnVtYXNzMDogQkJCIGJ1bGstaW4gY2xlYXIgc3RhbGwgZmFpbGVk LCBJT0VSUk9SCnVtYXNzMDogQ2xlYXIgZW5kcG9pbnQgMHgwMSBzdGFsbAp1 bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSA5IChCQkIgYnVsay1vdXQgY2xl YXIgc3RhbGwpLCB4ZmVyPTB4YzA2Y2ZiMDAsIElPRVJST1IKdW1hc3MwOiBC QkIgYnVsay1vdXQgY2xlYXIgc3RhbGwgZmFpbGVkLCBJT0VSUk9SCnVtYXNz MDowOjA6MDpYUFRfU0NTSV9JTzogY21kOiAweDAwLCBmbGFnczogMHhjMCwg NmIgY21kLzBiIGRhdGEvMzJiIHNlbnNlCnVtYXNzMDogQ29udmVydGVkIFRF U1RfVU5JVF9SRUFEWSB0byBTVEFSVF9VTklUCnVtYXNzMDogQ0JXIDIyOiBj bWQgPSAxNmIgKDB4MWIwMDAwMDAwMTAwLi4uKSwgZGF0YSA9IDAgYnl0ZXMs IGRpciA9IG91dAp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSAxIChCQkIg Q0JXKSwgeGZlcj0weGMwNmM5MTgwLCBJT0VSUk9SCnVtYXNzMDogZmFpbGVk IHRvIHNlbmQgQ0JXCnVtYXNzMDogQnVsayBSZXNldAp1bWFzczA6IEhhbmRs aW5nIEJCQiBzdGF0ZSA3IChCQkIgUmVzZXQpLCB4ZmVyPTB4YzA2Y2ZjMDAs IElPRVJST1IKdW1hc3MwOiBCQkIgcmVzZXQgZmFpbGVkLCBJT0VSUk9SCnVt YXNzMDogQ2xlYXIgZW5kcG9pbnQgMHg4MiBzdGFsbAp1bWFzczA6IEhhbmRs aW5nIEJCQiBzdGF0ZSA4IChCQkIgYnVsay1pbiBjbGVhciBzdGFsbCksIHhm ZXI9MHhjMDZjZmI4MCwgSU9FUlJPUgp1bWFzczA6IEJCQiBidWxrLWluIGNs ZWFyIHN0YWxsIGZhaWxlZCwgSU9FUlJPUgp1bWFzczA6IENsZWFyIGVuZHBv aW50IDB4MDEgc3RhbGwKdW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgOSAo QkJCIGJ1bGstb3V0IGNsZWFyIHN0YWxsKSwgeGZlcj0weGMwNmNmYjAwLCBJ T0VSUk9SCnVtYXNzMDogQkJCIGJ1bGstb3V0IGNsZWFyIHN0YWxsIGZhaWxl ZCwgSU9FUlJPUgp1bWFzczA6MDowOjA6WFBUX1NDU0lfSU86IGNtZDogMHgx MiwgZmxhZ3M6IDB4NDAsIDZiIGNtZC8zNmIgZGF0YS8xOGIgc2Vuc2UKdW1h c3MwOiBDQlcgMjM6IGNtZCA9IDZiICgweDEyMDAwMDAwMjQwMCksIGRhdGEg PSAzNiBieXRlcywgZGlyID0gaW4KdW1hc3MwOiBIYW5kbGluZyBCQkIgc3Rh dGUgMSAoQkJCIENCVyksIHhmZXI9MHhjMDZjOTE4MCwgSU9FUlJPUgp1bWFz czA6IGZhaWxlZCB0byBzZW5kIENCVwp1bWFzczA6IEJ1bGsgUmVzZXQKdW1h c3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgNyAoQkJCIFJlc2V0KSwgeGZlcj0w eGMwNmNmYzAwLCBJT0VSUk9SCnVtYXNzMDogQkJCIHJlc2V0IGZhaWxlZCwg SU9FUlJPUgp1bWFzczA6IENsZWFyIGVuZHBvaW50IDB4ODIgc3RhbGwKdW1h c3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgOCAoQkJCIGJ1bGstaW4gY2xlYXIg c3RhbGwpLCB4ZmVyPTB4YzA2Y2ZiODAsIElPRVJST1IKdW1hc3MwOiBCQkIg YnVsay1pbiBjbGVhciBzdGFsbCBmYWlsZWQsIElPRVJST1IKdW1hc3MwOiBD bGVhciBlbmRwb2ludCAweDAxIHN0YWxsCnVtYXNzMDogSGFuZGxpbmcgQkJC IHN0YXRlIDkgKEJCQiBidWxrLW91dCBjbGVhciBzdGFsbCksIHhmZXI9MHhj MDZjZmIwMCwgSU9FUlJPUgp1bWFzczA6IEJCQiBidWxrLW91dCBjbGVhciBz dGFsbCBmYWlsZWQsIElPRVJST1IKdW1hc3MwOjA6MDowOlhQVF9TQ1NJX0lP OiBjbWQ6IDB4MTIsIGZsYWdzOiAweDQwLCA2YiBjbWQvMzZiIGRhdGEvMThi IHNlbnNlCnVtYXNzMDogQ0JXIDI0OiBjbWQgPSA2YiAoMHgxMjAwMDAwMDI0 MDApLCBkYXRhID0gMzYgYnl0ZXMsIGRpciA9IGluCnVtYXNzMDogSGFuZGxp bmcgQkJCIHN0YXRlIDEgKEJCQiBDQlcpLCB4ZmVyPTB4YzA2YzkxODAsIElP RVJST1IKdW1hc3MwOiBmYWlsZWQgdG8gc2VuZCBDQlcKdW1hc3MwOiBCdWxr IFJlc2V0CnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDcgKEJCQiBSZXNl dCksIHhmZXI9MHhjMDZjZmMwMCwgSU9FUlJPUgp1bWFzczA6IEJCQiByZXNl dCBmYWlsZWQsIElPRVJST1IKdW1hc3MwOiBDbGVhciBlbmRwb2ludCAweDgy IHN0YWxsCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDggKEJCQiBidWxr LWluIGNsZWFyIHN0YWxsKSwgeGZlcj0weGMwNmNmYjgwLCBJT0VSUk9SCnVt YXNzMDogQkJCIGJ1bGstaW4gY2xlYXIgc3RhbGwgZmFpbGVkLCBJT0VSUk9S CnVtYXNzMDogQ2xlYXIgZW5kcG9pbnQgMHgwMSBzdGFsbAp1bWFzczA6IEhh bmRsaW5nIEJCQiBzdGF0ZSA5IChCQkIgYnVsay1vdXQgY2xlYXIgc3RhbGwp LCB4ZmVyPTB4YzA2Y2ZiMDAsIElPRVJST1IKdW1hc3MwOiBCQkIgYnVsay1v dXQgY2xlYXIgc3RhbGwgZmFpbGVkLCBJT0VSUk9SCnVtYXNzMDowOjA6MDpY UFRfU0NTSV9JTzogY21kOiAweDEyLCBmbGFnczogMHg0MCwgNmIgY21kLzM2 YiBkYXRhLzE4YiBzZW5zZQp1bWFzczA6IENCVyAyNTogY21kID0gNmIgKDB4 MTIwMDAwMDAyNDAwKSwgZGF0YSA9IDM2IGJ5dGVzLCBkaXIgPSBpbgp1bWFz czA6IEhhbmRsaW5nIEJCQiBzdGF0ZSAxIChCQkIgQ0JXKSwgeGZlcj0weGMw NmM5MTgwLCBJT0VSUk9SCnVtYXNzMDogZmFpbGVkIHRvIHNlbmQgQ0JXCnVt YXNzMDogQnVsayBSZXNldAp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSA3 IChCQkIgUmVzZXQpLCB4ZmVyPTB4YzA2Y2ZjMDAsIElPRVJST1IKdW1hc3Mw OiBCQkIgcmVzZXQgZmFpbGVkLCBJT0VSUk9SCnVtYXNzMDogQ2xlYXIgZW5k cG9pbnQgMHg4MiBzdGFsbAp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0ZSA4 IChCQkIgYnVsay1pbiBjbGVhciBzdGFsbCksIHhmZXI9MHhjMDZjZmI4MCwg SU9FUlJPUgp1bWFzczA6IEJCQiBidWxrLWluIGNsZWFyIHN0YWxsIGZhaWxl ZCwgSU9FUlJPUgp1bWFzczA6IENsZWFyIGVuZHBvaW50IDB4MDEgc3RhbGwK dW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgOSAoQkJCIGJ1bGstb3V0IGNs ZWFyIHN0YWxsKSwgeGZlcj0weGMwNmNmYjAwLCBJT0VSUk9SCnVtYXNzMDog QkJCIGJ1bGstb3V0IGNsZWFyIHN0YWxsIGZhaWxlZCwgSU9FUlJPUgp1bWFz czA6MDowOjA6WFBUX1NDU0lfSU86IGNtZDogMHgxMiwgZmxhZ3M6IDB4NDAs IDZiIGNtZC8zNmIgZGF0YS8xOGIgc2Vuc2UKdW1hc3MwOiBDQlcgMjY6IGNt ZCA9IDZiICgweDEyMDAwMDAwMjQwMCksIGRhdGEgPSAzNiBieXRlcywgZGly ID0gaW4KdW1hc3MwOiBIYW5kbGluZyBCQkIgc3RhdGUgMSAoQkJCIENCVyks IHhmZXI9MHhjMDZjOTE4MCwgSU9FUlJPUgp1bWFzczA6IGZhaWxlZCB0byBz ZW5kIENCVwp1bWFzczA6IEJ1bGsgUmVzZXQKdW1hc3MwOiBIYW5kbGluZyBC QkIgc3RhdGUgNyAoQkJCIFJlc2V0KSwgeGZlcj0weGMwNmNmYzAwLCBJT0VS Uk9SCnVtYXNzMDogQkJCIHJlc2V0IGZhaWxlZCwgSU9FUlJPUgp1bWFzczA6 IENsZWFyIGVuZHBvaW50IDB4ODIgc3RhbGwKdW1hc3MwOiBIYW5kbGluZyBC QkIgc3RhdGUgOCAoQkJCIGJ1bGstaW4gY2xlYXIgc3RhbGwpLCB4ZmVyPTB4 YzA2Y2ZiODAsIElPRVJST1IKdW1hc3MwOiBCQkIgYnVsay1pbiBjbGVhciBz dGFsbCBmYWlsZWQsIElPRVJST1IKdW1hc3MwOiBDbGVhciBlbmRwb2ludCAw eDAxIHN0YWxsCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDkgKEJCQiBi dWxrLW91dCBjbGVhciBzdGFsbCksIHhmZXI9MHhjMDZjZmIwMCwgSU9FUlJP Ugp1bWFzczA6IEJCQiBidWxrLW91dCBjbGVhciBzdGFsbCBmYWlsZWQsIElP RVJST1IKdW1hc3MwOjA6MDowOlhQVF9TQ1NJX0lPOiBjbWQ6IDB4MTIsIGZs YWdzOiAweDQwLCA2YiBjbWQvMzZiIGRhdGEvMThiIHNlbnNlCnVtYXNzMDog Q0JXIDI3OiBjbWQgPSA2YiAoMHgxMjAwMDAwMDI0MDApLCBkYXRhID0gMzYg Ynl0ZXMsIGRpciA9IGluCnVtYXNzMDogSGFuZGxpbmcgQkJCIHN0YXRlIDEg KEJCQiBDQlcpLCB4ZmVyPTB4YzA2YzkxODAsIElPRVJST1IKdW1hc3MwOiBm YWlsZWQgdG8gc2VuZCBDQlcKdW1hc3MwOiBCdWxrIFJlc2V0CnVtYXNzMDog SGFuZGxpbmcgQkJCIHN0YXRlIDcgKEJCQiBSZXNldCksIHhmZXI9MHhjMDZj ZmMwMCwgSU9FUlJPUgp1bWFzczA6IEJCQiByZXNldCBmYWlsZWQsIElPRVJS T1IKdW1hc3MwOiBDbGVhciBlbmRwb2ludCAweDgyIHN0YWxsCnVtYXNzMDog SGFuZGxpbmcgQkJCIHN0YXRlIDggKEJCQiBidWxrLWluIGNsZWFyIHN0YWxs KSwgeGZlcj0weGMwNmNmYjgwLCBJT0VSUk9SCnVtYXNzMDogQkJCIGJ1bGst aW4gY2xlYXIgc3RhbGwgZmFpbGVkLCBJT0VSUk9SCnVtYXNzMDogQ2xlYXIg ZW5kcG9pbnQgMHgwMSBzdGFsbAp1bWFzczA6IEhhbmRsaW5nIEJCQiBzdGF0 ZSA5IChCQkIgYnVsay1vdXQgY2xlYXIgc3RhbGwpLCB4ZmVyPTB4YzA2Y2Zi MDAsIElPRVJST1IKdW1hc3MwOiBCQkIgYnVsay1vdXQgY2xlYXIgc3RhbGwg ZmFpbGVkLCBJT0VSUk9SCihkYTA6dW1hc3Mtc2ltMDowOjA6MCk6IGxvc3Qg ZGV2aWNlCg== ------=_NextPart_000_7db4_3641_2ff1-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 13 4:27: 8 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from mailbox.univie.ac.at (mailbox.univie.ac.at [131.130.1.27]) by hub.freebsd.org (Postfix) with ESMTP id D128837B404 for ; Sat, 13 Apr 2002 04:27:03 -0700 (PDT) Received: from korben (mailboxts3-35.univie.ac.at [131.130.99.35]) by mailbox.univie.ac.at (8.12.2/8.12.2) with ESMTP id g3DBQjRL1040268; Sat, 13 Apr 2002 13:26:52 +0200 Date: Sat, 13 Apr 2002 13:26:32 +0200 (=?ISO-8859-1?Q?Westeurop=E4ische_Sommerzeit?=) From: Lukas Ertl To: Paul Saab Cc: freebsd-scsi@freebsd.org Subject: Re: ciss driver and tagged queuing In-Reply-To: <20020411091935.GA99318@elvis.mu.org> Message-ID: X-X-Sender: le@mailbox.univie.ac.at MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, 11 Apr 2002, Paul Saab wrote: > Can you try this patch? It should fix the performance problems you > are having. Hi, I've seen that the patch already made it intp -STABLE, so I cvsupped and rebuilt everything, but I'm afraid to say that things got worse. Mounting the file system that is located on the Smart Array controller works, but as soon as there is some heavier disk activity on the controller (like the daily security runs etc.), the accessing processes hang up and keep stuck in an "uninterruptable disk wait" state. I can't even reboot the machine remotely, I have to go to the system room and push the button. camcontrol now gives this output: [root@raidtest /home/le]# camcontrol tags da0 -v (pass0:ciss0:0:0:0): dev_openings 1024 (pass0:ciss0:0:0:0): dev_active 0 (pass0:ciss0:0:0:0): devq_openings 1024 (pass0:ciss0:0:0:0): devq_queued 0 (pass0:ciss0:0:0:0): held 0 (pass0:ciss0:0:0:0): mintags 2 (pass0:ciss0:0:0:0): maxtags 255 (This is taken from the built-in SmartArray 5i controller, but the figures were the same on the 5300 controller AFAIR. I can't verify it right now, because "camcontrol tags da1" gets stuck too and I'm about 200km away from the machine :-( ). Any hints? I can test more patches if you have them, but not before monday, when I'm back to work. regards, le --=20 Lukas Ertl eMail: l.ertl@univie.ac.at UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universit=E4t Wien http://mailbox.univie.ac.at/~le/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 13 8:41:28 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from TheWorld.com (pcls3.std.com [199.172.62.105]) by hub.freebsd.org (Postfix) with ESMTP id BCAC237B404; Sat, 13 Apr 2002 08:41:20 -0700 (PDT) Received: from world.std.com (jhenry@world-f.std.com [199.172.62.5]) by TheWorld.com (8.9.3/8.9.3) with ESMTP id LAA04842; Sat, 13 Apr 2002 11:41:16 -0400 Received: (from kwc@localhost) by world.std.com (8.9.3/8.9.3) id LAA12983; Sat, 13 Apr 2002 11:41:16 -0400 (EDT) Date: Sat, 13 Apr 2002 11:41:16 -0400 (EDT) From: Kenneth W Cochran Message-Id: <200204131541.LAA12983@world.std.com> To: Nick Hibma Subject: Re: Status, USB/Olympus E-10 Cc: freebsd-scsi@freebsd.org, freebsd-stable@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Hi, sorry so late with reply... >Date: Thu, 11 Apr 2002 08:31:47 +0200 (CEST) >From: Nick Hibma >To: Kenneth W Cochran >cc: "freebsd-stable@FreeBSD.ORG" , > "freebsd-scsi@FreeBSD.ORG" >Subject: Re: Status, USB/Olympus E-10 > >Compile a kernel with UMASS_DEBUG (or load the module compile with >CFLAGS+=-DUMASS_DEBUG) and send me the output of an attach. It should be >possible to make it work. Done at beginning... >The fact that it reboots without reason is very very strange indeed. If >that is the case, check that your machine is grounded properly. Static >electricity nuked my Win2k box every once in a while when I did a sync >with my Palm. Grounding definitely not a problem; system doesn't panic until I try to mount the device. Based on another message thread in -stable ("very old bug") I wonder if it might be related: the E-10 is supposedly a MS-DOS filesystem, & I think it is readonly (not sure, though). >Nick -kc >On Sun, 6 Jan 2002, Kenneth W Cochran wrote: > >> (cc'ed to -scsi) >> >> Hello, >> >> A couple of committers & I were working last July (2001) with >> support for the Olympus E-10 digital camera in FreeBSD. This >> is a USB device. >> >> I just saw some commits in cam/scsi_da for Nikon & I'm wondering >> what the situation is wrt Olympus? >> >> The problem I was having was that even though FreeBSD (then >> 4.3-stable) would recognise the camera, if I tried to mount() >> it the os would reboot(!) :(( No panic, no nothing, just a >> hard freeze & rebooting. Obviously, this is Very Very Bad. >> >> I've seen Linux (2.4-something) working with this just fine. >> Linux sees this camera as a SCSI device with a MS-DOS filesystem. >> >> I'm now running a 4.5-PRERELEASE & wonder if, assuming this >> hasn't been fixed since 4.3, that this might be fixed in 4.5? >> At least if the camera isn't/can't be supported in time (for >> 4.5), is there some way we could at least protect the system >> from the rebooting? I can probably help test. >> >> I'm thinking of filing a PR, but seek advice before doing that. >> >> Many thanks, >> >> -kc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Apr 13 15:40:59 2002 Delivered-To: freebsd-scsi@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id DC24637B405 for ; Sat, 13 Apr 2002 15:40:48 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1000) id AB739AE163; Sat, 13 Apr 2002 15:40:48 -0700 (PDT) Date: Sat, 13 Apr 2002 15:40:48 -0700 From: Paul Saab To: Lukas Ertl Cc: freebsd-scsi@freebsd.org Subject: Re: ciss driver and tagged queuing Message-ID: <20020413224048.GA6046@elvis.mu.org> References: <20020411091935.GA99318@elvis.mu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit Yea.. Mike and I discovered that the CAM sim was being frozen but never being unfrozen. Can you try this patch? I still have not put this into FreeBSD because of other weirdness I am seeing on my DL380g2, but I am unable to reproduce the same problems w/ my DL360g2, so I'm going to put another DL380g2 in the rack on monday and see if it suffers from the lockups I am seeing or if that machine's array is just jacked. Lukas Ertl (l.ertl@univie.ac.at) wrote: > On Thu, 11 Apr 2002, Paul Saab wrote: > > > Can you try this patch? It should fix the performance problems you > > are having. > > Hi, > > I've seen that the patch already made it intp -STABLE, so I cvsupped > and rebuilt everything, but I'm afraid to say that things got worse. > Mounting the file system that is located on the Smart Array controller > works, but as soon as there is some heavier disk activity on the > controller (like the daily security runs etc.), the accessing processes > hang up and keep stuck in an "uninterruptable disk wait" state. I can't > even reboot the machine remotely, I have to go to the system room and > push the button. > > camcontrol now gives this output: > > [root@raidtest /home/le]# camcontrol tags da0 -v > (pass0:ciss0:0:0:0): dev_openings 1024 > (pass0:ciss0:0:0:0): dev_active 0 > (pass0:ciss0:0:0:0): devq_openings 1024 > (pass0:ciss0:0:0:0): devq_queued 0 > (pass0:ciss0:0:0:0): held 0 > (pass0:ciss0:0:0:0): mintags 2 > (pass0:ciss0:0:0:0): maxtags 255 > > (This is taken from the built-in SmartArray 5i controller, but the figures > were the same on the 5300 controller AFAIR. I can't verify it right now, > because "camcontrol tags da1" gets stuck too and I'm about 200km away > from the machine :-( ). > > Any hints? I can test more patches if you have them, but not before > monday, when I'm back to work. > > regards, > le > > -- > Lukas Ertl eMail: l.ertl@univie.ac.at > UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 > Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 > der Universität Wien http://mailbox.univie.ac.at/~le/ -- Paul Saab Technical Yahoo ps@mu.org - ps@yahoo-inc.com - ps@freebsd.org Do You .. uhh .. Yahoo!? --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=diff Index: yahoo/ybsd_4/src/sys/dev/ciss/ciss.c =========================================================================== --- ciss.c 2002/04/13 15:36:17 #3 +++ yahoo/ybsd_4/src/sys/dev/ciss/ciss.c 2002/04/13 15:36:17 @@ -2000,7 +2000,7 @@ */ if ((sc->ciss_cam_sim = cam_sim_alloc(ciss_cam_action, ciss_cam_poll, "ciss", sc, device_get_unit(sc->ciss_dev), - sc->ciss_cfg->max_outstanding_commands, + sc->ciss_max_requests - 2, 1, sc->ciss_cam_devq)) == NULL) { ciss_printf(sc, "can't allocate CAM SIM\n"); @@ -2421,6 +2421,9 @@ /* handle post-command fixup */ ciss_cam_complete_fixup(sc, csio); + /* tell CAM we're ready for more commands */ + csio->ccb_h.status |= CAM_RELEASE_SIMQ; + xpt_done((union ccb *)csio); ciss_release_request(cr); } --HlL+5n6rz5pIUxbD-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message