From owner-freebsd-scsi Tue Sep 26 6:45:10 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.gmx.net (pop.gmx.net [194.221.183.20]) by hub.freebsd.org (Postfix) with SMTP id B86D937B422 for ; Tue, 26 Sep 2000 06:45:06 -0700 (PDT) Received: (qmail 32279 invoked by uid 0); 26 Sep 2000 13:45:02 -0000 Received: from p3e9ec8e9.dip0.t-ipconnect.de (HELO wunderland.own) (62.158.200.233) by mail.gmx.net with SMTP; 26 Sep 2000 13:45:02 -0000 Received: from wunderland.own (localhost [127.0.0.1]) by wunderland.own (8.11.0/8.9.3) with SMTP id e8QDjQn00630 for ; Tue, 26 Sep 2000 15:45:26 +0200 (CEST) (envelope-from klaus.herrmann@gmx.net) Message-Id: <200009261345.e8QDjQn00630@wunderland.own> Content-Type: text/plain Content-Disposition: inline Mime-Version: 1.0 From: Klaus Herrmann To: freebsd-scsi@freebsd.org Reply-To: Klaus Herrmann Subject: dds2tar / mtio X-Mailer: CSCMail v1.6.1 Date: 26 Sep 2000 15:45:12 CEST Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey Folks! I wonder if one could make dds2tar or at least a patched tar to get work on freebsd(4.1). the author says it runs on linux and hpux. the thing is: This tool was originally written for Linux SCSI tape archives. All device dependent code is separated. It should be easy, to change this for your machine type. The only problem should be the ioctls for MTIOCTOP,(MTSEEK,arg) and MTIOCPOS. well, according to mtio(4) we have the MTIOCTOP ioctl, but no MTSEEK and MTIOCPOS. (in fact i took a look at the tar-patch and i don't think the author uses MTSEEK so all we need is MTIOCPOS as long as we only use the tar-patch and not the whole dds2tar package). as i am not a kernel programmer i can't tell wether it is possible or not to implement this ioctl and how much work it would be to do it. What do you think? has anyone tried this? or are there already similar ioctls which could be uses instead? #if defined(MTIOCPOS) /* Prints the tape block number on every Linux SCSI-device */ if ( record_file_name ) { struct mtpos pos ; int i ; i = ioctl(archive,MTIOCPOS,&pos); if ( i == 0 ) { fprintf(stdrec, "loc number of the first block is %d\n", pos.mt_blkno ); } } #endif this is the only time MTIOCPOS is used i think. oh, one more thing: the README says MTIOCTOP is used but i can only find MTIOCGET in the sources. but both seem to be implemented so no need to worry i hope). do you think we could make this work? fast file recovery with tar would be great as tar is cool as long as you dont want to restore a file which is somewhere on this 45GB (3x15GB tapes) backup.... regards, Klaus -- "Don't put off for tomorrow what you can do today, because if you enjoy it today you can do it again tomorrow." Klaus Herrmann PGP-Fingerprint: B6FD E394 B6BB 0B58 17BF 35EC 1AF3 A4BD B8D6 E23A To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 28 10:37:22 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from polaris.we.lc.ehu.es (polaris.we.lc.ehu.es [158.227.6.43]) by hub.freebsd.org (Postfix) with ESMTP id 846CE37B423 for ; Thu, 28 Sep 2000 10:37:16 -0700 (PDT) Received: from v-ger.we.lc.ehu.es (v-ger [158.227.6.179]) by polaris.we.lc.ehu.es (8.9.1/8.9.1) with ESMTP id TAA10516 for ; Thu, 28 Sep 2000 19:37:07 +0200 (MET DST) Received: from we.lc.ehu.es (localhost [127.0.0.1]) by v-ger.we.lc.ehu.es (8.11.0/8.11.0) with ESMTP id e8SHZ2S00689 for ; Thu, 28 Sep 2000 19:35:02 +0200 (CEST) (envelope-from jose@we.lc.ehu.es) Message-ID: <39D38146.671CFFF0@we.lc.ehu.es> Date: Thu, 28 Sep 2000 19:35:02 +0200 From: "Jose M. Alcaide" Organization: Universidad del Pais Vasco - Dpto. de Electricidad y Electronica X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.12 i386) X-Accept-Language: es-ES, es, en-US, en MIME-Version: 1.0 To: scsi@FreeBSD.org Subject: panic when removing device with "camcontrol rescan" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, I am running a pretty recent -current (Sept. 21) on a machine equipped with an Adaptec 7880 controller. There are a HD, a MO unit (both internal) and a DLT drive connected to the SCSI bus. I can trigger a panic if I power the DLT off and then type "camcontrol rescan 0", in order to remove the CAM device. The SCSI subsystem hangs, so I cannot generate a crash dump. I compiled a kernel with DDB, and I got the following trace output (function parameters left out - I am copying by hand): destroy_dev() at destroy_dev+0x7 sacleanup() at sacleanup+0x2d camperiphfree() at camperiphfree+0x42 cam_periph_invalidate() cam_periph_async() saaync() xpt_async_bcast() xpt_async() probedone() camisr() swi_cambio() intr_soft() fork_trampoline() If there is a way for getting more post-mortem information, I could try it... Any ideas? Cheers, -- JMA ****** Jose M. Alcaide // jose@we.lc.ehu.es // jmas@FreeBSD.org ****** ** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein ** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 28 10:39:43 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 3770E37B423 for ; Thu, 28 Sep 2000 10:39:37 -0700 (PDT) Received: from zeppo.feral.com (IDENT:mjacob@zeppo [192.67.166.71]) by feral.com (8.9.3/8.9.3) with ESMTP id KAA09780; Thu, 28 Sep 2000 10:39:23 -0700 Date: Thu, 28 Sep 2000 10:36:24 -0700 (PDT) From: Matthew Jacob Reply-To: mjacob@feral.com To: "Jose M. Alcaide" Cc: scsi@FreeBSD.ORG Subject: Re: panic when removing device with "camcontrol rescan" In-Reply-To: <39D38146.671CFFF0@we.lc.ehu.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmm...good info.. That seems like it's my bug... it'll take me a day to get to it though... can you remind me if you don't see a fix by next week? > Hello, > > I am running a pretty recent -current (Sept. 21) on a machine equipped > with an Adaptec 7880 controller. There are a HD, a MO unit (both internal) > and a DLT drive connected to the SCSI bus. > > I can trigger a panic if I power the DLT off and then type "camcontrol > rescan 0", in order to remove the CAM device. The SCSI subsystem hangs, > so I cannot generate a crash dump. I compiled a kernel with DDB, and > I got the following trace output (function parameters left out - I am > copying by hand): > > destroy_dev() at destroy_dev+0x7 > sacleanup() at sacleanup+0x2d > camperiphfree() at camperiphfree+0x42 > cam_periph_invalidate() > cam_periph_async() > saaync() > xpt_async_bcast() > xpt_async() > probedone() > camisr() > swi_cambio() > intr_soft() > fork_trampoline() > > If there is a way for getting more post-mortem information, I could > try it... Any ideas? > > Cheers, > -- JMA > ****** Jose M. Alcaide // jose@we.lc.ehu.es // jmas@FreeBSD.org ****** > ** "Beware of Programmers who carry screwdrivers" -- Leonard Brandwein ** > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-scsi" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 28 13:26:29 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 0F12537B42C for ; Thu, 28 Sep 2000 13:26:26 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id OAA17304 for ; Thu, 28 Sep 2000 14:26:24 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id OAA71656 for ; Thu, 28 Sep 2000 14:26:24 -0600 (MDT) Message-Id: <200009282026.OAA71656@harmony.village.org> To: scsi@freebsd.org Subject: AHA-14*5*0A Date: Thu, 28 Sep 2000 14:26:24 -0600 From: Warner Losh Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does anybody know what chip is inside the APA-1450A pccard adapter? It looks like I can get one very cheaply. I mildly suspect that it is the aic-6260, but I could be wrong about that. Does anybody know for sure? adaptec's web site was less than helpful here. It kinda looks like it is nearly the same as the 1460, but there's no place I could find with enough details to know for sure. On a related note, I also have a line of an oddball Ethernet SCSI combo card. It is made by fujitsu and all I know about it is that it is a LAN/SCSI card. Fujitsu's web site doesn't even seem to acknowledge that this card exists... Does anybody have any experience with it? I've unsubscribed from scsi list, so please cc me on replies. Thanks much! Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 28 15:57:15 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id C31E037B440; Thu, 28 Sep 2000 15:56:42 -0700 (PDT) Received: from localhost (bandix@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id SAA91542; Thu, 28 Sep 2000 18:57:37 -0400 (EDT) (envelope-from bandix@looksharp.net) Date: Thu, 28 Sep 2000 18:57:37 -0400 (EDT) From: "Brandon D. Valentine" To: scsi@freebsd.org, gibbs@freebsd.org Subject: More ahc woes. Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm really sorry to have to come to you with another bug report, Justin, I know you're probably sick of hearing from me by now. That machine with the Supermicro 370DL3 is broken under 4.1.1-RELEASE and the drivers you committed just before the release. The install disks panic on boot with the following: ahc0: port 0xe400-0xe4ff mem 0xfebfe000-0xfebfefff irq 15 at device 1.0 on pci1 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x1c fault code = supervisor read, page not present instruction pointer = 0x8:0xc02b5fe4 stack pointer = 0x10:0xc0659e58 frame pointer = 0x10:0xc0659e58 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL=0 current process = 0 (swapper) interrupt mask = net tty bio cam trap number = 12 panic: page fault Uptime: 0s Attached is the boot -v from a machine running: FreeBSD 5.0-20000827-CURRENT #0: Sun Aug 27 12:36:38 GMT 2000 root@usw2.freebsd.org:/usr/src/sys/compile/GENERIC This machine runs perfectly with the code from this revision of current. I suspect one of the changes made to accomodate the older controllers broke the support for this board. Let me know what other debug information I can get you. I thought perhaps it would help to compile a debug kernel on one of my working 4.x boxes, copy to the -current root and boot it, allowing debug information to spew to the -current system's filesystem. I needn't worry about the world/kernel mismatch since I'll never get as far as init anyway. If it would help we are willing to box up the motherboard and ship it to you. However, let's try a little remote debugging before we resort to that. Thanks for your diligence, Justin, and let me know what else I can do. Brandon D. Valentine Systems Administrator Vanderbilt University, Center for Structural Biology -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 28 16:21:45 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id D7C2037B423; Thu, 28 Sep 2000 16:20:59 -0700 (PDT) Received: from localhost (bandix@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id TAA91722; Thu, 28 Sep 2000 19:21:55 -0400 (EDT) (envelope-from bandix@looksharp.net) Date: Thu, 28 Sep 2000 19:21:55 -0400 (EDT) From: "Brandon D. Valentine" To: scsi@freebsd.org, gibbs@freebsd.org Subject: Re: More ahc woes. In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-401528494-970183315=:90309" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to mime@docserver.cac.washington.edu for more info. --0-401528494-970183315=:90309 Content-Type: TEXT/PLAIN; charset=US-ASCII On Thu, 28 Sep 2000, Brandon D. Valentine wrote: >Attached is the boot -v from a machine running: >FreeBSD 5.0-20000827-CURRENT #0: Sun Aug 27 12:36:38 GMT 2000 >root@usw2.freebsd.org:/usr/src/sys/compile/GENERIC It would of course help if I attached the boot -v. Brandon D. Valentine -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying --0-401528494-970183315=:90309 Content-Type: TEXT/PLAIN; charset=US-ASCII; name="dmesg.boot" Content-Transfer-Encoding: BASE64 Content-ID: Content-Description: boot -v Content-Disposition: attachment; filename="dmesg.boot" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDAgVGhlIEZyZWVCU0QgUHJvamVjdC4N CkNvcHlyaWdodCAoYykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwg MTk4OSwgMTk5MSwgMTk5MiwgMTk5MywgMTk5NA0KCVRoZSBSZWdlbnRzIG9m IHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCByaWdodHMgcmVz ZXJ2ZWQuDQpGcmVlQlNEIDUuMC0yMDAwMDgyNy1DVVJSRU5UICMwOiBTdW4g QXVnIDI3IDEyOjM2OjM4IEdNVCAyMDAwDQogICAgcm9vdEB1c3cyLmZyZWVi c2Qub3JnOi91c3Ivc3JjL3N5cy9jb21waWxlL0dFTkVSSUMNCkNhbGlicmF0 aW5nIGNsb2NrKHMpIC4uLiBUU0MgY2xvY2s6IDczMzAyOTk4NSBIeiwgaTgy NTQgY2xvY2s6IDExOTMyNjMgSHoNCkNMS19VU0VfSTgyNTRfQ0FMSUJSQVRJ T04gbm90IHNwZWNpZmllZCAtIHVzaW5nIGRlZmF1bHQgZnJlcXVlbmN5DQpU aW1lY291bnRlciAiaTgyNTQiICBmcmVxdWVuY3kgMTE5MzE4MiBIeg0KQ0xL X1VTRV9UU0NfQ0FMSUJSQVRJT04gbm90IHNwZWNpZmllZCAtIHVzaW5nIG9s ZCBjYWxpYnJhdGlvbiBtZXRob2QNClRpbWVjb3VudGVyICJUU0MiICBmcmVx dWVuY3kgNzMyOTgzMjc3IEh6DQpDUFU6IFBlbnRpdW0gSUlJL1BlbnRpdW0g SUlJIFhlb24vQ2VsZXJvbiAoNzMyLjk4LU1IeiA2ODYtY2xhc3MgQ1BVKQ0K ICBPcmlnaW4gPSAiR2VudWluZUludGVsIiAgSWQgPSAweDY4MyAgU3RlcHBp bmcgPSAzDQogIEZlYXR1cmVzPTB4MzgzZmJmZjxGUFUsVk1FLERFLFBTRSxU U0MsTVNSLFBBRSxNQ0UsQ1g4LEFQSUMsU0VQLE1UUlIsUEdFLE1DQSxDTU9W LFBBVCxQU0UzNixNTVgsRlhTUixYTU0+DQpyZWFsIG1lbW9yeSAgPSAyNjg0 MzU0NTYgKDI2MjE0NEsgYnl0ZXMpDQpQaHlzaWNhbCBtZW1vcnkgY2h1bmso cyk6DQoweDAwMDAxMDAwIC0gMHgwMDA5ZWZmZiwgNjQ3MTY4IGJ5dGVzICgx NTggcGFnZXMpDQoweDAwNDVkMDAwIC0gMHgwZmZmN2ZmZiwgMjYzODI3NDU2 IGJ5dGVzICg2NDQxMSBwYWdlcykNCmF2YWlsIG1lbW9yeSA9IDI1Njk3MDc1 MiAoMjUwOTQ4SyBieXRlcykNCmJpb3MzMjogRm91bmQgQklPUzMyIFNlcnZp Y2UgRGlyZWN0b3J5IGhlYWRlciBhdCAweGMwMGZkYjgwDQpiaW9zMzI6IEVu dHJ5ID0gMHhmZGI5MCAoYzAwZmRiOTApICBSZXYgPSAwICBMZW4gPSAxDQpw Y2liaW9zOiBQQ0kgQklPUyBlbnRyeSBhdCAweGYwMDAwKzB4ZGJiMQ0KcG5w YmlvczogRm91bmQgUG5QIEJJT1MgZGF0YSBhdCAweGMwMGY2YTgwDQpwbnBi aW9zOiBFbnRyeSA9IGYwMDAwOjYyMDQgIFJldiA9IDEuMA0KT3RoZXIgQklP UyBzaWduYXR1cmVzIGZvdW5kOg0KQUNQSTogMDAwMDAwMDANClByZWxvYWRl ZCBlbGYga2VybmVsICJrZXJuZWwiIGF0IDB4YzA0NDQwMDAuDQpudWxsZGV2 OiA8bnVsbCBkZXZpY2UsIHplcm8gZGV2aWNlPg0KcmFuZG9tOiA8ZW50cm9w eSBzb3VyY2U+DQptZW06IDxtZW1vcnkgJiBJL08+DQpQZW50aXVtIFBybyBN VFJSIHN1cHBvcnQgZW5hYmxlZA0KQ3JlYXRpbmcgRElTSyBtZDANCm1kMDog TWFsbG9jIGRpc2sNCk1hdGggZW11bGF0b3IgcHJlc2VudA0KbnB4MDogPG1h dGggcHJvY2Vzc29yPiBvbiBtb3RoZXJib2FyZA0KbnB4MDogSU5UIDE2IGlu dGVyZmFjZQ0KcGNpYjA6IDxSQ0MgTEUgaG9zdCB0byBQQ0kgYnJpZGdlPiBv biBtb3RoZXJib2FyZA0KZm91bmQtPgl2ZW5kb3I9MHgxMTY2LCBkZXY9MHgw MDA5LCByZXZpZD0weDA1DQoJY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgw MCwgbWZkZXY9MQ0KCXN1Ym9yZGluYXRlYnVzPTAgCXNlY29uZGFyeWJ1cz0w DQpmb3VuZC0+CXZlbmRvcj0weDExNjYsIGRldj0weDAwMDksIHJldmlkPTB4 MDUNCgljbGFzcz0wNi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJ c3Vib3JkaW5hdGVidXM9MCAJc2Vjb25kYXJ5YnVzPTANCmZvdW5kLT4JdmVu ZG9yPTB4MTAwMiwgZGV2PTB4NDc1NiwgcmV2aWQ9MHg3YQ0KCWNsYXNzPTAz LTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCglzdWJvcmRpbmF0ZWJ1 cz0wIAlzZWNvbmRhcnlidXM9MA0KCWludHBpbj1hLCBpcnE9MTENCgltYXBb MTBdOiB0eXBlIDMsIHJhbmdlIDMyLCBiYXNlIGZkMDAwMDAwLCBzaXplIDI0 LCBlbmFibGVkDQoJbWFwWzE0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAw MDAwZDgwMCwgc2l6ZSAgOCwgZW5hYmxlZA0KCW1hcFsxOF06IHR5cGUgMSwg cmFuZ2UgMzIsIGJhc2UgZmVhZmYwMDAsIHNpemUgMTIsIGVuYWJsZWQNCmZv dW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MTIyOSwgcmV2aWQ9MHgwOA0K CWNsYXNzPTAyLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCglzdWJv cmRpbmF0ZWJ1cz0wIAlzZWNvbmRhcnlidXM9MA0KCWludHBpbj1hLCBpcnE9 OQ0KCW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmVhZmQwMDAs IHNpemUgMTIsIGVuYWJsZWQNCgltYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMy LCBiYXNlIDAwMDBkNDAwLCBzaXplICA2LCBlbmFibGVkDQoJbWFwWzE4XTog dHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmZTkwMDAwMCwgc2l6ZSAyMCwgZW5h YmxlZA0KZm91bmQtPgl2ZW5kb3I9MHgxMTY2LCBkZXY9MHgwMjAwLCByZXZp ZD0weDRmDQoJY2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MQ0KCXN1Ym9yZGluYXRlYnVzPTAgCXNlY29uZGFyeWJ1cz0wDQpmb3VuZC0+ CXZlbmRvcj0weDExNjYsIGRldj0weDAyMTEsIHJldmlkPTB4MDANCgljbGFz cz0wMS0wMS04YSwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJc3Vib3JkaW5h dGVidXM9MCAJc2Vjb25kYXJ5YnVzPTANCgltYXBbMjBdOiB0eXBlIDQsIHJh bmdlIDMyLCBiYXNlIDAwMDBmZmEwLCBzaXplICA0LCBwb3J0IGRpc2FibGVk DQpmb3VuZC0+CXZlbmRvcj0weDExNjYsIGRldj0weDAyMjAsIHJldmlkPTB4 MDQNCgljbGFzcz0wYy0wMy0xMCwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJ c3Vib3JkaW5hdGVidXM9MCAJc2Vjb25kYXJ5YnVzPTANCglpbnRwaW49YSwg aXJxPTEwDQoJbWFwWzEwXTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmZWFm ZTAwMCwgc2l6ZSAxMiwgZW5hYmxlZA0KcGNpMDogPFBDSSBidXM+IG9uIHBj aWIwDQpwY2kwOiA8SG9zdCB0byBQQ0kgYnJpZGdlICh2ZW5kb3I9MTE2NiBk ZXZpY2U9MDAwOSk+ICh2ZW5kb3I9MHgxMTY2LCBkZXY9MHgwMDA5KSBhdCAw LjANCnBjaTA6IDxIb3N0IHRvIFBDSSBicmlkZ2UgKHZlbmRvcj0xMTY2IGRl dmljZT0wMDA5KT4gKHZlbmRvcj0weDExNjYsIGRldj0weDAwMDkpIGF0IDAu MQ0KcGNpMDogPEFUSSBNYWNoNjQtR1YgZ3JhcGhpY3MgYWNjZWxlcmF0b3I+ ICh2ZW5kb3I9MHgxMDAyLCBkZXY9MHg0NzU2KSBhdCAxLjAgaXJxIDExDQpm eHAwOiA8SW50ZWwgUHJvIDEwLzEwMEIvMTAwKyBFdGhlcm5ldD4gcG9ydCAw eGQ0MDAtMHhkNDNmIG1lbSAweGZlOTAwMDAwLTB4ZmU5ZmZmZmYsMHhmZWFm ZDAwMC0weGZlYWZkZmZmIGlycSA5IGF0IGRldmljZSA2LjAgb24gcGNpMA0K ZnhwMDogRXRoZXJuZXQgYWRkcmVzcyAwMDozMDo0ODoxMDo1OTo1Mg0KYnBm OiBmeHAwIGF0dGFjaGVkDQppc2FiMDogPFBDSSB0byBJU0EgYnJpZGdlICh2 ZW5kb3I9MTE2NiBkZXZpY2U9MDIwMCk+IGF0IGRldmljZSAxNS4wIG9uIHBj aTANCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMA0KYXRhcGNpMDogPEdlbmVy aWMgUENJIEFUQSBjb250cm9sbGVyPiBhdCBkZXZpY2UgMTUuMSBvbiBwY2kw DQphdGFwY2kwOiBCdXNtYXN0ZXJpbmcgRE1BIG5vdCBlbmFibGVkDQphdGEw OiBpb2Jhc2U9MHgwMWYwIGFsdGlvYmFzZT0weDAzZjYgYm1hZGRyPTB4MDAw MA0KYXRhMDogbWFzaz0wMCBzdGF0dXMwPWZmIHN0YXR1czE9ZmYNCmF0YTA6 IHByb2JlIGFsbG9jYXRpb24gZmFpbGVkDQphdGExOiBpb2Jhc2U9MHgwMTcw IGFsdGlvYmFzZT0weDAzNzYgYm1hZGRyPTB4MDAwMQ0KYXRhMTogbWFzaz0w MCBzdGF0dXMwPWZmIHN0YXR1czE9ZmYNCmF0YTE6IHByb2JlIGFsbG9jYXRp b24gZmFpbGVkDQpvaGNpMDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9s bGVyPiBtZW0gMHhmZWFmZTAwMC0weGZlYWZlZmZmIGlycSAxMCBhdCBkZXZp Y2UgMTUuMiBvbiBwY2kwDQpvaGNpMDogKE5ldyBPSENJIERldmljZUlkPTB4 MDIyMDExNjYpDQp1c2IwOiBPSENJIHZlcnNpb24gMS4wLCBsZWdhY3kgc3Vw cG9ydA0KdXNiMDogPE9IQ0kgKGdlbmVyaWMpIFVTQiBjb250cm9sbGVyPiBv biBvaGNpMA0KdXNiMDogVVNCIHJldmlzaW9uIDEuMA0KdWh1YjA6ICh1bmtu b3duKSBPSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMQ0KdWh1YjA6IDQgcG9ydHMgd2l0aCA0IHJlbW92YWJsZSwgc2Vs ZiBwb3dlcmVkDQpwY2liMTogPFJDQyBMRSBob3N0IHRvIFBDSSBicmlkZ2U+ IG9uIG1vdGhlcmJvYXJkDQpmb3VuZC0+CXZlbmRvcj0weDkwMDUsIGRldj0w eDAwODAsIHJldmlkPTB4MDINCgljbGFzcz0wMS0wMC0wMCwgaGRydHlwZT0w eDAwLCBtZmRldj0wDQoJc3Vib3JkaW5hdGVidXM9MCAJc2Vjb25kYXJ5YnVz PTANCglpbnRwaW49YSwgaXJxPTE1DQoJbWFwWzEwXTogdHlwZSA0LCByYW5n ZSAzMiwgYmFzZSAwMDAwZTQwMCwgc2l6ZSAgOCwgZW5hYmxlZA0KCW1hcFsx NF06IHR5cGUgMSwgcmFuZ2UgNjQsIGJhc2UgZmViZmUwMDAsIHNpemUgMTIs IGVuYWJsZWQNCmZvdW5kLT4JdmVuZG9yPTB4OTAwNSwgZGV2PTB4MDA4Ziwg cmV2aWQ9MHgwMg0KCWNsYXNzPTAxLTAwLTAwLCBoZHJ0eXBlPTB4MDAsIG1m ZGV2PTANCglzdWJvcmRpbmF0ZWJ1cz0wIAlzZWNvbmRhcnlidXM9MA0KCWlu dHBpbj1hLCBpcnE9MTANCgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBi YXNlIDAwMDBlODAwLCBzaXplICA4LCBlbmFibGVkDQoJbWFwWzE0XTogdHlw ZSAxLCByYW5nZSA2NCwgYmFzZSBmZWJmZjAwMCwgc2l6ZSAxMiwgZW5hYmxl ZA0KcGNpMTogPFBDSSBidXM+IG9uIHBjaWIxDQphaGMwOiA8QWRhcHRlYyAy OTE2MCBVbHRyYTE2MCBTQ1NJIGFkYXB0ZXI+IHBvcnQgMHhlNDAwLTB4ZTRm ZiBtZW0gMHhmZWJmZTAwMC0weGZlYmZlZmZmIGlycSAxNSBhdCBkZXZpY2Ug MS4wIG9uIHBjaTENCmFoYzA6IFJlYWRpbmcgU0VFUFJPTS4uLmRvbmUuDQph aGMwOiBCSU9TIGVlcHJvbSBpcyBwcmVzZW50DQphaGMwOiBTZWNvbmRhcnkg SGlnaCBieXRlIHRlcm1pbmF0aW9uIEVuYWJsZWQNCmFoYzA6IFNlY29uZGFy eSBMb3cgYnl0ZSB0ZXJtaW5hdGlvbiBFbmFibGVkDQphaGMwOiBQcmltYXJ5 IEhpZ2ggQnl0ZSB0ZXJtaW5hdGlvbiBFbmFibGVkDQphaGMwOiBhaWM3ODky IFdpZGUgQ2hhbm5lbCBBLCBTQ1NJIElkPTcsIDMyLzI1NSBTQ0JzDQphaGMw OiBEb3dubG9hZGluZyBTZXF1ZW5jZXIgUHJvZ3JhbS4uLiA0MjggaW5zdHJ1 Y3Rpb25zIGRvd25sb2FkZWQNCmFoYzE6IDxBZGFwdGVjIGFpYzc4OTIgVWx0 cmExNjAgU0NTSSBhZGFwdGVyPiBwb3J0IDB4ZTgwMC0weGU4ZmYgbWVtIDB4 ZmViZmYwMDAtMHhmZWJmZmZmZiBpcnEgMTAgYXQgZGV2aWNlIDMuMCBvbiBw Y2kxDQphaGMxOiBSZWFkaW5nIFNFRVBST00uLi5kb25lLg0KYWhjMTogTWFu dWFsIExWRCBUZXJtaW5hdGlvbg0KYWhjMTogQklPUyBlZXByb20gaXMgcHJl c2VudA0KYWhjMTogU2Vjb25kYXJ5IEhpZ2ggYnl0ZSB0ZXJtaW5hdGlvbiBF bmFibGVkDQphaGMxOiBTZWNvbmRhcnkgTG93IGJ5dGUgdGVybWluYXRpb24g RW5hYmxlZA0KYWhjMTogUHJpbWFyeSBMb3cgQnl0ZSB0ZXJtaW5hdGlvbiBF bmFibGVkDQphaGMxOiBQcmltYXJ5IEhpZ2ggQnl0ZSB0ZXJtaW5hdGlvbiBF bmFibGVkDQphaGMxOiBhaWM3ODkyIFdpZGUgQ2hhbm5lbCBBLCBTQ1NJIElk PTcsIDMyLzI1NSBTQ0JzDQphaGMxOiBEb3dubG9hZGluZyBTZXF1ZW5jZXIg UHJvZ3JhbS4uLiA0MjggaW5zdHJ1Y3Rpb25zIGRvd25sb2FkZWQNCgl1c2lu ZyBzaGFyZWQgaXJxMTAuDQpleF9pc2FfaWRlbnRpZnkoKQ0KcG5wYmlvczog MTYgZGV2aWNlcywgbGFyZ2VzdCAyMTggYnl0ZXMNClBOUDBjMDE6IGFkZGlu ZyBmaXhlZCBtZW1vcnkzMiByYW5nZSAwLTB4OWZiZmYsIHNpemU9MHg5ZmMw MA0KUE5QMGMwMTogYWRkaW5nIGZpeGVkIG1lbW9yeTMyIHJhbmdlIDB4OWZj MDAtMHg5ZmZmZiwgc2l6ZT0weDQwMA0KUE5QMGMwMTogYWRkaW5nIGZpeGVk IG1lbW9yeTMyIHJhbmdlIDB4ZTAwMDAtMHhmZmZmZiwgc2l6ZT0weDIwMDAw DQpQTlAwYzAxOiBhZGRpbmcgZml4ZWQgbWVtb3J5MzIgcmFuZ2UgMHgxMDAw MDAtMHhmZmZmZmZmLCBzaXplPTB4ZmYwMDAwMA0KUE5QMGMwMTogYWRkaW5n IGZpeGVkIG1lbW9yeTMyIHJhbmdlIDB4ZmVjMDAwMDAtMHhmZWMwMGZmZiwg c2l6ZT0weDEwMDANClBOUDBjMDE6IGFkZGluZyBmaXhlZCBtZW1vcnkzMiBy YW5nZSAweGZlZTAwMDAwLTB4ZmVlMDBmZmYsIHNpemU9MHgxMDAwDQpQTlAw YzAxOiBhZGRpbmcgZml4ZWQgbWVtb3J5MzIgcmFuZ2UgMHhmZmY4MDAwMC0w eGZmZmZmZmZmLCBzaXplPTB4ODAwMDANClBOUDBjMDE6IGVuZCBjb25maWcN CnBucGJpb3M6IGhhbmRsZSAwIGRldmljZSBJRCBQTlAwYzAxICgwMTBjZDA0 MSkNClBOUDAwMDA6IGFkZGluZyBmaXhlZCBpbyByYW5nZSAweDIwLTB4MjEs IHNpemU9MHgyLCBhbGlnbj0weDENClBOUDAwMDA6IGFkZGluZyBmaXhlZCBp byByYW5nZSAweGEwLTB4YTEsIHNpemU9MHgyLCBhbGlnbj0weDENClBOUDAw MDA6IGFkZGluZyBpcnEgbWFzayAweDQNClBOUDAwMDA6IGVuZCBjb25maWcN CnBucGJpb3M6IGhhbmRsZSAxIGRldmljZSBJRCBQTlAwMDAwICgwMDAwZDA0 MSkNClBOUDAyMDA6IGFkZGluZyBkbWEgbWFzayAweDEwDQpQTlAwMjAwOiBh ZGRpbmcgZml4ZWQgaW8gcmFuZ2UgMC0weGYsIHNpemU9MHgxMCwgYWxpZ249 MHgxDQpQTlAwMjAwOiBhZGRpbmcgZml4ZWQgaW8gcmFuZ2UgMHg4MC0weDkw LCBzaXplPTB4MTEsIGFsaWduPTB4MQ0KUE5QMDIwMDogYWRkaW5nIGZpeGVk IGlvIHJhbmdlIDB4OTQtMHg5Ziwgc2l6ZT0weGMsIGFsaWduPTB4MQ0KUE5Q MDIwMDogYWRkaW5nIGZpeGVkIGlvIHJhbmdlIDB4YzAtMHhkZSwgc2l6ZT0w eDFmLCBhbGlnbj0weDENClBOUDAyMDA6IGVuZCBjb25maWcNCnBucGJpb3M6 IGhhbmRsZSAyIGRldmljZSBJRCBQTlAwMjAwICgwMDAyZDA0MSkNClBOUDAx MDA6IGFkZGluZyBpcnEgbWFzayAweDENClBOUDAxMDA6IGFkZGluZyBmaXhl ZCBpbyByYW5nZSAweDQwLTB4NDMsIHNpemU9MHg0LCBhbGlnbj0weDENClBO UDAxMDA6IGVuZCBjb25maWcNCnBucGJpb3M6IGhhbmRsZSAzIGRldmljZSBJ RCBQTlAwMTAwICgwMDAxZDA0MSkNClBOUDBiMDA6IGFkZGluZyBpcnEgbWFz ayAweDEwMA0KUE5QMGIwMDogYWRkaW5nIGZpeGVkIGlvIHJhbmdlIDB4NzAt MHg3MSwgc2l6ZT0weDIsIGFsaWduPTB4MQ0KUE5QMGIwMDogZW5kIGNvbmZp Zw0KcG5wYmlvczogaGFuZGxlIDQgZGV2aWNlIElEIFBOUDBiMDAgKDAwMGJk MDQxKQ0KUE5QMDMwMzogYWRkaW5nIGlycSBtYXNrIDB4Mg0KUE5QMDMwMzog YWRkaW5nIGZpeGVkIGlvIHJhbmdlIDB4NjAtMHg2MCwgc2l6ZT0weDEsIGFs aWduPTB4MQ0KUE5QMDMwMzogYWRkaW5nIGZpeGVkIGlvIHJhbmdlIDB4NjQt MHg2NCwgc2l6ZT0weDEsIGFsaWduPTB4MQ0KUE5QMDMwMzogZW5kIGNvbmZp Zw0KcG5wYmlvczogaGFuZGxlIDUgZGV2aWNlIElEIFBOUDAzMDMgKDAzMDNk MDQxKQ0KUE5QMDgwMDogYWRkaW5nIGZpeGVkIGlvIHJhbmdlIDB4NjEtMHg2 MSwgc2l6ZT0weDEsIGFsaWduPTB4MQ0KUE5QMDgwMDogZW5kIGNvbmZpZw0K cG5wYmlvczogaGFuZGxlIDYgZGV2aWNlIElEIFBOUDA4MDAgKDAwMDhkMDQx KQ0KUE5QMGMwNDogYWRkaW5nIGlycSBtYXNrIDB4MjAwMA0KUE5QMGMwNDog YWRkaW5nIGZpeGVkIGlvIHJhbmdlIDB4ZjAtMHhmZiwgc2l6ZT0weDEwLCBh bGlnbj0weDENClBOUDBjMDQ6IGVuZCBjb25maWcNCnBucGJpb3M6IGhhbmRs ZSA3IGRldmljZSBJRCBQTlAwYzA0ICgwNDBjZDA0MSkNClBOUDBjMDI6IGFk ZGluZyBpbyByYW5nZSAweDRkMC0weDRkMSwgc2l6ZT0weDIsIGFsaWduPTB4 MQ0KUE5QMGMwMjogYWRkaW5nIGlvIHJhbmdlIDB4Y2Y4LTB4Y2ZmLCBzaXpl PTB4OCwgYWxpZ249MHgxDQpQTlAwYzAyOiBhZGRpbmcgaW8gcmFuZ2UgMHgx MC0weDFmLCBzaXplPTB4MTAsIGFsaWduPTB4MQ0KUE5QMGMwMjogYWRkaW5n IGlvIHJhbmdlIDB4NDBiLTB4NDBiLCBzaXplPTB4MSwgYWxpZ249MHgxDQpQ TlAwYzAyOiBhZGRpbmcgaW8gcmFuZ2UgMHg0ZDYtMHg0ZDYsIHNpemU9MHgx LCBhbGlnbj0weDENClBOUDBjMDI6IGFkZGluZyBpbyByYW5nZSAweGMwMC0w eGMwMSwgc2l6ZT0weDIsIGFsaWduPTB4MQ0KUE5QMGMwMjogYWRkaW5nIGlv IHJhbmdlIDB4YzE0LTB4YzE0LCBzaXplPTB4MSwgYWxpZ249MHgxDQpQTlAw YzAyOiBhZGRpbmcgaW8gcmFuZ2UgMHhjNDktMHhjNGEsIHNpemU9MHgyLCBh bGlnbj0weDENClBOUDBjMDI6IGFkZGluZyBpbyByYW5nZSAweGM1Mi0weGM1 Miwgc2l6ZT0weDEsIGFsaWduPTB4MQ0KUE5QMGMwMjogYWRkaW5nIGlvIHJh bmdlIDB4YzZjLTB4YzZjLCBzaXplPTB4MSwgYWxpZ249MHgxDQpQTlAwYzAy OiBhZGRpbmcgaW8gcmFuZ2UgMHhjNmYtMHhjNmYsIHNpemU9MHgxLCBhbGln bj0weDENClBOUDBjMDI6IGFkZGluZyBpbyByYW5nZSAweGNkNi0weGNkNywg c2l6ZT0weDIsIGFsaWduPTB4MQ0KUE5QMGMwMjogYWRkaW5nIGlvIHJhbmdl IDB4ZjUwLTB4ZjU3LCBzaXplPTB4OCwgYWxpZ249MHgxDQpQTlAwYzAyOiBh ZGRpbmcgZml4ZWQgbWVtb3J5MzIgcmFuZ2UgMHhjZWUwMC0weGQ3ZmZmLCBz aXplPTB4OTIwMA0KUE5QMGMwMjogc2tpcHBpbmcgZW1wdHkgcmFuZ2UNClBO UDBjMDI6IHNraXBwaW5nIGVtcHR5IHJhbmdlDQpQTlAwYzAyOiBza2lwcGlu ZyBlbXB0eSByYW5nZQ0KUE5QMGMwMjogc2tpcHBpbmcgZW1wdHkgcmFuZ2UN ClBOUDBjMDI6IHNraXBwaW5nIGVtcHR5IHJhbmdlDQpQTlAwYzAyOiBza2lw cGluZyBlbXB0eSByYW5nZQ0KUE5QMGMwMjogc2tpcHBpbmcgZW1wdHkgcmFu Z2UNClBOUDBjMDI6IGVuZCBjb25maWcNCnBucGJpb3M6IGhhbmRsZSA4IGRl dmljZSBJRCBQTlAwYzAyICgwMjBjZDA0MSkNClBOUDBjMDI6IGFkZGluZyBp byByYW5nZSAweDJlLTB4MmUsIHNpemU9MHgxLCBhbGlnbj0weDENClBOUDBj MDI6IGFkZGluZyBpbyByYW5nZSAweDJmLTB4MmYsIHNpemU9MHgxLCBhbGln bj0weDENClBOUDBjMDI6IGFkZGluZyBpbyByYW5nZSAweDU4MC0weDU4Ziwg c2l6ZT0weDEwLCBhbGlnbj0weDENClBOUDBjMDI6IGFkZGluZyBpbyByYW5n ZSAweDUzMC0weDUzMSwgc2l6ZT0weDIsIGFsaWduPTB4MQ0KUE5QMGMwMjog YWRkaW5nIGlvIHJhbmdlIDB4NTQwLTB4NTVmLCBzaXplPTB4MjAsIGFsaWdu PTB4MQ0KUE5QMGMwMjogYWRkaW5nIGlvIHJhbmdlIDB4NTAwLTB4NTFmLCBz aXplPTB4MjAsIGFsaWduPTB4MQ0KUE5QMGMwMjogYWRkaW5nIGlvIHJhbmdl IDB4Yzk4LTB4Yzk4LCBzaXplPTB4MSwgYWxpZ249MHgxDQpQTlAwYzAyOiBl bmQgY29uZmlnDQpwbnBiaW9zOiBoYW5kbGUgOSBkZXZpY2UgSUQgUE5QMGMw MiAoMDIwY2QwNDEpDQpQTlAwNTAxOiBhZGRpbmcgaW8gcmFuZ2UgMHgzZjgt MHgzZmYsIHNpemU9MHg4LCBhbGlnbj0weDgNClBOUDA1MDE6IGFkZGluZyBp cnEgbWFzayAweDEwDQpQTlAwNTAxOiBlbmQgY29uZmlnDQpwbnBiaW9zOiBo YW5kbGUgMTAgZGV2aWNlIElEIFBOUDA1MDEgKDAxMDVkMDQxKQ0KUE5QMDUw MTogYWRkaW5nIGlvIHJhbmdlIDB4MmY4LTB4MmZmLCBzaXplPTB4OCwgYWxp Z249MHg4DQpQTlAwNTAxOiBhZGRpbmcgaXJxIG1hc2sgMHg4DQpQTlAwNTAx OiBlbmQgY29uZmlnDQpwbnBiaW9zOiBoYW5kbGUgMTEgZGV2aWNlIElEIFBO UDA1MDEgKDAxMDVkMDQxKQ0KUE5QMDQwMTogYWRkaW5nIGlvIHJhbmdlIDB4 Mzc4LTB4MzdiLCBzaXplPTB4NCwgYWxpZ249MHg4DQpQTlAwNDAxOiBhZGRp bmcgaW8gcmFuZ2UgMHg3NzgtMHg3N2EsIHNpemU9MHgzLCBhbGlnbj0weDgN ClBOUDA0MDE6IGFkZGluZyBpcnEgbWFzayAweDgwDQpQTlAwNDAxOiBhZGRp bmcgZG1hIG1hc2sgMHg4DQpQTlAwNDAxOiBlbmQgY29uZmlnDQpwbnBiaW9z OiBoYW5kbGUgMTIgZGV2aWNlIElEIFBOUDA0MDEgKDAxMDRkMDQxKQ0KUE5Q MDcwMDogYWRkaW5nIGlvIHJhbmdlIDB4M2YwLTB4M2Y1LCBzaXplPTB4Niwg YWxpZ249MHgxDQpQTlAwNzAwOiBhZGRpbmcgaXJxIG1hc2sgMHg0MA0KUE5Q MDcwMDogYWRkaW5nIGRtYSBtYXNrIDB4NA0KUE5QMDcwMDogZW5kIGNvbmZp Zw0KcG5wYmlvczogaGFuZGxlIDEzIGRldmljZSBJRCBQTlAwNzAwICgwMDA3 ZDA0MSkNClBOUDBmMTM6IGFkZGluZyBpcnEgbWFzayAweDEwMDANClBOUDBm MTM6IGVuZCBjb25maWcNCnBucGJpb3M6IGhhbmRsZSAxNCBkZXZpY2UgSUQg UE5QMGYxMyAoMTMwZmQwNDEpDQpQTlAwYTAzOiBlbmQgY29uZmlnDQpwbnBi aW9zOiBoYW5kbGUgMTUgZGV2aWNlIElEIFBOUDBhMDMgKDAzMGFkMDQxKQ0K YXRhLTogYXRhMCBleGlzdHMsIHVzaW5nIG5leHQgYXZhaWxhYmxlIHVuaXQg bnVtYmVyDQphdGEtOiBhdGExIGV4aXN0cywgdXNpbmcgbmV4dCBhdmFpbGFi bGUgdW5pdCBudW1iZXINClRyeWluZyBSZWFkX1BvcnQgYXQgMjAzDQpUcnlp bmcgUmVhZF9Qb3J0IGF0IDI0Mw0KVHJ5aW5nIFJlYWRfUG9ydCBhdCAyODMN ClRyeWluZyBSZWFkX1BvcnQgYXQgMmMzDQpUcnlpbmcgUmVhZF9Qb3J0IGF0 IDMwMw0KVHJ5aW5nIFJlYWRfUG9ydCBhdCAzNDMNClRyeWluZyBSZWFkX1Bv cnQgYXQgMzgzDQpUcnlpbmcgUmVhZF9Qb3J0IGF0IDNjMw0Kc2MtOiBzYzAg ZXhpc3RzLCB1c2luZyBuZXh0IGF2YWlsYWJsZSB1bml0IG51bWJlcg0Kdmdh LTogdmdhMCBleGlzdHMsIHVzaW5nIG5leHQgYXZhaWxhYmxlIHVuaXQgbnVt YmVyDQppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGluZyBQblAgZGV2aWNl cw0KaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2aWNl cw0KZmUwIGZhaWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4MzAwIG9uIGlzYTAN CmFkdjAgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgzMzAgb24gaXNhMA0K YWhhMDogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZg0KYWhhMDogc3RhdHVz IHJlZyB0ZXN0IGZhaWxlZCBmZg0KYWhhMDogc3RhdHVzIHJlZyB0ZXN0IGZh aWxlZCBmZg0KYWhhMDogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZg0KYWhh MDogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZg0KYWhhMDogc3RhdHVzIHJl ZyB0ZXN0IGZhaWxlZCBmZg0KYWhhMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9y dCAweDEzNC0weDEzNyBvbiBpc2EwDQphaWMwIGZhaWxlZCB0byBwcm9iZSBh dCBwb3J0IDB4MTQwLTB4MTVmIG9uIGlzYTANCmF0YTI6IGlvYmFzZT0weDAx ZjAgYWx0aW9iYXNlPTB4MDNmNiBibWFkZHI9MHgwMDAwDQphdGEyOiBtYXNr PTAwIHN0YXR1czA9ZmYgc3RhdHVzMT1mZg0KYXRhMjogcHJvYmUgYWxsb2Nh dGlvbiBmYWlsZWQNCmF0YTIgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQgMHgx ZjAtMHgxZjcsMHgzZjYgaXJxIDE0IG9uIGlzYTANCmF0YTM6IGlvYmFzZT0w eDAxNzAgYWx0aW9iYXNlPTB4MDM3NiBibWFkZHI9MHgwMDAwDQphdGEzOiBt YXNrPTAwIHN0YXR1czA9ZmYgc3RhdHVzMT1mZg0KYXRhMzogcHJvYmUgYWxs b2NhdGlvbiBmYWlsZWQNCmF0YTMgZmFpbGVkIHRvIHByb2JlIGF0IHBvcnQg MHgxNzAtMHgxNzcsMHgzNzYgaXJxIDE1IG9uIGlzYTANCmF0a2JkYzA6IDxL ZXlib2FyZCBjb250cm9sbGVyIChpODA0Mik+IGF0IHBvcnQgMHg2MCwweDY0 IG9uIGlzYTANCmF0a2JkMDogPEFUIEtleWJvYXJkPiBmbGFncyAweDEgaXJx IDEgb24gYXRrYmRjMA0KYXRrYmQ6IHRoZSBjdXJyZW50IGtiZCBjb250cm9s bGVyIGNvbW1hbmQgYnl0ZSAwMDY1DQphdGtiZDoga2V5Ym9hcmQgSUQgMHg0 MWFiICgyKQ0Ka2JkYzogUkVTRVRfS0JEIHJldHVybiBjb2RlOjAwZmENCmti ZGM6IFJFU0VUX0tCRCBzdGF0dXM6MDBhYQ0Ka2JkMCBhdCBhdGtiZDANCmti ZDA6IGF0a2JkMCwgQVQgMTAxLzEwMiAoMiksIGNvbmZpZzoweDEsIGZsYWdz OjB4M2QwMDAwDQpwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTowMDY1DQpr YmRjOiBURVNUX0FVWF9QT1JUIHN0YXR1czowMDAwDQprYmRjOiBSRVNFVF9B VVggcmV0dXJuIGNvZGU6MDBmYQ0Ka2JkYzogUkVTRVRfQVVYIHN0YXR1czow MGFhDQprYmRjOiBSRVNFVF9BVVggSUQ6MDAwMA0KcHNtOiBzdGF0dXMgMDAg MDIgNjQNCnBzbTogc3RhdHVzIDkwIDAzIDNjDQpwc206IHN0YXR1cyA5MCAw MyAzYw0KcHNtOiBzdGF0dXMgOTAgMDMgM2MNCnBzbTogZGF0YSAwOCAwMCAw MA0KcHNtOiBzdGF0dXMgMDAgMDAgM2MNCnBzbTogc3RhdHVzIDAwIDAyIDY0 DQpwc206IGRhdGEgMDggMDAgMDANCnBzbTogc3RhdHVzIDAwIDAyIDY0DQpw c20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzANCnBzbTA6IG1v ZGVsIEdlbmVyaWMgUFMvMiBtb3VzZSwgZGV2aWNlIElEIDAtMDAsIDMgYnV0 dG9ucw0KcHNtMDogY29uZmlnOjAwMDAwMDAwLCBmbGFnczowMDAwMDAwMCwg cGFja2V0IHNpemU6Mw0KcHNtMDogc3luY21hc2s6YzAsIHN5bmNiaXRzOjAw DQpidDA6IEZhaWxlZCBTdGF0dXMgUmVnIFRlc3QgLSBmZg0KYnRfaXNhX3By b2JlOiBQcm9iZSBmYWlsZWQgYXQgMHgzMzANCmJ0MDogRmFpbGVkIFN0YXR1 cyBSZWcgVGVzdCAtIGZmDQpidF9pc2FfcHJvYmU6IFByb2JlIGZhaWxlZCBh dCAweDMzNA0KYnQwOiBGYWlsZWQgU3RhdHVzIFJlZyBUZXN0IC0gZmYNCmJ0 X2lzYV9wcm9iZTogUHJvYmUgZmFpbGVkIGF0IDB4MjMwDQpidDA6IEZhaWxl ZCBTdGF0dXMgUmVnIFRlc3QgLSBmZg0KYnRfaXNhX3Byb2JlOiBQcm9iZSBm YWlsZWQgYXQgMHgyMzQNCmJ0MDogRmFpbGVkIFN0YXR1cyBSZWcgVGVzdCAt IGZmDQpidF9pc2FfcHJvYmU6IFByb2JlIGZhaWxlZCBhdCAweDEzMA0KYnQw OiBGYWlsZWQgU3RhdHVzIFJlZyBUZXN0IC0gZmYNCmJ0X2lzYV9wcm9iZTog UHJvYmUgZmFpbGVkIGF0IDB4MTM0DQpidDAgZmFpbGVkIHRvIHByb2JlIGF0 IHBvcnQgMHgxMzQtMHgxMzcgb24gaXNhMA0KY3MwIGZhaWxlZCB0byBwcm9i ZSBhdCBwb3J0IDB4MzAwLTB4MzFmIG9uIGlzYTANCmVkMCBmYWlsZWQgdG8g cHJvYmUgYXQgcG9ydCAweDI4MC0weDI5ZiBpb21lbSAweGQ4MDAwIGlycSAx MCBvbiBpc2EwDQpmZGMwOiA8TkVDIDcyMDY1QiBvciBjbG9uZT4gYXQgcG9y dCAweDNmMC0weDNmNSwweDNmNyBpcnEgNiBkcnEgMiBvbiBpc2EwDQpmZGMw OiBGSUZPIGVuYWJsZWQsIDggYnl0ZXMgdGhyZXNob2xkDQpmZDA6IDwxNDQw LUtCIDMuNSIgZHJpdmU+IG9uIGZkYzAgZHJpdmUgMA0KaWUwIGZhaWxlZCB0 byBwcm9iZSBhdCBwb3J0IDB4MzAwIGlvbWVtIDB4ZDAwMDAgaXJxIDEwIG9u IGlzYTANCmxlMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDMwMCBpb21l bSAweGQwMDAwIGlycSA1IG9uIGlzYTANCmxuYzAgZmFpbGVkIHRvIHByb2Jl IGF0IHBvcnQgMHgyODAgaXJxIDEwIGRycSAwIG9uIGlzYTANCnBjaWMwIGZh aWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2UwIGlvbWVtIDB4ZDAwMDAgb24g aXNhMA0KcGNpYzE6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0KcHBjMDogcGFy YWxsZWwgcG9ydCBmb3VuZCBhdCAweDM3OA0KcHBjMDogdXNpbmcgZXh0ZW5k ZWQgSS9PIHBvcnQgcmFuZ2UNCnBwYzA6IEVDUCBTUFAgU1BQDQpwcGMwOiA8 UGFyYWxsZWwgcG9ydD4gYXQgcG9ydCAweDM3OC0weDM3ZiBpcnEgNyBvbiBp c2EwDQpwcGMwOiBHZW5lcmljIGNoaXBzZXQgKEVDUC9QUzIvTklCQkxFKSBp biBDT01QQVRJQkxFIG1vZGUNCnBwYzA6IEZJRk8gd2l0aCAxNi8xNi84IGJ5 dGVzIHRocmVzaG9sZA0KcGxpcDA6IDxQTElQIG5ldHdvcmsgaW50ZXJmYWNl PiBvbiBwcGJ1czANCmJwZjogbHAwIGF0dGFjaGVkDQpscHQwOiA8UHJpbnRl cj4gb24gcHBidXMwDQpscHQwOiBJbnRlcnJ1cHQtZHJpdmVuIHBvcnQNCnBw aTA6IDxQYXJhbGxlbCBJL08+IG9uIHBwYnVzMA0Kc2MwOiA8U3lzdGVtIGNv bnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTANCnNjMDogVkdBIDwxNiB2 aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4NCnNjMDogZmIwLCBrYmQw LCB0ZXJtaW5hbCBlbXVsYXRvcjogc2MgKHN5c2NvbnMgdGVybWluYWwpDQpz aW8wOiBpcnEgbWFwczogMHg0MSAweDUxIDB4NDEgMHg0MQ0Kc2lvMCBhdCBw b3J0IDB4M2Y4LTB4M2ZmIGlycSA0IGZsYWdzIDB4MTAgb24gaXNhMA0Kc2lv MDogdHlwZSAxNjU1MEENCnNpbzE6IGlycSBtYXBzOiAweDQxIDB4NDkgMHg0 MSAweDQxDQpzaW8xIGF0IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMgb24gaXNh MA0Kc2lvMTogdHlwZSAxNjU1MEENCnNpbzI6IG5vdCBwcm9iZWQgKGRpc2Fi bGVkKQ0Kc2lvMzogbm90IHByb2JlZCAoZGlzYWJsZWQpDQpzbjAgZmFpbGVk IHRvIHByb2JlIGF0IHBvcnQgMHgzMDAtMHgzMGYgaXJxIDEwIG9uIGlzYTAN CnZnYTA6IDxHZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYg aW9tZW0gMHhhMDAwMC0weGJmZmZmIG9uIGlzYTANCmZiMDogdmdhMCwgdmdh LCB0eXBlOlZHQSAoNSksIGZsYWdzOjB4NzAwN2YNCmZiMDogcG9ydDoweDNj MC0weDNkZiwgY3J0YzoweDNkNCwgbWVtOjB4YTAwMDAgMHgyMDAwMA0KZmIw OiBpbml0IG1vZGU6MjQsIGJpb3MgbW9kZTozLCBjdXJyZW50IG1vZGU6MjQN CmZiMDogd2luZG93OjB4YzAwYjgwMDAgc2l6ZTozMmsgZ3JhbjozMmssIGJ1 ZjowIHNpemU6MzJrDQpWR0EgcGFyYW1ldGVycyB1cG9uIHBvd2VyLXVwDQo1 MCAxOCAxMCAwMCAwMCAwMCAwMyAwMCAwMiA2NyA1ZiA0ZiA1MCA4MiA1NSA4 MSANCmJmIDFmIDAwIDRmIDBkIDBlIDAwIDAwIDA3IDgwIDljIDhlIDhmIDI4 IDFmIDk2IA0KYjkgYTMgZmYgMDAgMDEgMDIgMDMgMDQgMDUgMTQgMDcgMzgg MzkgM2EgM2IgM2MgDQozZCAzZSAzZiAwYyAwMCAwZiAwOCAwMCAwMCAwMCAw MCAwMCAxMCAwZSAwMCBmZiANClZHQSBwYXJhbWV0ZXJzIGluIEJJT1MgZm9y IG1vZGUgMjQNCjUwIDE4IDEwIDAwIDEwIDAwIDAzIDAwIDAyIDY3IDVmIDRm IDUwIDgyIDU1IDgxIA0KYmYgMWYgMDAgNGYgMGQgMGUgMDAgMDAgMDAgMDAg OWMgOGUgOGYgMjggMWYgOTYgDQpiOSBhMyBmZiAwMCAwMSAwMiAwMyAwNCAw NSAxNCAwNyAzOCAzOSAzYSAzYiAzYyANCjNkIDNlIDNmIDBjIDAwIDBmIDA4 IDAwIDAwIDAwIDAwIDAwIDEwIDBlIDAwIGZmIA0KRUdBL1ZHQSBwYXJhbWV0 ZXJzIHRvIGJlIHVzZWQgZm9yIG1vZGUgMjQNCjUwIDE4IDEwIDAwIDEwIDAw IDAzIDAwIDAyIDY3IDVmIDRmIDUwIDgyIDU1IDgxIA0KYmYgMWYgMDAgNGYg MGQgMGUgMDAgMDAgMDAgMDAgOWMgOGUgOGYgMjggMWYgOTYgDQpiOSBhMyBm ZiAwMCAwMSAwMiAwMyAwNCAwNSAxNCAwNyAzOCAzOSAzYSAzYiAzYyANCjNk IDNlIDNmIDBjIDAwIDBmIDA4IDAwIDAwIDAwIDAwIDAwIDEwIDBlIDAwIGZm IA0KdnQwIGZhaWxlZCB0byBwcm9iZSBvbiBpc2EwDQpzYzE6IG5vIHZpZGVv IGFkYXB0ZXIgaXMgZm91bmQuDQpzYzE6IDxTeXN0ZW0gY29uc29sZT4gZmFp bGVkIHRvIHByb2JlIG9uIGlzYTANCnZnYTE6IDxHZW5lcmljIElTQSBWR0E+ IGZhaWxlZCB0byBwcm9iZSBvbiBpc2EwDQppc2FfcHJvYmVfY2hpbGRyZW46 IHByb2JpbmcgUG5QIGRldmljZXMNCmFkdjE6IEludmFsaWQgYmFzZXBvcnQg b2YgMHgyMCBzcGVjaWZpZWQuIE5lYXJlc3QgdmFsaWQgYmFzZXBvcnQgaXMg MHgxMDAuICBGYWlsaW5nIHByb2JlLg0KdW5rbm93bjogPFBOUDAyMDA+IGNh bid0IGFzc2lnbiByZXNvdXJjZXMNCnVua25vd246IDxQTlAwMjAwPiBhdCBw b3J0IDAtMHhmIG9uIGlzYTANCmFkdjE6IEludmFsaWQgYmFzZXBvcnQgb2Yg MHg0MCBzcGVjaWZpZWQuIE5lYXJlc3QgdmFsaWQgYmFzZXBvcnQgaXMgMHgx MDAuICBGYWlsaW5nIHByb2JlLg0KYWR2MTogSW52YWxpZCBiYXNlcG9ydCBv ZiAweDcwIHNwZWNpZmllZC4gTmVhcmVzdCB2YWxpZCBiYXNlcG9ydCBpcyAw eDEwMC4gIEZhaWxpbmcgcHJvYmUuDQp1bmtub3duOiA8UE5QMDMwMz4gY2Fu J3QgYXNzaWduIHJlc291cmNlcw0KdW5rbm93bjogPFBOUDAzMDM+IGF0IHBv cnQgMHg2MCBvbiBpc2EwDQphZHYxOiBJbnZhbGlkIGJhc2Vwb3J0IG9mIDB4 NjEgc3BlY2lmaWVkLiBOZWFyZXN0IHZhbGlkIGJhc2Vwb3J0IGlzIDB4MTAw LiAgRmFpbGluZyBwcm9iZS4NCnVua25vd246IDxQTlAwODAwPiBmYWlsZWQg dG8gcHJvYmUgYXQgcG9ydCAweDYxIG9uIGlzYTANCmFkdjE6IEludmFsaWQg YmFzZXBvcnQgb2YgMHhmMCBzcGVjaWZpZWQuIE5lYXJlc3QgdmFsaWQgYmFz ZXBvcnQgaXMgMHgxMDAuICBGYWlsaW5nIHByb2JlLg0KYWR2MTogSW52YWxp ZCBiYXNlcG9ydCBvZiAweDRkMCBzcGVjaWZpZWQuIE5lYXJlc3QgdmFsaWQg YmFzZXBvcnQgaXMgMHgzMzAuICBGYWlsaW5nIHByb2JlLg0KYWR2MTogSW52 YWxpZCBiYXNlcG9ydCBvZiAweDJlIHNwZWNpZmllZC4gTmVhcmVzdCB2YWxp ZCBiYXNlcG9ydCBpcyAweDEwMC4gIEZhaWxpbmcgcHJvYmUuDQp1bmtub3du OiA8UE5QMDUwMT4gY2FuJ3QgYXNzaWduIHJlc291cmNlcw0KdW5rbm93bjog PFBOUDA1MDE+IGF0IHBvcnQgMHgzZjgtMHgzZmYgb24gaXNhMA0KdW5rbm93 bjogPFBOUDA1MDE+IGNhbid0IGFzc2lnbiByZXNvdXJjZXMNCnVua25vd246 IDxQTlAwNTAxPiBhdCBwb3J0IDB4MmY4LTB4MmZmIG9uIGlzYTANCnVua25v d246IDxQTlAwNDAxPiBjYW4ndCBhc3NpZ24gcmVzb3VyY2VzDQp1bmtub3du OiA8UE5QMDQwMT4gYXQgcG9ydCAweDM3OC0weDM3YiBvbiBpc2EwDQp1bmtu b3duOiA8UE5QMDcwMD4gY2FuJ3QgYXNzaWduIHJlc291cmNlcw0KdW5rbm93 bjogPFBOUDA3MDA+IGF0IHBvcnQgMHgzZjAtMHgzZjUgb24gaXNhMA0KdW5r bm93bjogPFBOUDBmMTM+IGNhbid0IGFzc2lnbiByZXNvdXJjZXMNCnVua25v d246IDxQTlAwZjEzPiBhdCBpcnEgMTIgb24gaXNhMA0KQklPUyBHZW9tZXRy aWVzOg0KIDA6MDNmZWZlM2YgMC4uMTAyMj0xMDIzIGN5bGluZGVycywgMC4u MjU0PTI1NSBoZWFkcywgMS4uNjM9NjMgc2VjdG9ycw0KIDE6MDNmZWZlM2Yg MC4uMTAyMj0xMDIzIGN5bGluZGVycywgMC4uMjU0PTI1NSBoZWFkcywgMS4u NjM9NjMgc2VjdG9ycw0KIDAgYWNjb3VudGVkIGZvcg0KRGV2aWNlIGNvbmZp Z3VyYXRpb24gZmluaXNoZWQuDQpicGY6IHBwcDAgYXR0YWNoZWQNCm5ldyBt YXNrczogYmlvIDY4MDQ0MCwgdHR5IDYzMTA5YSwgbmV0IDY3MTI5YQ0KYnBm OiBmYWl0aDAgYXR0YWNoZWQNCmJwZjogZ2lmMCBhdHRhY2hlZA0KYnBmOiBn aWYxIGF0dGFjaGVkDQpicGY6IGdpZjIgYXR0YWNoZWQNCmJwZjogZ2lmMyBh dHRhY2hlZA0KYnBmOiBsbzAgYXR0YWNoZWQNCldhaXRpbmcgMTUgc2Vjb25k cyBmb3IgU0NTSSBkZXZpY2VzIHRvIHNldHRsZQ0KKG5vcGVyaXBoOmFoYzA6 MDotMTotMSk6IFNDU0kgYnVzIHJlc2V0IGRlbGl2ZXJlZC4gMCBTQ0JzIGFi b3J0ZWQuDQoobm9wZXJpcGg6YWhjMTowOi0xOi0xKTogU0NTSSBidXMgcmVz ZXQgZGVsaXZlcmVkLiAwIFNDQnMgYWJvcnRlZC4NCmFoYzA6IHRhcmdldCA4 IHVzaW5nIDE2Yml0IHRyYW5zZmVycw0KYWhjMDogdGFyZ2V0IDggc3luY2hy b25vdXMgYXQgNDAuME1Ieiwgb2Zmc2V0ID0gMHgxZg0KYWhjMDogdGFyZ2V0 IDYgdXNpbmcgMTZiaXQgdHJhbnNmZXJzDQphaGMwOiB0YXJnZXQgNiBzeW5j aHJvbm91cyBhdCA0MC4wTUh6LCBvZmZzZXQgPSAweDFlDQoocHJvYmUxODph aGMxOjA6MzowKTogSU5RVUlSWS4gQ0RCOiAxMiAxIDgwIDAgZmYgMCANCihw cm9iZTE4OmFoYzE6MDozOjApOiBJTExFR0FMIFJFUVVFU1QgYXNjOjI0LDAN Cihwcm9iZTE4OmFoYzE6MDozOjApOiBJbnZhbGlkIGZpZWxkIGluIENEQg0K YWhjMTogdGFyZ2V0IDMgc3luY2hyb25vdXMgYXQgMjAuME1Ieiwgb2Zmc2V0 ID0gMHhmDQpDcmVhdGluZyBESVNLIGNkMA0KQ3JlYXRpbmcgRElTSyBkYTAN CkNyZWF0aW5nIERJU0sgZGExDQpwYXNzMCBhdCBhaGMwIGJ1cyAwIHRhcmdl dCA2IGx1biAwDQpwYXNzMDogPElCTSBETkVTLTMwOTE3MFcgU0FIMD4gRml4 ZWQgRGlyZWN0IEFjY2VzcyBTQ1NJLTMgZGV2aWNlIA0KcGFzczA6IFNlcmlh bCBOdW1iZXIgICAgICAgICBBSkxIMzM4Nw0KcGFzczA6IDgwLjAwME1CL3Mg dHJhbnNmZXJzICg0MC4wMDBNSHosIG9mZnNldCAzMCwgMTZiaXQpDQpwYXNz MSBhdCBhaGMwIGJ1cyAwIHRhcmdldCA4IGx1biAwDQpwYXNzMTogPCAgPiBG aXhlZCBEaXJlY3QgQWNjZXNzIFNDU0ktMiBkZXZpY2UgDQpwYXNzMTogU2Vy aWFsIE51bWJlciAxOTQ4MDk2MzA3OTcNCnBhc3MxOiA4MC4wMDBNQi9zIHRy YW5zZmVycyAoNDAuMDAwTUh6LCBvZmZzZXQgMzEsIDE2Yml0KQ0KcGFzczIg YXQgYWhjMSBidXMgMCB0YXJnZXQgMyBsdW4gMA0KcGFzczI6IDxQTEVYVE9S IENELVJPTSBQWC00MFRTIDEuMTE+IFJlbW92YWJsZSBDRC1ST00gU0NTSS0y IGRldmljZSANCnBhc3MyOiAyMC4wMDBNQi9zIHRyYW5zZmVycyAoMjAuMDAw TUh6LCBvZmZzZXQgMTUpDQpkYTEgYXQgYWhjMCBidXMgMCB0YXJnZXQgOCBs dW4gMA0KZGExOiA8ICA+IEZpeGVkIERpcmVjdCBBY2Nlc3MgU0NTSS0yIGRl dmljZSANCmRhMTogU2VyaWFsIE51bWJlciAxOTQ4MDk2MzA3OTcNCmRhMTog ODAuMDAwTUIvcyB0cmFuc2ZlcnMgKDQwLjAwME1Ieiwgb2Zmc2V0IDMxLCAx NmJpdCkNCmRhMTogMzA3ODQwTUIgKDYzMDQ1NjMyMCA1MTIgYnl0ZSBzZWN0 b3JzOiAyNTVIIDYzUy9UIDM5MjQ0QykNCk1vdW50aW5nIHJvb3QgZnJvbSB1 ZnM6L2Rldi9kYTBzMWENCihjZDA6YWhjMTowOjM6MCk6IFJFQUQgQ0QgUkVD T1JERUQgQ0FQQUNJVFkuIENEQjogMjUgMCAwIDAgMCAwIDAgMCAwIDAgDQoo Y2QwOmFoYzE6MDozOjApOiBOT1QgUkVBRFkgYXNjOjNhLDENCihjZDA6YWhj MTowOjM6MCk6IE1lZGl1bSBub3QgcHJlc2VudCAtIHRyYXkgY2xvc2VkDQpj ZDAgYXQgYWhjMSBidXMgMCB0YXJnZXQgMyBsdW4gMA0KY2QwOiA8UExFWFRP UiBDRC1ST00gUFgtNDBUUyAxLjExPiBSZW1vdmFibGUgQ0QtUk9NIFNDU0kt MiBkZXZpY2UgDQpjZDA6IDIwLjAwME1CL3MgdHJhbnNmZXJzICgyMC4wMDBN SHosIG9mZnNldCAxNSkNCmNkMDogQXR0ZW1wdCB0byBxdWVyeSBkZXZpY2Ug c2l6ZSBmYWlsZWQ6IE5PVCBSRUFEWSwgTWVkaXVtIG5vdCBwcmVzZW50IC0g dHJheSBjbG9zZWQNCmRhMCBhdCBhaGMwIGJ1cyAwIHRhcmdldCA2IGx1biAw DQpkYTA6IDxJQk0gRE5FUy0zMDkxNzBXIFNBSDA+IEZpeGVkIERpcmVjdCBB Y2Nlc3MgU0NTSS0zIGRldmljZSANCmRhMDogU2VyaWFsIE51bWJlciAgICAg ICAgIEFKTEgzMzg3DQpkYTA6IDgwLjAwME1CL3MgdHJhbnNmZXJzICg0MC4w MDBNSHosIG9mZnNldCAzMCwgMTZiaXQpDQpkYTA6IDg3NDhNQiAoMTc5MTYy NDAgNTEyIGJ5dGUgc2VjdG9yczogMjU1SCA2M1MvVCAxMTE1QykNCmRhMHMx OiB0eXBlIDB4YTUsIHN0YXJ0IDYzLCBlbmQgPSAxNzkxMjQ3NCwgc2l6ZSAx NzkxMjQxMiA6IE9LDQpzdGFydF9pbml0OiB0cnlpbmcgL3NiaW4vaW5pdA0K YWhjMDogdGFyZ2V0IDggdXNpbmcgYXN5bmNocm9ub3VzIHRyYW5zZmVycw0K YWhjMDogdGFyZ2V0IDggc3luY2hyb25vdXMgYXQgNDAuME1Ieiwgb2Zmc2V0 ID0gMHgxZg0K --0-401528494-970183315=:90309-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 28 16:25:18 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 6501937B422; Thu, 28 Sep 2000 16:25:16 -0700 (PDT) Received: from caspian.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id RAA48031; Thu, 28 Sep 2000 17:25:11 -0600 (MDT) (envelope-from gibbs@plutotech.com) Message-Id: <200009282325.RAA48031@pluto.plutotech.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Brandon D. Valentine" Cc: scsi@freebsd.org, gibbs@freebsd.org Subject: Re: More ahc woes. In-Reply-To: Your message of "Thu, 28 Sep 2000 18:57:37 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 28 Sep 2000 17:26:32 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >I'm really sorry to have to come to you with another bug report, Justin, >I know you're probably sick of hearing from me by now. That machine >with the Supermicro 370DL3 is broken under 4.1.1-RELEASE and the drivers >you committed just before the release. The install disks panic on boot >with the following: > >ahc0: port 0xe400-0xe4ff mem >0xfebfe000-0xfebfefff irq 15 at device 1.0 on pci1 The Supermicro 370DL3 will *not* work if you have options AHC_ALLOW_MEMIO. I've been working with Dan Eischen on this problem, but we don't have a solution yet. If you aren't using this option, I'm not sure what the problem is with your system since Dan's seems to run okay. > >Fatal trap 12: page fault while in kernel mode >fault virtual address = 0x1c >fault code = supervisor read, page not present >instruction pointer = 0x8:0xc02b5fe4 I need to know what this address corresponds to in your kernel. nm panicing.kernel | sort will show you what function is at fault. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 28 17:18:23 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from turtle.looksharp.net (cc360882-a.strhg1.mi.home.com [24.2.221.22]) by hub.freebsd.org (Postfix) with ESMTP id 0C16837B424; Thu, 28 Sep 2000 17:17:13 -0700 (PDT) Received: from localhost (bandix@localhost) by turtle.looksharp.net (8.9.3/8.9.3) with ESMTP id UAA92180; Thu, 28 Sep 2000 20:18:04 -0400 (EDT) (envelope-from bandix@looksharp.net) Date: Thu, 28 Sep 2000 20:18:04 -0400 (EDT) From: "Brandon D. Valentine" To: "Justin T. Gibbs" Cc: scsi@freebsd.org, gibbs@freebsd.org Subject: Re: More ahc woes. In-Reply-To: <200009282325.RAA48031@pluto.plutotech.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 28 Sep 2000, Justin T. Gibbs wrote: >The Supermicro 370DL3 will *not* work if you have options AHC_ALLOW_MEMIO. >I've been working with Dan Eischen on this problem, but we don't have >a solution yet. If you aren't using this option, I'm not sure what >the problem is with your system since Dan's seems to run okay. Hmm, I'm not sure what's up either then. This kernel is the BOOTMFS kernel that is on the 4.1.1 install floppy. I do not believe AHC_ALLOW_MEMIO is in this kernel as it is not in GENERIC presently. >> >>Fatal trap 12: page fault while in kernel mode >>fault virtual address = 0x1c >>fault code = supervisor read, page not present >>instruction pointer = 0x8:0xc02b5fe4 > >I need to know what this address corresponds to in your kernel. > >nm panicing.kernel | sort > >will show you what function is at fault. I pulled the kernel off of the install disk but it's been stripped. nm didn't do me much good. nm -D will return dynamic symbols but none of them correspond to any of the addresses returned in the panic message. My next thought is to build a kernel on a 4.1 system and copy it over to the working current partition and boot it and write down the symbol addresses. So I'll be able to track down which function it is panicing in because I won't strip the kernel. Anything else you can think of while I'm working on this? Brandon D. Valentine -- bandix at looksharp.net | bandix at structbio.vanderbilt.edu "Truth suffers from too much analysis." -- Ancient Fremen Saying To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Thu Sep 28 21:33:29 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from dreaming.darkspire.org (dreaming.darkspire.org [12.2.86.250]) by hub.freebsd.org (Postfix) with ESMTP id 1EFC937B422 for ; Thu, 28 Sep 2000 21:33:24 -0700 (PDT) Received: from localhost (oneiros@localhost) by dreaming.darkspire.org (8.9.3/8.9.3) with ESMTP id EAA53430 for ; Thu, 29 Sep 1994 04:40:15 GMT (envelope-from oneiros@dreaming.darkspire.org) Date: Thu, 29 Sep 1994 04:40:15 +0000 (GMT) From: oneiros To: freebsd-scsi@freebsd.org Subject: 4.1.1 and adaptec 29160N Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greetings, I've run in to a bit of a problem, and i thought this might be the place to get some guidence. My scsi disk, which ran well in 4.1-STABLE, will not boot after i cvsup'ed to 4.1.1-STABLE, error: Root mount failed: 22 (then asks for the ufs mount, which i supply and given the same reply) when trying to boot from the 4.1.1-RELEASE CD, it gives the following panic while initializing da0: panic: going nowehre with my init. as i said, neither the config not the hardware has changed since the last kernel. any suggestions? kernel config has ahc, da and scbus uncommented. any suggestions? thanks muchly, -justin da0: Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C) ahc0: port 0xb400-0xb4ff mem 0xe0000000-0xe0000fff irq 11 at device 10.0 on pci0 ahc0: aic7892 Wide Channel A, SCSI Id=7, 16/255 SCBs To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 29 7:48:42 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from akademie3000.de (akademie3000.de [194.121.70.49]) by hub.freebsd.org (Postfix) with ESMTP id 82D4737B43C; Fri, 29 Sep 2000 07:48:33 -0700 (PDT) Received: from schlappy.mobile.tld ([12.128.176.177]) by akademie3000.de (8.9.2/8.9.2) with ESMTP id QAA01042; Fri, 29 Sep 2000 16:48:15 +0200 (CEST) Received: (from andre@localhost) by schlappy.mobile.tld (8.11.0/8.11.0) id e8TESkw00722; Fri, 29 Sep 2000 16:28:46 +0200 (CEST) (envelope-from andre) Date: Fri, 29 Sep 2000 16:28:46 +0200 From: Andre Albsmeier To: Greg Lehey Cc: Marc Tardif , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: ccd with other filesystems Message-ID: <20000929162846.A698@schlappy.mobile.tld> References: <20000923133806.B78943@wantadilla.lemis.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20000923133806.B78943@wantadilla.lemis.com>; from grog@lemis.com on Sat, Sep 23, 2000 at 01:38:06PM +0930 X-Echelon: BND CIA NSA Mossad KGB MI6 IRA detonator nuclear assault strike Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 23-Sep-2000 at 13:38:06 +0930, Greg Lehey wrote: > > ... > > > I ask because I'm not sure how the word "partition" is used > > in the manpage, is it suppose to mean a slice (as in DOS > > partition) or the partition of a slice? Also, I'm intrigued > > by the following passage: > > Note that the `raw' partitions of the disks should not be > > combined. > > I really don't understand what this is supposed to mean. Could this mean that you should not use the 'c' partitions as ccd components? I, for example, use the 'a' partitions which start at sector 16... -Andre To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 29 10:13:56 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from kenny.mintel.co.uk (kenny.mintel.co.uk [212.134.144.82]) by hub.freebsd.org (Postfix) with ESMTP id 0267237B423 for ; Fri, 29 Sep 2000 10:13:47 -0700 (PDT) Received: from mintel.co.uk ([10.0.0.233]) by kenny.mintel.co.uk (8.9.3/8.9.3) with ESMTP id SAA74707; Fri, 29 Sep 2000 18:05:54 +0100 (BST) (envelope-from jason.thomson@mintel.co.uk) Message-ID: <39D4CEC0.98ED6B8F@mintel.co.uk> Date: Fri, 29 Sep 2000 18:17:52 +0100 From: Jason Thomson X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-scsi@freebsd.org Cc: mjabali@mintel.com Subject: Adaptec 7890 & new IBM DRHS-36D doesn't probe. Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We're using a Dell Poweredge 4300 with FreeBSD 3.1, and we've just added a 36GB IBM disk. Not strictly a FreeBSD question, perhaps, but this disk doesn't probe right. When the da driver tries to attach, we get the following error: (da3:ahc0:0:3:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 (da3:ahc0:0:3:0): NOT READY asc:4,2 (da3:ahc0:0:3:0): Logical unit not ready, initializing cmd. required (da3:ahc0:0:3:0): fatal error, failed to attach to device (da3:ahc0:0:3:0): lost device (da3:ahc0:0:3:0): removing device entry More dmesg: ahc0: rev 0x00 int a irq 10 on pci2.4.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x03 int a irq 10 on pci2.6.0 ahc1: aic7860 Single Channel A, SCSI Id=7, 3/255 SCBs da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 80.0MB/s transfers (40.0MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 17366MB (35566499 512 byte sectors: 255H 63S/T 2213C) da2 at ahc0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-3 device da2: 80.0MB/s transfers (40.0MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 34732MB (71133000 512 byte sectors: 255H 63S/T 4427C) cd0 at ahc1 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.0MB/s transfers (20.0MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 80.0MB/s transfers (40.0MHz, offset 31, 16bit) da1: 17375MB (35586001 512 byte sectors: 255H 63S/T 2215C) (da3:ahc0:0:3:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 I'm not sure what's happening, the following is the output from camcontrol. camcontrol devlist -v scbus-1 on xpt0 bus 0: < > at scbus-1 target -1 lun -1 (xpt0) scbus0 on ahc0 bus 0: at scbus0 target 0 lun 0 (pass0,da0) at scbus0 target 1 lun 0 (pass1,da1) at scbus0 target 2 lun 0 (pass2,da2) at scbus0 target 3 lun 0 (pass3) at scbus0 target 6 lun 0 (pass4) < > at scbus0 target -1 lun -1 () scbus1 on ahc1 bus 0: at scbus1 target 5 lun 0 (pass5,cd0) < > at scbus1 target -1 lun -1 () We've been on to Dell technical support, and the answer we got was a vague "reset the SCSI-BIOS to factory defaults - it's probably set up to probe the disk as a tape drive". I'm no SCSI expert, but that sounded weak to me. (We tried it anyway, and it didn't work :-). The BIOS probe identifies the disk as IBM DRSH. (The other disk in the machine identified as IBM DRHS36D). They are *supposed* to be the same model - that's what it says on the disks. I don't think it's just a bum disk, because we accidentally ordered two new disks (in addition to the one already in the machine) of the same type - tried them both - same result. We've also tried other slots in the backplane (different IDs). The jumpers are set on the disk for "Auto-Start" and "Disable Target Initiated Sync Negitiation". Can anyone help to shed some light? Thanks... Please CC me on any replies, and also my colleague (mjabali@mintel.com) - it's Friday and I'm off down the pub - but he's in the States and has another few hours on this yet :-). I'll be back in tomorrow :-(. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 29 10:29:13 2000 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 AD47F37B42C for ; Fri, 29 Sep 2000 10:29:09 -0700 (PDT) Received: (from ken@localhost) by panzer.kdm.org (8.9.3/8.9.1) id LAA89425; Fri, 29 Sep 2000 11:29:05 -0600 (MDT) (envelope-from ken) Date: Fri, 29 Sep 2000 11:29:04 -0600 From: "Kenneth D. Merry" To: Jason Thomson Cc: freebsd-scsi@FreeBSD.ORG, mjabali@mintel.com Subject: Re: Adaptec 7890 & new IBM DRHS-36D doesn't probe. Message-ID: <20000929112904.A89357@panzer.kdm.org> References: <39D4CEC0.98ED6B8F@mintel.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <39D4CEC0.98ED6B8F@mintel.co.uk>; from jason.thomson@mintel.co.uk on Fri, Sep 29, 2000 at 06:17:52PM +0100 Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 29, 2000 at 18:17:52 +0100, Jason Thomson wrote: > We're using a Dell Poweredge 4300 with FreeBSD 3.1, and we've just > added a 36GB IBM disk. > > Not strictly a FreeBSD question, perhaps, but this disk doesn't probe > right. When the da driver tries to attach, we get the following error: > > (da3:ahc0:0:3:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 > (da3:ahc0:0:3:0): NOT READY asc:4,2 > (da3:ahc0:0:3:0): Logical unit not ready, initializing cmd. required > (da3:ahc0:0:3:0): fatal error, failed to attach to device > (da3:ahc0:0:3:0): lost device > (da3:ahc0:0:3:0): removing device entry The disk isn't spinning up. When the error recovery code sees that particular error, it tries to spin up the disk. That probably isn't happening in this case. One way to test this out is: camcontrol tur -n pass -u 3 -v (you should get the same error as above) camcontrol start -n pass -u 3 -v (the disk should spin up, and shouldn't return an error if things are working properly) camcontrol tur -n pass -u 3 -v (If camcontrol start didn't return an error, this likely won't either. If camcontrol start returned an error, this will probably return the same error as the first tur attempt above.) [ ... ] > I'm not sure what's happening, the following is the output from > camcontrol. > > camcontrol devlist -v > scbus-1 on xpt0 bus 0: > < > at scbus-1 target -1 lun -1 (xpt0) > scbus0 on ahc0 bus 0: > at scbus0 target 0 lun 0 (pass0,da0) > at scbus0 target 1 lun 0 (pass1,da1) > at scbus0 target 2 lun 0 (pass2,da2) > at scbus0 target 3 lun 0 (pass3) > at scbus0 target 6 lun 0 (pass4) > < > at scbus0 target -1 lun -1 () > scbus1 on ahc1 bus 0: > at scbus1 target 5 lun 0 (pass5,cd0) > < > at scbus1 target -1 lun -1 () > > > > We've been on to Dell technical support, and the answer we got was a > vague "reset the SCSI-BIOS to factory defaults - it's probably set up to > probe the disk as a tape drive". I'm no SCSI expert, but that sounded > weak to me. (We tried it anyway, and it didn't work :-). > > The BIOS probe identifies the disk as IBM DRSH. (The other disk in the > machine identified as IBM DRHS36D). They are *supposed* to be the same > model - that's what it says on the disks. Some disks read firmware revisions or model numbers off the disk, I think. That's probably what is going on here -- you aren't getting the full inquiry information because the disk isn't spun up. > I don't think it's just a bum disk, because we accidentally ordered two > new disks (in addition to the one already in the machine) of the same > type - tried them both - same result. We've also tried other slots in > the backplane (different IDs). The jumpers are set on the disk for > "Auto-Start" and "Disable Target Initiated Sync Negitiation". Well, if it isn't starting, and you've got auto-start enabled, and the error recovery code can't start it, I would suspect bad 12V power. You've evidently got 5V power, since the disk can respond to basic commands, but it may be that you don't have 12V, since it can't spin up. > Please CC me on any replies, and also my colleague (mjabali@mintel.com) > - it's Friday and I'm off down the pub - but he's in the States and has > another few hours on this yet :-). I'll be back in tomorrow :-(. 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 Fri Sep 29 11:57:44 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from pluto.plutotech.com (mail.plutotech.com [206.168.67.137]) by hub.freebsd.org (Postfix) with ESMTP id 6B8F637B422 for ; Fri, 29 Sep 2000 11:57:36 -0700 (PDT) Received: from caspian.plutotech.com (root@mail.plutotech.com [206.168.67.137]) by pluto.plutotech.com (8.9.2/8.9.1) with ESMTP id MAA70366; Fri, 29 Sep 2000 12:57:31 -0600 (MDT) (envelope-from gibbs@plutotech.com) Message-Id: <200009291857.MAA70366@pluto.plutotech.com> To: oneiros Cc: scsi@FreeBSD.org Subject: Re: 4.1.1 and adaptec 29160N Date: Fri, 29 Sep 2000 12:58:53 -0600 From: "Justin T. Gibbs" Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > when trying to boot from the 4.1.1-RELEASE CD, it gives the following > panic while initializing da0: > > panic: going nowehre with my init. Hmm. I don't know why init cannot be found on the CDROM. I'm in the process of installing 4.1.1R from boot floppies, on a machine with both an aic7892 and a 29160 and it seems to boot okay. -- Justin To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 29 12:25:12 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from post.mail.nl.demon.net (post-10.mail.nl.demon.net [194.159.73.20]) by hub.freebsd.org (Postfix) with ESMTP id D76EC37B646 for ; Fri, 29 Sep 2000 12:25:06 -0700 (PDT) Received: from [212.238.54.101] (helo=freebie.demon.nl) by post.mail.nl.demon.net with smtp (Exim 3.14 #2) id 13f5mL-0002hL-00; Fri, 29 Sep 2000 19:25:05 +0000 Received: (from wkb@localhost) by freebie.demon.nl (8.11.0/8.11.0) id e8TJQnI02442; Fri, 29 Sep 2000 21:26:49 +0200 (CEST) (envelope-from wkb) Date: Fri, 29 Sep 2000 21:26:49 +0200 From: Wilko Bulte To: "Justin T. Gibbs" Cc: oneiros , scsi@freebsd.org Subject: Re: 4.1.1 and adaptec 29160N Message-ID: <20000929212648.A2428@freebie.demon.nl> References: <200009291857.MAA70366@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i In-Reply-To: <200009291857.MAA70366@pluto.plutotech.com>; from gibbs@plutotech.com on Fri, Sep 29, 2000 at 12:58:53PM -0600 X-OS: FreeBSD 4.1-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Sep 29, 2000 at 12:58:53PM -0600, Justin T. Gibbs wrote: > > when trying to boot from the 4.1.1-RELEASE CD, it gives the following > > panic while initializing da0: > > > > panic: going nowehre with my init. > > Hmm. I don't know why init cannot be found on the CDROM. This is an infamous problem, also seen on alpha. See the mailinglist archives. There has never been a final verdict (that I know of). > I'm in the process of installing 4.1.1R from boot floppies, on a > machine with both an aic7892 and a 29160 and it seems to boot okay. -- Wilko Bulte wilko@freebsd.org Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Fri Sep 29 12:59: 2 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id B4EC337B48A for ; Fri, 29 Sep 2000 12:58:59 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e8TK0FA06146; Fri, 29 Sep 2000 13:00:16 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200009292000.e8TK0FA06146@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: "Justin T. Gibbs" Cc: oneiros , scsi@FreeBSD.org Subject: Re: 4.1.1 and adaptec 29160N In-reply-to: Your message of "Fri, 29 Sep 2000 12:58:53 MDT." <200009291857.MAA70366@pluto.plutotech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 29 Sep 2000 13:00:15 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > when trying to boot from the 4.1.1-RELEASE CD, it gives the following > > panic while initializing da0: > > > > panic: going nowehre with my init. > > Hmm. I don't know why init cannot be found on the CDROM. > > I'm in the process of installing 4.1.1R from boot floppies, on a > machine with both an aic7892 and a 29160 and it seems to boot okay. This typically happens when sysinstall exits unexpectedly. There are a large number of err() calls in libdisk which will do this. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Sep 30 19: 9:43 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by hub.freebsd.org (Postfix) with SMTP id 9E67337B66C for ; Sat, 30 Sep 2000 19:09:38 -0700 (PDT) Received: (qmail 84647 invoked by uid 1000); 1 Oct 2000 02:09:37 -0000 Date: Sun, 1 Oct 2000 04:09:37 +0200 From: "Karsten W. Rohrbach" To: Andre Albsmeier Cc: Greg Lehey , Marc Tardif , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: ccd with other filesystems Message-ID: <20001001040937.E83678@rohrbach.de> Reply-To: karsten@rohrbach.de References: <20000923133806.B78943@wantadilla.lemis.com> <20000929162846.A698@schlappy.mobile.tld> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000929162846.A698@schlappy.mobile.tld>; from andre@akademie3000.de on Fri, Sep 29, 2000 at 04:28:46PM +0200 X-Arbitrary-Number-Of-The-Day: 42 X-Sender: karsten@rohrbach.de Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org the 'a' partition is reserved for the rootfs, as 'b' is for swap and 'c' for the whole device. you should use 'e' and p for payload (eg. mounted filesystems) i dont quite know why it is still possible doing a newfs on a 'c' partition, since the partition type is 'unused' and not '4.2BSD'. newfs should check this and throw an error while providing an expert-only-feature command line option to explicitly override it. it is a bad thing[tm] to be able to wedge every single blockdev in your system by (ab)using newfs. /k Andre Albsmeier(andre@akademie3000.de)@Fri, Sep 29, 2000 at 04:28:46PM +0200: > On Sat, 23-Sep-2000 at 13:38:06 +0930, Greg Lehey wrote: > > > > ... > > > > > I ask because I'm not sure how the word "partition" is used > > > in the manpage, is it suppose to mean a slice (as in DOS > > > partition) or the partition of a slice? Also, I'm intrigued > > > by the following passage: > > > Note that the `raw' partitions of the disks should not be > > > combined. > > > > I really don't understand what this is supposed to mean. > > Could this mean that you should not use the 'c' partitions as ccd > components? I, for example, use the 'a' partitions which start at > sector 16... > > -Andre > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-fs" in the body of the message -- > What can you use used tampons for? Tea bags for vampires. KR433/KR11-RIPE -- http://www.webmonster.de -- ftp://ftp.webmonster.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Sep 30 19:16:19 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 3C41137B503; Sat, 30 Sep 2000 19:16:11 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e912Fe844311; Sun, 1 Oct 2000 11:45:40 +0930 (CST) (envelope-from grog) Date: Sun, 1 Oct 2000 11:45:40 +0930 From: Greg Lehey To: "Karsten W. Rohrbach" Cc: Andre Albsmeier , Marc Tardif , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: ccd with other filesystems Message-ID: <20001001114540.G43885@wantadilla.lemis.com> References: <20000923133806.B78943@wantadilla.lemis.com> <20000929162846.A698@schlappy.mobile.tld> <20001001040937.E83678@rohrbach.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20001001040937.E83678@rohrbach.de>; from karsten@rohrbach.de on Sun, Oct 01, 2000 at 04:09:37AM +0200 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 1 October 2000 at 4:09:37 +0200, Karsten W. Rohrbach wrote: > Andre Albsmeier(andre@akademie3000.de)@Fri, Sep 29, 2000 at 04:28:46PM +0200: >> On Sat, 23-Sep-2000 at 13:38:06 +0930, Greg Lehey wrote: >>> >>> ... >>> >>>> I ask because I'm not sure how the word "partition" is used >>>> in the manpage, is it suppose to mean a slice (as in DOS >>>> partition) or the partition of a slice? Also, I'm intrigued >>>> by the following passage: >>>> Note that the `raw' partitions of the disks should not be >>>> combined. >>> >>> I really don't understand what this is supposed to mean. >> >> Could this mean that you should not use the 'c' partitions as ccd >> components? I, for example, use the 'a' partitions which start at >> sector 16... > > the 'a' partition is reserved for the rootfs, as 'b' is for swap and > 'c' for the whole device. you should use 'e' and p for payload > (eg. mounted filesystems) None of the partitions is special except for 'c'. By convention we put root file systems on 'a' and swap on 'b', but nothing relies on this convention. > i dont quite know why it is still possible doing a newfs on a 'c' > partition, since the partition type is 'unused' and not > '4.2BSD'. newfs should check this and throw an error while providing > an expert-only-feature command line option to explicitly override > it. I think this is a bug in newfs. It should only create file systems on partitions of type 4.2BSD. Does anybody disagree? Otherwise I'll fix it. > it is a bad thing[tm] to be able to wedge every single blockdev in your > system by (ab)using newfs. Agreed. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Sep 30 19:28:32 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp05.primenet.com (smtp05.primenet.com [206.165.6.135]) by hub.freebsd.org (Postfix) with ESMTP id 3E71C37B503; Sat, 30 Sep 2000 19:28:26 -0700 (PDT) Received: (from daemon@localhost) by smtp05.primenet.com (8.9.3/8.9.3) id TAA20661; Sat, 30 Sep 2000 19:28:46 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp05.primenet.com, id smtpdAAADAa4vO; Sat Sep 30 19:28:37 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA18618; Sat, 30 Sep 2000 19:28:14 -0700 (MST) From: Terry Lambert Message-Id: <200010010228.TAA18618@usr05.primenet.com> Subject: Re: ccd with other filesystems To: grog@lemis.com (Greg Lehey) Date: Sun, 1 Oct 2000 02:28:09 +0000 (GMT) Cc: karsten@rohrbach.de (Karsten W. Rohrbach), andre@akademie3000.de (Andre Albsmeier), intmktg@CAM.ORG (Marc Tardif), freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <20001001114540.G43885@wantadilla.lemis.com> from "Greg Lehey" at Oct 01, 2000 11:45:40 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greg Writes: > None of the partitions is special except for 'c'. By convention we > put root file systems on 'a' and swap on 'b', but nothing relies on > this convention. The kernel and other files loaded by the loader myst be below the 1024 cylinder boundary on the disk, since the FrrBSD boot loader, unlike Linux's LILO, can not read past cylinder 1024, since it does not understand how to make LBA BIOS calls properly. If you have a FreeBSD straddling the 8G boundary on a large drive, therefore, you will want to ensure that whatever partition you place "/" on is entirely below the 8G limit. You're right that this is no necessarily "a", but in general, the installation tools will order allocations as a,b,..., which makes it "a" in common practice. The same applies to a FreeBSD-only system, with a very large drive, even if it's "dangerously dedicated". > > i dont quite know why it is still possible doing a newfs on a 'c' > > partition, since the partition type is 'unused' and not > > '4.2BSD'. newfs should check this and throw an error while providing > > an expert-only-feature command line option to explicitly override > > it. > > I think this is a bug in newfs. It should only create file systems on > partitions of type 4.2BSD. Does anybody disagree? Otherwise I'll fix > it. I have several systems, where the entirety of the disk (the "c" partition) is mounted as a single file system. So long as this is done right, such that I can tell it that the "c" partition is of type "4.2BSD", and so long as the sysinstall and other tools do the right thing, it doesn't matter to me if you fix it. But... > > it is a bad thing[tm] to be able to wedge every single blockdev in your > > system by (ab)using newfs. > > Agreed. This appears to be a problem with not checking the label for overlap, since a mounted FS should not be spam'able under any circumstances. Protecting people from spam'ming unmounted FSs by pounding on "c" might be a laudable goal, but provides only a tiny amount of additional protection. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Sep 30 19:35:32 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 9B7F737B502; Sat, 30 Sep 2000 19:35:21 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e912YrT49033; Sun, 1 Oct 2000 12:04:53 +0930 (CST) (envelope-from grog) Date: Sun, 1 Oct 2000 12:04:53 +0930 From: Greg Lehey To: Terry Lambert Cc: "Karsten W. Rohrbach" , Andre Albsmeier , Marc Tardif , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: ccd with other filesystems Message-ID: <20001001120453.I43885@wantadilla.lemis.com> References: <20001001114540.G43885@wantadilla.lemis.com> <200010010228.TAA18618@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200010010228.TAA18618@usr05.primenet.com>; from tlambert@primenet.com on Sun, Oct 01, 2000 at 02:28:09AM +0000 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 1 October 2000 at 2:28:09 +0000, Terry Lambert wrote: > Greg Writes: >> None of the partitions is special except for 'c'. By convention we >> put root file systems on 'a' and swap on 'b', but nothing relies on >> this convention. > > The kernel and other files loaded by the loader myst be below > the 1024 cylinder boundary on the disk, since the FrrBSD boot > loader, unlike Linux's LILO, can not read past cylinder 1024, > since it does not understand how to make LBA BIOS calls > properly. This is no longer the case. The restriction was lifted a few months back. >>> i dont quite know why it is still possible doing a newfs on a 'c' >>> partition, since the partition type is 'unused' and not >>> '4.2BSD'. newfs should check this and throw an error while providing >>> an expert-only-feature command line option to explicitly override >>> it. >> >> I think this is a bug in newfs. It should only create file systems on >> partitions of type 4.2BSD. Does anybody disagree? Otherwise I'll fix >> it. > > I have several systems, where the entirety of the disk (the "c" > partition) is mounted as a single file system. You can do it, but it's not a good idea. I'd like to see a good reason for doing this. > So long as this is done right, such that I can tell it that the "c" > partition is of type "4.2BSD", and so long as the sysinstall and > other tools do the right thing, it doesn't matter to me if you fix > it. There is no way to do this right. >>> it is a bad thing[tm] to be able to wedge every single blockdev in your >>> system by (ab)using newfs. >> >> Agreed. > > This appears to be a problem with not checking the label for > overlap, since a mounted FS should not be spam'able under any > circumstances. Protecting people from spam'ming unmounted FSs by > pounding on "c" might be a laudable goal, but provides only a tiny > amount of additional protection. This is a separate issue. Yes, disklabel should warn about a number of things, including overlapping partitions and incorrect partition types (c should be "unused", because by definition it overlaps all other partitions). Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Sep 30 19:49: 5 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from smtp03.primenet.com (smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (Postfix) with ESMTP id 0024037B502; Sat, 30 Sep 2000 19:48:59 -0700 (PDT) Received: (from daemon@localhost) by smtp03.primenet.com (8.9.3/8.9.3) id TAA20726; Sat, 30 Sep 2000 19:47:31 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp03.primenet.com, id smtpdAAA2qayEO; Sat Sep 30 19:47:27 2000 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id TAA19148; Sat, 30 Sep 2000 19:48:53 -0700 (MST) From: Terry Lambert Message-Id: <200010010248.TAA19148@usr05.primenet.com> Subject: Re: ccd with other filesystems To: grog@lemis.com (Greg Lehey) Date: Sun, 1 Oct 2000 02:48:53 +0000 (GMT) Cc: tlambert@primenet.com (Terry Lambert), karsten@rohrbach.de (Karsten W. Rohrbach), andre@akademie3000.de (Andre Albsmeier), intmktg@CAM.ORG (Marc Tardif), freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG In-Reply-To: <20001001120453.I43885@wantadilla.lemis.com> from "Greg Lehey" at Oct 01, 2000 12:04:53 PM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > The kernel and other files loaded by the loader myst be below > > the 1024 cylinder boundary on the disk, since the FrrBSD boot > > loader, unlike Linux's LILO, can not read past cylinder 1024, > > since it does not understand how to make LBA BIOS calls > > properly. > > This is no longer the case. The restriction was lifted a few months > back. Someone should tell my Sony Vaio, which hated having 4.1 installed on it past 8G on an 18G drive. > > I have several systems, where the entirety of the disk (the "c" > > partition) is mounted as a single file system. > > You can do it, but it's not a good idea. I'd like to see a good > reason for doing this. If "c" is defined to be "the whole disk" , and you want to use "the whole disk", it makes sense. I uses to mount most of my CDROMs that way, as well. > > This appears to be a problem with not checking the label for > > overlap, since a mounted FS should not be spam'able under any > > circumstances. Protecting people from spam'ming unmounted FSs by > > pounding on "c" might be a laudable goal, but provides only a tiny > > amount of additional protection. > > This is a separate issue. Yes, disklabel should warn about a number > of things, including overlapping partitions and incorrect partition > types (c should be "unused", because by definition it overlaps all > other partitions). I really _don't_ want the use of "c" broken ("fixed"). The "c" partition is not "defined" to overlap; it merely does so by default and by istorical convention. I threw away this convention on many of my systems long ago, when I resigned myself to aving a DOS parititon table on my machines, when the Alpha and PReP platforms decided to require it as well. I have eight or ten disks that have non-overlapping "c" values that place their regions between "b" and "d" regions on the disk. If that's not enough, the best argument I have for three of those is "so that I can have one more partition that I would otherwise be permitted to have". Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Sep 30 20:41:59 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from wantadilla.lemis.com (wantadilla.lemis.com [192.109.197.80]) by hub.freebsd.org (Postfix) with ESMTP id 4AA3237B502; Sat, 30 Sep 2000 20:41:52 -0700 (PDT) Received: (from grog@localhost) by wantadilla.lemis.com (8.11.0/8.9.3) id e913fQi80746; Sun, 1 Oct 2000 13:11:26 +0930 (CST) (envelope-from grog) Date: Sun, 1 Oct 2000 13:11:26 +0930 From: Greg Lehey To: Terry Lambert Cc: "Karsten W. Rohrbach" , Andre Albsmeier , Marc Tardif , freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Partitioning (was: ccd with other filesystems) Message-ID: <20001001131126.L43885@wantadilla.lemis.com> References: <20001001120453.I43885@wantadilla.lemis.com> <200010010248.TAA19148@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200010010248.TAA19148@usr05.primenet.com>; from tlambert@primenet.com on Sun, Oct 01, 2000 at 02:48:53AM +0000 Organization: LEMIS, PO Box 460, Echunga SA 5153, Australia Phone: +61-8-8388-8286 Fax: +61-8-8388-8725 Mobile: +61-418-838-708 WWW-Home-Page: http://www.lemis.com/~grog X-PGP-Fingerprint: 6B 7B C3 8C 61 CD 54 AF 13 24 52 F8 6D A4 95 EF Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sunday, 1 October 2000 at 2:48:53 +0000, Terry Lambert wrote: >>> The kernel and other files loaded by the loader myst be below >>> the 1024 cylinder boundary on the disk, since the FrrBSD boot >>> loader, unlike Linux's LILO, can not read past cylinder 1024, >>> since it does not understand how to make LBA BIOS calls >>> properly. >> >> This is no longer the case. The restriction was lifted a few months >> back. > > Someone should tell my Sony Vaio, which hated having 4.1 installed > on it past 8G on an 18G drive. > >>> I have several systems, where the entirety of the disk (the "c" >>> partition) is mounted as a single file system. >> >> You can do it, but it's not a good idea. I'd like to see a good >> reason for doing this. > > If "c" is defined to be "the whole disk" , and you want to use "the > whole disk", it makes sense. No, you don't *ever* want a UFS on the whole disk, you want it on a partition, because those are the objects on which file systems work. The partition may well cover the entire disk, but that doesn't give it the same semantics as an unused partition which covers it. > I uses to mount most of my CDROMs that way, as well. That's OK. CD-ROMs don't have partitions. It's probably a bug that we even have partition letters for non-partitioned media. >>> This appears to be a problem with not checking the label for >>> overlap, since a mounted FS should not be spam'able under any >>> circumstances. Protecting people from spam'ming unmounted FSs by >>> pounding on "c" might be a laudable goal, but provides only a tiny >>> amount of additional protection. >> >> This is a separate issue. Yes, disklabel should warn about a number >> of things, including overlapping partitions and incorrect partition >> types (c should be "unused", because by definition it overlaps all >> other partitions). > > I really _don't_ want the use of "c" broken ("fixed"). > > The "c" partition is not "defined" to overlap; it merely does so by > default and by istorical convention. Agreed. But there were good reasons for this. > I threw away this convention on many of my systems long ago, when I > resigned myself to aving a DOS parititon table on my machines, when > the Alpha and PReP platforms decided to require it as well. Is your 'h' key sticking? :-) I strongly object to the Microsoft "partition" table, and I don't use it myself. And of course you're welcome to use whatever you find convenient. It's not until you advocate making this a standard way that anybody can have any objection. Greg -- Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message From owner-freebsd-scsi Sat Sep 30 21: 4:39 2000 Delivered-To: freebsd-scsi@freebsd.org Received: from mass.osd.bsdi.com (adsl-63-202-176-106.dsl.snfc21.pacbell.net [63.202.176.106]) by hub.freebsd.org (Postfix) with ESMTP id 157FE37B503 for ; Sat, 30 Sep 2000 21:04:37 -0700 (PDT) Received: from mass.osd.bsdi.com (localhost [127.0.0.1]) by mass.osd.bsdi.com (8.11.0/8.9.3) with ESMTP id e913vDh00964; Sat, 30 Sep 2000 20:57:13 -0700 (PDT) (envelope-from msmith@mass.osd.bsdi.com) Message-Id: <200010010357.e913vDh00964@mass.osd.bsdi.com> X-Mailer: exmh version 2.1.1 10/15/1999 To: Terry Lambert Cc: freebsd-fs@FreeBSD.ORG, freebsd-scsi@FreeBSD.ORG Subject: Re: ccd with other filesystems In-reply-to: Your message of "Sun, 01 Oct 2000 02:28:09 -0000." <200010010228.TAA18618@usr05.primenet.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sat, 30 Sep 2000 20:57:13 -0700 From: Mike Smith Sender: owner-freebsd-scsi@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Greg Writes: > > None of the partitions is special except for 'c'. By convention we > > put root file systems on 'a' and swap on 'b', but nothing relies on > > this convention. > > The kernel and other files loaded by the loader myst be below > the 1024 cylinder boundary on the disk, since the FrrBSD boot > loader, unlike Linux's LILO, can not read past cylinder 1024, > since it does not understand how to make LBA BIOS calls > properly. This is manifestly untrue. John Baldwin will now hit you with the Damn Thing. > I have several systems, where the entirety of the disk (the "c" > partition) is mounted as a single file system. So long as this > is done right, such that I can tell it that the "c" partition is > of type "4.2BSD", and so long as the sysinstall and other tools > do the right thing, it doesn't matter to me if you fix it. But... Nothing (much) checks the partition type. I'm not entirely sure this is a bad thing (manifest constants are evil). -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message