From owner-freebsd-alpha Sun Mar 24 6:55:39 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 20ABF37B41A for ; Sun, 24 Mar 2002 06:55:37 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2OEtKp1061230 for ; Sun, 24 Mar 2002 15:55:21 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: alpha@freebsd.org Subject: Please test GEOM in -current... From: Poul-Henning Kamp Date: Sun, 24 Mar 2002 15:55:20 +0100 Message-ID: <61229.1016981720@critter.freebsd.dk> Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I belive that alpha BSD disklabels are now correctly handled in GEOM and would therefore appreciate if somebody could enable the GEOM option in a current kernel and tell me if I am right or not. Further more, if somebody could try to swap disks between an alpha and an i386 and tell me if the both recognize the "alien" disklabels when GEOM is enabled, that would be doubly nice. In fact, for ultimate h0h0 effect, you can try to stick a disk from a solaris machine into your alpha: it should recognize the partitioning on that as well. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Mar 25 6:53:52 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from 12-234-96-171.client.attbi.com (12-234-96-171.client.attbi.com [12.234.96.171]) by hub.freebsd.org (Postfix) with ESMTP id 3D53137B405 for ; Mon, 25 Mar 2002 06:53:50 -0800 (PST) Received: by 12-234-96-171.client.attbi.com (Postfix, from userid 1000) id 2AA755E79; Thu, 25 Apr 2002 06:53:41 -0700 (PDT) Date: Wed, 24 Apr 2002 18:20:41 -0700 From: Jon Mini To: freebsd-alpha@freebsd.org Subject: Please test loader changes for alpha Message-ID: <20020424182041.B26720@stylus.haikugeek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The patch referenced below upgrades our version of ficl in the loader. Unfortunately, it touches some of the alpha stuff, too, and I don't have an alpha to test on. Could someone pease compile and boot from a -current system with this patch applied: http://www.haikugeek.com/freebsd/boot-ficl302.diff If the system boots, it works. -- Jonathan Mini mini@haikugeek.com Yersterday, I was ashamed of myself. Today, I am just hungry. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Mar 25 8: 0:33 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 7E69E37B416 for ; Mon, 25 Mar 2002 08:00:25 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.6/8.11.6) with UUCP id g2PG0Jo85424; Mon, 25 Mar 2002 17:00:19 +0100 (CET) (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.1.10]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g2PFto6e083437; Mon, 25 Mar 2002 16:55:51 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (localhost [127.0.0.1]) by cicely8.cicely.de (8.12.2/8.12.2) with ESMTP id g2PFtonU014437; Mon, 25 Mar 2002 16:55:50 +0100 (CET) (envelope-from ticso@cicely8.cicely.de) Received: (from ticso@localhost) by cicely8.cicely.de (8.12.2/8.12.2/Submit) id g2PFtoCK014436; Mon, 25 Mar 2002 16:55:50 +0100 (CET) Date: Mon, 25 Mar 2002 16:54:24 +0100 From: Bernd Walter To: Jon Mini Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Please test loader changes for alpha Message-ID: <20020325155424.GB14060@cicely8.cicely.de> References: <20020424182041.B26720@stylus.haikugeek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020424182041.B26720@stylus.haikugeek.com> User-Agent: Mutt/1.3.26i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Apr 24, 2002 at 06:20:41PM -0700, Jon Mini wrote: > The patch referenced below upgrades our version of ficl in the loader. > Unfortunately, it touches some of the alpha stuff, too, and I don't > have an alpha to test on. Could someone pease compile and boot from > a -current system with this patch applied: > > http://www.haikugeek.com/freebsd/boot-ficl302.diff > > If the system boots, it works. My NoName (-current from 23th Mar) is still booting with this patch. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Mar 25 13:25:12 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from rahl.dorm.duke.edu (rahl.dorm.duke.edu [152.16.249.139]) by hub.freebsd.org (Postfix) with ESMTP id B993337B420 for ; Mon, 25 Mar 2002 13:24:39 -0800 (PST) Received: (from scott@localhost) by rahl.dorm.duke.edu (8.11.6/8.11.6) id g2PLOiw39838 for freebsd-alpha@freebsd.org; Mon, 25 Mar 2002 16:24:44 -0500 (EST) (envelope-from scott) Message-Id: <200203252124.g2PLOiw39838@rahl.dorm.duke.edu> Content-Type: text/plain; charset="iso-8859-1" From: Scott Sipe To: freebsd-alpha@freebsd.org Date: Mon, 25 Mar 2002 16:24:44 -0500 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Subject: Alpha Build Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org note: I already posted this to CURRENT, but then discovered Alpha. Sorry for double posting! Hi, I have a chance to pick up an Alpha machine which I would use for FreeBSD testing. There are 4 AlphaStation 600's from which I could pick, 2 of them have 'TGA graphics cards', 2 have "normal" graphics cards and "can run X."  Seeing as right now I know next to nothing about Alpha's, would it be better to pick one or the other, or, would one or the other be better for freeBSD testing? thanks much, Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Mar 25 13:46: 4 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 036EF37B400 for ; Mon, 25 Mar 2002 13:46:01 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g2PLjvG00803; Mon, 25 Mar 2002 22:45:57 +0100 (CET) (envelope-from wkb) Date: Mon, 25 Mar 2002 22:45:57 +0100 From: Wilko Bulte To: Scott Sipe Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Alpha Build Message-ID: <20020325224557.A776@freebie.xs4all.nl> References: <200203252124.g2PLOiw39838@rahl.dorm.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <200203252124.g2PLOiw39838@rahl.dorm.duke.edu>; from cscotts@mindspring.com on Mon, Mar 25, 2002 at 04:24:44PM -0500 X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Mar 25, 2002 at 04:24:44PM -0500, Scott Sipe wrote: > There are 4 AlphaStation 600's from which I could pick, 2 of them have 'TGA > graphics cards', 2 have "normal" graphics cards and "can run X."  Seeing as > right now I know next to nothing about Alpha's, would it be better to pick > one or the other, or, would one or the other be better for freeBSD testing? 'normal' graphics card is slightly non-descriptive I'm afraid ;) Can you get a SHOW CONF & SHOW DEV from all machines? Just hook up a serial port of a PC (or terminal) to serial port #1 of the Allpha (9600N81) and look for the >>> prompt before entering the command. SHOW CONF will give you all info on the box. CPU speed, memory, expansion boards etc. SHOW DEVICES will give you the peripherals Wilko -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Mar 25 13:49:30 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from rahl.dorm.duke.edu (rahl.dorm.duke.edu [152.16.249.139]) by hub.freebsd.org (Postfix) with ESMTP id 1B15B37B416 for ; Mon, 25 Mar 2002 13:49:27 -0800 (PST) Received: (from scott@localhost) by rahl.dorm.duke.edu (8.11.6/8.11.6) id g2PLnUd39882; Mon, 25 Mar 2002 16:49:30 -0500 (EST) (envelope-from scott) Message-Id: <200203252149.g2PLnUd39882@rahl.dorm.duke.edu> Content-Type: text/plain; charset="iso-8859-15" From: Scott Sipe To: Wilko Bulte Subject: Re: Alpha Build Date: Mon, 25 Mar 2002 16:49:30 -0500 X-Mailer: KMail [version 1.3.2] References: <200203252124.g2PLOiw39838@rahl.dorm.duke.edu> <20020325224557.A776@freebie.xs4all.nl> In-Reply-To: <20020325224557.A776@freebie.xs4all.nl> Cc: freebsd-alpha@FreeBSD.ORG MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Monday 25 March 2002 16:45, you wrote: > On Mon, Mar 25, 2002 at 04:24:44PM -0500, Scott Sipe wrote: > > There are 4 AlphaStation 600's from which I could pick, 2 of them have > > 'TGA graphics cards', 2 have "normal" graphics cards and "can run X." > >  Seeing as right now I know next to nothing about Alpha's, would it be > > better to pick one or the other, or, would one or the other be better for > > freeBSD testing? > > 'normal' graphics card is slightly non-descriptive I'm afraid ;) > > Can you get a SHOW CONF & SHOW DEV from all machines? Just hook up a serial > port of a PC (or terminal) to serial port #1 of the Allpha (9600N81) > and look for the >>> prompt before entering the command. > > SHOW CONF will give you all info on the box. CPU speed, memory, > expansion boards etc. SHOW DEVICES will give you the peripherals > > Wilko I really can't I don't think, unfortunately. These computers as I understand are sitting somewhere in a closet in my school's CS department. I'll see what I can do though. I'll probably try to take a look at them tomorrow or something. Scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Mar 25 13:56:12 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 43A9837B41F for ; Mon, 25 Mar 2002 13:55:51 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g2PLtll00921; Mon, 25 Mar 2002 22:55:47 +0100 (CET) (envelope-from wkb) Date: Mon, 25 Mar 2002 22:55:47 +0100 From: Wilko Bulte To: Scott Sipe Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Alpha Build Message-ID: <20020325225547.A899@freebie.xs4all.nl> References: <200203252124.g2PLOiw39838@rahl.dorm.duke.edu> <20020325224557.A776@freebie.xs4all.nl> <200203252149.g2PLnUd39882@rahl.dorm.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <200203252149.g2PLnUd39882@rahl.dorm.duke.edu>; from cscotts@mindspring.com on Mon, Mar 25, 2002 at 04:49:30PM -0500 X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Mon, Mar 25, 2002 at 04:49:30PM -0500, Scott Sipe wrote: > On Monday 25 March 2002 16:45, you wrote: > > On Mon, Mar 25, 2002 at 04:24:44PM -0500, Scott Sipe wrote: > > > There are 4 AlphaStation 600's from which I could pick, 2 of them have > > > 'TGA graphics cards', 2 have "normal" graphics cards and "can run X." > > >  Seeing as right now I know next to nothing about Alpha's, would it be > > > better to pick one or the other, or, would one or the other be better for > > > freeBSD testing? > > > > 'normal' graphics card is slightly non-descriptive I'm afraid ;) > > > > Can you get a SHOW CONF & SHOW DEV from all machines? Just hook up a serial > > port of a PC (or terminal) to serial port #1 of the Allpha (9600N81) > > and look for the >>> prompt before entering the command. > > > > SHOW CONF will give you all info on the box. CPU speed, memory, > > expansion boards etc. SHOW DEVICES will give you the peripherals > > > > Wilko > > I really can't I don't think, unfortunately. These computers as I understand > are sitting somewhere in a closet in my school's CS department. I'll see > what I can do though. I'll probably try to take a look at them tomorrow or > something. Well, whatever you can find out about them will probably help us help you. You want: the one with the most memory. Generally a cheap, simple PCI VGA card will do it in case you end up with an oddball display adapter. Disks are also handy, as is a working CD drive. And I forgot: don't connect a keyboard, that should make the console default to serial. Wilko -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Mon Mar 25 19:34: 2 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mail.alfredstate.edu (mail.alfredstate.edu [136.224.32.28]) by hub.freebsd.org (Postfix) with ESMTP id AA56037B417; Mon, 25 Mar 2002 19:33:56 -0800 (PST) Received: from WORKSTATION ([136.224.236.68]) by mail.alfredstate.edu with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 11CS2LTA; Mon, 25 Mar 2002 22:33:52 -0500 From: "Levi Adams" To: Cc: "Freebsd-Alpha" Subject: i have a question for you guys Date: Mon, 25 Mar 2002 22:44:57 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0000_01C1D44E.B0721A50" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MS-TNEF-Correlator: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-freebsd-alpha@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_0000_01C1D44E.B0721A50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Kinda new to the freeBSD Alpha side of the world, so i was looking for some help. i have an Alphaserver 3305 500 Mhz 21164A 4- 9.1 GB Viking II SCSI Drives 512 MB (all banks populated) my problem is that i can not get the FreeBSD 4.5 RELEASE CD to boot it gives me this error ********************** jumping to bootstrap code halted CPU 0 halt code =2 kernel stack not valid halt PC=0 boot failure *********************** i have FreeBSD 4.4 RC4 on it right now running stable, but i really prefer KDE and 4.5 in general. i updated the SRM to it as i was recommended from someone on geocrawler but it still will not boot the 4.5 CD. any help would be appreciated. -Ivel ------=_NextPart_000_0000_01C1D44E.B0721A50 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IjkDAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEGgAMADgAAANIHAwAZABYAJgAAAAEAMgEB A5AGADwHAAAlAAAACwACAAEAAAALACMAAAAAAAMAJgAAAAAACwApAAAAAAADADYAAAAAAB4AcAAB AAAAHwAAAGkgaGF2ZSBhIHF1ZXN0aW9uIGZvciB5b3UgZ3V5cwAAAgFxAAEAAAAWAAAAAcHUd6R+ jjh+j6DfQDiZonjWwj5E0AAAAgEdDAEAAAAdAAAAU01UUDpBREFNU0xUQEFMRlJFRFNUQVRFLkVE VQAAAAALAAEOAAAAAEAABg4AHGGgd9TBAQIBCg4BAAAAGAAAAAAAAAD6KatOc69RSoDdiiq3t0ds woAAAAsAHw4BAAAAAgEJEAEAAAC6AgAAtgIAAMcDAABMWkZ1KR/vHQMACgByY3BnMTI1FjIA+Atg bg4QMDMzTwH3AqQDYwIAY2gKwHPwZXQwIAdtAoMAUAPUVxDJBxMCgH0KgXYIkHfSawuAZDQMYGMA UAsDzHNiD0ABQHNhFeILtIg0IEsU4WEgbgfRxHRvF5BoZSADUAngSEJTRBPQbHAQ8CCjAJABACBv ZhfDdwWwWGxkLBjgF7BpGaBh6wQgCQBvFNFnGAAFsRog7QeAIBfgGKAuCqIKgBpQfRDwdhfwEKEc IxiTESBypxywBcAPYDA1AzBsC4ANF/A1FfAF0Gh6IDJgMTE2NEEeZB50NAAtIDkuMSBHQkggVmka 40lJBgBD+lMhkEQFEBywBCEehA4gWwXQIPAoB0ADIGIAcGuhBCBwb3B1C2B0CYByKR/JbXkj4ANg AmBlvm0aQAQgF9AkQBpBYwORtG5vBUBnETAXw0YYJQQ0Lh5QUkVMRUHwU0UgQxhwF6EG4Cbh/mkm 8SIjG5EX0CXxBJADYDsK0R/YKiuvK/IedGp1DG1wGvIpBXN0cmHecCaABHEfyRDwbCRRKMA4UFUg AUAvDC6jID17DlAeg2sEkRvQGOABkGN6aybDdgdAGQAvkx50UOxDPTBUKSRmC3AKQAlwPytPLE8a QRyTJ5gW4FJDzxbgAiApcgUQZ2gFQCbQ8QfgcnVuAwAbATKhJaH5GgBidSZSCXAjUSVSARD5HfFL RCiwAHAv8CgSC4AnJwEXYC5wbC4aQXVwxxcwL9IX0lNSTReSKYHvGoEaVAlwBaBtB4AU8C/hXwNS G2MCIBkhPVJvBQBh/nclsAXAO0MFQC5QAxADIP8D8CNhJtIpMxfSKBIo0D3gvxzRJVAbwhmhJCAv 8GIcwTpwPBFjBzAkURwFLUn/HLAJUBwjCvQSowwBHCMUUQIASWAAAAsAAYAIIAYAAAAAAMAAAAAA AABGAAAAAAOFAAAAAAAAAwADgAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAAeACCAGAAAA AADAAAAAAAAARgAAAABShQAAJ2oBAB4ACYAIIAYAAAAAAMAAAAAAAABGAAAAAFSFAAABAAAABAAA ADkuMAAeAAqACCAGAAAAAADAAAAAAAAARgAAAAA2hQAAAQAAAAEAAAAAAAAAHgALgAggBgAAAAAA wAAAAAAAAEYAAAAAN4UAAAEAAAABAAAAAAAAAB4ADIAIIAYAAAAAAMAAAAAAAABGAAAAADiFAAAB AAAAAQAAAAAAAAALAA2ACCAGAAAAAADAAAAAAAAARgAAAACChQAAAQAAAAsAOoAIIAYAAAAAAMAA AAAAAABGAAAAAA6FAAAAAAAAAwA8gAggBgAAAAAAwAAAAAAAAEYAAAAAEYUAAAAAAAADAD2ACCAG AAAAAADAAAAAAAAARgAAAAAYhQAAAAAAAAsAUoAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAAAA AwBTgAggBgAAAAAAwAAAAAAAAEYAAAAAAYUAAAAAAAACAfgPAQAAABAAAAD6KatOc69RSoDdiiq3 t0dsAgH6DwEAAAAQAAAA+imrTnOvUUqA3Yoqt7dHbAIB+w8BAAAAnwAAAAAAAAA4obsQBeUQGqG7 CAArKlbCAABQU1RQUlguRExMAAAAAAAAAABOSVRB+b+4AQCqADfZbgAAAEM6XERvY3VtZW50cyBh bmQgU2V0dGluZ3NcYWRtaW5pc3RyYXRvclxMb2NhbCBTZXR0aW5nc1xBcHBsaWNhdGlvbiBEYXRh XE1pY3Jvc29mdFxPdXRsb29rXG91dGxvb2sucHN0AAADAP4PBQAAAAMADTT9NwAAAgF/AAEAAAA3 AAAAPEZCRUtJQU5OSEFBREJNUEpERU1ERUVJQ0NBQUEuYWRhbXNsdEBhbGZyZWRzdGF0ZS5lZHU+ AAADAAYQ2pbtgQMABxAVAgAAAwAQEAAAAAADABEQAAAAAB4ACBABAAAAZQAAAEtJTkRBTkVXVE9U SEVGUkVFQlNEQUxQSEFTSURFT0ZUSEVXT1JMRCxTT0lXQVNMT09LSU5HRk9SU09NRUhFTFBJSEFW RUFOQUxQSEFTRVJWRVIzMzA1NTAwTUhaMjExNjRBNC0AAAAAS6s= ------=_NextPart_000_0000_01C1D44E.B0721A50-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Mar 26 1:10:15 2002 Delivered-To: freebsd-alpha@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 1632D37B41B for ; Tue, 26 Mar 2002 01:10:01 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2Q9A1F86546; Tue, 26 Mar 2002 01:10:01 -0800 (PST) (envelope-from gnats) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id D34DC37B417 for ; Tue, 26 Mar 2002 01:06:02 -0800 (PST) Received: (from nobody@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2Q962l84742; Tue, 26 Mar 2002 01:06:02 -0800 (PST) (envelope-from nobody) Message-Id: <200203260906.g2Q962l84742@freefall.freebsd.org> Date: Tue, 26 Mar 2002 01:06:02 -0800 (PST) From: "Loren J. Rittle" To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: alpha/36327: trap within cvt() while attempting to printf() an FP number Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 36327 >Category: alpha >Synopsis: trap within cvt() while attempting to printf() an FP number >Confidential: no >Severity: non-critical >Priority: low >Responsible: freebsd-alpha >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Tue Mar 26 01:10:00 PST 2002 >Closed-Date: >Last-Modified: >Originator: Loren J. Rittle >Release: 4.2 and 5.0 on alpha hardware >Organization: On behalf of libjava project of GCC >Environment: FreeBSD clerc-milon.rsch.comm.mot.com 4.2-STABLE FreeBSD 4.2-STABLE #0: Tue Dec 19 09:52:15 CST 2000 rittle@clerc-milon.rsch.comm.mot.com:/usr/obj/usr/src/sys/CLERC-MILON alpha FreeBSD beast.freebsd.org 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Sat Mar 16 13:34:04 PST 2002 root@beast.freebsd.org:/usr/src/sys/alpha/compile/BEAST alpha >Description: The attached small test case was found by trying to bootstrap libjava on alpha*-*-freebsd[45]* as will be released with gcc 3.1. The exact failure in libjava is different than the constructed small test case but the failure point within the system routine is the same. Also, I attempted to use the information from fpsetmask(3) to avoid the trap without success. Even the exact example from the man page suggested to avoid the divide by zero trap does not work as documented. >How-To-Repeat: Compile this program with the system gcc without -O flags on FreeBSD/alpha: #include #include main() { double d = DBL_MIN; printf (" = %.17g;\n", d); printf (" = %.17g;\n", d/10); printf (" = %.17g;\n", (DBL_MIN/10)*10); printf (" = %.17g;\n", (DBL_MIN/10)); } It will produce this output: = 2.2250738585072014e-308; = 0; = 2.2250738585072034e-308; floating point exception--core dumped ISO C might allow the test case to perform as seen. However, FreeBSD/alpha has a man page discussing how to avoid the trap. Cut-and-paste the sample code to avoid a divide by zero. It doesn't disable the trap. It might be OK if there was no way to avoid the trap with this exact test case but knowing when it is safe to call libc routines with a given FP value would be helpful/required to allow libjava to work on FreeBSD/alpha. >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Mar 26 6:30:28 2002 Delivered-To: freebsd-alpha@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9522137B419 for ; Tue, 26 Mar 2002 06:30:02 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2QEU2s77171; Tue, 26 Mar 2002 06:30:02 -0800 (PST) (envelope-from gnats) Date: Tue, 26 Mar 2002 06:30:02 -0800 (PST) Message-Id: <200203261430.g2QEU2s77171@freefall.freebsd.org> To: freebsd-alpha@FreeBSD.org Cc: From: Andrew Gallatin Subject: Re: alpha/36327: trap within cvt() while attempting to printf() an FP number Reply-To: Andrew Gallatin Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR alpha/36327; it has been noted by GNATS. From: Andrew Gallatin To: "Loren J. Rittle" Cc: freebsd-gnats-submit@FreeBSD.ORG Subject: Re: alpha/36327: trap within cvt() while attempting to printf() an FP number Date: Tue, 26 Mar 2002 09:21:25 -0500 (EST) I beleive this only works for floating point operations which have software completion enabled. Eg, -mieee. Have you tried adding -mieee to CFLAGS? Drew Loren J. Rittle writes: > > >Number: 36327 > >Category: alpha > >Synopsis: trap within cvt() while attempting to printf() an FP number > >Confidential: no > >Severity: non-critical > >Priority: low > >Responsible: freebsd-alpha > >State: open > >Quarter: > >Keywords: > >Date-Required: > >Class: sw-bug > >Submitter-Id: current-users > >Arrival-Date: Tue Mar 26 01:10:00 PST 2002 > >Closed-Date: > >Last-Modified: > >Originator: Loren J. Rittle > >Release: 4.2 and 5.0 on alpha hardware > >Organization: > On behalf of libjava project of GCC > >Environment: > FreeBSD clerc-milon.rsch.comm.mot.com 4.2-STABLE FreeBSD 4.2-STABLE #0: Tue Dec 19 09:52:15 CST 2000 rittle@clerc-milon.rsch.comm.mot.com:/usr/obj/usr/src/sys/CLERC-MILON alpha > FreeBSD beast.freebsd.org 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Sat Mar 16 13:34:04 PST 2002 root@beast.freebsd.org:/usr/src/sys/alpha/compile/BEAST alpha > >Description: > The attached small test case was found by trying to bootstrap libjava > on alpha*-*-freebsd[45]* as will be released with gcc 3.1. The > exact failure in libjava is different than the constructed small test > case but the failure point within the system routine is the same. > > Also, I attempted to use the information from fpsetmask(3) to avoid > the trap without success. Even the exact example from the man page > suggested to avoid the divide by zero trap does not work as documented. > >How-To-Repeat: > Compile this program with the system gcc without -O flags on > FreeBSD/alpha: > > #include > #include > > main() { > double d = DBL_MIN; > > printf (" = %.17g;\n", d); > printf (" = %.17g;\n", d/10); > printf (" = %.17g;\n", (DBL_MIN/10)*10); > printf (" = %.17g;\n", (DBL_MIN/10)); > } > > It will produce this output: > > = 2.2250738585072014e-308; > = 0; > = 2.2250738585072034e-308; > floating point exception--core dumped > > ISO C might allow the test case to perform as seen. However, > FreeBSD/alpha has a man page discussing how to avoid the trap. > Cut-and-paste the sample code to avoid a divide by zero. It > doesn't disable the trap. It might be OK if there was no way > to avoid the trap with this exact test case but knowing when > it is safe to call libc routines with a given FP value would > be helpful/required to allow libjava to work on FreeBSD/alpha. > >Fix: > > >Release-Note: > >Audit-Trail: > >Unformatted: > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Mar 26 6:42:24 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from qescan1.qgraph.com (QESCAN1.qgraph.com [206.158.124.7]) by hub.freebsd.org (Postfix) with SMTP id 2CB9637B41A for ; Tue, 26 Mar 2002 06:42:19 -0800 (PST) Received: from 192.168.200.28 by qescan1.qgraph.com (InterScan E-Mail VirusWall NT); Tue, 26 Mar 2002 08:42:17 -0600 Received: by sxsmtp1.qgraph.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 08:42:17 -0600 Message-ID: <1F095B0753FCD411857700010333058A03DB917F@waexch1.qgraph.com> From: "Schroeder, Aaron" To: "'freebsd-alpha@freebsd.org'" Subject: Kernel compile error on AS4000 Date: Tue, 26 Mar 2002 08:42:15 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1D4D4.6C049740" Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C1D4D4.6C049740 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1D4D4.6C049740" ------_=_NextPart_001_01C1D4D4.6C049740 Content-Type: text/plain Hello all, I am running an AS4000 right now. I have downloaded the CURRENT source and did a make buildworld. I then wanted to compile a kernel for SMP (This box has two 5/400's in it) I went through the config file for the kernel and then wanted to compile and install the "traditional" way. When I issue the command /usr/sbin/config MYKERNEL it comes up with this error: 75: unknown option "APIC_IO" I read that this is needed with another option in order to make use of SMP. I have included a text file of my kernel that I am trying to compile. Any help would be appreciated, <> AJ Schroeder Imaging Systems Administrator Quad/Graphics, Inc. 414.566.2705 mailto:aaron.schroeder@qg.com ------_=_NextPart_001_01C1D4D4.6C049740 Content-Type: text/html Content-Transfer-Encoding: quoted-printable Kernel compile error on AS4000

Hello all,

I am running an AS4000 = right now. I have downloaded the CURRENT source and did a make = buildworld. I then wanted to compile a kernel for SMP (This box has two = 5/400's in it) I went through the config file for the kernel and then = wanted to compile and install the "traditional" way. When I = issue the command /usr/sbin/config MYKERNEL it comes up with this = error:

75: unknown option = "APIC_IO"

I read that this is = needed with another option in order to make use of SMP. I have included = a text file of my kernel that I am trying to compile.

Any help would be = appreciated, = <<MYKERNEL.txt>>

AJ Schroeder
Imaging Systems = Administrator
Quad/Graphics, = Inc.
414.566.2705
mailto:aaron.schroeder@qg.com

------_=_NextPart_001_01C1D4D4.6C049740-- ------_=_NextPart_000_01C1D4D4.6C049740 Content-Type: text/plain; name="MYKERNEL.txt" Content-Disposition: attachment; filename="MYKERNEL.txt" ------_=_NextPart_000_01C1D4D4.6C049740-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Mar 26 6:46: 7 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 320E737B405 for ; Tue, 26 Mar 2002 06:46:02 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g2QEjvX03919; Tue, 26 Mar 2002 15:45:57 +0100 (CET) (envelope-from wkb) Date: Tue, 26 Mar 2002 15:45:57 +0100 From: Wilko Bulte To: "Schroeder, Aaron" Cc: "'freebsd-alpha@freebsd.org'" Subject: Re: Kernel compile error on AS4000 Message-ID: <20020326154557.B3879@freebie.xs4all.nl> References: <1F095B0753FCD411857700010333058A03DB917F@waexch1.qgraph.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <1F095B0753FCD411857700010333058A03DB917F@waexch1.qgraph.com>; from Aaron.Schroeder@qg.com on Tue, Mar 26, 2002 at 08:42:15AM -0600 X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Mar 26, 2002 at 08:42:15AM -0600, Schroeder, Aaron wrote: APIC is Intel-only. options SMP should be sufficient on Alpha. > > Hello all, > > I am running an AS4000 right now. I have downloaded the CURRENT source and > did a make buildworld. I then wanted to compile a kernel for SMP (This box > has two 5/400's in it) I went through the config file for the kernel and > then wanted to compile and install the "traditional" way. When I issue the > command /usr/sbin/config MYKERNEL it comes up with this error: > > 75: unknown option "APIC_IO" > > I read that this is needed with another option in order to make use of SMP. > I have included a text file of my kernel that I am trying to compile. > > Any help would be appreciated, <> > > AJ Schroeder > Imaging Systems Administrator > Quad/Graphics, Inc. > 414.566.2705 > mailto:aaron.schroeder@qg.com > ---end of quoted text--- -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Mar 26 6:49: 4 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from qescan2.qgraph.com (QESCAN2.qgraph.com [206.158.124.8]) by hub.freebsd.org (Postfix) with SMTP id 6FDB737B416 for ; Tue, 26 Mar 2002 06:48:52 -0800 (PST) Received: from 192.168.200.29 by qescan2.qgraph.com (InterScan E-Mail VirusWall NT); Tue, 26 Mar 2002 08:48:43 -0600 Received: by sxsmtp2.qgraph.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 08:48:42 -0600 Message-ID: <1F095B0753FCD411857700010333058A03DB9182@waexch1.qgraph.com> From: "Schroeder, Aaron" To: 'Wilko Bulte' Cc: "'freebsd-alpha@freebsd.org'" Subject: RE: Kernel compile error on AS4000 Date: Tue, 26 Mar 2002 08:48:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Oh, ok, that would explain the problem. Thank you. -----Original Message----- From: Wilko Bulte [mailto:wkb@freebie.xs4all.nl] Sent: Tuesday, March 26, 2002 8:46 AM To: Schroeder, Aaron Cc: 'freebsd-alpha@freebsd.org' Subject: Re: Kernel compile error on AS4000 On Tue, Mar 26, 2002 at 08:42:15AM -0600, Schroeder, Aaron wrote: APIC is Intel-only. options SMP should be sufficient on Alpha. > > Hello all, > > I am running an AS4000 right now. I have downloaded the CURRENT source > and did a make buildworld. I then wanted to compile a kernel for SMP > (This box has two 5/400's in it) I went through the config file for > the kernel and then wanted to compile and install the "traditional" > way. When I issue the command /usr/sbin/config MYKERNEL it comes up > with this error: > > 75: unknown option "APIC_IO" > > I read that this is needed with another option in order to make use of > SMP. I have included a text file of my kernel that I am trying to > compile. > > Any help would be appreciated, <> > > AJ Schroeder > Imaging Systems Administrator > Quad/Graphics, Inc. > 414.566.2705 > mailto:aaron.schroeder@qg.com > ---end of quoted text--- -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Mar 26 6:54:30 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from qescan3.qgraph.com (QESCAN3.qgraph.com [206.158.124.15]) by hub.freebsd.org (Postfix) with SMTP id DA65337B400 for ; Tue, 26 Mar 2002 06:54:25 -0800 (PST) Received: from 192.168.200.30 by qescan3.qgraph.com (InterScan E-Mail VirusWall NT); Tue, 26 Mar 2002 08:54:18 -0600 (Central Standard Time) Received: by SXSMTP3 with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 08:54:16 -0600 Message-ID: <1F095B0753FCD411857700010333058A03DB9183@waexch1.qgraph.com> From: "Schroeder, Aaron" To: 'Wilko Bulte' Cc: "'freebsd-alpha@freebsd.org'" Subject: RE: Kernel compile error on AS4000 Date: Tue, 26 Mar 2002 08:54:11 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Now for the start of Round 2: I did a '/usr/sbin/config MYKERNEL', it went fine, I then issued a 'cd ../../compile/MYKERNEL' in order to 'make depend' And I get this: make: don't know how to make ../../alpha/alpha/mp_machdep.c. Stop Doh! TIA, AJ Schroeder -----Original Message----- From: Wilko Bulte [mailto:wkb@freebie.xs4all.nl] Sent: Tuesday, March 26, 2002 8:46 AM To: Schroeder, Aaron Cc: 'freebsd-alpha@freebsd.org' Subject: Re: Kernel compile error on AS4000 On Tue, Mar 26, 2002 at 08:42:15AM -0600, Schroeder, Aaron wrote: APIC is Intel-only. options SMP should be sufficient on Alpha. > > Hello all, > > I am running an AS4000 right now. I have downloaded the CURRENT source > and did a make buildworld. I then wanted to compile a kernel for SMP > (This box has two 5/400's in it) I went through the config file for > the kernel and then wanted to compile and install the "traditional" > way. When I issue the command /usr/sbin/config MYKERNEL it comes up > with this error: > > 75: unknown option "APIC_IO" > > I read that this is needed with another option in order to make use of > SMP. I have included a text file of my kernel that I am trying to > compile. > > Any help would be appreciated, <> > > AJ Schroeder > Imaging Systems Administrator > Quad/Graphics, Inc. > 414.566.2705 > mailto:aaron.schroeder@qg.com > ---end of quoted text--- -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Mar 26 7:40:34 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 2885237B419 for ; Tue, 26 Mar 2002 07:40:30 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id KAA11720; Tue, 26 Mar 2002 10:40:28 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2QFdwm62373; Tue, 26 Mar 2002 10:39:58 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15520.38478.153969.513665@grasshopper.cs.duke.edu> Date: Tue, 26 Mar 2002 10:39:58 -0500 (EST) To: "Schroeder, Aaron" Cc: "'Wilko Bulte'" , "'freebsd-alpha@freebsd.org'" Subject: RE: Kernel compile error on AS4000 In-Reply-To: <1F095B0753FCD411857700010333058A03DB9183@waexch1.qgraph.com> References: <1F095B0753FCD411857700010333058A03DB9183@waexch1.qgraph.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Something is wrong with your env. Did you installworld too? FWIW, the alpha GENERIC kernel in -current is SMP aware, so you should just be able to follow the normal updating procedure of make buildkernel; make installkernel. Drew Schroeder, Aaron writes: > Now for the start of Round 2: > > I did a '/usr/sbin/config MYKERNEL', it went fine, > I then issued a 'cd ../../compile/MYKERNEL' in order to 'make depend' > > And I get this: > > make: don't know how to make ../../alpha/alpha/mp_machdep.c. Stop > > Doh! > > TIA, > > AJ Schroeder > > -----Original Message----- > From: Wilko Bulte [mailto:wkb@freebie.xs4all.nl] > Sent: Tuesday, March 26, 2002 8:46 AM > To: Schroeder, Aaron > Cc: 'freebsd-alpha@freebsd.org' > Subject: Re: Kernel compile error on AS4000 > > > On Tue, Mar 26, 2002 at 08:42:15AM -0600, Schroeder, Aaron wrote: > > APIC is Intel-only. options SMP should be sufficient on Alpha. > > > > > Hello all, > > > > I am running an AS4000 right now. I have downloaded the CURRENT source > > and did a make buildworld. I then wanted to compile a kernel for SMP > > (This box has two 5/400's in it) I went through the config file for > > the kernel and then wanted to compile and install the "traditional" > > way. When I issue the command /usr/sbin/config MYKERNEL it comes up > > with this error: > > > > 75: unknown option "APIC_IO" > > > > I read that this is needed with another option in order to make use of > > SMP. I have included a text file of my kernel that I am trying to > > compile. > > > > Any help would be appreciated, <> > > > > AJ Schroeder > > Imaging Systems Administrator > > Quad/Graphics, Inc. > > 414.566.2705 > > mailto:aaron.schroeder@qg.com > > > > > ---end of quoted text--- > > -- > | / o / /_ _ wilko@FreeBSD.org > |/|/ / / /( (_) Bulte Arnhem, the Netherlands > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Mar 26 9:10:41 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from qescan1.qgraph.com (QESCAN1.qgraph.com [206.158.124.7]) by hub.freebsd.org (Postfix) with SMTP id E18A737B421 for ; Tue, 26 Mar 2002 09:10:33 -0800 (PST) Received: from 192.168.200.28 by qescan1.qgraph.com (InterScan E-Mail VirusWall NT); Tue, 26 Mar 2002 11:09:42 -0600 Received: by sxsmtp1.qgraph.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 11:09:42 -0600 Message-ID: <1F095B0753FCD411857700010333058A03DB918C@waexch1.qgraph.com> From: "Schroeder, Aaron" To: 'Andrew Gallatin' Cc: 'Wilko Bulte' , "'freebsd-alpha@freebsd.org'" Subject: RE: Kernel compile error on AS4000 Date: Tue, 26 Mar 2002 11:09:39 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org I did not installworld yet, I thought that I needed to make the kernel before doing the installworld. -----Original Message----- From: Andrew Gallatin [mailto:gallatin@cs.duke.edu] Sent: Tuesday, March 26, 2002 9:40 AM To: Schroeder, Aaron Cc: 'Wilko Bulte'; 'freebsd-alpha@freebsd.org' Subject: RE: Kernel compile error on AS4000 Something is wrong with your env. Did you installworld too? FWIW, the alpha GENERIC kernel in -current is SMP aware, so you should just be able to follow the normal updating procedure of make buildkernel; make installkernel. Drew Schroeder, Aaron writes: > Now for the start of Round 2: > > I did a '/usr/sbin/config MYKERNEL', it went fine, > I then issued a 'cd ../../compile/MYKERNEL' in order to 'make depend' > > And I get this: > > make: don't know how to make ../../alpha/alpha/mp_machdep.c. Stop > > Doh! > > TIA, > > AJ Schroeder > > -----Original Message----- > From: Wilko Bulte [mailto:wkb@freebie.xs4all.nl] > Sent: Tuesday, March 26, 2002 8:46 AM > To: Schroeder, Aaron > Cc: 'freebsd-alpha@freebsd.org' > Subject: Re: Kernel compile error on AS4000 > > > On Tue, Mar 26, 2002 at 08:42:15AM -0600, Schroeder, Aaron wrote: > > APIC is Intel-only. options SMP should be sufficient on Alpha. > > > > > Hello all, > > > > I am running an AS4000 right now. I have downloaded the CURRENT source > > and did a make buildworld. I then wanted to compile a kernel for SMP > > (This box has two 5/400's in it) I went through the config file for > > the kernel and then wanted to compile and install the "traditional" > > way. When I issue the command /usr/sbin/config MYKERNEL it comes up > > with this error: > > > > 75: unknown option "APIC_IO" > > > > I read that this is needed with another option in order to make use of > > SMP. I have included a text file of my kernel that I am trying to > > compile. > > > > Any help would be appreciated, <> > > > > AJ Schroeder > > Imaging Systems Administrator > > Quad/Graphics, Inc. > > 414.566.2705 > > mailto:aaron.schroeder@qg.com > > > > > ---end of quoted text--- > > -- > | / o / /_ _ wilko@FreeBSD.org > |/|/ / / /( (_) Bulte Arnhem, the Netherlands > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Mar 26 9:21: 1 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 9400537B421 for ; Tue, 26 Mar 2002 09:20:29 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id MAA15326; Tue, 26 Mar 2002 12:20:24 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2QHJsE63267; Tue, 26 Mar 2002 12:19:54 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15520.44474.240043.891269@grasshopper.cs.duke.edu> Date: Tue, 26 Mar 2002 12:19:54 -0500 (EST) To: "Schroeder, Aaron" Cc: "'Wilko Bulte'" , "'freebsd-alpha@freebsd.org'" Subject: RE: Kernel compile error on AS4000 In-Reply-To: <1F095B0753FCD411857700010333058A03DB918C@waexch1.qgraph.com> References: <1F095B0753FCD411857700010333058A03DB918C@waexch1.qgraph.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Schroeder, Aaron writes: > I did not installworld yet, I thought that I needed to make the kernel > before doing the installworld. Unless you really know what you're doing, you need to make & install the new kernel using the "make buildkernel" and "make installkernel" targets, so that the appropriate config, .mk, headers, etc, are used. You should familiarize yourself with -current & the upgrade procedure before attempting to run -current. Read UPDATING & subscribe to freebsd-current@freebsd.org. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Mar 26 9:22:44 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from qescan2.qgraph.com (QESCAN2.qgraph.com [206.158.124.8]) by hub.freebsd.org (Postfix) with SMTP id F002D37B400 for ; Tue, 26 Mar 2002 09:22:40 -0800 (PST) Received: from 192.168.200.29 by qescan2.qgraph.com (InterScan E-Mail VirusWall NT); Tue, 26 Mar 2002 11:22:02 -0600 Received: by sxsmtp2.qgraph.com with Internet Mail Service (5.5.2653.19) id ; Tue, 26 Mar 2002 11:22:01 -0600 Message-ID: <1F095B0753FCD411857700010333058A03DB9190@waexch1.qgraph.com> From: "Schroeder, Aaron" To: 'Andrew Gallatin' Cc: 'Wilko Bulte' , "'freebsd-alpha@freebsd.org'" Subject: RE: Kernel compile error on AS4000 Date: Tue, 26 Mar 2002 11:21:59 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org oic, in that case, I need to get reading. Thanks for the help! -----Original Message----- From: Andrew Gallatin [mailto:gallatin@cs.duke.edu] Sent: Tuesday, March 26, 2002 11:20 AM To: Schroeder, Aaron Cc: 'Wilko Bulte'; 'freebsd-alpha@freebsd.org' Subject: RE: Kernel compile error on AS4000 Schroeder, Aaron writes: > I did not installworld yet, I thought that I needed to make the kernel > before doing the installworld. Unless you really know what you're doing, you need to make & install the new kernel using the "make buildkernel" and "make installkernel" targets, so that the appropriate config, .mk, headers, etc, are used. You should familiarize yourself with -current & the upgrade procedure before attempting to run -current. Read UPDATING & subscribe to freebsd-current@freebsd.org. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Mar 26 9:23:29 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 5E54E37B400 for ; Tue, 26 Mar 2002 09:23:26 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.6/8.11.6) with UUCP id g2QHNCR08171; Tue, 26 Mar 2002 18:23:12 +0100 (CET) (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.1.10]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g2QHKw6e098661; Tue, 26 Mar 2002 18:20:58 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (localhost [127.0.0.1]) by cicely8.cicely.de (8.12.2/8.12.2) with ESMTP id g2QHKunU018112; Tue, 26 Mar 2002 18:20:56 +0100 (CET) (envelope-from ticso@cicely8.cicely.de) Received: (from ticso@localhost) by cicely8.cicely.de (8.12.2/8.12.2/Submit) id g2QHKt22018111; Tue, 26 Mar 2002 18:20:56 +0100 (CET) Date: Tue, 26 Mar 2002 18:20:54 +0100 From: Bernd Walter To: "Schroeder, Aaron" Cc: "'Andrew Gallatin'" , "'Wilko Bulte'" , "'freebsd-alpha@freebsd.org'" Subject: Re: Kernel compile error on AS4000 Message-ID: <20020326172054.GE17565@cicely8.cicely.de> References: <1F095B0753FCD411857700010333058A03DB918C@waexch1.qgraph.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1F095B0753FCD411857700010333058A03DB918C@waexch1.qgraph.com> User-Agent: Mutt/1.3.26i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Tue, Mar 26, 2002 at 11:09:39AM -0600, Schroeder, Aaron wrote: > I did not installworld yet, I thought that I needed to make the kernel > before doing the installworld. If you want to make the kernel before installworld you should use: make KERNCONF=MYKERNEL buildkernel installkernel You need to buildworld first. Everthing else may or may not work. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Tue Mar 26 20:17:34 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from mta07.mail.mel.aone.net.au (mta07.mail.au.uu.net [203.2.192.88]) by hub.freebsd.org (Postfix) with ESMTP id 428CB37B416 for ; Tue, 26 Mar 2002 20:17:30 -0800 (PST) Received: from ausyddtp0050.ozemail.com.au ([203.166.67.234]) by mta07.mail.mel.aone.net.au with ESMTP id <20020327041729.SWDC17371.mta07.mail.mel.aone.net.au@ausyddtp0050.ozemail.com.au> for ; Wed, 27 Mar 2002 15:17:29 +1100 Message-Id: <5.1.0.14.2.20020327150951.00a78020@pop.ozemail.com.au> X-Sender: rbyrnes@pop.ozemail.com.au X-Mailer: I wish it was Linux Date: Wed, 27 Mar 2002 15:17:27 +1100 To: freebsd-alpha@freebsd.org From: Rob B Subject: Re: Seti not working on 4.5-STABLE In-Reply-To: <20020319082257.GB12319@cicely8.cicely.de> References: <5.1.0.14.2.20020314152904.01c3f940@pop.ozemail.com.au> <5.1.0.14.2.20020314152904.01c3f940@pop.ozemail.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org At 19:22 19/03/2002, Bernd Walter sent this up the stick: >On Tue, Mar 19, 2002 at 02:07:05PM +1100, Rob B wrote: > > Hi all, > > > > I'm trying to get the OSF1 client running, > > I do have the osf1 module loaded: > > > > erwin# kldstat > > Id Refs Address Size Name > > 1 3 0xfffffc0000300000 2dda68 kernel > > 2 1 0xfffffe0000b70000 20000 osf1.ko > > 3 1 0xfffffe0000b96000 28000 linux.ko > > > > I also get a similar result with the Linux client. Do I need any special > > magic to get it to work? > >You may want to check your /etc/resolv.conf and /etc/hosts. >AFAIK the osf1 libs are more sensible about propper syntax. Continuing on my little setiathome thread, I'm running it from cron thus: [root@erwin]/root: crontab -l # Run setiathome, and check it every hour 0 * * * * cd /usr/local/bin/seti-tru; ./setiathome > /dev/null 2> /dev/null This is as suggested on the seti website. the issue with this is that the lockfile (lock.sah) is not being respected by the client, and cron ends up starting the setiathome process every hour. Is there a way to test whether the client is running, and not start a new process of it if there is one? Cheers, Rob -- We should build an Intel processor out of penguins. [15200.8 km (8207.8 mi), 262.8 deg](Apparent) Rennerian This is random quote 1124 of a collection of 1223 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Mar 27 2:10:31 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 1230837B417 for ; Wed, 27 Mar 2002 02:10:27 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.6/8.11.6) with UUCP id g2RAAF422790; Wed, 27 Mar 2002 11:10:15 +0100 (CET) (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (cicely8.cicely.de [10.1.1.10]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g2RA8r6e005924; Wed, 27 Mar 2002 11:08:53 +0100 (CET)?g (envelope-from ticso@cicely8.cicely.de) Received: from cicely8.cicely.de (localhost [127.0.0.1]) by cicely8.cicely.de (8.12.2/8.12.2) with ESMTP id g2RA8rnU020505; Wed, 27 Mar 2002 11:08:53 +0100 (CET) (envelope-from ticso@cicely8.cicely.de) Received: (from ticso@localhost) by cicely8.cicely.de (8.12.2/8.12.2/Submit) id g2RA8q0b020504; Wed, 27 Mar 2002 11:08:52 +0100 (CET) Date: Wed, 27 Mar 2002 11:08:52 +0100 From: Bernd Walter To: Rob B Cc: freebsd-alpha@FreeBSD.ORG Subject: Re: Seti not working on 4.5-STABLE Message-ID: <20020327100851.GI17565@cicely8.cicely.de> References: <5.1.0.14.2.20020314152904.01c3f940@pop.ozemail.com.au> <5.1.0.14.2.20020314152904.01c3f940@pop.ozemail.com.au> <5.1.0.14.2.20020327150951.00a78020@pop.ozemail.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.1.0.14.2.20020327150951.00a78020@pop.ozemail.com.au> User-Agent: Mutt/1.3.26i X-Operating-System: FreeBSD cicely8.cicely.de 5.0-CURRENT i386 Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Wed, Mar 27, 2002 at 03:17:27PM +1100, Rob B wrote: > At 19:22 19/03/2002, Bernd Walter sent this up the stick: > >On Tue, Mar 19, 2002 at 02:07:05PM +1100, Rob B wrote: > >> Hi all, > >> > >> I'm trying to get the OSF1 client running, > > >> I do have the osf1 module loaded: > >> > >> erwin# kldstat > >> Id Refs Address Size Name > >> 1 3 0xfffffc0000300000 2dda68 kernel > >> 2 1 0xfffffe0000b70000 20000 osf1.ko > >> 3 1 0xfffffe0000b96000 28000 linux.ko > >> > >> I also get a similar result with the Linux client. Do I need any special > >> magic to get it to work? > > > >You may want to check your /etc/resolv.conf and /etc/hosts. > >AFAIK the osf1 libs are more sensible about propper syntax. > > Continuing on my little setiathome thread, I'm running it from cron thus: > > [root@erwin]/root: crontab -l > # Run setiathome, and check it every hour > 0 * * * * cd /usr/local/bin/seti-tru; > ./setiathome > /dev/null 2> /dev/null > > This is as suggested on the seti website. the issue with this is that the > lockfile (lock.sah) is not being respected by the client, and cron ends up > starting the setiathome process every hour. > > Is there a way to test whether the client is running, and not start a new > process of it if there is one? You could use /usr/bin/lockf to start the programm. E.G.: /usr/bin/lockf -t 1 -s ./seti.lock ./setiathome -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Mar 27 14:50:52 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from obsecurity.dyndns.org (adsl-64-169-104-17.dsl.lsan03.pacbell.net [64.169.104.17]) by hub.freebsd.org (Postfix) with ESMTP id A0F9137B427; Wed, 27 Mar 2002 14:50:18 -0800 (PST) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 61A0966F6C; Wed, 27 Mar 2002 14:49:41 -0800 (PST) Date: Wed, 27 Mar 2002 14:49:41 -0800 From: Kris Kennaway To: alpha@FreeBSD.org, ports@FreeBSD.org Subject: Much unhappiness in alpha package build Message-ID: <20020327144941.A80110@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Please see http://beta.freebsd.org/errorlogs/5-latest/ There is a *lot* of breakage in the alpha package collection. They were built with the latest DP1 source tree, so if there are any problems which have been fixed in -current it's an indication they need to be merged. Maintainers, please check the above list for ports you maintain: it's quite common for ports which built fine on i386 to fail on alpha because of code bugs. Kris --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE8okyEWry0BWjoQKURAhl/AKD37Gfi3dqy5TGJvlQIBxbJFxthOACfbZHE 3VYRAzMvSY+TxroL2jRitzc= =vFjD -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Mar 27 14:51:20 2002 Delivered-To: freebsd-alpha@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 9584037B420 for ; Wed, 27 Mar 2002 14:50:30 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2RMo2p58365; Wed, 27 Mar 2002 14:50:02 -0800 (PST) (envelope-from gnats) Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0A88937B442 for ; Wed, 27 Mar 2002 14:47:07 -0800 (PST) Received: (from nobody@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2RMkJ657777; Wed, 27 Mar 2002 14:46:19 -0800 (PST) (envelope-from nobody) Message-Id: <200203272246.g2RMkJ657777@freefall.freebsd.org> Date: Wed, 27 Mar 2002 14:46:19 -0800 (PST) From: Nicholas Paufler To: freebsd-gnats-submit@FreeBSD.org X-Send-Pr-Version: www-1.0 Subject: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org >Number: 36390 >Category: alpha >Synopsis: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE >Confidential: no >Severity: serious >Priority: medium >Responsible: freebsd-alpha >State: open >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: current-users >Arrival-Date: Wed Mar 27 14:50:02 PST 2002 >Closed-Date: >Last-Modified: >Originator: Nicholas Paufler >Release: 4.5-RELEASE >Organization: The Internet Centre >Environment: FreeBSD endor.incentre.net 4.5-RELEASE FreeBSD 4.5-RELEASE #0: Tue Jan 29 07:52:50 GMT 2002 murray@axpbuilder.freebsdmall.com:/usr/src/sys/compile/GENERIC alpha >Description: I just did an FTP install of 4.5-RELEASE onto an AlphaStation 400 4/233. The install went smoothly (save for the DEC network card causing the machine to hang while waiting for SCSI devices to settle) but now I am trying to get it into a more usable state. I grabbed the cvsup-without-gui Alpha package and pkg_added it and attempted to use cvsup to update ports, but it core dumps: npaufler@endor:/usr/local/etc> sudo cvsup ports-supfile *** *** runtime error: *** Value out of range *** file "/tmp/a/ports/lang/ezm3/work/ezm3-1.0/libs/libm3/src/uid/Common/TimeStamp.m3", line 63 *** use option @M3stackdump to get a stack trace Abort trap (core dumped) I've tried installing a few variant packages (cvsup.tgz, some versions from older -releases) but they all crash in the same manner. Running it with the stack dump enabled as suggested gives the following: npaufler@endor:/usr/local/etc> sudo cvsup @M3stackdump ports-supfile *** *** runtime error: *** Value out of range *** file "/tmp/a/ports/lang/ezm3/work/ezm3-1.0/libs/libm3/src/uid/Common/TimeStamp.m3", line 63 *** ------------------ EXCEPTION HANDLER STACK --------------------- 0x11ffa118 LOCK mutex = 0x120190720 0x11ffa108 RAISES {} 0x11ffa1b8 RAISES {} 0x11ffb638 TRY-FINALLY proc = 0x12002ea10 frame = 0x11ffa2f8 0x11ffb0c0 TRY-EXCEPT {Main.Error} 0x11ffab48 TRY-EXCEPT {Thread.Alerted} ---------------------------------------------------------------- Abort trap (core dumped) >How-To-Repeat: Install FreeBSD 4.5-RELEASE on an AlphaStation 400 4/233. Install the cvsup (or cvsup-without-gui) package built for Alpha. Try and cvsup using one of the supplied ports-supfile or stable-supfile. cvsup will then core dump. >Fix: >Release-Note: >Audit-Trail: >Unformatted: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Mar 27 17:35:43 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id D774B37B41D; Wed, 27 Mar 2002 17:34:29 -0800 (PST) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g2S1YTf25957; Wed, 27 Mar 2002 17:34:29 -0800 (PST) (envelope-from mjacob@feral.com) Date: Wed, 27 Mar 2002 17:34:29 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: alpha@FreeBSD.ORG Subject: Re: Please test GEOM in -current... In-Reply-To: <61229.1016981720@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sun, 24 Mar 2002, Poul-Henning Kamp wrote: > > I belive that alpha BSD disklabels are now correctly handled in > GEOM and would therefore appreciate if somebody could enable the > GEOM option in a current kernel and tell me if I am right or not. > > Further more, if somebody could try to swap disks between an alpha > and an i386 and tell me if the both recognize the "alien" disklabels > when GEOM is enabled, that would be doubly nice. > > In fact, for ultimate h0h0 effect, you can try to stick a disk > from a solaris machine into your alpha: it should recognize > the partitioning on that as well. > It's all quite verbose, so it's a bit hard to figure out what's what for Alpha. Also, it *appeared* to blow up in my face on a system that had an IDE drive as the root device- but I'm trying to ascertain whether that was really the case right now. That system was also the one on the same fabric as Solaris labelled disks.... -matt sio1: gdb debugging port Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #8: Wed Mar 27 16:58:21 PST 2002 mjacob@nellie.feral.com:/tstsys/alpha/compile/GPLUS Preloaded elf kernel "/boot/kernel/kernel" at 0xfffffc000087c000. Preloaded elf module "/boot/kernel/ispfw.ko" at 0xfffffc000087c0d0. AlphaServer 4100 AlphaServer 4100 5/533 4MB, 531MHz 8192 byte page size, 4 processors. CPU: EV56 (21164A) major=7 minor=2 extensions=0x1 OSF PAL rev: 0x4000100020117 real memory = 534757376 (522224K bytes) Physical memory chunk(s): 0x0089e000 - 0x1fff3fff, 527785984 bytes (64427 pages) avail memory = 512311296 (500304K bytes) smp_start_secondary: starting cpu 1 smp_start_secondary: cpu 1 started smp_start_secondary: starting cpu 2 smp_start_secondary: cpu 2 started smp_start_secondary: starting cpu 3 smp_start_secondary: cpu 3 started FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs null: random: mem: mcbus0: pcib0: at mcbus0 gid 7 mid 5 pcib0: Horse Revision 3, Left Handed Saddle Revision 3, CAP Revision 2 pci0: physical bus=0 map[10]: type 4, range 32, base 01fffd00, size 8, enabled map[14]: type 1, range 32, base 07feee00, size 8, enabled found-> vendor=0x1000, dev=0x0001, revid=0x02 bus=0, slot=1, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=4 map[10]: type 4, range 32, base 01fffe00, size 7, enabled map[14]: type 1, range 32, base 07feef00, size 7, enabled found-> vendor=0x1011, dev=0x0009, revid=0x12 bus=0, slot=2, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=8 map[10]: type 4, range 32, base 01ffff00, size 8, enabled map[14]: type 1, range 32, base 07fef000, size 12, enabled found-> vendor=0x1077, dev=0x1020, revid=0x05 bus=0, slot=5, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=20 pci0: on pcib0 sym0: <810> port 0x1fffd00-0x1fffdff mem 0x7feee00-0x7feeeff irq 4 at device 1.0 on pci0 sym0: No NVRAM, ID 7, Fast-10, SE, parity checking sym0: open drain IRQ line driver sym0: using NCR-generic firmware. sym0: initial SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 00/00/00/00/00/00 sym0: final SCNTL3/DMODE/DCNTL/CTEST3/4/5 = (hex) 03/c8/00/00/08/00 sym0: Delay (GEN=11): 266 msec, 33414 KHz sym0: Delay (GEN=11): 283 msec, 31407 KHz sym0: Delay (GEN=11): 282 msec, 31518 KHz sym0: interrupting at IRQ 0x10 intA (vec 0xb40) de0: port 0x1fffe00-0x1fffe7f mem 0x7feef00-0x7feef7f irq 8 at device 2.0 on pci0 de0: interrupting at IRQ 0x0 intA (vec 0xb80) de0: DEC DE500-XA 21140 [10-100Mb/s] pass 1.2 de0: address 00:00:f8:01:8b:d7 de0: enabling Full Duplex 100baseTX port bpf: de0 attached Qlogic ISP Driver, FreeBSD Version 5.9, Core Version 2.5 isp0: port 0x1ffff00-0x1ffffff mem 0x7fef000-0x7feffff irq 20 at device 5.0 on pci0 isp0: using Memory space register mapping isp0: interrupting at IRQ 0xc intA (vec 0xc40) isp0: Differential Mode isp0: Ultra Mode Capable isp0: Board Type 1040B, Chip Revision 0x5, resident F/W Revision 5.57.1 isp0: Last F/W revision was 5.57.1 isp0: 256 max I/O commands supported isp0: Initiator ID is 7 on Channel 0 pcib1: at mcbus0 gid 7 mid 4 pcib1: Horse Revision 3, Left Handed Saddle Revision 3, CAP Revision 2 pci1: physical bus=0 found-> vendor=0x8086, dev=0x0482, revid=0x15 bus=0, slot=1, func=0 class=00-00-00, hdrtype=0x00, mfdev=0 illegal PCI extended capability offset 256 map[10]: type 4, range 32, base 01fffe00, size 8, enabled map[14]: type 1, range 32, base 07fce000, size 12, enabled found-> vendor=0x1077, dev=0x1080, revid=0x01 bus=0, slot=3, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=12 illegal PCI extended capability offset 256 map[10]: type 4, range 32, base 01ffff00, size 8, enabled map[14]: type 1, range 32, base 07fcf000, size 12, enabled found-> vendor=0x1077, dev=0x2200, revid=0x05 bus=0, slot=5, func=0 class=01-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=20 pci1: on pcib1 eisab0: at device 1.0 on pci1 isa0: on eisab0 isp1: port 0x1fffe00-0x1fffeff mem 0x7fce000-0x7fcefff irq 12 at device 3.0 on pci1 isp1: using Memory space register mapping isp1: interrupting at IRQ 0x4 intA (vec 0x9c0) isp1: bus 0 is in LVD Mode isp1: Board Type 1080, Chip Revision 0x1, resident F/W Revision 8.15.0 isp1: 527 max I/O commands supported isp1: Initiator ID is 6 on Channel 0 isp1: Enabled FW features (0xa) isp2: port 0x1ffff00-0x1ffffff mem 0x7fcf000-0x7fcffff irq 20 at device 5.0 on pci1 isp2: using Memory space register mapping isp2: interrupting at IRQ 0xc intA (vec 0xa40) isp2: Board Type 2200, Chip Revision 0x5, resident F/W Revision 2.1.36 isp2: Installed in 64-Bit PCI slot isp2: 985 max I/O commands supported isp2: NVRAM Port WWN 0x210000e08b016899 Trying Read_Port at 203 Trying Read_Port at 243 Trying Read_Port at 283 Trying Read_Port at 2c3 Trying Read_Port at 303 Trying Read_Port at 343 Trying Read_Port at 383 Trying Read_Port at 3c3 sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices atkbdc0: at port 0x64,0x60 on isa0 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 atkbd0: irq 1 on atkbdc0 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 kbd0: atkbd0, generic (0), config:0x0, flags:0x1f0000 atkbd0: interrupting at ISA irq 1 psm0: current command byte:0061 kbdc: TEST_AUX_PORT status:0000 kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: RESET_AUX return code:00fe kbdc: DIAGNOSE status:0055 kbdc: TEST_KBD_PORT status:0000 psm0: failed to reset the aux device. fdc0: at port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on isa0 fdc0: interrupting at ISA irq 6 mcclock0: at port 0x70-0x71 on isa0 Calibrating clock(s) ... PCC clock: 532792192 Hz (firmware 531914893 Hz) i8254 clock: 1193142 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency ppc0: using extended I/O port range ppc0: SPP ppc0: at port 0x3bc-0x3c3 irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode plip0: cannot reserve interrupt, failed. lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 ppc0: interrupting at ISA irq 7 sc0: no video adapter found. sc0: failed to probe on isa0 sio0: configured irq 4 not in bitmap of probed irqs 0 sio0: port may not be enabled sio0: irq maps: 0 0 0 0 sio0 at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A, console sio0: interrupting at ISA irq 4 sio1: reserved for low-level i/o sio1 failed to probe at port 0x2f8-0x2ff irq 3 flags 0x50 on isa0 vga0: failed to probe on isa0 isa_probe_children: probing PnP devices procfs registered Timecounter "i8254" frequency 1193182 Hz Initializing GEOMetry subsystem g_add_class(BSD-class) g_add_class(MBR-class) g_add_class(MBREXT-class) g_add_class(SUNLABEL-class) g_add_class(DEV-class) bpf: lo0 attached bpf: ppp0 attached Waiting 15 seconds for SCSI devices to settle (noperiph:sym0:0:-1:-1): SCSI BUS reset delivered. isp0: driver initiated bus reset of bus 0 isp1: driver initiated bus reset of bus 0 isp2: LIP Received isp2: Loop UP isp2: Port Database Changed isp2: Port Database Changed isp2: Firmware State Ready> isp2: Target 126 (Loop 0x7e) Port ID 0xfffffe (role (none)) Arrived Port WWN 0x200600c0dd008073 Node WWN 0x100000c0dd008073 isp2: Loop ID 0, AL_PA 0xef, Port ID 0x7006ef, Loop State 0x2, Topology 'FL Port' isp2: Target 0 (Loop 0x0) Port ID 0x7006ef (role Initiator) Arrived Port WWN 0x210000e08b016899 Node WWN 0x200000e08b016899 isp2: NL_Port @ 0x7f04bc, Node 0x200000203726216b Port 210000203726216b isp2: NL_Port @ 0x7f04c3, Node 0x200000203700c39a Port 210000203700c39a isp2: NL_Port @ 0x7f04c5, Node 0x200000203700c3ac Port 210000203700c3ac isp2: NL_Port @ 0x7f04c6, Node 0x2000002037083e9b Port 2100002037083e9b isp2: NL_Port @ 0x7f04c7, Node 0x2000002037083e13 Port 2100002037083e13 isp2: NL_Port @ 0x7f04c9, Node 0x200000203700c350 Port 210000203700c350 isp2: NL_Port @ 0x7f04ca, Node 0x20000020370094e0 Port 21000020370094e0 isp2: NL_Port @ 0x7f04cb, Node 0x200000203700955f Port 210000203700955f isp2: NL_Port @ 0x7f04cc, Node 0x200000203700c3a0 Port 210000203700c3a0 isp2: NL_Port @ 0x7f04cd, Node 0x20000020370096a1 Port 21000020370096a1 isp2: N_Port @ 0x7f0c00, Node 0x200000e08b06ceb6 Port 210000e08b06ceb6 isp2: NL_Port @ 0x70002d, Node 0x200000e08b00e3d8 Port 210000e08b00e3d8 isp2: NL_Port @ 0x7002e1, Node 0x20000020370f847e Port 21000020370f847e isp2: NL_Port @ 0x7002e2, Node 0x20000020370fa077 Port 21000020370fa077 isp2: NL_Port @ 0x7002e4, Node 0x20000020370f83c0 Port 21000020370f83c0 isp2: NL_Port @ 0x7002e8, Node 0x20000020370f848e Port 21000020370f848e isp2: NL_Port @ 0x7006ef, Node 0x200000e08b016899 Port 210000e08b016899 isp2: Retaining Loop ID 0x7e for Target 126 (Port 0xfffffe) isp2: Target 129 (Loop 0x82) Port ID 0x7f04bc (role Target) Arrived Port WWN 0x210000203726216b Node WWN 0x200000203726216b isp2: Target 130 (Loop 0x83) Port ID 0x7f04c3 (role Target) Arrived Port WWN 0x210000203700c39a Node WWN 0x200000203700c39a isp2: Target 131 (Loop 0x84) Port ID 0x7f04c5 (role Target) Arrived Port WWN 0x210000203700c3ac Node WWN 0x200000203700c3ac isp2: Target 132 (Loop 0x85) Port ID 0x7f04c6 (role Target) Arrived Port WWN 0x2100002037083e9b Node WWN 0x2000002037083e9b isp2: Target 133 (Loop 0x86) Port ID 0x7f04c7 (role Target) Arrived Port WWN 0x2100002037083e13 Node WWN 0x2000002037083e13 isp2: Target 134 (Loop 0x87) Port ID 0x7f04c9 (role Target) Arrived Port WWN 0x210000203700c350 Node WWN 0x200000203700c350 isp2: Target 135 (Loop 0x88) Port ID 0x7f04ca (role Target) Arrived Port WWN 0x21000020370094e0 Node WWN 0x20000020370094e0 isp2: Target 136 (Loop 0x89) Port ID 0x7f04cb (role Target) Arrived Port WWN 0x210000203700955f Node WWN 0x200000203700955f isp2: Target 137 (Loop 0x8a) Port ID 0x7f04cc (role Target) Arrived Port WWN 0x210000203700c3a0 Node WWN 0x200000203700c3a0 isp2: Target 138 (Loop 0x8b) Port ID 0x7f04cd (role Target) Arrived Port WWN 0x21000020370096a1 Node WWN 0x20000020370096a1 isp2: Target 139 (Loop 0x8c) Port ID 0x7f0c00 (role Initiator) Arrived Port WWN 0x210000e08b06ceb6 Node WWN 0x200000e08b06ceb6 isp2: Target 140 (Loop 0x8d) Port ID 0x70002d (role Initiator) Arrived Port WWN 0x210000e08b00e3d8 Node WWN 0x200000e08b00e3d8 isp2: Target 141 (Loop 0x8e) Port ID 0x7002e1 (role Target) Arrived Port WWN 0x21000020370f847e Node WWN 0x20000020370f847e isp2: Target 142 (Loop 0x8f) Port ID 0x7002e2 (role Target) Arrived Port WWN 0x21000020370fa077 Node WWN 0x20000020370fa077 isp2: Target 143 (Loop 0x90) Port ID 0x7002e4 (role Target) Arrived Port WWN 0x21000020370f83c0 Node WWN 0x20000020370f83c0 isp2: Target 144 (Loop 0x91) Port ID 0x7002e8 (role Target) Arrived Port WWN 0x21000020370f848e Node WWN 0x20000020370f848e (probe167:isp2:0:130:0): Retrying Command(1) (probe169:isp2:0:132:0): Retrying Command(1) (probe173:isp2:0:136:0): Retrying Command(1) (probe178:isp2:0:141:0): Retrying Command(1) (probe179:isp2:0:142:0): Retrying Command(1) (probe175:isp2:0:138:0): Retrying Command(1) (probe181:isp2:0:144:0): Retrying Command(1) (probe166:isp2:0:129:0): Retrying Command(1) (probe168:isp2:0:131:0): Retrying Command(1) (probe170:isp2:0:133:0): Retrying Command(1) (probe171:isp2:0:134:0): Retrying Command(1) (probe172:isp2:0:135:0): Retrying Command(1) (probe174:isp2:0:137:0): Retrying Command(1) (probe180:isp2:0:143:0): Retrying Command(1) (probe10:isp0:0:3:0): Retrying Command(1) (probe14:isp0:0:8:0): Retrying Command(1) (probe7:isp0:0:0:0): Retrying Command(1) (probe8:isp0:0:1:0): Retrying Command(1) (probe9:isp0:0:2:0): Retrying Command(1) (probe16:isp0:0:10:0): Retrying Command(1) (probe15:isp0:0:9:0): Retrying Command(1) (probe5:sym0:0:5:0): Retrying Command(1) (probe5:sym0:0:5:0): error 22 (probe5:sym0:0:5:0): Unretryable Error g_add_class(DISK-class) g_post_event(1, 0, 0, 0xfffffe0016e6f880, 0) g_post_event(1, 0, 0, 0xfffffe0016e6fb00, 0) g_post_event(1, 0, 0, 0xfffffe0016dd5900, 0) g_post_event(1, 0, 0, 0xfffffe0016ccb780, 0) g_post_event(1, 0, 0, 0xfffffe0016e6f800, 0) g_post_event(1, 0, 0, 0xfffffe0016e6ea00, 0) g_post_event(1, 0, 0, 0xfffffe0016d8ec00, 0) g_post_event(1, 0, 0, 0xfffffe0016e6e500, 0) g_post_event(1, 0, 0, 0xfffffe0016e6e880, 0) g_post_event(1, 0, 0, 0xfffffe0016e21e00, 0) g_post_event(1, 0, 0, 0xfffffe0016e6e580, 0) g_post_event(1, 0, 0, 0xfffffe0016e6e300, 0) g_post_event(1, 0, 0, 0xfffffe0016ccbb80, 0) g_post_event(1, 0, 0, 0xfffffe0016e21c00, 0) g_post_event(1, 0, 0, 0xfffffe0016e6e200, 0) g_post_event(1, 0, 0, 0xfffffe0016e6f180, 0) g_post_event(1, 0, 0, 0xfffffe0016dd5200, 0) g_post_event(1, 0, 0, 0xfffffe0016dd5a00, 0) g_post_event(1, 0, 0, 0xfffffe0016eb3c80, 0) g_post_event(1, 0, 0, 0xfffffe0016ccb100, 0) g_post_event(1, 0, 0, 0xfffffe0016ccb400, 0) g_post_event(1, 0, 0, 0xfffffe0016ccb700, 0) pass0 at sym0 bus 0 target 5 lun 0 pass0: Removable CD-ROM SCSI-2 device pass0: 10.000MB/s transfers (10.000MHz, offset 8) pass1 at sym0 bus 0 target 6 lun 0 pass1: Removable Sequential Access SCSI-2 device pass1: Serial Number 0003203169 pass1: 10.000MB/s transfers (10.000MHz, offset 8) pass2 at isp0 bus 0 target 0 lun 0 pass2: Fixed Direct Access SCSI-2 device pass2: Serial Number 5U5Z9126 g_do_event(0xfffffe0016bf0880) 1 m:0 g:0 p:0xfffffe0016e6f880 c:0 - EV_NEW_PROVIDER(cd0) dev_taste(DEV-class,cd0) pass2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled pass3 at isp0 bus 0 target 1 lun 0 pass3: Fixed Direct Access SCSI-2 device pass3: Serial Number JDY591270SXELP pass3: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled pass4 at isp0 bus 0 target 2 lun 0 pass4: Fixed Direct Access SCSI-2 device pass4: Serial Number 174708531988 pass4: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled pass5 at isp0 bus 0 target 3 lun 0 pass5: Fixed Direct Access SCSI-2 device pass5: Serial Number EG959RV pass5: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) pass6 at isp0 bus 0 target 8 lun 0 pass6: Fixed Direct Access SCSI-2 device pass6: Serial Number EG95AEA pass6: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) pass7 at isp0 bus 0 target 9 lun 0 pass7: Fixed Direct Access SCSI-2 device pass7: Serial Number LR2745110000100635B5 pass7: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled pass8 at isp0 bus 0 target 10 lun 0 pass8: Fixed Direct Access SCSI-2 device pass8: Serial Number 174708632521 pass8: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled pass9 at isp0 bus 0 target 14 lun 0 pass9: Fixed Processor SCSI-2 device pass9: Serial Number 1 pass9: 3.300MB/s transfers pass10 at isp0 bus 0 target 15 lun 0 pass10: Fixed Processor SCSI-2 device pass10: Serial Number 1 pass10: 3.300MB/s transfers pass11 at isp2 bus 0 target 129 lun 0 pass11: Fixed Direct Access SCSI-2 device pass11: Serial Number LJR396410000294601KM pass11: 100.000MB/s transfers, Tagged Queueing Enabled pass12 at isp2 bus 0 target 130 lun 0 pass12: Fixed Direct Access SCSI-2 device pass12: Serial Number LJ7625860000291908YL pass12: 100.000MB/s transfers, Tagged Queueing Enabled pass13 at isp2 bus 0 target 131 lun 0 pass13: Fixed Direct Access SCSI-2 device pass13: Serial Number LJ7627710000291908DU pass13: 100.000MB/s transfers, Tagged Queueing Enabled pass14 at isp2 bus 0 target 132 lun 0 pass14: Fixed Direct Access SCSI-2 device pass14: Serial Number LJA174130000292103HC pass14: 100.000MB/s transfers, Tagged Queueing Enabled pass15 at isp2 bus 0 target 133 lun 0 pass15: Fixed Direct Access SCSI-2 device pass15: Serial Number LJA19587000029210B5B pass15: 100.000MB/s transfers, Tagged Queueing Enabled pass16 at isp2 bus 0 target 134 lun 0 pass16: Fixed Direct Access SCSI-2 device pass16: Serial Number LJ74959500002919083X pass16: 100.000MB/s transfers, Tagged Queueing Enabled pass17 at isp2 bus 0 target 135 lun 0 pass17: Fixed Direct Access SCSI-2 device pass17: Serial Number NJ1200430000H8450JP3 pass17: 100.000MB/s transfers, Tagged Queueing Enabled pass18 at isp2 bus 0 target 136 lun 0 pass18: Fixed Direct Access SCSI-2 device pass18: Serial Number NJ1151800000H8440HED pass18: 100.000MB/s transfers, Tagged Queueing Enabled pass19 at isp2 bus 0 target 137 lun 0 pass19: Fixed Direct Access SCSI-2 device pass19: Serial Number LJ762695000029190ACX pass19: 100.000MB/s transfers, Tagged Queueing Enabled pass20 at isp2 bus 0 target 138 lun 0 pass20: Fixed Direct Access SCSI-2 device pass20: Serial Number NJ11513800002918H5HW pass20: 100.000MB/s transfers, Tagged Queueing Enabled pass21 at isp2 bus 0 target 141 lun 0 pass21: Fixed Direct Access SCSI-2 device pass21: Serial Number LJ50954400002911JBH9 pass21: 100.000MB/s transfers, Tagged Queueing Enabled pass22 at isp2 bus 0 target 142 lun 0 pass22: Fixed Direct Access SCSI-2 device pass22: Serial Number LJ52164600002912K0DL pass22: 100.000MB/s transfers, Tagged Queueing Enabled pass23 at isp2 bus 0 target 143 lun 0 pass23: Fixed Direct Access SCSI-2 device pass23: Serial Number LJ51715600002911K2H0 pass23: 100.000MB/s transfers, Tagged Queueing Enabled pass24 at isp2 bus 0 target 144 lun 0 pass24: Fixed Direct Access SCSI-2 device pass24: Serial Number LJ51658000002912H5VS pass24: 100.000MB/s transfers, Tagged Queueing Enabled sa0 at sym0 bus 0 target 6 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: Serial Number 0003203169 sa0: 10.000MB/s transfers (10.000MHz, offset 8) ses0 at isp0 bus 0 target 14 lun 0 ses0: Fixed Processor SCSI-2 device ses0: Serial Number 1 ses0: 3.300MB/s transfers ses0: SAF-TE Compliant Device ses1 at isp0 bus 0 target 15 lun 0 ses1: Fixed Processor SCSI-2 device ses1: Serial Number 1 ses1: 3.300MB/s transfers ses1: SAF-TE Compliant Device da0 at isp0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: Serial Number 5U5Z9126 da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) da7 at isp2 bus 0 target 129 lun 0 da7: Fixed Direct Access SCSI-2 device da7: Serial Number LJR396410000294601KM da7: 100.000MB/s transfers, Tagged Queueing Enabled da7: 8637MB (17689267 512 byte sectors: 255H 63S/T 1101C) da8 at isp2 bus 0 target 130 lun 0 da8: Fixed Direct Access SCSI-2 device da8: Serial Number LJ7625860000291908YL da8: 100.000MB/s transfers, Tagged Queueing Enabled da8: 8625MB (17664229 512 byte sectors: 255H 63S/T 1099C) da9 at isp2 bus 0 target 131 lun 0 da9: Fixed Direct Access SCSI-2 device da9: Serial Number LJ7627710000291908DU da9: 100.000MB/s transfers, Tagged Queueing Enabled da9: 8625MB (17664229 512 byte sectors: 255H 63S/T 1099C) da10 at isp2 bus 0 target 132 lun 0 da10: Fixed Direct Access SCSI-2 device da10: Serial Number LJA174130000292103HC da10: 100.000MB/s transfers, Tagged Queueing Enabled da10: 8625MB (17664229 512 byte sectors: 255H 63S/T 1099C) da11 at isp2 bus 0 target 133 lun 0 da11: Fixed Direct Access SCSI-2 device da11: Serial Number LJA19587000029210B5B da11: 100.000MB/s transfers, Tagged Queueing Enabled da11: 8625MB (17664229 512 byte sectors: 255H 63S/T 1099C) da12 at isp2 bus 0 target 134 lun 0 da12: Fixed Direct Access SCSI-2 device da12: Serial Number LJ74959500002919083X da12: 100.000MB/s transfers, Tagged Queueing Enabled da12: 8748MB (17917393 512 byte sectors: 255H 63S/T 1115C) da13 at isp2 bus 0 target 135 lun 0 da13: Fixed Direct Access SCSI-2 device da13: Serial Number NJ1200430000H8450JP3 da13: 100.000MB/s transfers, Tagged Queueing Enabled da13: 8748MB (17917393 512 byte sectors: 255H 63S/T 1115C) da14 at isp2 bus 0 target 136 lun 0 da14: Fixed Direct Access SCSI-2 device da14: Serial Number NJ1151800000H8440HED da14: 100.000MB/s transfers, Tagged Queueing Enabled da14: 8748MB (17917393 512 byte sectors: 255H 63S/T 1115C) da15 at isp2 bus 0 target 137 lun 0 da15: Fixed Direct Access SCSI-2 device da15: Serial Number LJ762695000029190ACX da15: 100.000MB/s transfers, Tagged Queueing Enabled da15: 8748MB (17917393 512 byte sectors: 255H 63S/T 1115C) da16 at isp2 bus 0 target 138 lun 0 da16: Fixed Direct Access SCSI-2 device da16: Serial Number NJ11513800002918H5HW da16: 100.000MB/s transfers, Tagged Queueing Enabled da16: 8748MB (17917393 512 byte sectors: 255H 63S/T 1115C) da17 at isp2 bus 0 target 141 lun 0 da17: Fixed Direct Access SCSI-2 device da17: Serial Number LJ50954400002911JBH9 da17: 100.000MB/s transfers, Tagged Queueing Enabled da17: 8625MB (17664229 512 byte sectors: 255H 63S/T 1099C) da18 at isp2 bus 0 target 142 lun 0 da18: Fixed Direct Access SCSI-2 device da18: Serial Number LJ52164600002912K0DL da18: 100.000MB/s transfers, Tagged Queueing Enabled da18: 8625MB (17664229 512 byte sectors: 255H 63S/T 1099C) da19 at isp2 bus 0 target 143 lun 0 da19: Fixed Direct Access SCSI-2 device da19: Serial Number LJ51715600002911K2H0 da19: 100.000MB/s transfers, Tagged Queueing Enabled da19: 8625MB (17664229 512 byte sectors: 255H 63S/T 1099C) da20 at isp2 bus 0 target 144 lun 0 da20: Fixed Direct Access SCSI-2 device da20: Serial Number LJ51658000002912H5VS da20: 100.000MB/s transfers, Tagged Queueing Enabled da20: 8625MB (17664229 512 byte sectors: 255H 63S/T 1099C) da1 at isp0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: Serial Number JDY591270SXELP da1: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da1: 4094MB (8385121 512 byte sectors: 255H 63S/T 521C) da2 at isp0 bus 0 target 2 lun 0 da2: Fixed Direct Access SCSI-2 device da2: Serial Number 174708531988 da2: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da2: 4094MB (8385121 512 byte sectors: 255H 63S/T 521C) da3 at isp0 bus 0 target 3 lun 0 da3: Fixed Direct Access SCSI-2 device da3: Serial Number EG959RV da3: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) da3: 2048MB (4194304 512 byte sectors: 255H 63S/T 261C) da4 at isp0 bus 0 target 8 lun 0 da4: Fixed Direct Access SCSI-2 device da4: Serial Number EG95AEA da4: 20.000MB/s transfers (10.000MHz, offset 8, 16bit) da4: 2048MB (4194304 512 byte sectors: 255H 63S/T 261C) da5 at isp0 bus 0 target 9 lun 0 da5: Fixed Direct Access SCSI-2 device da5: Serial Number LR2745110000100635B5 da5: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da5: 17366MB (35566480 512 byte sectors: 255H 63S/T 2213C) da6 at isp0 bus 0 target 10 lun 0 da6: Fixed Direct Access SCSI-2 device da6: Serial Number 174708632521 da6: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da6: 4094MB (8385121 512 byte sectors: 255H 63S/T 521C) (cd0:sym0:0:5:0): error 6 (cd0:sym0:0:5:0): Unretryable Error cd0 at sym0 bus 0 target 5 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 8) cd0: Attempt to query device size failed: NOT READY, Medium not present release_aps: releasing secondary CPUs SMP: AP CPU #2 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #1 Launched! Mounting root from ufs:/dev/da2a g_dev_clone(da2a) (cd0:sym0:0:5:0): error 6 (cd0:sym0:0:5:0): Unretryable Error Opened disk cd0 -> 6 GEOM: "cd0" (size unavailable) g_sunlabel_taste(SUNLABEL-class,cd0) (cd0:sym0:0:5:0): error 6 (cd0:sym0:0:5:0): Unretryable Error Opened disk cd0 -> 6 g_dettach(0xfffffe0016d8e500) g_destroy_consumer(0xfffffe0016d8e500) g_destroy_geom(0xfffffe0016d8e680(cd0)) g_mbrext_taste(MBREXT-class,cd0) mbr_taste(MBR-class,cd0) (cd0:sym0:0:5:0): error 6 (cd0:sym0:0:5:0): Unretryable Error Opened disk cd0 -> 6 g_dettach(0xfffffe0016eb4080) g_destroy_consumer(0xfffffe0016eb4080) g_destroy_geom(0xfffffe0016eb3d80(cd0)) bsd_taste(BSD-class,cd0) (cd0:sym0:0:5:0): error 6 (cd0:sym0:0:5:0): Unretryable Error Opened disk cd0 -> 6 g_dettach(0xfffffe0016e20c80) g_destroy_consumer(0xfffffe0016e20c80) g_destroy_geom(0xfffffe0016e20c00(cd0)) g_do_event(0xfffffe0016bf0940) 1 m:0 g:0 p:0xfffffe0016e6fb00 c:0 - EV_NEW_PROVIDER(da0) dev_taste(DEV-class,da0) GEOM: "da0" 2164083200 bytes in 4226725 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da0) g_std_spoiled(0xfffffe0016dd4c80) g_dettach(0xfffffe0016dd4c80) g_destroy_consumer(0xfffffe0016dd4c80) g_destroy_geom(0xfffffe0016dd5100(da0)) g_mbrext_taste(MBREXT-class,da0) mbr_taste(MBR-class,da0) g_std_spoiled(0xfffffe0016eb3f00) g_dettach(0xfffffe0016eb3f00) g_destroy_consumer(0xfffffe0016eb3f00) g_destroy_geom(0xfffffe0016ccad80(da0)) bsd_taste(BSD-class,da0) 0000 57 45 56 82 04 00 00 00 00 00 00 00 00 00 00 00 |WEV.............| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 0030 ff 00 00 00 07 01 00 00 c1 3e 00 00 47 78 40 00 |.........>..Gx@.| 0040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0080 00 00 00 00 57 45 56 82 f4 3e 03 00 00 20 00 00 |....WEV..>... ..| 0090 00 20 00 00 c1 3e 00 00 00 00 00 00 00 00 00 00 |. ...>..........| 00a0 08 00 00 00 f1 02 0c 00 c1 3e 00 00 00 00 00 00 |.........>......| 00b0 01 00 00 00 95 36 34 00 b2 41 0c 00 00 00 00 00 |.....64..A......| 00c0 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0110 00 00 00 00 00 00 00 00 |........ | g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016dd5000, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016dd4a00, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016e20e00, 0) g_do_event(0xfffffe0016bf09c0) 1 m:0 g:0 p:0xfffffe0016dd5900 c:0 - EV_NEW_PROVIDER(da1) dev_taste(DEV-class,da1) GEOM: "da1" 4293181952 bytes in 8385121 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da1) g_std_spoiled(0xfffffe0016e21700) g_dettach(0xfffffe0016e21700) g_destroy_consumer(0xfffffe0016e21700) g_destroy_geom(0xfffffe0016e21680(da1)) g_mbrext_taste(MBREXT-class,da1) mbr_taste(MBR-class,da1) g_std_spoiled(0xfffffe0016e21380) g_dettach(0xfffffe0016e21380) g_destroy_consumer(0xfffffe0016e21380) g_destroy_geom(0xfffffe0016e21100(da1)) bsd_taste(BSD-class,da1) 0000 57 45 56 82 04 00 00 00 53 45 41 47 41 54 45 20 |WEV.....SEAGATE | 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 0030 ff 00 00 00 09 02 00 00 c1 3e 00 00 61 f2 7f 00 |.........>..a...| 0040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0080 00 00 00 00 57 45 56 82 16 22 08 00 00 20 00 00 |....WEV.."... ..| 0090 00 20 00 00 2c 8a 49 00 00 00 00 00 00 04 00 00 |. ..,.I.........| 00a0 07 08 10 00 35 68 36 00 2c 8a 49 00 00 00 00 00 |....5h6.,.I.....| 00b0 01 00 00 00 61 f2 7f 00 00 00 00 00 00 00 00 00 |....a...........| 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0110 00 00 00 00 00 00 00 00 |........ | g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016eb4000, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016eb4100, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016e21900, 0) g_do_event(0xfffffe0016bf0a40) 1 m:0 g:0 p:0xfffffe0016ccb780 c:0 - EV_NEW_PROVIDER(da2) dev_taste(DEV-class,da2) GEOM: "da2" 4293181952 bytes in 8385121 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da2) g_std_spoiled(0xfffffe0016e21980) g_dettach(0xfffffe0016e21980) g_destroy_consumer(0xfffffe0016e21980) g_destroy_geom(0xfffffe0016e21880(da2)) g_mbrext_taste(MBREXT-class,da2) mbr_taste(MBR-class,da2) g_std_spoiled(0xfffffe0016d8f080) g_dettach(0xfffffe0016d8f080) g_destroy_consumer(0xfffffe0016d8f080) g_destroy_geom(0xfffffe0016e21600(da2)) bsd_taste(BSD-class,da2) 0000 57 45 56 82 04 00 00 00 51 55 41 4e 54 55 4d 20 |WEV.....QUANTUM | 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 0030 ff 00 00 00 09 02 00 00 c1 3e 00 00 61 f2 7f 00 |.........>..a...| 0040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0080 00 00 00 00 57 45 56 82 76 14 08 00 00 20 00 00 |....WEV.v.... ..| 0090 00 20 00 00 05 ab 4f 00 00 00 00 00 00 04 00 00 |. ....O.........| 00a0 07 08 00 01 5c 47 30 00 05 ab 4f 00 00 00 00 00 |....\G0...O.....| 00b0 01 00 00 00 61 f2 7f 00 00 00 00 00 00 00 00 00 |....a...........| 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0110 00 00 00 00 00 00 00 00 |........ | g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016d8f180, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016d8f280, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016d8f380, 0) g_do_event(0xfffffe0016bf0ac0) 1 m:0 g:0 p:0xfffffe0016e6f800 c:0 - EV_NEW_PROVIDER(da3) dev_taste(DEV-class,da3) GEOM: "da3" 2147483648 bytes in 4194304 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da3) g_std_spoiled(0xfffffe0016d8f480) g_dettach(0xfffffe0016d8f480) g_destroy_consumer(0xfffffe0016d8f480) g_destroy_geom(0xfffffe0016d8f500(da3)) g_mbrext_taste(MBREXT-class,da3) mbr_taste(MBR-class,da3) g_std_spoiled(0xfffffe0016eb3800) g_dettach(0xfffffe0016eb3800) g_destroy_consumer(0xfffffe0016eb3800) g_destroy_geom(0xfffffe0016eb3980(da3)) bsd_taste(BSD-class,da3) g_std_spoiled(0xfffffe0016e21d00) g_dettach(0xfffffe0016e21d00) g_destroy_consumer(0xfffffe0016e21d00) g_destroy_geom(0xfffffe0016e21c80(da3)) g_do_event(0xfffffe0016bf0b40) 1 m:0 g:0 p:0xfffffe0016e6ea00 c:0 - EV_NEW_PROVIDER(da4) dev_taste(DEV-class,da4) GEOM: "da4" 2147483648 bytes in 4194304 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da4) g_std_spoiled(0xfffffe0016e6e600) g_dettach(0xfffffe0016e6e600) g_destroy_consumer(0xfffffe0016e6e600) g_destroy_geom(0xfffffe0016e6e400(da4)) g_mbrext_taste(MBREXT-class,da4) mbr_taste(MBR-class,da4) g_std_spoiled(0xfffffe0016e6e980) g_dettach(0xfffffe0016e6e980) g_destroy_consumer(0xfffffe0016e6e980) g_destroy_geom(0xfffffe0016e6e700(da4)) bsd_taste(BSD-class,da4) 0000 57 45 56 82 04 00 00 00 43 4f 4e 4e 45 52 20 20 |WEV.....CONNER | 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 0030 ff 00 00 00 05 01 00 00 c1 3e 00 00 00 00 40 00 |.........>....@.| 0040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0080 00 00 00 00 57 45 56 82 26 4c 08 00 00 20 00 00 |....WEV.&L... ..| 0090 00 20 00 00 00 00 40 00 00 00 00 00 00 04 00 00 |. ....@.........| 00a0 07 08 10 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00b0 00 00 00 00 00 00 40 00 00 00 00 00 00 00 00 00 |......@.........| 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0110 00 00 00 00 00 00 00 00 |........ | g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016eb3280, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016eb3200, 0) g_do_event(0xfffffe0016bf0bc0) 1 m:0 g:0 p:0xfffffe0016d8ec00 c:0 - EV_NEW_PROVIDER(da5) dev_taste(DEV-class,da5) GEOM: "da5" 18210037760 bytes in 35566480 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da5) g_std_spoiled(0xfffffe0016eb3100) g_dettach(0xfffffe0016eb3100) g_destroy_consumer(0xfffffe0016eb3100) g_destroy_geom(0xfffffe0016eb3180(da5)) g_mbrext_taste(MBREXT-class,da5) mbr_taste(MBR-class,da5) g_std_spoiled(0xfffffe0016ccb280) g_dettach(0xfffffe0016ccb280) g_destroy_consumer(0xfffffe0016ccb280) g_destroy_geom(0xfffffe0016dd4780(da5)) bsd_taste(BSD-class,da5) 0000 57 45 56 82 04 00 00 00 53 45 41 47 41 54 45 20 |WEV.....SEAGATE | 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 0030 ff 00 00 00 a5 08 00 00 c1 3e 00 00 90 b3 1e 02 |.........>......| 0040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0080 00 00 00 00 57 45 56 82 36 e9 08 00 00 20 00 00 |....WEV.6.... ..| 0090 00 20 00 00 90 b3 1e 02 00 00 00 00 00 10 00 00 |. ..............| 00a0 07 04 10 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00b0 00 00 00 00 90 b3 1e 02 00 00 00 00 00 00 00 00 |................| 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0110 00 00 00 00 00 00 00 00 |........ | g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016dd4900, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016dd4180, 0) g_do_event(0xfffffe0016bf1240) 1 m:0 g:0 p:0xfffffe0016e6e500 c:0 - EV_NEW_PROVIDER(da6) dev_taste(DEV-class,da6) GEOM: "da6" 4293181952 bytes in 8385121 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da6) g_std_spoiled(0xfffffe0016dd4000) g_dettach(0xfffffe0016dd4000) g_destroy_consumer(0xfffffe0016dd4000) g_destroy_geom(0xfffffe0016d8ff00(da6)) g_mbrext_taste(MBREXT-class,da6) mbr_taste(MBR-class,da6) g_std_spoiled(0xfffffe0016d8f780) g_dettach(0xfffffe0016d8f780) g_destroy_consumer(0xfffffe0016d8f780) g_destroy_geom(0xfffffe0016d8fc80(da6)) bsd_taste(BSD-class,da6) 0000 57 45 56 82 00 00 00 00 6d 69 6e 69 6d 75 6d 32 |WEV.....minimum2| 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0020 00 00 00 00 00 00 00 00 00 02 00 00 80 16 00 00 |................| 0030 01 00 00 00 01 00 00 00 80 16 00 00 80 16 00 00 |................| 0040 00 00 00 00 00 00 00 00 2c 01 01 00 00 00 00 00 |........,.......| 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0080 00 00 00 00 57 45 56 82 ac 52 03 00 00 20 00 00 |....WEV..R... ..| 0090 00 20 00 00 80 16 00 00 00 00 00 00 00 02 00 00 |. ..............| 00a0 00 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00b0 00 00 00 00 80 16 00 00 00 00 00 00 00 02 00 00 |................| 00c0 07 08 06 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0110 00 00 00 00 00 00 00 00 |........ | g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016dd4080, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016dd4200, 0) g_do_event(0xfffffe0016bf0c40) 1 m:0 g:0 p:0xfffffe0016e6e880 c:0 - EV_NEW_PROVIDER(da7) dev_taste(DEV-class,da7) GEOM: "da7" 9056904704 bytes in 17689267 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da7) g_std_spoiled(0xfffffe0016dd4380) g_dettach(0xfffffe0016dd4380) g_destroy_consumer(0xfffffe0016dd4380) g_destroy_geom(0xfffffe0016dd4300(da7)) g_mbrext_taste(MBREXT-class,da7) mbr_taste(MBR-class,da7) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016d8e100, 0) bsd_taste(BSD-class,da7) g_std_spoiled(0xfffffe0016d8f980) g_dettach(0xfffffe0016d8f980) g_destroy_consumer(0xfffffe0016d8f980) g_destroy_geom(0xfffffe0016d8fa00(da7)) g_do_event(0xfffffe0016bf0cc0) 1 m:0 g:0 p:0xfffffe0016e21e00 c:0 - EV_NEW_PROVIDER(da8) dev_taste(DEV-class,da8) GEOM: "da8" 9044085248 bytes in 17664229 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da8) g_std_spoiled(0xfffffe0016eb2f00) g_dettach(0xfffffe0016eb2f00) g_destroy_consumer(0xfffffe0016eb2f00) g_destroy_geom(0xfffffe0016eb2f80(da8)) g_mbrext_taste(MBREXT-class,da8) mbr_taste(MBR-class,da8) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016d8f100, 0) bsd_taste(BSD-class,da8) g_std_spoiled(0xfffffe0016d8f600) g_dettach(0xfffffe0016d8f600) g_destroy_consumer(0xfffffe0016d8f600) g_destroy_geom(0xfffffe0016d8ef80(da8)) g_do_event(0xfffffe0016bf0d40) 1 m:0 g:0 p:0xfffffe0016e6e580 c:0 - EV_NEW_PROVIDER(da9) dev_taste(DEV-class,da9) GEOM: "da9" 9044085248 bytes in 17664229 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da9) g_std_spoiled(0xfffffe0016dd4a80) g_dettach(0xfffffe0016dd4a80) g_destroy_consumer(0xfffffe0016dd4a80) g_destroy_geom(0xfffffe0016dd4980(da9)) g_mbrext_taste(MBREXT-class,da9) mbr_taste(MBR-class,da9) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016ccaf80, 0) bsd_taste(BSD-class,da9) g_std_spoiled(0xfffffe0016eb2c00) g_dettach(0xfffffe0016eb2c00) g_destroy_consumer(0xfffffe0016eb2c00) g_destroy_geom(0xfffffe0016eb2c80(da9)) g_do_event(0xfffffe0016bf0dc0) 1 m:0 g:0 p:0xfffffe0016e6e300 c:0 - EV_NEW_PROVIDER(da10) dev_taste(DEV-class,da10) GEOM: "da10" 9044085248 bytes in 17664229 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da10) g_std_spoiled(0xfffffe0016dd4e00) g_dettach(0xfffffe0016dd4e00) g_destroy_consumer(0xfffffe0016dd4e00) g_destroy_geom(0xfffffe0016dd4d80(da10)) g_mbrext_taste(MBREXT-class,da10) mbr_taste(MBR-class,da10) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016d8e780, 0) bsd_taste(BSD-class,da10) g_std_spoiled(0xfffffe0016dd5280) g_dettach(0xfffffe0016dd5280) g_destroy_consumer(0xfffffe0016dd5280) g_destroy_geom(0xfffffe0016e6fa80(da10)) g_do_event(0xfffffe0016bf0e40) 1 m:0 g:0 p:0xfffffe0016ccbb80 c:0 - EV_NEW_PROVIDER(da11) dev_taste(DEV-class,da11) GEOM: "da11" 9044085248 bytes in 17664229 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da11) g_std_spoiled(0xfffffe0016ccab80) g_dettach(0xfffffe0016ccab80) g_destroy_consumer(0xfffffe0016ccab80) g_destroy_geom(0xfffffe0016d8f300(da11)) g_mbrext_taste(MBREXT-class,da11) mbr_taste(MBR-class,da11) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016dd4e80, 0) bsd_taste(BSD-class,da11) g_std_spoiled(0xfffffe0016dd4f80) g_dettach(0xfffffe0016dd4f80) g_destroy_consumer(0xfffffe0016dd4f80) g_destroy_geom(0xfffffe0016dd4f00(da11)) g_do_event(0xfffffe0016bf0ec0) 1 m:0 g:0 p:0xfffffe0016e21c00 c:0 - EV_NEW_PROVIDER(da12) dev_taste(DEV-class,da12) GEOM: "da12" 9173705216 bytes in 17917393 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da12) g_std_spoiled(0xfffffe0016e21500) g_dettach(0xfffffe0016e21500) g_destroy_consumer(0xfffffe0016e21500) g_destroy_geom(0xfffffe0016ccac00(da12)) g_mbrext_taste(MBREXT-class,da12) mbr_taste(MBR-class,da12) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016ccb200, 0) bsd_taste(BSD-class,da12) g_std_spoiled(0xfffffe0016dd5880) g_dettach(0xfffffe0016dd5880) g_destroy_consumer(0xfffffe0016dd5880) g_destroy_geom(0xfffffe0016dd5780(da12)) g_do_event(0xfffffe0016bf0f40) 1 m:0 g:0 p:0xfffffe0016e6e200 c:0 - EV_NEW_PROVIDER(da13) dev_taste(DEV-class,da13) GEOM: "da13" 9173705216 bytes in 17917393 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da13) g_std_spoiled(0xfffffe0016dd4280) g_dettach(0xfffffe0016dd4280) g_destroy_consumer(0xfffffe0016dd4280) g_destroy_geom(0xfffffe0016dd4680(da13)) g_mbrext_taste(MBREXT-class,da13) mbr_taste(MBR-class,da13) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016d8ee00, 0) bsd_taste(BSD-class,da13) g_std_spoiled(0xfffffe0016eb2980) g_dettach(0xfffffe0016eb2980) g_destroy_consumer(0xfffffe0016eb2980) g_destroy_geom(0xfffffe0016eb2a00(da13)) g_do_event(0xfffffe0016bf0fc0) 1 m:0 g:0 p:0xfffffe0016e6f180 c:0 - EV_NEW_PROVIDER(da14) dev_taste(DEV-class,da14) GEOM: "da14" 9173705216 bytes in 17917393 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da14) g_std_spoiled(0xfffffe0016eb2700) g_dettach(0xfffffe0016eb2700) g_destroy_consumer(0xfffffe0016eb2700) g_destroy_geom(0xfffffe0016eb2780(da14)) g_mbrext_taste(MBREXT-class,da14) mbr_taste(MBR-class,da14) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016dd5d00, 0) bsd_taste(BSD-class,da14) g_std_spoiled(0xfffffe0016eb2400) g_dettach(0xfffffe0016eb2400) g_destroy_consumer(0xfffffe0016eb2400) g_destroy_geom(0xfffffe0016eb2480(da14)) g_do_event(0xfffffe0016bf1040) 1 m:0 g:0 p:0xfffffe0016dd5200 c:0 - EV_NEW_PROVIDER(da15) dev_taste(DEV-class,da15) GEOM: "da15" 9173705216 bytes in 17917393 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da15) g_std_spoiled(0xfffffe0016eb2180) g_dettach(0xfffffe0016eb2180) g_destroy_consumer(0xfffffe0016eb2180) g_destroy_geom(0xfffffe0016eb2200(da15)) g_mbrext_taste(MBREXT-class,da15) mbr_taste(MBR-class,da15) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016e20e80, 0) bsd_taste(BSD-class,da15) g_std_spoiled(0xfffffe0016ccb680) g_dettach(0xfffffe0016ccb680) g_destroy_consumer(0xfffffe0016ccb680) g_destroy_geom(0xfffffe0016ccb480(da15)) g_do_event(0xfffffe0016bf10c0) 1 m:0 g:0 p:0xfffffe0016dd5a00 c:0 - EV_NEW_PROVIDER(da16) dev_taste(DEV-class,da16) GEOM: "da16" 9173705216 bytes in 17917393 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da16) g_std_spoiled(0xfffffe0016eb2080) g_dettach(0xfffffe0016eb2080) g_destroy_consumer(0xfffffe0016eb2080) g_destroy_geom(0xfffffe0016eb2100(da16)) g_mbrext_taste(MBREXT-class,da16) mbr_taste(MBR-class,da16) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016dd5b80, 0) bsd_taste(BSD-class,da16) g_std_spoiled(0xfffffe0016e20b00) g_dettach(0xfffffe0016e20b00) g_destroy_consumer(0xfffffe0016e20b00) g_destroy_geom(0xfffffe0016e20a80(da16)) g_do_event(0xfffffe0016bf1140) 1 m:0 g:0 p:0xfffffe0016eb3c80 c:0 - EV_NEW_PROVIDER(da17) dev_taste(DEV-class,da17) GEOM: "da17" 9044085248 bytes in 17664229 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da17) g_std_spoiled(0xfffffe0016d8e380) g_dettach(0xfffffe0016d8e380) g_destroy_consumer(0xfffffe0016d8e380) g_destroy_geom(0xfffffe0016d8e300(da17)) g_mbrext_taste(MBREXT-class,da17) mbr_taste(MBR-class,da17) g_std_spoiled(0xfffffe0016ccbe00) g_dettach(0xfffffe0016ccbe00) g_destroy_consumer(0xfffffe0016ccbe00) g_destroy_geom(0xfffffe0016ccbc80(da17)) bsd_taste(BSD-class,da17) 0000 57 45 56 82 04 00 00 00 53 45 41 47 41 54 45 20 |WEV.....SEAGATE | 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0020 00 00 00 00 00 00 00 00 00 02 00 00 20 00 00 00 |............ ...| 0030 43 01 00 00 ad 06 00 00 60 28 00 00 e0 88 0d 01 |C.......`(......| 0040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0080 00 00 00 00 57 45 56 82 a5 7d 08 00 00 20 00 00 |....WEV..}... ..| 0090 00 20 00 00 e0 88 0d 01 00 00 00 00 00 04 00 00 |. ..............| 00a0 07 08 00 01 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00b0 00 00 00 00 e0 88 0d 01 00 00 00 00 00 00 00 00 |................| 00c0 00 00 00 00 e0 88 0d 01 00 00 00 00 00 20 00 00 |............. ..| 00d0 07 04 00 01 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0110 00 00 00 00 00 00 00 00 |........ | g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016e20a80, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016e20b00, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016eb2000, 0) g_do_event(0xfffffe0016bf11c0) 1 m:0 g:0 p:0xfffffe0016ccb100 c:0 - EV_NEW_PROVIDER(da18) dev_taste(DEV-class,da18) GEOM: "da18" 9044085248 bytes in 17664229 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da18) g_std_spoiled(0xfffffe0016dd4f00) g_dettach(0xfffffe0016dd4f00) g_destroy_consumer(0xfffffe0016dd4f00) g_destroy_geom(0xfffffe0016dd5080(da18)) g_mbrext_taste(MBREXT-class,da18) mbr_taste(MBR-class,da18) g_std_spoiled(0xfffffe0016e6fc00) g_dettach(0xfffffe0016e6fc00) g_destroy_consumer(0xfffffe0016e6fc00) g_destroy_geom(0xfffffe0016e6fd80(da18)) bsd_taste(BSD-class,da18) g_std_spoiled(0xfffffe0016e6fd80) g_dettach(0xfffffe0016e6fd80) g_destroy_consumer(0xfffffe0016e6fd80) g_destroy_geom(0xfffffe0016e6fb80(da18)) g_do_event(0xfffffe0016bf12c0) 1 m:0 g:0 p:0xfffffe0016ccb400 c:0 - EV_NEW_PROVIDER(da19) dev_taste(DEV-class,da19) GEOM: "da19" 9044085248 bytes in 17664229 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da19) g_std_spoiled(0xfffffe0016eb2380) g_dettach(0xfffffe0016eb2380) g_destroy_consumer(0xfffffe0016eb2380) g_destroy_geom(0xfffffe0016e6ff00(da19)) g_mbrext_taste(MBREXT-class,da19) mbr_taste(MBR-class,da19) g_std_spoiled(0xfffffe0016e21280) g_dettach(0xfffffe0016e21280) g_destroy_consumer(0xfffffe0016e21280) g_destroy_geom(0xfffffe0016ccba00(da19)) bsd_taste(BSD-class,da19) 0000 57 45 56 82 04 00 00 00 53 45 41 47 41 54 45 20 |WEV.....SEAGATE | 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 0030 ff 00 00 00 4b 04 00 00 c1 3e 00 00 e5 88 0d 01 |....K....>......| 0040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0080 00 00 00 00 57 45 56 82 b8 c5 08 00 00 20 00 00 |....WEV...... ..| 0090 00 20 00 00 e5 88 0d 01 00 00 00 00 00 04 00 00 |. ..............| 00a0 07 08 16 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00b0 00 00 00 00 e5 88 0d 01 00 00 00 00 00 00 00 00 |................| 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0110 00 00 00 00 00 00 00 00 |........ | g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016e21200, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016e6ee00, 0) g_do_event(0xfffffe0016bf1780) 1 m:0 g:0 p:0xfffffe0016ccb700 c:0 - EV_NEW_PROVIDER(da20) dev_taste(DEV-class,da20) GEOM: "da20" 9044085248 bytes in 17664229 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da20) g_std_spoiled(0xfffffe0016eb2180) g_dettach(0xfffffe0016eb2180) g_destroy_consumer(0xfffffe0016eb2180) g_destroy_geom(0xfffffe0016eb2200(da20)) g_mbrext_taste(MBREXT-class,da20) mbr_taste(MBR-class,da20) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016dd5300, 0) bsd_taste(BSD-class,da20) 0000 57 45 56 82 04 00 00 00 53 45 41 47 41 54 45 20 |WEV.....SEAGATE | 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0020 00 00 00 00 00 00 00 00 00 02 00 00 3f 00 00 00 |............?...| 0030 ff 00 00 00 4b 04 00 00 c1 3e 00 00 e5 88 0d 01 |....K....>......| 0040 00 00 00 00 00 00 00 00 10 0e 01 00 00 00 00 00 |................| 0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0080 00 00 00 00 57 45 56 82 b8 c5 08 00 00 20 00 00 |....WEV...... ..| 0090 00 20 00 00 e5 88 0d 01 00 00 00 00 00 04 00 00 |. ..............| 00a0 07 08 16 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00b0 00 00 00 00 e5 88 0d 01 00 00 00 00 00 00 00 00 |................| 00c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 00f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| 0110 00 00 00 00 00 00 00 00 |........ | g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016e6ff00, 0) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0016eb2380, 0) g_do_event(0xfffffe0016bf08c0) 1 m:0 g:0 p:0xfffffe0016dd5000 c:0 - EV_NEW_PROVIDER(da0a) dev_taste(DEV-class,da0a) GEOM: "da0a" 8225280 bytes in 16065 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da0a) g_std_spoiled(0xfffffe0016eb2080) g_dettach(0xfffffe0016eb2080) g_destroy_consumer(0xfffffe0016eb2080) g_destroy_geom(0xfffffe0016eb2100(da0a)) g_mbrext_taste(MBREXT-class,da0a) mbr_taste(MBR-class,da0a) g_std_spoiled(0xfffffe0016e6f580) g_dettach(0xfffffe0016e6f580) g_destroy_consumer(0xfffffe0016e6f580) g_destroy_geom(0xfffffe0016e6f900(da0a)) bsd_taste(BSD-class,da0a) g_do_event(0xfffffe0016f5fd40) 1 m:0 g:0 p:0xfffffe0016dd4a00 c:0 - EV_NEW_PROVIDER(da0b) dev_taste(DEV-class,da0b) GEOM: "da0b" 403038720 bytes in 787185 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da0b) g_std_spoiled(0xfffffe0016d8f600) g_dettach(0xfffffe0016d8f600) g_destroy_consumer(0xfffffe0016d8f600) g_destroy_geom(0xfffffe0016d8ef80(da0b)) g_mbrext_taste(MBREXT-class,da0b) mbr_taste(MBR-class,da0b) g_std_spoiled(0xfffffe0016eb2f00) g_dettach(0xfffffe0016eb2f00) g_destroy_consumer(0xfffffe0016eb2f00) g_destroy_geom(0xfffffe0016dd5780(da0b)) bsd_taste(BSD-class,da0b) g_do_event(0xfffffe0016f5fcc0) 1 m:0 g:0 p:0xfffffe0016e20e00 c:0 - EV_NEW_PROVIDER(da0c) dev_taste(DEV-class,da0c) GEOM: "da0c" 1751984640 bytes in 3421845 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da0c) g_std_spoiled(0xfffffe0016e6f100) g_dettach(0xfffffe0016e6f100) g_destroy_consumer(0xfffffe0016e6f100) g_destroy_geom(0xfffffe0016e6f380(da0c)) g_mbrext_taste(MBREXT-class,da0c) mbr_taste(MBR-class,da0c) g_std_spoiled(0xfffffe0016e6e980) g_dettach(0xfffffe0016e6e980) g_destroy_consumer(0xfffffe0016e6e980) g_destroy_geom(0xfffffe0016d8fc80(da0c)) bsd_taste(BSD-class,da0c) g_do_event(0xfffffe0017981d40) 1 m:0 g:0 p:0xfffffe0016eb4000 c:0 - EV_NEW_PROVIDER(da1a) dev_taste(DEV-class,da1a) GEOM: "da1a" 2467584000 bytes in 4819500 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da1a) g_std_spoiled(0xfffffe0016e6eb00) g_dettach(0xfffffe0016e6eb00) g_destroy_consumer(0xfffffe0016e6eb00) g_destroy_geom(0xfffffe0016e6ed00(da1a)) g_mbrext_taste(MBREXT-class,da1a) mbr_taste(MBR-class,da1a) g_std_spoiled(0xfffffe0016d8f880) g_dettach(0xfffffe0016d8f880) g_destroy_consumer(0xfffffe0016d8f880) g_destroy_geom(0xfffffe0016eb3500(da1a)) bsd_taste(BSD-class,da1a) g_do_event(0xfffffe0017981cc0) 1 m:0 g:0 p:0xfffffe0016eb4100 c:0 - EV_NEW_PROVIDER(da1b) dev_taste(DEV-class,da1b) GEOM: "da1b" 1825597952 bytes in 3565621 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da1b) g_std_spoiled(0xfffffe0016eb3400) g_dettach(0xfffffe0016eb3400) g_destroy_consumer(0xfffffe0016eb3400) g_destroy_geom(0xfffffe0016e6ea80(da1b)) g_mbrext_taste(MBREXT-class,da1b) mbr_taste(MBR-class,da1b) g_std_spoiled(0xfffffe0016dd4300) g_dettach(0xfffffe0016dd4300) g_destroy_consumer(0xfffffe0016dd4300) g_destroy_geom(0xfffffe0016dd4600(da1b)) bsd_taste(BSD-class,da1b) g_do_event(0xfffffe0017981c40) 1 m:0 g:0 p:0xfffffe0016e21900 c:0 - EV_NEW_PROVIDER(da1c) dev_taste(DEV-class,da1c) GEOM: "da1c" 4293181952 bytes in 8385121 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da1c) g_std_spoiled(0xfffffe0016dd4d80) g_dettach(0xfffffe0016dd4d80) g_destroy_consumer(0xfffffe0016dd4d80) g_destroy_geom(0xfffffe0016e21500(da1c)) g_mbrext_taste(MBREXT-class,da1c) mbr_taste(MBR-class,da1c) g_std_spoiled(0xfffffe0016e21e80) g_dettach(0xfffffe0016e21e80) g_destroy_consumer(0xfffffe0016e21e80) g_destroy_geom(0xfffffe0016e6e100(da1c)) bsd_taste(BSD-class,da1c) g_do_event(0xfffffe0016f5fa40) 1 m:0 g:0 p:0xfffffe0016d8f180 c:0 - EV_NEW_PROVIDER(da2a) dev_taste(DEV-class,da2a) GEOM: "da2a" 2673216000 bytes in 5221125 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da2a) g_std_spoiled(0xfffffe0016d8fd80) g_dettach(0xfffffe0016d8fd80) g_destroy_consumer(0xfffffe0016d8fd80) g_destroy_geom(0xfffffe0016dd4380(da2a)) g_mbrext_taste(MBREXT-class,da2a) mbr_taste(MBR-class,da2a) g_std_spoiled(0xfffffe0016dd5100) g_dettach(0xfffffe0016dd5100) g_destroy_consumer(0xfffffe0016dd5100) g_destroy_geom(0xfffffe0016eb3b80(da2a)) bsd_taste(BSD-class,da2a) g_do_event(0xfffffe0016f5f9c0) 1 m:0 g:0 p:0xfffffe0016d8f280 c:0 - EV_NEW_PROVIDER(da2b) dev_taste(DEV-class,da2b) GEOM: "da2b" 1619965952 bytes in 3163996 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da2b) g_std_spoiled(0xfffffe0016ccb500) g_dettach(0xfffffe0016ccb500) g_destroy_consumer(0xfffffe0016ccb500) g_destroy_geom(0xfffffe0016dd4c80(da2b)) g_mbrext_taste(MBREXT-class,da2b) mbr_taste(MBR-class,da2b) g_std_spoiled(0xfffffe0016ccb500) g_dettach(0xfffffe0016ccb500) g_destroy_consumer(0xfffffe0016ccb500) g_destroy_geom(0xfffffe0016e20c00(da2b)) bsd_taste(BSD-class,da2b) g_do_event(0xfffffe0016f5f940) 1 m:0 g:0 p:0xfffffe0016d8f380 c:0 - EV_NEW_PROVIDER(da2c) dev_taste(DEV-class,da2c) GEOM: "da2c" 4293181952 bytes in 8385121 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da2c) g_std_spoiled(0xfffffe0016eb3600) g_dettach(0xfffffe0016eb3600) g_destroy_consumer(0xfffffe0016eb3600) g_destroy_geom(0xfffffe0016e21d80(da2c)) g_mbrext_taste(MBREXT-class,da2c) mbr_taste(MBR-class,da2c) g_std_spoiled(0xfffffe0016eb3180) g_dettach(0xfffffe0016eb3180) g_destroy_consumer(0xfffffe0016eb3180) g_destroy_geom(0xfffffe0016dd4e00(da2c)) bsd_taste(BSD-class,da2c) g_do_event(0xfffffe0017981ac0) 1 m:0 g:0 p:0xfffffe0016eb3280 c:0 - EV_NEW_PROVIDER(da4a) dev_taste(DEV-class,da4a) GEOM: "da4a" 2147483648 bytes in 4194304 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da4a) g_std_spoiled(0xfffffe0016e21e80) g_dettach(0xfffffe0016e21e80) g_destroy_consumer(0xfffffe0016e21e80) g_destroy_geom(0xfffffe0016e6e100(da4a)) g_mbrext_taste(MBREXT-class,da4a) mbr_taste(MBR-class,da4a) g_std_spoiled(0xfffffe0016e21980) g_dettach(0xfffffe0016e21980) g_destroy_consumer(0xfffffe0016e21980) g_destroy_geom(0xfffffe0016e6e000(da4a)) bsd_taste(BSD-class,da4a) g_do_event(0xfffffe001797d980) 1 m:0 g:0 p:0xfffffe0016eb3200 c:0 - EV_NEW_PROVIDER(da4c) dev_taste(DEV-class,da4c) GEOM: "da4c" 2147483648 bytes in 4194304 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da4c) g_std_spoiled(0xfffffe0016eb3980) g_dettach(0xfffffe0016eb3980) g_destroy_consumer(0xfffffe0016eb3980) g_destroy_geom(0xfffffe0016eb3680(da4c)) g_mbrext_taste(MBREXT-class,da4c) mbr_taste(MBR-class,da4c) g_std_spoiled(0xfffffe0016eb3980) g_dettach(0xfffffe0016eb3980) g_destroy_consumer(0xfffffe0016eb3980) g_destroy_geom(0xfffffe0016eb3e80(da4c)) bsd_taste(BSD-class,da4c) g_do_event(0xfffffe0016bf07c0) 1 m:0 g:0 p:0xfffffe0016dd4900 c:0 - EV_NEW_PROVIDER(da5a) dev_taste(DEV-class,da5a) GEOM: "da5a" 18210037760 bytes in 35566480 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da5a) g_std_spoiled(0xfffffe0016ccb180) g_dettach(0xfffffe0016ccb180) g_destroy_consumer(0xfffffe0016ccb180) g_destroy_geom(0xfffffe0016eb3100(da5a)) g_mbrext_taste(MBREXT-class,da5a) mbr_taste(MBR-class,da5a) g_std_spoiled(0xfffffe0016d8ef80) g_dettach(0xfffffe0016d8ef80) g_destroy_consumer(0xfffffe0016d8ef80) g_destroy_geom(0xfffffe0016e6eb00(da5a)) bsd_taste(BSD-class,da5a) g_do_event(0xfffffe0016bf0740) 1 m:0 g:0 p:0xfffffe0016dd4180 c:0 - EV_NEW_PROVIDER(da5c) dev_taste(DEV-class,da5c) GEOM: "da5c" 18210037760 bytes in 35566480 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da5c) g_std_spoiled(0xfffffe0016d8e000) g_dettach(0xfffffe0016d8e000) g_destroy_consumer(0xfffffe0016d8e000) g_destroy_geom(0xfffffe0016ccbd00(da5c)) g_mbrext_taste(MBREXT-class,da5c) mbr_taste(MBR-class,da5c) g_std_spoiled(0xfffffe0016e6f580) g_dettach(0xfffffe0016e6f580) g_destroy_consumer(0xfffffe0016e6f580) g_destroy_geom(0xfffffe0016d8f600(da5c)) bsd_taste(BSD-class,da5c) g_do_event(0xfffffe0016f5f800) 1 m:0 g:0 p:0xfffffe0016dd4080 c:0 - EV_NEW_PROVIDER(da6a) dev_taste(DEV-class,da6a) GEOM: "da6a" 2949120 bytes in 5760 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da6a) g_std_spoiled(0xfffffe0016e21e80) g_dettach(0xfffffe0016e21e80) g_destroy_consumer(0xfffffe0016e21e80) g_destroy_geom(0xfffffe0016e6e100(da6a)) g_mbrext_taste(MBREXT-class,da6a) mbr_taste(MBR-class,da6a) g_std_spoiled(0xfffffe0016ccb300) g_dettach(0xfffffe0016ccb300) g_destroy_consumer(0xfffffe0016ccb300) g_destroy_geom(0xfffffe0016d8e600(da6a)) bsd_taste(BSD-class,da6a) g_do_event(0xfffffe0016f5f780) 1 m:0 g:0 p:0xfffffe0016dd4200 c:0 - EV_NEW_PROVIDER(da6c) dev_taste(DEV-class,da6c) GEOM: "da6c" 2949120 bytes in 5760 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da6c) g_std_spoiled(0xfffffe0016d8f080) g_dettach(0xfffffe0016d8f080) g_destroy_consumer(0xfffffe0016d8f080) g_destroy_geom(0xfffffe0016e21100(da6c)) g_mbrext_taste(MBREXT-class,da6c) mbr_taste(MBR-class,da6c) g_std_spoiled(0xfffffe0016d8fe00) g_dettach(0xfffffe0016d8fe00) g_destroy_consumer(0xfffffe0016d8fe00) g_destroy_geom(0xfffffe0016d8f800(da6c)) bsd_taste(BSD-class,da6c) g_do_event(0xfffffe0016bf05c0) 1 m:0 g:0 p:0xfffffe0016d8e100 c:0 - EV_NEW_PROVIDER(da7s1) dev_taste(DEV-class,da7s1) GEOM: "da7s1" 9056001024 bytes in 17687502 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da7s1) g_std_spoiled(0xfffffe0016dd4e00) g_dettach(0xfffffe0016dd4e00) g_destroy_consumer(0xfffffe0016dd4e00) g_destroy_geom(0xfffffe0016d8fb00(da7s1)) g_mbrext_taste(MBREXT-class,da7s1) g_std_spoiled(0xfffffe0016eb3b80) g_dettach(0xfffffe0016eb3b80) g_destroy_consumer(0xfffffe0016eb3b80) g_destroy_geom(0xfffffe0016eb3180(da7s1)) mbr_taste(MBR-class,da7s1) g_std_spoiled(0xfffffe0016dd4f80) g_dettach(0xfffffe0016dd4f80) g_destroy_consumer(0xfffffe0016dd4f80) g_destroy_geom(0xfffffe0016dd5100(da7s1)) bsd_taste(BSD-class,da7s1) g_std_spoiled(0xfffffe0016d8f480) g_dettach(0xfffffe0016d8f480) g_destroy_consumer(0xfffffe0016d8f480) g_destroy_geom(0xfffffe0016e21600(da7s1)) g_do_event(0xfffffe0016bf04c0) 1 m:0 g:0 p:0xfffffe0016d8f100 c:0 - EV_NEW_PROVIDER(da8s1) dev_taste(DEV-class,da8s1) GEOM: "da8s1" 9039550464 bytes in 17655372 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da8s1) g_std_spoiled(0xfffffe0016ccae80) g_dettach(0xfffffe0016ccae80) g_destroy_consumer(0xfffffe0016ccae80) g_destroy_geom(0xfffffe0016ccb080(da8s1)) g_mbrext_taste(MBREXT-class,da8s1) g_std_spoiled(0xfffffe0016d8f880) g_dettach(0xfffffe0016d8f880) g_destroy_consumer(0xfffffe0016d8f880) g_destroy_geom(0xfffffe0016eb3800(da8s1)) mbr_taste(MBR-class,da8s1) g_std_spoiled(0xfffffe0016dd4600) g_dettach(0xfffffe0016dd4600) g_destroy_consumer(0xfffffe0016dd4600) g_destroy_geom(0xfffffe0016e21500(da8s1)) bsd_taste(BSD-class,da8s1) g_std_spoiled(0xfffffe0016d8f600) g_dettach(0xfffffe0016d8f600) g_destroy_consumer(0xfffffe0016d8f600) g_destroy_geom(0xfffffe0016eb2780(da8s1)) g_do_event(0xfffffe0016bf0440) 1 m:0 g:0 p:0xfffffe0016ccaf80 c:0 - EV_NEW_PROVIDER(da9s1) dev_taste(DEV-class,da9s1) GEOM: "da9s1" 9039550464 bytes in 17655372 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da9s1) g_std_spoiled(0xfffffe0016d8e000) g_dettach(0xfffffe0016d8e000) g_destroy_consumer(0xfffffe0016d8e000) g_destroy_geom(0xfffffe0016ccbd00(da9s1)) g_mbrext_taste(MBREXT-class,da9s1) g_std_spoiled(0xfffffe0016d8e000) g_dettach(0xfffffe0016d8e000) g_destroy_consumer(0xfffffe0016d8e000) g_destroy_geom(0xfffffe0016eb2f00(da9s1)) mbr_taste(MBR-class,da9s1) g_std_spoiled(0xfffffe0016d8fb00) g_dettach(0xfffffe0016d8fb00) g_destroy_consumer(0xfffffe0016d8fb00) g_destroy_geom(0xfffffe0016e21600(da9s1)) bsd_taste(BSD-class,da9s1) g_std_spoiled(0xfffffe0016e21100) g_dettach(0xfffffe0016e21100) g_destroy_consumer(0xfffffe0016e21100) g_destroy_geom(0xfffffe0016dd4e00(da9s1)) g_do_event(0xfffffe0016bf02c0) 1 m:0 g:0 p:0xfffffe0016d8e780 c:0 - EV_NEW_PROVIDER(da10s1) dev_taste(DEV-class,da10s1) GEOM: "da10s1" 9039550464 bytes in 17655372 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da10s1) g_std_spoiled(0xfffffe0016ccad00) g_dettach(0xfffffe0016ccad00) g_destroy_consumer(0xfffffe0016ccad00) g_destroy_geom(0xfffffe0016ccab00(da10s1)) g_mbrext_taste(MBREXT-class,da10s1) g_std_spoiled(0xfffffe0016eb3500) g_dettach(0xfffffe0016eb3500) g_destroy_consumer(0xfffffe0016eb3500) g_destroy_geom(0xfffffe0016eb3100(da10s1)) mbr_taste(MBR-class,da10s1) g_std_spoiled(0xfffffe0016dd4e00) g_dettach(0xfffffe0016dd4e00) g_destroy_consumer(0xfffffe0016dd4e00) g_destroy_geom(0xfffffe0016eb3100(da10s1)) bsd_taste(BSD-class,da10s1) g_std_spoiled(0xfffffe0016e20f80) g_dettach(0xfffffe0016e20f80) g_destroy_consumer(0xfffffe0016e20f80) g_destroy_geom(0xfffffe0016eb3700(da10s1)) g_do_event(0xfffffe0016f5f400) 1 m:0 g:0 p:0xfffffe0016dd4e80 c:0 - EV_NEW_PROVIDER(da11s1) dev_taste(DEV-class,da11s1) GEOM: "da11s1" 9039550464 bytes in 17655372 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da11s1) g_std_spoiled(0xfffffe0016ccae80) g_dettach(0xfffffe0016ccae80) g_destroy_consumer(0xfffffe0016ccae80) g_destroy_geom(0xfffffe0016ccb080(da11s1)) g_mbrext_taste(MBREXT-class,da11s1) g_std_spoiled(0xfffffe0016e20c00) g_dettach(0xfffffe0016e20c00) g_destroy_consumer(0xfffffe0016e20c00) g_destroy_geom(0xfffffe0016e21700(da11s1)) mbr_taste(MBR-class,da11s1) g_std_spoiled(0xfffffe0016ccb080) g_dettach(0xfffffe0016ccb080) g_destroy_consumer(0xfffffe0016ccb080) g_destroy_geom(0xfffffe0016ccb500(da11s1)) bsd_taste(BSD-class,da11s1) g_std_spoiled(0xfffffe0016e6e100) g_dettach(0xfffffe0016e6e100) g_destroy_consumer(0xfffffe0016e6e100) g_destroy_geom(0xfffffe0016d8f480(da11s1)) g_do_event(0xfffffe0016f5f2c0) 1 m:0 g:0 p:0xfffffe0016ccb200 c:0 - EV_NEW_PROVIDER(da12s1) dev_taste(DEV-class,da12s1) GEOM: "da12s1" 9171154944 bytes in 17912412 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da12s1) g_std_spoiled(0xfffffe0016eb3100) g_dettach(0xfffffe0016eb3100) g_destroy_consumer(0xfffffe0016eb3100) g_destroy_geom(0xfffffe0016ccae80(da12s1)) g_mbrext_taste(MBREXT-class,da12s1) g_std_spoiled(0xfffffe0016e21500) g_dettach(0xfffffe0016e21500) g_destroy_consumer(0xfffffe0016e21500) g_destroy_geom(0xfffffe0016ccab00(da12s1)) mbr_taste(MBR-class,da12s1) g_std_spoiled(0xfffffe0016d8f880) g_dettach(0xfffffe0016d8f880) g_destroy_consumer(0xfffffe0016d8f880) g_destroy_geom(0xfffffe0016eb2780(da12s1)) bsd_taste(BSD-class,da12s1) g_std_spoiled(0xfffffe0016dd5780) g_dettach(0xfffffe0016dd5780) g_destroy_consumer(0xfffffe0016dd5780) g_destroy_geom(0xfffffe0016dd4600(da12s1)) g_do_event(0xfffffe0016bf0040) 1 m:0 g:0 p:0xfffffe0016d8ee00 c:0 - EV_NEW_PROVIDER(da13s1) dev_taste(DEV-class,da13s1) GEOM: "da13s1" 9171154944 bytes in 17912412 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da13s1) g_std_spoiled(0xfffffe0016dd5780) g_dettach(0xfffffe0016dd5780) g_destroy_consumer(0xfffffe0016dd5780) g_destroy_geom(0xfffffe0016d8f800(da13s1)) g_mbrext_taste(MBREXT-class,da13s1) g_std_spoiled(0xfffffe0016e6e000) g_dettach(0xfffffe0016e6e000) g_destroy_consumer(0xfffffe0016e6e000) g_destroy_geom(0xfffffe0016e6eb00(da13s1)) mbr_taste(MBR-class,da13s1) g_std_spoiled(0xfffffe0016e6e980) g_dettach(0xfffffe0016e6e980) g_destroy_consumer(0xfffffe0016e6e980) g_destroy_geom(0xfffffe0016e21d80(da13s1)) bsd_taste(BSD-class,da13s1) g_std_spoiled(0xfffffe0016d8e500) g_dettach(0xfffffe0016d8e500) g_destroy_consumer(0xfffffe0016d8e500) g_destroy_geom(0xfffffe0016ccad80(da13s1)) g_do_event(0xfffffe001797d480) 1 m:0 g:0 p:0xfffffe0016dd5d00 c:0 - EV_NEW_PROVIDER(da14s1) dev_taste(DEV-class,da14s1) GEOM: "da14s1" 9171154944 bytes in 17912412 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da14s1) g_std_spoiled(0xfffffe0016d8f880) g_dettach(0xfffffe0016d8f880) g_destroy_consumer(0xfffffe0016d8f880) g_destroy_geom(0xfffffe0016eb2780(da14s1)) g_mbrext_taste(MBREXT-class,da14s1) g_std_spoiled(0xfffffe0016e6eb00) g_dettach(0xfffffe0016e6eb00) g_destroy_consumer(0xfffffe0016e6eb00) g_destroy_geom(0xfffffe0016eb2080(da14s1)) mbr_taste(MBR-class,da14s1) g_std_spoiled(0xfffffe0016dd5100) g_dettach(0xfffffe0016dd5100) g_destroy_consumer(0xfffffe0016dd5100) g_destroy_geom(0xfffffe0016eb2080(da14s1)) bsd_taste(BSD-class,da14s1) g_std_spoiled(0xfffffe0016e21d80) g_dettach(0xfffffe0016e21d80) g_destroy_consumer(0xfffffe0016e21d80) g_destroy_geom(0xfffffe0016d8e500(da14s1)) g_do_event(0xfffffe00179814c0) 1 m:0 g:0 p:0xfffffe0016e20e80 c:0 - EV_NEW_PROVIDER(da15s1) dev_taste(DEV-class,da15s1) GEOM: "da15s1" 9171154944 bytes in 17912412 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da15s1) g_std_spoiled(0xfffffe0016e21e80) g_dettach(0xfffffe0016e21e80) g_destroy_consumer(0xfffffe0016e21e80) g_destroy_geom(0xfffffe0016e21500(da15s1)) g_mbrext_taste(MBREXT-class,da15s1) g_std_spoiled(0xfffffe0016e21e80) g_dettach(0xfffffe0016e21e80) g_destroy_consumer(0xfffffe0016e21e80) g_destroy_geom(0xfffffe0016eb3100(da15s1)) mbr_taste(MBR-class,da15s1) g_std_spoiled(0xfffffe0017996180) g_dettach(0xfffffe0017996180) g_destroy_consumer(0xfffffe0017996180) g_destroy_geom(0xfffffe0016eb3100(da15s1)) bsd_taste(BSD-class,da15s1) g_std_spoiled(0xfffffe0016e21d80) g_dettach(0xfffffe0016e21d80) g_destroy_consumer(0xfffffe0016e21d80) g_destroy_geom(0xfffffe0016d8e500(da15s1)) g_do_event(0xfffffe0016bf0240) 1 m:0 g:0 p:0xfffffe0016dd5b80 c:0 - EV_NEW_PROVIDER(da16s1) dev_taste(DEV-class,da16s1) GEOM: "da16s1" 9171154944 bytes in 17912412 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da16s1) g_std_spoiled(0xfffffe0016d8f480) g_dettach(0xfffffe0016d8f480) g_destroy_consumer(0xfffffe0016d8f480) g_destroy_geom(0xfffffe0016e6e000(da16s1)) g_mbrext_taste(MBREXT-class,da16s1) g_std_spoiled(0xfffffe0016ccb080) g_dettach(0xfffffe0016ccb080) g_destroy_consumer(0xfffffe0016ccb080) g_destroy_geom(0xfffffe0016e6e100(da16s1)) mbr_taste(MBR-class,da16s1) g_std_spoiled(0xfffffe0016eb5d80) g_dettach(0xfffffe0016eb5d80) g_destroy_consumer(0xfffffe0016eb5d80) g_destroy_geom(0xfffffe0016eb5f00(da16s1)) bsd_taste(BSD-class,da16s1) g_std_spoiled(0xfffffe0016eb5c80) g_dettach(0xfffffe0016eb5c80) g_destroy_consumer(0xfffffe0016eb5c80) g_destroy_geom(0xfffffe0016eb5d00(da16s1)) g_do_event(0xfffffe0016f5f080) 1 m:0 g:0 p:0xfffffe0016e20a80 c:0 - EV_NEW_PROVIDER(da17a) dev_taste(DEV-class,da17a) GEOM: "da17a" 9044082688 bytes in 17664224 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da17a) g_std_spoiled(0xfffffe0017996180) g_dettach(0xfffffe0017996180) g_destroy_consumer(0xfffffe0017996180) g_destroy_geom(0xfffffe0016eb3100(da17a)) g_mbrext_taste(MBREXT-class,da17a) mbr_taste(MBR-class,da17a) g_std_spoiled(0xfffffe0017998180) g_dettach(0xfffffe0017998180) g_destroy_consumer(0xfffffe0017998180) g_destroy_geom(0xfffffe0016eb3100(da17a)) bsd_taste(BSD-class,da17a) g_do_event(0xfffffe0017981440) 1 m:0 g:0 p:0xfffffe0016e20b00 c:0 - EV_NEW_PROVIDER(da17c) dev_taste(DEV-class,da17c) GEOM: "da17c" 9044082688 bytes in 17664224 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da17c) g_std_spoiled(0xfffffe0016d8f480) g_dettach(0xfffffe0016d8f480) g_destroy_consumer(0xfffffe0016d8f480) g_destroy_geom(0xfffffe0016e6e000(da17c)) g_mbrext_taste(MBREXT-class,da17c) mbr_taste(MBR-class,da17c) g_std_spoiled(0xfffffe0017997d80) g_dettach(0xfffffe0017997d80) g_destroy_consumer(0xfffffe0017997d80) g_destroy_geom(0xfffffe0017997f00(da17c)) bsd_taste(BSD-class,da17c) g_do_event(0xfffffe00179813c0) 1 m:0 g:0 p:0xfffffe0016eb2000 c:0 - EV_NEW_PROVIDER(da17d) dev_taste(DEV-class,da17d) GEOM: "da17d" 9044082688 bytes in 17664224 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da17d) g_std_spoiled(0xfffffe0016eb3700) g_dettach(0xfffffe0016eb3700) g_destroy_consumer(0xfffffe0016eb3700) g_destroy_geom(0xfffffe0016d8f080(da17d)) g_mbrext_taste(MBREXT-class,da17d) mbr_taste(MBR-class,da17d) g_std_spoiled(0xfffffe0017997a00) g_dettach(0xfffffe0017997a00) g_destroy_consumer(0xfffffe0017997a00) g_destroy_geom(0xfffffe0017997b80(da17d)) bsd_taste(BSD-class,da17d) g_do_event(0xfffffe0016bf0480) 1 m:0 g:0 p:0xfffffe0016e21200 c:0 - EV_NEW_PROVIDER(da19a) dev_taste(DEV-class,da19a) GEOM: "da19a" 9044085248 bytes in 17664229 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da19a) g_std_spoiled(0xfffffe0016dd4e00) g_dettach(0xfffffe0016dd4e00) g_destroy_consumer(0xfffffe0016dd4e00) g_destroy_geom(0xfffffe0016e20f80(da19a)) g_mbrext_taste(MBREXT-class,da19a) mbr_taste(MBR-class,da19a) g_std_spoiled(0xfffffe001799a780) g_dettach(0xfffffe001799a780) g_destroy_consumer(0xfffffe001799a780) g_destroy_geom(0xfffffe0016e20f80(da19a)) bsd_taste(BSD-class,da19a) g_do_event(0xfffffe0016bf0580) 1 m:0 g:0 p:0xfffffe0016e6ee00 c:0 - EV_NEW_PROVIDER(da19c) dev_taste(DEV-class,da19c) GEOM: "da19c" 9044085248 bytes in 17664229 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da19c) g_std_spoiled(0xfffffe0016eb5b80) g_dettach(0xfffffe0016eb5b80) g_destroy_consumer(0xfffffe0016eb5b80) g_destroy_geom(0xfffffe0016eb5c00(da19c)) g_mbrext_taste(MBREXT-class,da19c) mbr_taste(MBR-class,da19c) g_std_spoiled(0xfffffe0016d8e000) g_dettach(0xfffffe0016d8e000) g_destroy_consumer(0xfffffe0016d8e000) g_destroy_geom(0xfffffe0016e21600(da19c)) bsd_taste(BSD-class,da19c) g_do_event(0xfffffe001797d040) 1 m:0 g:0 p:0xfffffe0016dd5300 c:0 - EV_NEW_PROVIDER(da20s1) dev_taste(DEV-class,da20s1) GEOM: "da20s1" 9039550464 bytes in 17655372 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da20s1) g_std_spoiled(0xfffffe0017997600) g_dettach(0xfffffe0017997600) g_destroy_consumer(0xfffffe0017997600) g_destroy_geom(0xfffffe0017997680(da20s1)) g_mbrext_taste(MBREXT-class,da20s1) g_std_spoiled(0xfffffe0017997480) g_dettach(0xfffffe0017997480) g_destroy_consumer(0xfffffe0017997480) g_destroy_geom(0xfffffe0017997580(da20s1)) mbr_taste(MBR-class,da20s1) g_std_spoiled(0xfffffe0016eb5c80) g_dettach(0xfffffe0016eb5c80) g_destroy_consumer(0xfffffe0016eb5c80) g_destroy_geom(0xfffffe0016eb5b80(da20s1)) bsd_taste(BSD-class,da20s1) g_std_spoiled(0xfffffe001799a680) g_dettach(0xfffffe001799a680) g_destroy_consumer(0xfffffe001799a680) g_destroy_geom(0xfffffe001799a700(da20s1)) g_do_event(0xfffffe0016bf0640) 1 m:0 g:0 p:0xfffffe0016e6ff00 c:0 - EV_NEW_PROVIDER(da20a) dev_taste(DEV-class,da20a) GEOM: "da20a" 9044085248 bytes in 17664229 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da20a) g_std_spoiled(0xfffffe0016dd5100) g_dettach(0xfffffe0016dd5100) g_destroy_consumer(0xfffffe0016dd5100) g_destroy_geom(0xfffffe0016eb2080(da20a)) g_mbrext_taste(MBREXT-class,da20a) mbr_taste(MBR-class,da20a) g_std_spoiled(0xfffffe0017997480) g_dettach(0xfffffe0017997480) g_destroy_consumer(0xfffffe0017997480) g_destroy_geom(0xfffffe0016eb2080(da20a)) bsd_taste(BSD-class,da20a) g_do_event(0xfffffe0016bf06c0) 1 m:0 g:0 p:0xfffffe0016eb2380 c:0 - EV_NEW_PROVIDER(da20c) dev_taste(DEV-class,da20c) GEOM: "da20c" 9044085248 bytes in 17664229 sectors of 512 bytes g_sunlabel_taste(SUNLABEL-class,da20c) g_std_spoiled(0xfffffe001799a400) g_dettach(0xfffffe001799a400) g_destroy_consumer(0xfffffe001799a400) g_destroy_geom(0xfffffe001799a480(da20c)) g_mbrext_taste(MBREXT-class,da20c) mbr_taste(MBR-class,da20c) g_std_spoiled(0xfffffe0017997280) g_dettach(0xfffffe0017997280) g_destroy_consumer(0xfffffe0017997280) g_destroy_geom(0xfffffe0017997400(da20c)) bsd_taste(BSD-class,da20c) g_dev_clone(da2a) = 0xfffffe0016e59a00 g_post_event(2, 0, 0, 0xfffffe0016d8f180, 0xfffffe0016eb3b00) g_post_event(2, 0, 0, 0xfffffe0016ccb780, 0xfffffe0016e21b80) g_do_event(0xfffffe0016f5e680) 2 m:0 g:0 p:0xfffffe0016d8f180 c:0xfffffe0016eb3b00 - EV_SPOILED(0xfffffe0016d8f180(da2a),0xfffffe0016eb3b00) g_do_event(0xfffffe0016f5e6c0) 2 m:0 g:0 p:0xfffffe0016ccb780 c:0xfffffe0016e21b80 - EV_SPOILED(0xfffffe0016ccb780(da2),0xfffffe0016e21b80) spoiling 0xfffffe0016e21580 (da2) (0) start_init: trying /sbin/init Entropy harvesting: interrupts ethernet point_to_point. g_post_event(2, 0, 0, 0xfffffe0016d8f280, 0xfffffe0016d8fb80) g_do_event(0xfffffe0016f5f2c0) 2 m:0 g:0 p:0xfffffe0016d8f280 c:0xfffffe0016d8fb80 - EV_SPOILED(0xfffffe0016d8f280(da2b),0xfffffe0016d8fb80) swapon: adding /dev/da2b as swap device Automatic boot in progress... /dev/da2a: FILESYSTEM CLEAN; SKIPPING CHECKS /dev/da2a: clean, 1228635 free (28251 frags, 150048 blocks, 1.1% fragmentation) Doing initial network setup: host.conf hostname domain. de0: flags=8843 mtu 1500 inet 192.67.166.18 netmask 0xffffff00 broadcast 192.67.166.255 inet6 fe80::200:f8ff:fe01:8bd7%de0 prefixlen 64 tentative scopeid 0x1 ether 00:00:f8:01:8b:d7 media: Ethernet 100baseTX status: active lo0: flags=8049 mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 inet 127.0.0.1 netmask 0xff000000 add net default: gateway 192.67.166.126 Additional routing options:. Routing daemons:. Mounting NFS file systems:. g_dev_clone(tty[pqrsPQRS]*) g_dev_clone(tty[pqrsPQRS]*) Clearing /tmp:. Additional daemog_ns:dev_clone(log) g_dev_clone(log) g_dev_clone(log) g_dev_clone(log) g_dev_clone(log) syslogdMar 27 17:28:40 nellie syslogd: kernel boot file is /boot/kernel/kernel . g_dev_clone(ad0b) Doing additional network setup: ntpdate ntpd rpcbind ypbind. Starting final network daemons: mountd nfsd NFS access cache time=2 . ELF ldconfig path: /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib Starting standard daemons: inetd cron sshdg_dev_clone(tty) sendmail. g_dev_clone(vga) g_dev_clone(vga) g_dev_clone(vga) g_dev_clone(vga) Initial rc.alpha initialization:. Configuring syscons:. Additional ABI support:. Starting local daemons:g_post_event(1, 0, 0, 0xfffffe0017be5c80, 0) g_do_event(0xfffffe0016f5f440) 1 m:0 g:0 p:0xfffffe0017be5c80 c:0 - EV_NEW_PROVIDER(md10) dev_taste(DEV-class,md10) GEOM: "md10" 134217728 bytes in 16384 sectors of 8192 bytes g_sunlabel_taste(SUNLABEL-class,mgd_1d0e)v_ clone(md10c) g_std_spoiled(0xfffffe0017c4c700) g_dettach(0xfffffe0017c4c700) g_destroy_consumer(0xfffffe0017c4c700) g_destroy_geom(0xfffffe001799b380(md10)) g_mbrext_taste(MBREXT-class,md10) mbr_taste(MBR-class,md10) g_std_spoiled(0xfffffe0017be5300) g_dettach(0xfffffe0017be5300) g_destroy_consumer(0xfffffe0017be5300) g_destroy_geom(0xfffffe00179e7180(md10)) bsd_taste(BSD-class,md10) g_std_spoiled(0xfffffe0017c9b380) g_dettach(0xfffffe0017c9b380) g_destroy_consumer(0xfffffe0017c9b380) g_destroy_geom(0xfffffe0017c9b400(md10)) g_post_event(2, 0, 0, 0xfffffe0017be5c80, 0xfffffe0017c4cb80) g_do_event(0xfffffe0017c4a400) 2 m:0 g:0 p:0xfffffe0017be5c80 c:0xfffffe0017c4cb80 - EV_SPOILED(0xfffffe0017be5c80(md10),0xfffffe0017c4cb80) g_create_geom(BSD-class, 0xfffffe0017be5c80(md10)) g_class_by_name(BSD-class) bsd_taste(BSD-class,md10) g_slice_addslice() g_post_event(1, 0, 0, 0xfffffe0017c4c400, 0) g_do_event(0xfffffe0017c4ab80) 1 m:0 g:0 p:0xfffffe0017c4c400 c:0 - EV_NEW_PROVIDER(md10c) dev_taste(DEV-class,md10c) GEOM: "md10c" (size unavailable) g_sunlabel_taste(SUNLABEL-class,md10c) g_dettach(0xfffffe00179e7000) g_destroy_consumer(0xfffffe00179e7000) g_destroy_geom(0xfffffe00179e7080(md10c)) g_mbrext_taste(MBREXT-class,md10c) mbr_taste(MBR-class,md10c) g_dettach(0xfffffe001799a900) g_destroy_consumer(0xfffffe001799a900) g_destroy_geom(0xfffffe001799b000(md10c)) bsd_taste(BSD-class,md10c) IOCTL(0x41186469) "md10" 'd'/105 O(280) = ENOIOCTL IOCTL(0x41186465) "md10" 'd'/101 O(280) = ENOIOCTL disklabel: gioctl DIOCGDINFO_p: oInappropriate iosctl for device t_disklabel: auto:e unknown disk tyvepe nt(1, 0, 0, 0xfffffe0017be5c80, 0) g_do_event(0xfffffe0017c4ab40) 1 m:0 g:0 p:0xfffffe0017be5c80 c:0 - EV_NEW_PROVIDER(md10) g_sunlabel_taste(SUNLABEL-class,md10) g_std_spoiled(0xfffffe00179e7000) g_dettach(0xfffffe00179e7000) g_destroy_consumer(0xfffffe00179e7000) g_destroy_geom(0xfffffe00179e7080(md10)) g_mbrext_taste(MBREXT-class,md10) mbr_taste(MBR-class,md10) g_std_spoiled(0xfffffe0017c9af00) g_dettach(0xfffffe0017c9af00) g_destroy_consumer(0xfffffe0017c9af00) g_destroy_geom(0xfffffe0017c9b080(md10)) g_post_event(2, 0, 0, 0xfffffe0017c4c400, 0xfffffe0017c9b400) g_post_event(2, 0, 0, 0xfffffe0017be5c80, 0xfffffe0016eb3100) g_do_event(0xfffffe0017c4a9c0) 2 m:0 g:0 p:0xfffffe0017c4c400 c:0xfffffe0017c9b400 - EV_SPOILED(0xfffffe0017c4c400(md10c),0xfffffe0017c9b400) g_do_event(0xfffffe0016bf0300) 2 m:0 g:0 p:0xfffffe0017be5c80 c:0xfffffe0016eb3100 - EV_SPOILED(0xfffffe0017be5c80(md10),0xfffffe0016eb3100) spoiling 0xfffffe0017c4cb80 (md10) (0) Warning: Block sgize restricts cy_plinders per grouop to 65048. stinode blocks/cyl_e group (70) >= dveata blocks (-999nt424) (number of cylind1ers per cylinder, group (65048) m0ust be increased, . 0, 0xfffffe0017c4c400, 0) g_post_event(1, 0, 0, 0xfffffe0017be5c80, 0) g_do_event(0xfffffe001797cbc0) 1 m:0 g:0 p:0xfffffe0017c4c400 c:0 - EV_NEW_PROVIDER(md10c) g_sunlabel_taste(SUNLABEL-class,md10c) g_std_spoiled(0xfffffe0017c4ca00) g_dettach(0xfffffe0017c4ca00) g_destroy_consumer(0xfffffe0017c4ca00) g_destroy_geom(0xfffffe0017999e80(md10c)) g_mbrext_taste(MBREXT-class,md10c) mbr_taste(MBR-class,md10c) g_std_spoiled(0xfffffe0017997280) g_dettach(0xfffffe0017997280) g_destroy_consumer(0xfffffe0017997280) g_destroy_geom(0xfffffe001799b380(md10c)) bsd_taste(BSD-class,md10c) g_do_event(0xfffffe0016f5e680) 1 m:0 g:0 p:0xfffffe0017be5c80 c:0 - EV_NEW_PROVIDER(md10) g_sunlabel_taste(SUNLABEL-class,md10) g_std_spoiled(0xfffffe0017c9ac00) g_dettach(0xfffffe0017c9ac00) g_destroy_consumer(0xfffffe0017c9ac00) g_destroy_geom(0xfffffe0017c9ac80(md10)) g_mbrext_taste(MBREXT-class,md10) mbr_taste(MBR-class,md10) g_std_spoiled(0xfffffe0017997b80) g_dettach(0xfffffe0017997b80) g_destroy_consumer(0xfffffe0017997b80) g_destroy_geom(0xfffffe0017999000(md10)) g_post_event(2, 0, 0, 0xfffffe0017c4c400, 0xfffffe0017c9b400) g_post_event(2, 0, 0, 0xfffffe0017be5c80, 0xfffffe0016eb3100) g_do_event(0xfffffe0017c4b040) 2 m:0 g:0 p:0xfffffe0017c4c400 c:0xfffffe0017c9b400 - EV_SPOILED(0xfffffe0017c4c400(md10c),0xfffffe0017c9b400) g_do_event(0xfffffe00179806c0) 2 m:0 g:0 p:0xfffffe0017be5c80 c:0xfffffe0016eb3100 - EV_SPOILED(0xfffffe0017be5c80(md10),0xfffffe0016eb3100) spoiling 0xfffffe0017c4cb80 (md10) (0) g_post_event(1, 0, 0, 0xfffffe0017c4c400, 0) g_post_event(1, 0, 0, 0xfffffe0017be5c80, 0) g_do_event(0xfffffe0017c4b380) 1 m:0 g:0 p:0xfffffe0017c4c400 c:0 - EV_NEW_PROVIDER(md10c) g_sunlabel_taste(SUNLABEL-class,md10c) g_std_spoiled(0xfffffe0017996800) g_dettach(0xfffffe0017996800) g_destroy_consumer(0xfffffe0017996800) g_destroy_geom(0xfffffe0017996380(md10c)) g_mbrext_taste(MBREXT-class,md10c) mbr_taste(MBR-class,md10c) g_std_spoiled(0xfffffe00179e6a00) g_dettach(0xfffffe00179e6a00) g_destroy_consumer(0xfffffe00179e6a00) g_destroy_geom(0xfffffe0017c9aa80(md10c)) bsd_taste(BSD-class,md10c) g_do_event(0xfffffe0016bf1140) 1 m:0 g:0 p:0xfffffe0017be5c80 c:0 - EV_NEW_PROVIDER(md10) g_sunlabel_taste(SUNLABEL-class,md10) g_std_spoiled(0xfffffe0017c4ca80) g_dettach(0xfffffe0017c4ca80) g_destroy_consumer(0xfffffe0017c4ca80) g_destroy_geom(0xfffffe00179e6180(md10)) g_mbrext_taste(MBREXT-class,md10) mbr_taste(MBR-class,md10) g_std_spoiled(0xfffffe001799b380) g_dettach(0xfffffe001799b380) g_destroy_consumer(0xfffffe001799b380) g_destroy_geom(0xfffffe0017c9ac80(md10)) mount: /dev/md10c on /tmp: incorrect super block . Local package initialization:. Additional TCP options:. Starting background filesystem checks Wed Mar 27 17:30:20 PST 2002 FreeBSD/alpha (nellie.feral.com) (ttyd0) login: To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Wed Mar 27 23:24:18 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 0FBA837B405 for ; Wed, 27 Mar 2002 23:24:14 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2S7Nme7065048; Thu, 28 Mar 2002 08:23:49 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: alpha@FreeBSD.ORG Subject: Re: Please test GEOM in -current... In-Reply-To: Your message of "Wed, 27 Mar 2002 17:34:29 PST." Date: Thu, 28 Mar 2002 08:23:48 +0100 Message-ID: <65047.1017300228@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message , Matthew Jacob writ es: >> I belive that alpha BSD disklabels are now correctly handled in >> GEOM and would therefore appreciate if somebody could enable the >> GEOM option in a current kernel and tell me if I am right or not. >> >> Further more, if somebody could try to swap disks between an alpha >> and an i386 and tell me if the both recognize the "alien" disklabels >> when GEOM is enabled, that would be doubly nice. >> >> In fact, for ultimate h0h0 effect, you can try to stick a disk >> from a solaris machine into your alpha: it should recognize >> the partitioning on that as well. >> > >It's all quite verbose, so it's a bit hard to figure out what's what for >Alpha. Also, it *appeared* to blow up in my face on a system that had an IDE >drive as the root device- but I'm trying to ascertain whether that was really >the case right now. > >That system was also the one on the same fabric as Solaris labelled disks.... It doesn't look entirely wrong to me. I can see that there may be some issue with the cd0, it should probably be more graceful about not finding a disk there. You need to make sure that you have a post-cleanup newfs or GEOM+md+newfs will not play. I also fixed a buglet in the alpha-disklabel code yesterday, I can't tell if you have that fix or not in your kernel. Other than that it seems pretty ok to me. Sorry about the verboseness, it will be reduced. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 7:48: 6 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 76CDB37B41A for ; Thu, 28 Mar 2002 07:48:02 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g2SFllo71686; Thu, 28 Mar 2002 07:47:47 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g2SFlTS11478; Thu, 28 Mar 2002 07:47:29 -0800 (PST) (envelope-from jdp) Date: Thu, 28 Mar 2002 07:47:29 -0800 (PST) Message-Id: <200203281547.g2SFlTS11478@vashon.polstra.com> To: alpha@freebsd.org From: John Polstra Cc: echofox@discordia.ca Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE In-Reply-To: <200203272246.g2RMkJ657777@freefall.freebsd.org> References: <200203272246.g2RMkJ657777@freefall.freebsd.org> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <200203272246.g2RMkJ657777@freefall.freebsd.org>, Nicholas Paufler wrote: > I grabbed the cvsup-without-gui Alpha package and pkg_added it and attempted to use cvsup to update ports, but it core dumps: > > npaufler@endor:/usr/local/etc> sudo cvsup ports-supfile > > > *** > *** runtime error: > *** Value out of range > *** file "/tmp/a/ports/lang/ezm3/work/ezm3-1.0/libs/libm3/src/uid/Common/TimeStamp.m3", line 63 > *** Is anybody else seeing this on the Alpha using the cvsup-without-gui package or port? John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 7:51:58 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 92D9E37B416 for ; Thu, 28 Mar 2002 07:51:37 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id KAA29676; Thu, 28 Mar 2002 10:51:35 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2SFp5F79248; Thu, 28 Mar 2002 10:51:05 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15523.15336.854733.561407@grasshopper.cs.duke.edu> Date: Thu, 28 Mar 2002 10:51:04 -0500 (EST) To: John Polstra Cc: alpha@FreeBSD.ORG, echofox@discordia.ca Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE In-Reply-To: <200203281547.g2SFlTS11478@vashon.polstra.com> References: <200203272246.g2RMkJ657777@freefall.freebsd.org> <200203281547.g2SFlTS11478@vashon.polstra.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra writes: > In article <200203272246.g2RMkJ657777@freefall.freebsd.org>, > Nicholas Paufler wrote: > > I grabbed the cvsup-without-gui Alpha package and pkg_added it and attempted to use cvsup to update ports, but it core dumps: > > > > npaufler@endor:/usr/local/etc> sudo cvsup ports-supfile > > > > > > *** > > *** runtime error: > > *** Value out of range > > *** file "/tmp/a/ports/lang/ezm3/work/ezm3-1.0/libs/libm3/src/uid/Common/TimeStamp.m3", line 63 > > *** > > Is anybody else seeing this on the Alpha using the cvsup-without-gui > package or port? I'm using the non-gui cvsup-16.1d package w/o any problems. It was installed around Sept 1, 2001. Cheers, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 8: 3:28 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id E1CB537B439 for ; Thu, 28 Mar 2002 08:03:12 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g2SG38o71766; Thu, 28 Mar 2002 08:03:08 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g2SG37S11604; Thu, 28 Mar 2002 08:03:07 -0800 (PST) (envelope-from jdp) Date: Thu, 28 Mar 2002 08:03:07 -0800 (PST) Message-Id: <200203281603.g2SG37S11604@vashon.polstra.com> To: alpha@freebsd.org From: John Polstra Cc: gallatin@cs.duke.edu, echofox@discordia.ca Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE In-Reply-To: <15523.15336.854733.561407@grasshopper.cs.duke.edu> References: <200203272246.g2RMkJ657777@freefall.freebsd.org> <200203281547.g2SFlTS11478@vashon.polstra.com> <15523.15336.854733.561407@grasshopper.cs.duke.edu> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <15523.15336.854733.561407@grasshopper.cs.duke.edu>, Andrew Gallatin wrote: > > John Polstra writes: > > In article <200203272246.g2RMkJ657777@freefall.freebsd.org>, > > Nicholas Paufler wrote: > > > I grabbed the cvsup-without-gui Alpha package and pkg_added it and attempted to use cvsup to update ports, but it core dumps: > > > > > > npaufler@endor:/usr/local/etc> sudo cvsup ports-supfile > > > > > > > > > *** > > > *** runtime error: > > > *** Value out of range > > > *** file "/tmp/a/ports/lang/ezm3/work/ezm3-1.0/libs/libm3/src/uid/Common/TimeStamp.m3", line 63 > > > *** > > > > Is anybody else seeing this on the Alpha using the cvsup-without-gui > > package or port? > > I'm using the non-gui cvsup-16.1d package w/o any problems. It was > installed around Sept 1, 2001. That pre-dates the use of ezm3, so it may not apply. Looks like I'd better update my Alpha box and try it. John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 10:55:52 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id D2ACF37B41E for ; Thu, 28 Mar 2002 10:55:48 -0800 (PST) Received: from strings.polstra.com (strings.polstra.com [206.213.73.20]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g2SItko72709; Thu, 28 Mar 2002 10:55:46 -0800 (PST) (envelope-from jdp@polstra.com) Message-ID: X-Mailer: XFMail 1.5.1 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Thu, 28 Mar 2002 10:55:46 -0800 (PST) Organization: Polstra & Co., Inc. From: John Polstra To: "Nicholas \"Echo|Fox\" Paufler" Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE Cc: alpha@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Nicholas \"Echo|Fox\" Paufler wrote: >> That pre-dates the use of ezm3, so it may not apply. Looks like I'd >> better update my Alpha box and try it. >> > > I found an alpha package for 16.1e and i get something slightly different > but with the same result: > > npaufler@endor:/usr/local/etc> sudo cvsup @M3stackdump ports-supfile > > *** > *** runtime error: > *** Value out of range > *** file > "/a/work/.amd_mnt/vashon/host/usr/ports/lang/pm3-base/work/pm3-1.1.15/libs/libm3/sr > c/uid/Common/TimeStamp.m3", > line 63 > *** It could take a few days before I can dig into this. If you have time, could you please try building the cvsup-without-gui port on the machine instead of using the package? Also, here is a long shot: Is the date set correctly on the machine? John To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 11: 9:33 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 933E137B416 for ; Thu, 28 Mar 2002 11:09:29 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA06171; Thu, 28 Mar 2002 14:09:26 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2SJ8uD79548; Thu, 28 Mar 2002 14:08:56 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15523.27208.853432.144659@grasshopper.cs.duke.edu> Date: Thu, 28 Mar 2002 14:08:56 -0500 (EST) To: "Nicholas \"Echo|Fox\" Paufler" Cc: John Polstra , alpha@FreeBSD.ORG Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE In-Reply-To: References: <15523.15336.854733.561407@grasshopper.cs.duke.edu> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org "Nicholas \"Echo|Fox\" Paufler" writes: > > > > I'm using the non-gui cvsup-16.1d package w/o any problems. It was > > installed around Sept 1, 2001. > > > Interesting. > I haven't been able to find a precompiled version of 16.1d. If you still > have the package lying around would I be able to get it from you to > attempt to see if it works on this machine? If it is related to the ezm3 > switch this should confirm that this is in fact the problem. I've used pkg_tarup to create a package & left it it at http://people.freebsd.org/~gallatin/cvsup-16.1d.tgz Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 11:13:58 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from wall.polstra.com (wall-gw.polstra.com [206.213.73.130]) by hub.freebsd.org (Postfix) with ESMTP id 4ACD137B41B for ; Thu, 28 Mar 2002 11:13:54 -0800 (PST) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.11.3/8.11.3) with ESMTP id g2SJDqo72891; Thu, 28 Mar 2002 11:13:52 -0800 (PST) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.6/8.11.0) id g2SJDp211885; Thu, 28 Mar 2002 11:13:51 -0800 (PST) (envelope-from jdp) Date: Thu, 28 Mar 2002 11:13:51 -0800 (PST) Message-Id: <200203281913.g2SJDp211885@vashon.polstra.com> To: alpha@freebsd.org From: John Polstra Cc: gallatin@cs.duke.edu Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE In-Reply-To: <15523.27208.853432.144659@grasshopper.cs.duke.edu> References: <15523.15336.854733.561407@grasshopper.cs.duke.edu> <15523.27208.853432.144659@grasshopper.cs.duke.edu> Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In article <15523.27208.853432.144659@grasshopper.cs.duke.edu>, Andrew Gallatin wrote: > > "Nicholas \"Echo|Fox\" Paufler" writes: > > > > > > I'm using the non-gui cvsup-16.1d package w/o any problems. It was > > > installed around Sept 1, 2001. > > > > > Interesting. > > I haven't been able to find a precompiled version of 16.1d. If you still > > have the package lying around would I be able to get it from you to > > attempt to see if it works on this machine? If it is related to the ezm3 > > switch this should confirm that this is in fact the problem. > > I've used pkg_tarup to create a package & left it it at > http://people.freebsd.org/~gallatin/cvsup-16.1d.tgz Off the list Nicholas told me a few minutes ago that the date on the Alpha was set to the year 1912. That was the cause of the problem (an overflow in a date calculation). John -- John Polstra John D. Polstra & Co., Inc. Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 11:15:56 2002 Delivered-To: freebsd-alpha@hub.freebsd.org Received: from freefall.freebsd.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 7E62137B419; Thu, 28 Mar 2002 11:15:54 -0800 (PST) Received: (from jdp@localhost) by freefall.freebsd.org (8.11.6/8.11.6) id g2SJFox68267; Thu, 28 Mar 2002 11:15:50 -0800 (PST) (envelope-from jdp) Date: Thu, 28 Mar 2002 11:15:50 -0800 (PST) From: Message-Id: <200203281915.g2SJFox68267@freefall.freebsd.org> To: echofox@discordia.ca, jdp@FreeBSD.org, freebsd-alpha@FreeBSD.org Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Synopsis: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE State-Changed-From-To: open->closed State-Changed-By: jdp State-Changed-When: Thu Mar 28 11:14:45 PST 2002 State-Changed-Why: It turns out that the date on the machine in question was set to some time in the year 1912. That caused an overflow in a Modula-3 date calculation. http://www.freebsd.org/cgi/query-pr.cgi?pr=36390 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 11:19:12 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 638CD37B404 for ; Thu, 28 Mar 2002 11:19:08 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA06591; Thu, 28 Mar 2002 14:18:57 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2SJIRV79566; Thu, 28 Mar 2002 14:18:27 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15523.27779.685851.597969@grasshopper.cs.duke.edu> Date: Thu, 28 Mar 2002 14:18:27 -0500 (EST) To: John Polstra Cc: alpha@FreeBSD.ORG, echofox@discordia.ca Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE In-Reply-To: <200203281913.g2SJDp211885@vashon.polstra.com> References: <15523.15336.854733.561407@grasshopper.cs.duke.edu> <15523.27208.853432.144659@grasshopper.cs.duke.edu> <200203281913.g2SJDp211885@vashon.polstra.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org John Polstra writes: > > Off the list Nicholas told me a few minutes ago that the date on the > Alpha was set to the year 1912. That was the cause of the problem (an > overflow in a date calculation). Ah, sounds like a job for clock_compat_osf1. Nicholas - if you're dual booting between FreeBSD & Tru64, try putting clock_compat_osf1=1 into /boot/loader.conf Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 11:24: 6 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id DC20437B425 for ; Thu, 28 Mar 2002 11:23:27 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g2SJNKr27500; Thu, 28 Mar 2002 20:23:20 +0100 (CET) (envelope-from wkb) Date: Thu, 28 Mar 2002 20:23:20 +0100 From: Wilko Bulte To: Andrew Gallatin Cc: John Polstra , alpha@FreeBSD.ORG, echofox@discordia.ca Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE Message-ID: <20020328202320.A27485@freebie.xs4all.nl> References: <15523.15336.854733.561407@grasshopper.cs.duke.edu> <15523.27208.853432.144659@grasshopper.cs.duke.edu> <200203281913.g2SJDp211885@vashon.polstra.com> <15523.27779.685851.597969@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15523.27779.685851.597969@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Thu, Mar 28, 2002 at 02:18:27PM -0500 X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Mar 28, 2002 at 02:18:27PM -0500, Andrew Gallatin wrote: > > John Polstra writes: > > > > Off the list Nicholas told me a few minutes ago that the date on the > > Alpha was set to the year 1912. That was the cause of the problem (an > > overflow in a date calculation). > > Ah, sounds like a job for clock_compat_osf1. > > Nicholas - if you're dual booting between FreeBSD & Tru64, try putting > clock_compat_osf1=1 > into /boot/loader.conf Drew, is there any reason to not have this as default? -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands We are FreeBSD. Resistance is futile. Prepare to be committed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 11:26:56 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 32FE037B417 for ; Thu, 28 Mar 2002 11:26:50 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA06848; Thu, 28 Mar 2002 14:26:49 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2SJQJj79585; Thu, 28 Mar 2002 14:26:19 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15523.28251.551575.812462@grasshopper.cs.duke.edu> Date: Thu, 28 Mar 2002 14:26:19 -0500 (EST) To: Wilko Bulte Cc: alpha@FreeBSD.ORG Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE In-Reply-To: <20020328202320.A27485@freebie.xs4all.nl> References: <15523.15336.854733.561407@grasshopper.cs.duke.edu> <15523.27208.853432.144659@grasshopper.cs.duke.edu> <200203281913.g2SJDp211885@vashon.polstra.com> <15523.27779.685851.597969@grasshopper.cs.duke.edu> <20020328202320.A27485@freebie.xs4all.nl> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Wilko Bulte writes: > On Thu, Mar 28, 2002 at 02:18:27PM -0500, Andrew Gallatin wrote: > > > > John Polstra writes: > > > > > > Off the list Nicholas told me a few minutes ago that the date on the > > > Alpha was set to the year 1912. That was the cause of the problem (an > > > overflow in a date calculation). > > > > Ah, sounds like a job for clock_compat_osf1. > > > > Nicholas - if you're dual booting between FreeBSD & Tru64, try putting > > clock_compat_osf1=1 > > into /boot/loader.conf > > Drew, is there any reason to not have this as default? Making it the default would cause needless pain & suffering for our entire installed base, as their clocks would suddenly be wrong. And it would introduce (the same) problems for people dual booting linux. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 11:30:53 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 88EE737B429 for ; Thu, 28 Mar 2002 11:29:53 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g2SJTp727632; Thu, 28 Mar 2002 20:29:51 +0100 (CET) (envelope-from wkb) Date: Thu, 28 Mar 2002 20:29:51 +0100 From: Wilko Bulte To: Andrew Gallatin Cc: alpha@FreeBSD.ORG Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE Message-ID: <20020328202951.A27598@freebie.xs4all.nl> References: <15523.15336.854733.561407@grasshopper.cs.duke.edu> <15523.27208.853432.144659@grasshopper.cs.duke.edu> <200203281913.g2SJDp211885@vashon.polstra.com> <15523.27779.685851.597969@grasshopper.cs.duke.edu> <20020328202320.A27485@freebie.xs4all.nl> <15523.28251.551575.812462@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15523.28251.551575.812462@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Thu, Mar 28, 2002 at 02:26:19PM -0500 X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Thu, Mar 28, 2002 at 02:26:19PM -0500, Andrew Gallatin wrote: > > Wilko Bulte writes: > > On Thu, Mar 28, 2002 at 02:18:27PM -0500, Andrew Gallatin wrote: > > > > > > John Polstra writes: > > > > > > > > Off the list Nicholas told me a few minutes ago that the date on the > > > > Alpha was set to the year 1912. That was the cause of the problem (an > > > > overflow in a date calculation). > > > > > > Ah, sounds like a job for clock_compat_osf1. > > > > > > Nicholas - if you're dual booting between FreeBSD & Tru64, try putting > > > clock_compat_osf1=1 > > > into /boot/loader.conf > > > > Drew, is there any reason to not have this as default? > > Making it the default would cause needless pain & suffering for our > entire installed base, as their clocks would suddenly be wrong. Hum, bah. Isn't there a way to determine if the clock value is sensible? I mean, 1912 is not. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands We are FreeBSD. Resistance is futile. Prepare to be committed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 11:34:44 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 9D7D137B416 for ; Thu, 28 Mar 2002 11:34:39 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id OAA07176; Thu, 28 Mar 2002 14:34:39 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2SJY9H79601; Thu, 28 Mar 2002 14:34:09 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15523.28721.22336.785915@grasshopper.cs.duke.edu> Date: Thu, 28 Mar 2002 14:34:09 -0500 (EST) To: Wilko Bulte Cc: alpha@FreeBSD.ORG Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE In-Reply-To: <20020328202951.A27598@freebie.xs4all.nl> References: <15523.15336.854733.561407@grasshopper.cs.duke.edu> <15523.27208.853432.144659@grasshopper.cs.duke.edu> <200203281913.g2SJDp211885@vashon.polstra.com> <15523.27779.685851.597969@grasshopper.cs.duke.edu> <20020328202320.A27485@freebie.xs4all.nl> <15523.28251.551575.812462@grasshopper.cs.duke.edu> <20020328202951.A27598@freebie.xs4all.nl> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Wilko Bulte writes: > > Hum, bah. Isn't there a way to determine if the clock value is sensible? > I mean, 1912 is not. Feel free to implement this. The code is inittodr() in sys/alpha/alpha/clock.c Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 11:55:54 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 27A6A37B400; Thu, 28 Mar 2002 11:55:49 -0800 (PST) Received: from pool0038.cvx40-bradley.dialup.earthlink.net ([216.244.42.38] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16qfzn-00002v-00; Thu, 28 Mar 2002 11:55:39 -0800 Message-ID: <3CA37525.892F13B2@mindspring.com> Date: Thu, 28 Mar 2002 11:55:17 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: jdp@FreeBSD.org Cc: echofox@discordia.ca, freebsd-alpha@FreeBSD.org Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE References: <200203281915.g2SJFox68267@freefall.freebsd.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org jdp@FreeBSD.org wrote: > Synopsis: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE > > State-Changed-From-To: open->closed > State-Changed-By: jdp > State-Changed-When: Thu Mar 28 11:14:45 PST 2002 > State-Changed-Why: > It turns out that the date on the machine in question was set to > some time in the year 1912. That caused an overflow in a Modula-3 > date calculation. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=36390 Heh. It's now tempting to submit a bug report about a core dump when I set my date to 1912. In other words, that fixes the symptom, but not the problem, so the PR should probably be updated with a workaround, but not marked closed. It doesn't mean you should feel obligated to fix it, just that it's not resolved. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 12: 0:19 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from albatross.prod.itd.earthlink.net (albatross.mail.pas.earthlink.net [207.217.120.120]) by hub.freebsd.org (Postfix) with ESMTP id 4CFB137B400 for ; Thu, 28 Mar 2002 12:00:05 -0800 (PST) Received: from pool0038.cvx40-bradley.dialup.earthlink.net ([216.244.42.38] helo=mindspring.com) by albatross.prod.itd.earthlink.net with esmtp (Exim 3.33 #1) id 16qg3o-0006V5-00; Thu, 28 Mar 2002 11:59:49 -0800 Message-ID: <3CA3761E.55E8E4E0@mindspring.com> Date: Thu, 28 Mar 2002 11:59:26 -0800 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Andrew Gallatin Cc: Wilko Bulte , alpha@FreeBSD.ORG Subject: Re: alpha/36390: cvsup core dumps on FreeBSD/Alpha 4.5-RELEASE References: <15523.15336.854733.561407@grasshopper.cs.duke.edu> <15523.27208.853432.144659@grasshopper.cs.duke.edu> <200203281913.g2SJDp211885@vashon.polstra.com> <15523.27779.685851.597969@grasshopper.cs.duke.edu> <20020328202320.A27485@freebie.xs4all.nl> <15523.28251.551575.812462@grasshopper.cs.duke.edu> <20020328202951.A27598@freebie.xs4all.nl> <15523.28721.22336.785915@grasshopper.cs.duke.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Andrew Gallatin wrote: > Wilko Bulte writes: > > Hum, bah. Isn't there a way to determine if the clock value is sensible? > > I mean, 1912 is not. > > Feel free to implement this. The code is inittodr() in > sys/alpha/alpha/clock.c Don't forget to make it turn-off-able: sysctl believe.the.freaking.clock=1 ...probably needs to be a loader variable. 8-) 8-) 8-) -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 20:20:52 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id 01BEF37B417 for ; Thu, 28 Mar 2002 20:20:47 -0800 (PST) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g2T4Kcf37066; Thu, 28 Mar 2002 20:20:38 -0800 (PST) (envelope-from mjacob@feral.com) Date: Thu, 28 Mar 2002 20:20:38 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: alpha@FreeBSD.ORG Subject: Re: Please test GEOM in -current... In-Reply-To: <65047.1017300228@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org It probably is right. The one system that I really had wanted to check this on was an XP1000 that was connected to my VERITAS fabric with lots of Sun labelled disks. Unfortunately, ATA chip for this system seems to be causing grief for Soren's latest code, so I can't get booted. C'est la vie- sorry..... -matt On Thu, 28 Mar 2002, Poul-Henning Kamp wrote: > In message , Matthew Jacob writ > es: > > >> I belive that alpha BSD disklabels are now correctly handled in > >> GEOM and would therefore appreciate if somebody could enable the > >> GEOM option in a current kernel and tell me if I am right or not. > >> > >> Further more, if somebody could try to swap disks between an alpha > >> and an i386 and tell me if the both recognize the "alien" disklabels > >> when GEOM is enabled, that would be doubly nice. > >> > >> In fact, for ultimate h0h0 effect, you can try to stick a disk > >> from a solaris machine into your alpha: it should recognize > >> the partitioning on that as well. > >> > > > >It's all quite verbose, so it's a bit hard to figure out what's what for > >Alpha. Also, it *appeared* to blow up in my face on a system that had an IDE > >drive as the root device- but I'm trying to ascertain whether that was really > >the case right now. > > > >That system was also the one on the same fabric as Solaris labelled disks.... > > It doesn't look entirely wrong to me. I can see that there may be > some issue with the cd0, it should probably be more graceful about > not finding a disk there. > > You need to make sure that you have a post-cleanup newfs or GEOM+md+newfs > will not play. > > I also fixed a buglet in the alpha-disklabel code yesterday, I can't > tell if you have that fix or not in your kernel. > > Other than that it seems pretty ok to me. Sorry about the verboseness, > it will be reduced. > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-alpha" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Thu Mar 28 22:56:33 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 5C10237B41E for ; Thu, 28 Mar 2002 22:56:25 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2T6u1e7028439; Fri, 29 Mar 2002 07:56:01 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: mjacob@feral.com Cc: alpha@FreeBSD.ORG Subject: Re: Please test GEOM in -current... In-Reply-To: Your message of "Thu, 28 Mar 2002 20:20:38 PST." Date: Fri, 29 Mar 2002 07:56:01 +0100 Message-ID: <28438.1017384961@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message , Matthew Jacob writ es: > >It probably is right. > >The one system that I really had wanted to check this on was an XP1000 that >was connected to my VERITAS fabric with lots of Sun labelled disks. > >Unfortunately, ATA chip for this system seems to be causing grief for Soren's >latest code, so I can't get booted. C'est la vie- sorry..... Try this: Index: ata-disk.c =================================================================== RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v retrieving revision 1.128 diff -u -r1.128 ata-disk.c --- ata-disk.c 16 Mar 2002 15:54:41 -0000 1.128 +++ ata-disk.c 28 Mar 2002 13:39:04 -0000 @@ -211,10 +211,12 @@ atadev->driver = adp; atadev->flags = 0; +#if 0 /* if this disk belongs to an ATA RAID dont print the probe */ if (ata_raiddisk_attach(adp)) adp->flags |= AD_F_RAID_SUBDISK; else +#endif ad_print(adp); } -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Mar 29 6:10:21 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 728F637B41B for ; Fri, 29 Mar 2002 06:10:09 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id JAA07067; Fri, 29 Mar 2002 09:10:05 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2TE9Zm81532; Fri, 29 Mar 2002 09:09:35 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15524.30111.733126.689172@grasshopper.cs.duke.edu> Date: Fri, 29 Mar 2002 09:09:35 -0500 (EST) To: Poul-Henning Kamp Cc: mjacob@feral.com, alpha@FreeBSD.ORG Subject: Re: Please test GEOM in -current... In-Reply-To: <28438.1017384961@critter.freebsd.dk> References: <28438.1017384961@critter.freebsd.dk> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Poul-Henning Kamp writes: > In message , Matthew Jacob writ > es: > > > >It probably is right. > > > >The one system that I really had wanted to check this on was an XP1000 that > >was connected to my VERITAS fabric with lots of Sun labelled disks. > > > >Unfortunately, ATA chip for this system seems to be causing grief for Soren's > >latest code, so I can't get booted. C'est la vie- sorry..... > > > Try this: > > Index: ata-disk.c > =================================================================== > RCS file: /home/ncvs/src/sys/dev/ata/ata-disk.c,v > retrieving revision 1.128 > diff -u -r1.128 ata-disk.c > --- ata-disk.c 16 Mar 2002 15:54:41 -0000 1.128 > +++ ata-disk.c 28 Mar 2002 13:39:04 -0000 > @@ -211,10 +211,12 @@ > atadev->driver = adp; > atadev->flags = 0; > > +#if 0 > /* if this disk belongs to an ATA RAID dont print the probe */ > if (ata_raiddisk_attach(adp)) > adp->flags |= AD_F_RAID_SUBDISK; > else > +#endif > ad_print(adp); > } Did this get broken again? I came up w/a fix for the ata raid probe code blowing up on 64-bit systems that Soren committed on the 16th.. Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Mar 29 7:56:20 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from gatekeeper.orem.verio.net (gatekeeper.orem.verio.net [192.41.0.8]) by hub.freebsd.org (Postfix) with ESMTP id 1B51137B405 for ; Fri, 29 Mar 2002 07:56:18 -0800 (PST) Received: from mx.dmz.orem.verio.net (mx.dmz.orem.verio.net [10.1.1.10]) by gatekeeper.orem.verio.net (Postfix) with ESMTP id A2EC73BF159 for ; Fri, 29 Mar 2002 08:56:17 -0700 (MST) Received: from vespa.dmz.orem.verio.net (vespa.dmz.orem.verio.net [10.1.1.59]) by mx.dmz.orem.verio.net (8.11.6/8.11.6) with ESMTP id g2TFuHf29001 for ; Fri, 29 Mar 2002 08:56:17 -0700 (MST) Date: Fri, 29 Mar 2002 09:09:45 -0700 (MST) From: Fred Clift X-X-Sender: To: Subject: Re: Please test GEOM in -current... In-Reply-To: Message-ID: <20020329090647.H45141-100000@vespa.dmz.orem.verio.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org You wouldn't happen to have patches against 4.5-STABLE? I can't afford to shut down the one alpha I have for long periods of time and dont really want to track -current with a 'production' box. I would however like to try the code out... Fred -- Fred Clift - fred@clift.org -- Remember: If brute force doesn't work, you're just not using enough. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Mar 29 9:33:59 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from beppo.feral.com (beppo.feral.com [192.67.166.79]) by hub.freebsd.org (Postfix) with ESMTP id CB2D537B404 for ; Fri, 29 Mar 2002 09:33:55 -0800 (PST) Received: from mailhost.feral.com (mjacob@mailhost.feral.com [192.67.166.1]) by beppo.feral.com (8.11.3/8.11.3) with ESMTP id g2THXpf42194; Fri, 29 Mar 2002 09:33:51 -0800 (PST) (envelope-from mjacob@feral.com) Date: Fri, 29 Mar 2002 09:33:51 -0800 (PST) From: Matthew Jacob X-Sender: mjacob@beppo Reply-To: mjacob@feral.com To: Poul-Henning Kamp Cc: alpha@FreeBSD.ORG Subject: Re: Please test GEOM in -current... In-Reply-To: <28438.1017384961@critter.freebsd.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, 29 Mar 2002, Poul-Henning Kamp wrote: > In message , Matthew Jacob writ > es: > > > >It probably is right. > > > >The one system that I really had wanted to check this on was an XP1000 that > >was connected to my VERITAS fabric with lots of Sun labelled disks. > > > >Unfortunately, ATA chip for this system seems to be causing grief for Soren's > >latest code, so I can't get booted. C'est la vie- sorry..... > > > Try this: I did already :-)... but then the machine froze: g_add_class(DISK-class) g_post_event(1, 0, 0, 0xfffffe0016c53d80, 0) ad0: ATA-5 disk at ata0-master ad0: 4126MB (8452080 sectors), 8944 C, 15 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, WDMA2 ad0: piomode=4 dmamode=2 udmamode=4 cblid=1 g_do_event(0xfffffe0016e15c00) 1 m:0 g:0 p:0xfffffe0016c53d80 c:0 - EV_NEW_PROVIDER(ad0) mbr_taste(MBR-class,ad0) ad1: success setting WDMA2 on Cypress chip g_post_event(1, 0, 0, 0xfffffe0016c53a00, 0) ad1: ATA-4 disk at ata0-slave ad1: 3098MB (6346368 sectors), 6296 C, 16 H, 63 S, 512 B ad1: 16 secs/int, 1 depth queue, WDMA2 ad1: piomode=4 dmamode=2 udmamode=2 cblid=0 Waiting 15 seconds for SCSI devices to settle isp1: driver initiated bus reset of bus 0 isp2: driver initiated bus reset of bus 0 g_post_event(1, 0, 0, 0xfffffe0016f1e580, 0) pass0 at isp0 bus 0 target 2 lun 0 pass0: Fixed Direct Access SCSI-3 device pass0: Serial Number pass0: 100.000MB/s transfers, Tagged Queueing Enabled da0 at isp0 bus 0 target 2 lun 0 da0: Fixed Direct Access SCSI-3 device da0: Serial Number da0: 100.000MB/s transfers, Tagged Queueing Enabled da0: 3920MB (8028160 512 byte sectors: 255H 63S/T 499C) release_aps: releasing secondary CPUs Mounting root from ufs:/dev/ad0a g_dev_clone(ad0a) Dunno whether this was a GEOM or ATA issue. I'm betting the latter because GEOM worked on the Alpha 4100 4-way that boots off of a differential ISP. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Mar 29 10:16: 0 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 9002637B422 for ; Fri, 29 Mar 2002 10:15:32 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g2TIF0e7052957; Fri, 29 Mar 2002 19:15:01 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Andrew Gallatin Cc: mjacob@feral.com, alpha@FreeBSD.ORG Subject: Re: Please test GEOM in -current... In-Reply-To: Your message of "Fri, 29 Mar 2002 09:09:35 EST." <15524.30111.733126.689172@grasshopper.cs.duke.edu> Date: Fri, 29 Mar 2002 19:15:00 +0100 Message-ID: <52956.1017425700@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org In message <15524.30111.733126.689172@grasshopper.cs.duke.edu>, Andrew Gallatin writes: > >Did this get broken again? I came up w/a fix for the ata raid probe >code blowing up on 64-bit systems that Soren committed on the 16th.. It blows up on (some) i386 boxes as well. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Mar 29 10:18: 5 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by hub.freebsd.org (Postfix) with ESMTP id 19D6D37B447 for ; Fri, 29 Mar 2002 10:17:43 -0800 (PST) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.9.3/8.9.3) with ESMTP id NAA14798; Fri, 29 Mar 2002 13:17:42 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id g2TIHCK81888; Fri, 29 Mar 2002 13:17:12 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15524.44968.321388.638851@grasshopper.cs.duke.edu> Date: Fri, 29 Mar 2002 13:17:12 -0500 (EST) To: Poul-Henning Kamp Cc: alpha@FreeBSD.ORG Subject: Re: Please test GEOM in -current... In-Reply-To: <52956.1017425700@critter.freebsd.dk> References: <15524.30111.733126.689172@grasshopper.cs.duke.edu> <52956.1017425700@critter.freebsd.dk> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org Poul-Henning Kamp writes: > In message <15524.30111.733126.689172@grasshopper.cs.duke.edu>, Andrew Gallatin > writes: > > > > >Did this get broken again? I came up w/a fix for the ata raid probe > >code blowing up on 64-bit systems that Soren committed on the 16th.. > > It blows up on (some) i386 boxes as well. It must be using a different brand of explosives now... Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message From owner-freebsd-alpha Fri Mar 29 11:29:11 2002 Delivered-To: freebsd-alpha@freebsd.org Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by hub.freebsd.org (Postfix) with ESMTP id 687B637B404 for ; Fri, 29 Mar 2002 11:29:08 -0800 (PST) Received: (from wkb@localhost) by freebie.xs4all.nl (8.11.6/8.11.6) id g2TJSxI26185; Fri, 29 Mar 2002 20:28:59 +0100 (CET) (envelope-from wkb) Date: Fri, 29 Mar 2002 20:28:59 +0100 From: Wilko Bulte To: Andrew Gallatin Cc: Poul-Henning Kamp , alpha@FreeBSD.ORG Subject: Re: Please test GEOM in -current... Message-ID: <20020329202859.A26167@freebie.xs4all.nl> References: <15524.30111.733126.689172@grasshopper.cs.duke.edu> <52956.1017425700@critter.freebsd.dk> <15524.44968.321388.638851@grasshopper.cs.duke.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <15524.44968.321388.638851@grasshopper.cs.duke.edu>; from gallatin@cs.duke.edu on Fri, Mar 29, 2002 at 01:17:12PM -0500 X-OS: FreeBSD 4.5-STABLE X-PGP: finger wilko@freebsd.org Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Fri, Mar 29, 2002 at 01:17:12PM -0500, Andrew Gallatin wrote: > > Poul-Henning Kamp writes: > > In message <15524.30111.733126.689172@grasshopper.cs.duke.edu>, Andrew Gallatin > > writes: > > > > > > > >Did this get broken again? I came up w/a fix for the ata raid probe > > >code blowing up on 64-bit systems that Soren committed on the 16th.. > > > > It blows up on (some) i386 boxes as well. > > It must be using a different brand of explosives now... Old fashioned 32bit explosives.. -- | / o / /_ _ wilko@FreeBSD.org |/|/ / / /( (_) Bulte Arnhem, the Netherlands We are FreeBSD. Resistance is futile. Prepare to be committed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message