From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 00:32:04 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6907316A41C for ; Sun, 17 Jul 2005 00:32:04 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from vomit.ugcs.caltech.edu (vomit.ugcs.caltech.edu [131.215.176.103]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B43943D46 for ; Sun, 17 Jul 2005 00:32:03 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by vomit.ugcs.caltech.edu (Postfix, from userid 3640) id 8B59AE816; Sat, 16 Jul 2005 17:32:03 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by vomit.ugcs.caltech.edu (Postfix) with ESMTP id 6B4CEE815; Sat, 16 Jul 2005 17:32:03 -0700 (PDT) Date: Sat, 16 Jul 2005 17:32:03 -0700 (PDT) From: Jon Dama To: Matthias Buelow In-Reply-To: <20050716172632.GG752@drjekyll.mkbuelow.net> Message-ID: References: <20050715224650.GA48516@outcold.yadt.co.uk> <200507152342.j6FNg5Tx015427@drjekyll.mkbuelow.net> <20050716133710.GA71580@outcold.yadt.co.uk> <20050716141630.GB752@drjekyll.mkbuelow.net> <1121530912.17757.32.camel@zappa.Chelsea-Ct.Org> <44k6jqof72.fsf@be-well.ilk.org> <20050716172632.GG752@drjekyll.mkbuelow.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org, Lowell Gilbert Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 00:32:04 -0000 No, it's at a level below softupdates that this must be done. Softupdates only understands when things have been marked completed with biodone()--the underlying scsi/ata/sata driver must make the determination as to when biodone should be called. The flush has to be done there. _IF_ the flush is being done there, then request barriers represent a performance enhancement, not an integrity enhancement. -Jon On Sat, 16 Jul 2005, Matthias Buelow wrote: > Lowell Gilbert wrote: > > >Well, break it down a little bit. If an ATA drive properly implements > >the cache flush command, then none of the ongoing discussion is > > Are you sure this is the case? Are there sequence points in softupdates > where it issues a flush request and by this guarantees fs integrity? > I've read thru McKusick's paper in search for an answer but haven't > found any. All I've read so far on mailing lists and from googling > was that softupdates doesn't work if the wb-cache is enabled. > > mkb. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 00:33:56 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 24DCD16A41C for ; Sun, 17 Jul 2005 00:33:56 +0000 (GMT) (envelope-from dave@horsfall.org) Received: from dave.horsfall.org (mrdavi2.lnk.telstra.net [139.130.75.233]) by mx1.FreeBSD.org (Postfix) with ESMTP id B444143D48 for ; Sun, 17 Jul 2005 00:33:54 +0000 (GMT) (envelope-from dave@horsfall.org) Received: from localhost (dave@localhost) by dave.horsfall.org (8.11.4/8.11.4) with ESMTP id j6H0XpZ25321 for ; Sun, 17 Jul 2005 10:33:51 +1000 (EST) Date: Sun, 17 Jul 2005 10:33:51 +1000 (EST) From: Dave Horsfall To: FreeBSD STABLE list In-Reply-To: <200507161656.j6GGuv611492@toad.rmkhome.com> Message-ID: References: <200507161656.j6GGuv611492@toad.rmkhome.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 00:33:56 -0000 On Sat, 16 Jul 2005, Rick Kelly wrote: > The main reason for sync;sync;sync on V7 UNIX was because you couldn't > do a shutdown, only a halt to the hardware monitor, on the PDP11. You > can verify that behavior with SIMH. :-) And you weren't supposed to use "sync;sync;sync" but this: # sync # sync # sync They were *not* the same. -- Dave From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 10:18:42 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 56EF316A41C; Sun, 17 Jul 2005 10:18:42 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr8.xs4all.nl (smtp-vbr8.xs4all.nl [194.109.24.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4EBF43D46; Sun, 17 Jul 2005 10:18:41 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr8.xs4all.nl (8.13.3/8.13.3) with ESMTP id j6HAIdg7036209; Sun, 17 Jul 2005 12:18:40 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.3/8.13.3) with ESMTP id j6HAIdu6082730; Sun, 17 Jul 2005 12:18:39 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.3/8.13.1/Submit) id j6HAId1K082729; Sun, 17 Jul 2005 12:18:39 +0200 (CEST) (envelope-from wb) Date: Sun, 17 Jul 2005 12:18:39 +0200 From: Wilko Bulte To: Garance A Drosihn , scottl@freebsd.org Message-ID: <20050717101838.GA82651@freebie.xs4all.nl> References: <42D79676.6040606@samsco.org> <1DE73C33-06AD-4569-A90C-370484EB6019@holmen.cc> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-OS: FreeBSD 5.4-STABLE User-Agent: Mutt/1.5.9i X-Virus-Scanned: by XS4ALL Virus Scanner Cc: =?iso-8859-1?Q?=D8ystein?= Holmen , freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.0-BETA1 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 10:18:42 -0000 On Sat, Jul 16, 2005 at 06:33:24PM -0400, Garance A Drosihn wrote.. > At 1:06 PM +0200 7/16/05, Øystein Holmen wrote: > >I was looking for a place to download 6.0-BETA1-powerpc-bootonly.iso > >to test om my PowerMac G4. But I cannot find it on any of > >the ftp-sites og mirrors. Where can I download it? > > It may have been taken down. There were a few problems with the > iso's of 6.0-beta1 for PowerPC. Well, ftp-master.freebsd.org carries it, so the mirrors should do as well: ftp-master: find . -name 6.0-BETA1-powerpc-bootonly.iso ./releases/ppc/ISO-IMAGES/6.0/6.0-BETA1-powerpc-bootonly.iso There is no ISO-IMAGES-powerpc in the top of the tree, like there is for the other archs. No idea why that is the case to be honest. Scott might know. Wilko -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 10:28:26 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 405E916A41C for ; Sun, 17 Jul 2005 10:28:26 +0000 (GMT) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD7DA43D45 for ; Sun, 17 Jul 2005 10:28:24 +0000 (GMT) (envelope-from michiel@boland.org) Received: from brakkenstein.nijmegen.internl.net by neerbosch.nijmegen.internl.net via brakkenstein.nijmegen.internl.net [217.149.193.41] with ESMTP for id j6HASNT1009771 (8.13.2/1.4); Sun, 17 Jul 2005 12:28:23 +0200 (MET DST) Received: from localhost by brakkenstein.nijmegen.internl.net via mboland@localhost with ESMTP for id j6HASMnq028806 (8.13.2/2.02); Sun, 17 Jul 2005 12:28:22 +0200 (MEST) X-Authentication-Warning: brakkenstein.nijmegen.internl.net: mboland owned process doing -bs Date: Sun, 17 Jul 2005 12:28:22 +0200 (MEST) From: Michiel Boland To: freebsd-stable@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: RELENG_6: panic in mpt_attach (amd64) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 10:28:26 -0000 RELENG_6 on amd64 (Sun V20Z), cvsupped today GENERIC kernel, except for additions of GEOM_MIRROR and BREAK_TO_DEBUGGER Crashes immeately on boot mpt0: port 0x2000-0x20ff mem 0xfe850000-0xfe85ffff,0xfe840000-0xfe84ffff irq 27 at device 4.0 on pci2 mpt0: [GIANT-LOCKED] mpt0: MPI Version=1.2.12.0 mpt0: Unhandled Event Notify Frame. Event 0xa. mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE ) mpt0: 0 Active Volumes (1 Max) mpt0: 0 Hidden Drive Members (6 Max) Memory modified after free 0xffffff00f3dec540(8) val=0 @ 0xffffff00f3dec540 panic: Most recently used by bus cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x2f: nop db> tr Tracing pid 0 tid 0 td 0xffffffff8081e380 kdb_enter() at kdb_enter+0x2f panic() at panic+0x249 mtrash_ctor() at mtrash_ctor+0x78 uma_zalloc_arg() at uma_zalloc_arg+0x2c6 malloc() at malloc+0xa3 mpt_core_attach() at mpt_core_attach+0x71a mpt_attach() at mpt_attach+0x49 mpt_pci_attach() at mpt_pci_attach+0x895 device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 acpi_pci_attach() at acpi_pci_attach+0xf1 device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 acpi_pcib_attach() at acpi_pcib_attach+0xf0 acpi_pcib_pci_attach() at acpi_pcib_pci_attach+0x97 device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 acpi_pci_attach() at acpi_pci_attach+0xf1 device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 acpi_pcib_attach() at acpi_pcib_attach+0xf0 acpi_pcib_acpi_attach() at acpi_pcib_acpi_attach+0xdb device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 acpi_attach() at acpi_attach+0x7f1 device_attach() at device_attach+0x292 bus_generic_attach() at bus_generic_attach+0x18 nexus_attach() at nexus_attach+0x19 device_attach() at device_attach+0x292 root_bus_configure() at root_bus_configure+0x1e configure() at configure+0xa mi_startup() at mi_startup+0xd3 btext() at btext+0x2c From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 11:17:19 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B8EF016A41C for ; Sun, 17 Jul 2005 11:17:19 +0000 (GMT) (envelope-from blaz@si.FreeBSD.org) Received: from out-2.mail.amis.net (out-2.mail.amis.net [212.18.32.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADDED43D4C for ; Sun, 17 Jul 2005 11:17:17 +0000 (GMT) (envelope-from blaz@si.FreeBSD.org) Received: from localhost (in-1.mail.amis.net [212.18.32.15]) by out-2.mail.amis.net (Postfix) with ESMTP id 7F71D108D33; Sun, 17 Jul 2005 13:17:16 +0200 (CEST) Received: from in-1.mail.amis.net ([127.0.0.1]) by localhost (in-1.mail.amis.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31715-04; Sun, 17 Jul 2005 13:17:12 +0200 (CEST) Received: from smtp.amis.net (smtp.amis.net [212.18.32.41]) by in-1.mail.amis.net (Postfix) with ESMTP id 46E023C7FA3; Sun, 17 Jul 2005 13:17:12 +0200 (CEST) Received: from titanic.medinet.si (titanic.medinet.si [212.18.42.5]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.amis.net (Postfix) with ESMTP id 34648396809; Sun, 17 Jul 2005 13:17:12 +0200 (CEST) Date: Sun, 17 Jul 2005 13:17:11 +0200 (CEST) From: Blaz Zupan X-X-Sender: blaz@titanic.medinet.si To: Matt Juszczak In-Reply-To: <20050712141639.U72892@neptune.atopia.net> Message-ID: <20050717131610.T29059@titanic.medinet.si> References: <42BF8815.6090909@atopia.net> <20050627081933.GA97832@cell.sick.ru> <42C16394.4040904@atopia.net> <1119971279.36316.45.camel@buffy.york.ac.uk> <42C16C0E.9090002@atopia.net> <20050629100535.GC27557@xor.obsecurity.org> <20050701184352.GA177@xor.obsecurity.org> <20050706093012.M3376@titanic.medinet.si> <20050706104344.U4718@titanic.medinet.si> <20050712141639.U72892@neptune.atopia.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at amis.net X-Spam-Status: No, hits=-5.113 required=5 tests=[ALL_TRUSTED=-3.3, AWL=0.786, BAYES_00=-2.599] X-Spam-Level: Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD -STABLE servers repeatedly crashing. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 11:17:19 -0000 On Tue, 12 Jul 2005, Matt Juszczak wrote: > So far a 13 day up time after switching from IPF to PF. If thats not the > problem, I hope I find it soon considering this is a production server ... > but it seems to be more stable. For me, 5 days up time after switching from IPF to PF. Before the switch a couple of hours of uptime was the maximum. Seems like the crashes are caused by ipfilter. From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 14:02:35 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91E7216A41C; Sun, 17 Jul 2005 14:02:35 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20C0543D46; Sun, 17 Jul 2005 14:02:34 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6HE762x096027; Sun, 17 Jul 2005 08:07:06 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42DA64FB.3040703@samsco.org> Date: Sun, 17 Jul 2005 08:02:35 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wilko Bulte References: <42D79676.6040606@samsco.org> <1DE73C33-06AD-4569-A90C-370484EB6019@holmen.cc> <20050717101838.GA82651@freebie.xs4all.nl> In-Reply-To: <20050717101838.GA82651@freebie.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: scottl@freebsd.org, =?ISO-8859-1?Q?=D8ystein_Holmen?= , Garance A Drosihn , freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.0-BETA1 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 14:02:35 -0000 Wilko Bulte wrote: > On Sat, Jul 16, 2005 at 06:33:24PM -0400, Garance A Drosihn wrote.. > >>At 1:06 PM +0200 7/16/05, Øystein Holmen wrote: >> >>>I was looking for a place to download 6.0-BETA1-powerpc-bootonly.iso >>>to test om my PowerMac G4. But I cannot find it on any of >>>the ftp-sites og mirrors. Where can I download it? >> >>It may have been taken down. There were a few problems with the >>iso's of 6.0-beta1 for PowerPC. > > > Well, ftp-master.freebsd.org carries it, so the mirrors should do as well: > > ftp-master: find . -name 6.0-BETA1-powerpc-bootonly.iso > ./releases/ppc/ISO-IMAGES/6.0/6.0-BETA1-powerpc-bootonly.iso > ftp-master didn't carry it until yesterday morning, due to a permission problem. > There is no ISO-IMAGES-powerpc in the top of the tree, like there is > for the other archs. No idea why that is the case to be honest. > Scott might know. Simple oversight. I'll into it, thanks. Scott From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 14:57:11 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F342116A41C for ; Sun, 17 Jul 2005 14:57:10 +0000 (GMT) (envelope-from Michiel.Boland@internl.net) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5C86C43D46 for ; Sun, 17 Jul 2005 14:57:09 +0000 (GMT) (envelope-from Michiel.Boland@internl.net) Received: from brakkenstein.nijmegen.internl.net by neerbosch.nijmegen.internl.net via brakkenstein.nijmegen.internl.net [217.149.193.41] with ESMTP for id j6HEv8FW029500 (8.13.2/1.4); Sun, 17 Jul 2005 16:57:08 +0200 (MET DST) Received: from localhost by brakkenstein.nijmegen.internl.net via mboland@localhost with ESMTP for id j6HEv8GH029566 (8.13.2/2.02); Sun, 17 Jul 2005 16:57:08 +0200 (MEST) X-Authentication-Warning: brakkenstein.nijmegen.internl.net: mboland owned process doing -bs Date: Sun, 17 Jul 2005 16:57:08 +0200 (MEST) From: Michiel Boland To: freebsd-stable@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: nextboot and gmirror X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 14:57:11 -0000 Hi. If nextboot_enable="YES", the loader scribbles in /boot/netxtboot.conf. But how exactly does this work on gmirror-ed disks? Does /boot/nextboot.conf get written on one disk only? How does the other disk know that /boot/nextboot.conf got changed? I am confused. Cheers Michiel From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 15:10:37 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A012C16A41C for ; Sun, 17 Jul 2005 15:10:37 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E4D343D45 for ; Sun, 17 Jul 2005 15:10:37 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id 485E2A2469C for ; Sun, 17 Jul 2005 12:10:36 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 08897-02 for ; Sun, 17 Jul 2005 15:10:36 +0000 (GMT) Received: from ganymede.hub.org (blk-224-176-51.eastlink.ca [24.224.176.51]) by hub.org (Postfix) with ESMTP id 31015A2465A for ; Sun, 17 Jul 2005 12:10:35 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id B1A8A47705; Sun, 17 Jul 2005 12:10:33 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id B0BDA47703 for ; Sun, 17 Jul 2005 12:10:33 -0300 (ADT) Date: Sun, 17 Jul 2005 12:10:33 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-stable@freebsd.org In-Reply-To: <20050715120008.H66818@ganymede.hub.org> Message-ID: <20050717120926.R66818@ganymede.hub.org> References: <20050715120008.H66818@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Subject: vnode leak in NFS (Was: Re: 4.11-STABLE leaks vnodes worse then 4.x from Feb 13th ... ?) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 15:10:37 -0000 Wow, now this was unexpected ... figured I try a quick theory this morning ... debug.freevnodes was down to: debug.freevnodes: 103987 umount /nfs and ... # sysctl debug.freevnodes debug.freevnodes: 332106 The vnode leak isn't in the unionfs code ... its in the nfs code :( On Fri, 15 Jul 2005, Marc G. Fournier wrote: > > Recently, I started having problems with one of my newest servers ... > figuring that it might have somethign to do with the fact that I went SATA > for this one (all others are SCSI), I figured it might be a driver issue > causing the problems, since everything else is the same as the other 5 > servers on our network ... > > Today, I'm starting to wonder if I've been just looking at the "most obvious" > cause, instead of looking deeper ... > > The problem that manifests itself is similar to the old 'ran out of vnode' > issue I used to experience under 4.x ... the server would still run, be > totally pingable, and you could even get the motd when you tried to ssh in, > but you couldn't get a prompt, and all processes were hung ... > > I just upgraded the kernel on this machine (mercury) on the 13th of July, and > its been running 1 day, 12 hrs now ... there is hardly anything running on > this machine (10 jails), and vnode usage is: > > debug.numvnodes: 336460 - debug.freevnodes: 5275 - debug.vnlru_nowhere: 0 - > vlruwt > > One of my older servers (neptune), running kernels from Feb 13th of this > year, and with 81 jails running on it, is using up *significantly less* > vnodes (uptime: 1 day, 10 hours): > > debug.numvnodes: 279710 - debug.freevnodes: 91442 - debug.vnlru_nowhere: 0 - > vlruwt > > Now, compared to neptune, mercury isn't running anything special ... several > apache 1 processes, postfix, cyrus-imapd and that's it ... neptune on the > other hand, is running the full gambit ... aolserver, java, apache 1 and 2, > postfix, etc ... > > So, I'm starting to think that the problem isn't "hardware related", but the > kernel itself ... the latest 4.11-STABLE kernel seems to have brought in new > vnode leakage, or ... vnlru isn't working as it should be to free up vnodes > ... > > Looking at that process on mercury: > > # ps aux | grep vnlru > root 7 0.0 0.0 0 0 ?? DL Wed11PM 0:00.65 (vnlru) > > whereas on neptune: > > # ps aux | grep vnlru > root 9 0.0 0.0 0 0 ?? DL Thu01AM 0:00.79 (vnlru) > > so about the same about of CPU time being expended ... a bit more on the more > loaded server, but not a major amount ... > > I'd like to try and debug this, but don't know where to start ... I realize > that 4.x isn't being pushed anymore, but there are alot of us that haven't > moved to 5.x yet (am working on that for our next server, but its going to > take me several months before I can convert all our existing servers up) ... > > I do have a serial console on this server, if that helps to debug things ... > > I've heard that there was some work done on 5.x to clean up some of the vnode > leaks ... not sure if that is fact or just rumor ... but, if so, would any of > them be MFCable to 4.x? > > Thanks ... > > ---- > Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) > Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 15:54:37 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2F10716A41C for ; Sun, 17 Jul 2005 15:54:37 +0000 (GMT) (envelope-from dlt@mebtel.net) Received: from bilbo.mebtel.net (bilbo.mebtel.net [64.40.67.45]) by mx1.FreeBSD.org (Postfix) with ESMTP id D013243D45 for ; Sun, 17 Jul 2005 15:54:36 +0000 (GMT) (envelope-from dlt@mebtel.net) Received: from localhost (localhost [127.0.0.1]) by bilbo.mebtel.net (Postfix) with ESMTP id D5A8B2A79F for ; Sun, 17 Jul 2005 11:54:35 -0400 (EDT) Received: from bilbo.mebtel.net ([127.0.0.1]) by localhost (bilbo [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05610-09 for ; Sun, 17 Jul 2005 11:54:35 -0400 (EDT) Received: from sukey.arm.org (66-79-79-172.dsl.mebtel.net [66.79.79.172]) by bilbo.mebtel.net (Postfix) with ESMTP id 437262A754 for ; Sun, 17 Jul 2005 11:54:35 -0400 (EDT) Received: from sukey.arm.org (localhost [127.0.0.1]) by sukey.arm.org (8.13.4/8.13.4) with ESMTP id j6HFsYRh045942 for ; Sun, 17 Jul 2005 11:54:34 -0400 (EDT) (envelope-from dlt@sukey.arm.org) Received: (from dlt@localhost) by sukey.arm.org (8.13.4/8.13.4/Submit) id j6HFsYhR045939; Sun, 17 Jul 2005 11:54:34 -0400 (EDT) (envelope-from dlt) Date: Sun, 17 Jul 2005 11:54:34 -0400 (EDT) Message-Id: <200507171554.j6HFsYhR045939@sukey.arm.org> From: Derek Tattersall To: freebsd-stable@FreeBSD.ORG X-Virus-Scanned: by amavisd-new at mebtel.net Cc: Subject: 6.0 BETA 1 post install issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 15:54:37 -0000 If this is the wrong group to discuss 6.0 installation problems, please refer me to the correct one. I installed 6.0 BETA 1 yesterday via NFS from my local server. The installation went with no reportable problems. However, when I got to the post install configuration menu, I could not get the console mouse to work. It didn't show a pointer, even after I set the protocol (auto) and the type (PS2). After rebooting, I configured rc.conf by hand and set the mouse related entries, rebooted and the mouse works fine. I'm not sure where to go from here. This was on an IBM G40 laptop, on which I have installed 5.2 through 5.4 without a problem configuring the mouse for the console. -- Derek Tattersall | (Insert witty remark here) | dlt@mebtel.net | dtatters@gmail.com | dlt666@yahoo.com | From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 15:58:58 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C72BB16A41C for ; Sun, 17 Jul 2005 15:58:58 +0000 (GMT) (envelope-from john.vansickle@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D54D43D46 for ; Sun, 17 Jul 2005 15:58:58 +0000 (GMT) (envelope-from john.vansickle@gmail.com) Received: by rproxy.gmail.com with SMTP id b11so1095234rne for ; Sun, 17 Jul 2005 08:58:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=uW6vRcTY67PJCP2ZfEmX/b5ZqlSgiDPolaPTK9SbiQOniDD81yrXkxQBu+m1DW1Yt44zGcvxgQU+ljVbjxy/NXJbcr/OmDUHNscG3Qdjg9rmb4rRcqmN8uQq+H2Nu2qIltQ3XpiWZi7e05FRBJYehMxmnKzvRhlYs3VY4SLOvkk= Received: by 10.38.207.2 with SMTP id e2mr1149187rng; Sun, 17 Jul 2005 08:58:57 -0700 (PDT) Received: by 10.38.76.61 with HTTP; Sun, 17 Jul 2005 08:58:57 -0700 (PDT) Message-ID: <138678280507170858c1b3898@mail.gmail.com> Date: Sun, 17 Jul 2005 11:58:57 -0400 From: John Van Sickle To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Atapicam problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Van Sickle List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 15:58:58 -0000 Hi, After a day or two I keep losing my /dev/cd0 and /dev/cd1 devices. When thi= s=20 happens I'm able to reboot and everything works again. By that I mean the= =20 drives show up in /dev again and 'camcontrol devlist' lists them. I haven't= =20 had any errors burning dvds/cds either. My log message gives me the=20 following info after I lose the drives: atapicam0: timeout waiting for ATAPI ready atapicam0: timeout waiting for ATAPI ready atapicam0: timeout waiting for ATAPI ready atapicam0: timeout waiting for ATAPI ready atapicam0: timeout waiting for ATAPI ready atapicam0: timeout waiting for ATAPI ready (probe2:ata1:0:0:0): Lost target 0??? I noticed the problem about two or so weeks ago. I tried running 'camcontro= l=20 rescan all' and 'camcontrol reset all' but it didn't help. I'd also like to= =20 note that I don't have "atapicd" in my kernel or acpi enabled. Not sure if= =20 that matters (hasn't in the past).=20 Thanks for your time. uname -a=20 FreeBSD workstation.insightbb.com =20 5.4-STABLE FreeBSD 5.4-STABLE #0: Fri Jul 15 20:38:58 EDT 2005=20 root@workstation.insightbb.com:/usr/obj/usr/src/sys/SAMSON i386 camcontrol devlist at scbus0 target 0 lun 0 (pass0,da0) <_NEC DVD_RW ND-3540A 1.01> at scbus2 target 0 lun 0 (pass1,cd0) at scbus2 target 1 lun 0 (pass2,cd1) dmesg | grep cd=20 cd0 at ata1 bus 0 target 0 lun 0 cd0: <_NEC DVD_RW ND-3540A 1.01> Removable CD-ROM SCSI-0 device=20 cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present cd1 at ata1 bus 0 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device=20 cd1: 16.000MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present info from 'pciconf -vl' on my ata chipset: atapci0@pci0:4:1: class=3D0x01018a card=3D0x00000000 chip=3D0x05711106 rev= =3D0x06=20 hdr=3D0x00 vendor =3D 'VIA Technologies Inc' device =3D 'VT82xxxx EIDE Controller (All VIA Chipsets)' class =3D mass storage subclass =3D ATA kernel config: machine i386 cpu I686_CPU ident SAMSON=20 # To statically compile in device wiring instead of /boot/device.hints #hints "GENERIC.hints" # Default places to look for devices. options SCHED_4BSD # 4BSD scheduler options INET # InterNETworking options INET6 # IPv6 communications protocols options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS # Pseudo-filesystem framework options GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options KTRACE # ktrace(1) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options KBD_INSTALL_CDEV # install a CDEV entry in /dev options ADAPTIVE_GIANT # Giant mutex is adaptive. device apic # I/O APIC # Bus support. Do not remove isa, even if you have no isa slots device isa device eisa device pci # Floppy drives device fdc # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapifd # ATAPI floppy drives options ATA_STATIC_ID # Static device numbering # SCSI peripherals device scbus # SCSI bus (required for SCSI) device da # Direct Access (disks) device sa # Sequential Access (tape etc) device cd # CD device pass # Passthrough device (direct SCSI access) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device psm # PS/2 mouse device vga # VGA video card driver device splash # Splash screen and screen saver support # syscons is the default console driver, resembling an SCO console device sc # Enable this for the pcvt (VT220 compatible) console driver #device vt #options XSERVER # support for X server on a vt console #options FAT_CURSOR # start with block cursor # Floating point support - do not disable. device npx # Power management support (see NOTES for more options) #device apm # Add suspend/resume support for the i8254. # Parallel port device ppbus # Parallel port bus (required) # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs= ! device miibus # MII bus support device fxp # Intel EtherExpress PRO/100B (82557, 82558) # Pseudo devices. device loop # Network loopback device mem # Memory and kernel memory devices device io # I/O device device random # Entropy device device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory "disks" device gif # IPv6 and IPv4 tunneling device faith # IPv6-to-IPv4 relaying (translation) # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci # UHCI PCI->USB interface device usb # USB Bus (required) #device udbp # USB Double Bulk Pipe devices device ugen # Generic device uhid # "Human Interface Devices" device ulpt # Printer device umass # Disks/Mass storage - Requires scbus and da device ukbd # Keyboard # FireWire support device firewire # FireWire bus code device sbp # SCSI over FireWire (Requires scbus and da) # Custom device sound device "snd_emu10k1" device atapicam options UDF=20 --=20 John Van Sickle www.johnvansickle.com From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 16:45:32 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23B7C16A41C for ; Sun, 17 Jul 2005 16:45:32 +0000 (GMT) (envelope-from jw@innerewut.de) Received: from smtprelay01.ispgateway.de (smtprelay01.ispgateway.de [80.67.18.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A19543D45 for ; Sun, 17 Jul 2005 16:45:29 +0000 (GMT) (envelope-from jw@innerewut.de) Received: (qmail 27323 invoked from network); 17 Jul 2005 16:45:25 -0000 Received: from unknown (HELO [192.168.0.200]) (068076@[85.178.220.90]) (envelope-sender ) by smtprelay01.ispgateway.de (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 17 Jul 2005 16:45:25 -0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 17 Jul 2005 18:45:20 +0200 From: Jonathan Weiss To: FreeBSD-Stable Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: RELENG_6 has problems with booting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 16:45:32 -0000 Cheers, Yesterday I updated my 5-STABLE system to RELENG_6 through cvsup&make. My machine will only boot in safe mode. Verbose or normal boot will result in a hang that occuers normally during local package startup or filesystem scan. I get no panic or LOR, the machine just completely hangs. I used the GENERIC kernel with these points added: --------------------------------------------------- # PF device pf device pflog device pfsync # ALTQ options ALTQ options ALTQ_CBQ # Class Bases Queueing options ALTQ_RED # Random Early Drop options ALTQ_RIO # RED In/Out options ALTQ_HFSC # Hierarchical Packet Scheduler options ALTQ_CDNR # Traffic conditioner options ALTQ_PRIQ # Priority Queueing options ALTQ_NOPCC # Required for SMP build options ALTQ_DEBUG # Sound device sound device "snd_via82c686" #atapicam device atapicam # GBDE options GEOM_BDE options COMPAT_FREEBSD5 --------------------------------------------------- I also tried a kernel with `options SMP` commented out but it still hangs. The dmesg: --------------------------------------------------- Copyright (c) 1992-2005 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 6.0-BETA1 #2: Sat Jul 16 23:22:20 CEST 2005 root@satan.nodomain:/usr/obj/usr/src/sys/XXX WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) XP 2500+ (1830.01-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 Features=0x383fbff AMD Features=0xc0400800 real memory = 536805376 (511 MB) avail memory = 515989504 (492 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pir0: on motherboard pci0: on pcib0 $PIR: No matching entry for 0.1.INTA $PIR: No matching entry for 0.2.INTA $PIR: No matching entry for 0.2.INTB $PIR: No matching entry for 0.2.INTC $PIR: No matching entry for 0.4.INTA $PIR: No matching entry for 0.6.INTA agp0: mem 0xd8000000-0xdbffffff at device 0.0 on pci0 pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) ohci0: mem 0xe0003000-0xe0003fff irq 12 at device 2.0 on pci0 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xe0004000-0xe0004fff irq 11 at device 2.1 on pci0 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xe0005000-0xe00050ff irq 5 at device 2.2 on pci0 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered ulpt0: Brother HL-5040, rev 2.00/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode nve0: port 0xd000-0xd007 mem 0xe0000000-0xe0000fff irq 11 at device 4.0 on pci0 nve0: Ethernet address 00:0c:6e:57:5a:25 miibus0: on nve0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nve0: Ethernet address: 00:0c:6e:57:5a:25 nve0: [GIANT-LOCKED] pci0: at device 6.0 (no driver attached) pcib1: at device 8.0 on pci0 pci1: on pcib1 ed0: port 0xc000-0xc01f irq 5 at device 8.0 on pci1 ed0: [GIANT-LOCKED] ed0: Ethernet address: 00:a0:d2:14:f5:33 ed0: if_start running deferred for Giant ed0: type NE2000 (16 bit) dc0: port 0xc400-0xc4ff mem 0xdf000000-0xdf0000ff irq 12 at device 10.0 on pci1 miibus1: on dc0 ukphy0: on miibus1 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: Ethernet address: 00:80:ad:04:c6:78 dc0: if_start running deferred for Giant dc0: [GIANT-LOCKED] atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 9.0 on pci0 ata0: on atapci0 ata1: on atapci0 pcib2: at device 30.0 on pci0 pci2: on pcib2 $PIR: ROUTE_INTERRUPT failed. pci2: at device 0.0 (no driver attached) pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcb7ff,0xcc000-0xcd7ff on isa0 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: [FAST] ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 unknown: can't assign resources (port) unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) Timecounter "TSC" frequency 1830013124 Hz quality 800 Timecounters tick every 1.000 msec ad0: 76319MB at ata0-master PIO4 ad1: 190782MB at ata0-slave PIO4 acd0: CDRW at ata1-master PIO4 acd1: DVDROM at ata1-slave PIO4 ATA PseudoRAID loaded Trying to mount root from ufs:/dev/ad0s1a cd0 at ata1 bus 0 target 0 lun 0 cd0: Removable CD-ROM SCSI-0 device cd0: 16.000MB/s transfers cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed cd1 at ata1 bus 0 target 1 lun 0 cd1: Removable CD-ROM SCSI-0 device cd1: 16.000MB/s transfers cd1: Attempt to query device size failed: NOT READY, Medium not present dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state WARNING: attempt to net_add_domain(netgraph) after domainfinalize() WARNING: /private was not properly dismounted ad1: FAILURE - out of memory in start -- Jonathan Weiss http://blog.innerewut.de From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 17:07:18 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1D76A16A41C for ; Sun, 17 Jul 2005 17:07:18 +0000 (GMT) (envelope-from subhro.kar@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DCAA43D45 for ; Sun, 17 Jul 2005 17:07:15 +0000 (GMT) (envelope-from subhro.kar@gmail.com) Received: by rproxy.gmail.com with SMTP id g11so300000rne for ; Sun, 17 Jul 2005 10:07:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:disposition-notification-to:date:from:organization:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type; b=TFVtpayVuUKvhdX9XT1GfQ/JAztd1rLG/l0Os59UMCKE0xGXHagUB6SrSJRcjaDZm69RzfoifbTTR6fo/8TO1WSPOyGkuuWa49zJ/kh5R+MWR1xjCxdFXM5ukmaNIqb8B4Q/+aPvN/6KbgxpoXIaGmQCydxOxnyE9c+N5z4Wrxs= Received: by 10.38.13.64 with SMTP id 64mr1188635rnm; Sun, 17 Jul 2005 10:07:14 -0700 (PDT) Received: from ?127.0.0.1? ([59.93.162.71]) by mx.gmail.com with ESMTP id b66sm2267340rne.2005.07.17.10.07.12; Sun, 17 Jul 2005 10:07:14 -0700 (PDT) Message-ID: <42DA903A.90102@gmail.com> Date: Sun, 17 Jul 2005 22:37:06 +0530 From: Subhro Organization: Indian Institute of Information Technology User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonathan Weiss References: In-Reply-To: Content-Type: multipart/mixed; boundary="------------040301060700030809000809" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: FreeBSD-Stable Subject: Re: RELENG_6 has problems with booting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 17:07:18 -0000 This is a multi-part message in MIME format. --------------040301060700030809000809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 7/17/2005 22:15, Jonathan Weiss wrote: >Cheers, > > >Yesterday I updated my 5-STABLE system to RELENG_6 through cvsup&make. >My machine will only boot in safe mode. Verbose or normal boot will result >in a hang that occuers normally during local package startup or filesystem >scan. > >I get no panic or LOR, the machine just completely hangs. > >I used the GENERIC kernel with these points added: >--------------------------------------------------- ># PF >device pf >device pflog >device pfsync > ># ALTQ >options ALTQ >options ALTQ_CBQ # Class Bases Queueing >options ALTQ_RED # Random Early Drop >options ALTQ_RIO # RED In/Out >options ALTQ_HFSC # Hierarchical Packet Scheduler >options ALTQ_CDNR # Traffic conditioner >options ALTQ_PRIQ # Priority Queueing >options ALTQ_NOPCC # Required for SMP build >options ALTQ_DEBUG > ># Sound >device sound >device "snd_via82c686" > >#atapicam >device atapicam > ># GBDE >options GEOM_BDE > >options COMPAT_FREEBSD5 >--------------------------------------------------- > >I also tried a kernel with `options SMP` commented out but it still hangs. > >The dmesg: >--------------------------------------------------- >Copyright (c) 1992-2005 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 6.0-BETA1 #2: Sat Jul 16 23:22:20 CEST 2005 > root@satan.nodomain:/usr/obj/usr/src/sys/XXX >WARNING: WITNESS option enabled, expect reduced performance. >Timecounter "i8254" frequency 1193182 Hz quality 0 >CPU: AMD Athlon(tm) XP 2500+ (1830.01-MHz 686-class CPU) > Origin = "AuthenticAMD" Id = 0x6a0 Stepping = 0 > >Features=0x383fbffCMOV,PAT,PSE36,MMX,FXSR,SSE> > AMD Features=0xc0400800 >real memory = 536805376 (511 MB) >avail memory = 515989504 (492 MB) >npx0: [FAST] >npx0: on motherboard >npx0: INT 16 interface >cpu0 on motherboard >pcib0: pcibus 0 on motherboard >pir0: on motherboard >pci0: on pcib0 >$PIR: No matching entry for 0.1.INTA >$PIR: No matching entry for 0.2.INTA >$PIR: No matching entry for 0.2.INTB >$PIR: No matching entry for 0.2.INTC >$PIR: No matching entry for 0.4.INTA >$PIR: No matching entry for 0.6.INTA >agp0: mem 0xd8000000-0xdbffffff at device >0.0 on pci0 >pci0: at device 0.1 (no driver attached) >pci0: at device 0.2 (no driver attached) >pci0: at device 0.3 (no driver attached) >pci0: at device 0.4 (no driver attached) >pci0: at device 0.5 (no driver attached) >isab0: at device 1.0 on pci0 >isa0: on isab0 >pci0: at device 1.1 (no driver attached) >ohci0: mem 0xe0003000-0xe0003fff irq 12 at >device 2.0 on pci0 >ohci0: [GIANT-LOCKED] >usb0: OHCI version 1.0, legacy support >usb0: on ohci0 >usb0: USB revision 1.0 >uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >uhub0: 3 ports with 3 removable, self powered >ohci1: mem 0xe0004000-0xe0004fff irq 11 at >device 2.1 on pci0 >ohci1: [GIANT-LOCKED] >usb1: OHCI version 1.0, legacy support >usb1: on ohci1 >usb1: USB revision 1.0 >uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 >uhub1: 3 ports with 3 removable, self powered >ehci0: mem 0xe0005000-0xe00050ff irq 5 >at device 2.2 on pci0 >ehci0: [GIANT-LOCKED] >usb2: EHCI version 1.0 >usb2: companion controllers, 4 ports each: usb0 usb1 >usb2: on ehci0 >usb2: USB revision 2.0 >uhub2: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 >uhub2: 6 ports with 6 removable, self powered >ulpt0: Brother HL-5040, rev 2.00/1.00, addr 2, iclass 7/1 >ulpt0: using bi-directional mode >nve0: port 0xd000-0xd007 mem >0xe0000000-0xe0000fff irq 11 at device 4.0 on pci0 >nve0: Ethernet address 00:0c:6e:57:5a:25 >miibus0: on nve0 >rlphy0: on miibus0 >rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >nve0: Ethernet address: 00:0c:6e:57:5a:25 >nve0: [GIANT-LOCKED] >pci0: at device 6.0 (no driver attached) >pcib1: at device 8.0 on pci0 >pci1: on pcib1 >ed0: port 0xc000-0xc01f irq 5 at device >8.0 on pci1 >ed0: [GIANT-LOCKED] >ed0: Ethernet address: 00:a0:d2:14:f5:33 >ed0: if_start running deferred for Giant >ed0: type NE2000 (16 bit) >dc0: port 0xc400-0xc4ff mem >0xdf000000-0xdf0000ff irq 12 at device 10.0 on pci1 >miibus1: on dc0 >ukphy0: on miibus1 >ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto >dc0: Ethernet address: 00:80:ad:04:c6:78 >dc0: if_start running deferred for Giant >dc0: [GIANT-LOCKED] >atapci0: port >0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 9.0 on pci0 >ata0: on atapci0 >ata1: on atapci0 >pcib2: at device 30.0 on pci0 >pci2: on pcib2 >$PIR: ROUTE_INTERRUPT failed. >pci2: at device 0.0 (no driver attached) >pmtimer0 on isa0 >orm0: at iomem 0xc0000-0xcb7ff,0xcc000-0xcd7ff on isa0 >atkbdc0: at port 0x60,0x64 on isa0 >atkbd0: irq 1 on atkbdc0 >kbd0 at atkbd0 >atkbd0: [GIANT-LOCKED] >fdc0: at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on >isa0 >fdc0: [FAST] >ppc0: at port 0x378-0x37f irq 7 on isa0 >ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode >ppc0: FIFO with 16/16/16 bytes threshold >ppbus0: on ppc0 >plip0: on ppbus0 >lpt0: on ppbus0 >lpt0: Interrupt-driven port >ppi0: on ppbus0 >sc0: at flags 0x100 on isa0 >sc0: VGA <16 virtual consoles, flags=0x300> >sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 >sio0: type 16550A >sio1 at port 0x2f8-0x2ff irq 3 on isa0 >sio1: type 16550A >vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 >unknown: can't assign resources (port) >unknown: can't assign resources (memory) >unknown: can't assign resources (port) >unknown: can't assign resources (port) >unknown: can't assign resources (port) >unknown: can't assign resources (port) >Timecounter "TSC" frequency 1830013124 Hz quality 800 >Timecounters tick every 1.000 msec >ad0: 76319MB at ata0-master PIO4 >ad1: 190782MB at ata0-slave PIO4 >acd0: CDRW at ata1-master PIO4 >acd1: DVDROM at ata1-slave PIO4 >ATA PseudoRAID loaded >Trying to mount root from ufs:/dev/ad0s1a >cd0 at ata1 bus 0 target 0 lun 0 >cd0: Removable CD-ROM SCSI-0 device >cd0: 16.000MB/s transfers >cd0: Attempt to query device size failed: NOT READY, Medium not present - >tray closed >cd1 at ata1 bus 0 target 1 lun 0 >cd1: Removable CD-ROM SCSI-0 device >cd1: 16.000MB/s transfers >cd1: Attempt to query device size failed: NOT READY, Medium not present >dc0: failed to force tx and rx to idle state >dc0: failed to force tx and rx to idle state >dc0: failed to force tx and rx to idle state >dc0: failed to force tx and rx to idle state >WARNING: attempt to net_add_domain(netgraph) after domainfinalize() >WARNING: /private was not properly dismounted >ad1: FAILURE - out of memory in start > > > >-- >Jonathan Weiss >http://blog.innerewut.de > > >_______________________________________________ >freebsd-stable@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-stable >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > What happens if you drop ATAPICAM and do you have a good reason why you are including GEOM_BDE? Thanks S. --------------040301060700030809000809-- From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 18:10:07 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CD0A16A41C for ; Sun, 17 Jul 2005 18:10:07 +0000 (GMT) (envelope-from jw@innerewut.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8C8543D45 for ; Sun, 17 Jul 2005 18:10:06 +0000 (GMT) (envelope-from jw@innerewut.de) Received: (qmail 7297 invoked from network); 17 Jul 2005 18:10:01 -0000 Received: from unknown (HELO [192.168.0.200]) (068076@[85.178.220.90]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 17 Jul 2005 18:10:01 -0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Sun, 17 Jul 2005 20:10:00 +0200 From: Jonathan Weiss To: Subhro Message-ID: In-Reply-To: <42DA903A.90102@gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: FreeBSD-Stable Subject: Re:RELENG_6 has problems with booting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 18:10:07 -0000 > What happens if you drop ATAPICAM and do you have a good reason why you > are including GEOM_BDE? > > Thanks > S. I will try a kernel without ATAPICAM. I need GEOM_BDE for my encrypted disk but I can also try a kernel without it. Greets, Jonathan -- Jonathan Weiss http://blog.innerewut.de From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 19:11:59 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6390416A41C for ; Sun, 17 Jul 2005 19:11:59 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A7D943D49 for ; Sun, 17 Jul 2005 19:11:58 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 63A1446B33; Sun, 17 Jul 2005 15:11:58 -0400 (EDT) Date: Sun, 17 Jul 2005 20:12:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Yann Golanski In-Reply-To: <20050715152744.GA67970@kierun.org> Message-ID: <20050717200728.Q19319@fledge.watson.org> References: <42D79676.6040606@samsco.org> <20050715115650.I66818@ganymede.hub.org> <42D7D3DA.20106@samsco.org> <20050715152744.GA67970@kierun.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD 6.0-BETA1 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 19:11:59 -0000 On Fri, 15 Jul 2005, Yann Golanski wrote: > Quoth Scott Long on Fri, Jul 15, 2005 at 09:18:50 -0600 >> Part of the purpose of moving quickly on to RELENG_6 is so that the >> migration work for users from 5.x to 6.x is very small. 6.x is really >> just an evolutionary step from 5.x, not the life-altering revolutionary >> step that 4.x->5.x was. It should be quite easy to deploy and maintain >> 5.x and 6.x machines side-by-side and migrate them as the need arises. >> We don't want people to be stranded on RELENG_5 like they were with >> RELENG_4. 6.x offers everything of 5.x, but with better performance >> and (hopefully) better stability. If you're thinking about evaluating >> 5.x, give 6.0 a try also. > > Does that mean that a cvsup with "*default tag=RELENG_6" and a rebuilt > of the world will work smoothly? Would it work at all? Is it even > recommended? > > I suspect that re-compiling every port is a good idea after making the > world in any case. I've run into two stumbles that are easily worked around once known: (1) I had to rm -Rf /usr/obj/... because incremental buildworld seemed unhappy as a result of directory and content changes. I don't know what that is. (2) /dev/cuaa* has been renamed to /dev/cuad* Otherwise, be aware that as with 5.x running 4.x binaries, 6.x needs compat stuff to run 5.x binaries. My intuition is that this is an area of the 6.x release that will need further honing, as I'm not sure there's a COMPAT5X library set in 6.x yet. If you're doing an incremental buildworld, this won't be a problem, but if you install a new 6.x machine, it might be. Likewise, BETA1 shipped without the kernel compat option, which won't affect most binaries, but this will be fixed in BETA2. So I think the usual advice holds true in general: do it on a test machine first, and backup, before your production machine with 10,000 users and your only copy of all your data. :-) 6.x seems to be flawlessly picking up work from my 5.x machines now, and generally working better. And hopefully in another week I'll get the netstat -mb fixes for SMP merged to RELENG_6 so that the mbuf allocation counters don't leak under high load on SMP resulting in erroneous statistics, a bug that has irritated me substantially in the 5.x branch. Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 21:27:49 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E2FDB16A41C for ; Sun, 17 Jul 2005 21:27:49 +0000 (GMT) (envelope-from jonathonklem@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7985343D45 for ; Sun, 17 Jul 2005 21:27:49 +0000 (GMT) (envelope-from jonathonklem@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so1128525rne for ; Sun, 17 Jul 2005 14:27:49 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=K7R/7SomCGa1nSQrthoJ04vdf2hf2aZp57KwYoOLkvBC4ImJRowtCR93ixDYWcDNA0NdqKH6UTAEARTVUgmLb6/0HZkWYIYt4Xf22uxQzBCgr7QV5XpwkcjCUG4L7mdzgnFhJQWA76lsv5QM+mU0l0hLy5iPsiwItl5IfKXJXG8= Received: by 10.38.11.44 with SMTP id 44mr1343617rnk; Sun, 17 Jul 2005 14:27:48 -0700 (PDT) Received: by 10.38.101.16 with HTTP; Sun, 17 Jul 2005 14:27:48 -0700 (PDT) Message-ID: Date: Sun, 17 Jul 2005 16:27:48 -0500 From: "Mr. Jonathon Klem" To: freebsd-stable@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <9375582312.93448106232@r4bh198.chello.upc.cz> <42D5FF95.6010100@codegurus.org> Subject: Re: 36 hours of freedom. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Mr. Jonathon Klem" List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 21:27:50 -0000 Bravo! Finally spam that is enlightening =3Dp > On 7/14/05, Jayton Garnett wrote: > > what the hell... > > > > Austin wrote: > > > > > Now you can improve your sexual life! > > > http://standards.mustajek.info/?balletxtvuytrigramszvpability > > > > > > > > > Mathematics is the language with which God has written the universe. > > > What's the difference between a boyfriend and a husband? About 30 > > > pounds. Eternity is very long, especially towards the end. I have > > > hardly ever known a mathematician who was capable of reasoning. > > > > > > _______________________________________________ > > > freebsd-stable@freebsd.org mailing list > > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.= org" > > > > > > > > > > > > -- > > Kind regards, > > Jayton Garnett > > > > email: jay@codegurus.org > > Main : www.uberhacker.co.uk > > Test server: jayton.plus.com > > > > > > _______________________________________________ > > freebsd-stable@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.or= g" > > >=20 >=20 > -- > http://joniscool.no-ip.com/ -- check it out >=20 --=20 http://joniscool.no-ip.com/ -- check it out From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 22:41:28 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 359BD16A41C for ; Sun, 17 Jul 2005 22:41:28 +0000 (GMT) (envelope-from carl@thegoodone.mine.nu) Received: from smtp-one-1.wash.one.se (smtp-one-1.one.se [213.80.101.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E68A43D48 for ; Sun, 17 Jul 2005 22:41:27 +0000 (GMT) (envelope-from carl@thegoodone.mine.nu) Received: from localhost (smtp-one-1.local [127.0.0.1]) by re-injector1.wash.one.se (Postfix) with ESMTP id 0654B2687E for ; Sun, 17 Jul 2005 22:37:03 +0000 (GMT) Received: from smtp-one-1.wash.one.se ([127.0.0.1]) by localhost (smtp-one-1.wash.one.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49145-01 for ; Sun, 17 Jul 2005 22:37:01 +0000 (GMT) Received: from thegoodone.mine.nu (81-170-146-43.bahnhofbredband.net [81.170.146.43]) by smtp-one-1.wash.one.se (Postfix) with ESMTP id B079A26871 for ; Sun, 17 Jul 2005 22:37:00 +0000 (GMT) Message-ID: <42DADE8F.8030903@thegoodone.mine.nu> Date: Mon, 18 Jul 2005 00:41:19 +0200 From: Carl Gustavsson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031205 Thunderbird/0.4 X-Accept-Language: en-us, en MIME-Version: 1.0 Cc: freebsd-stable@freebsd.org References: <42D79676.6040606@samsco.org> In-Reply-To: <42D79676.6040606@samsco.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 0528-6, 2005-07-16), Outbound message X-Antivirus-Status: Clean X-Virus-Scanned: by amavisd-new at one.se (smtp-one-1) X-Spam-Status: No, hits=0.827 tagged_above=-999 required=7 tests=AWL, BAYES_40, MISSING_HEADERS, RCVD_IN_NJABL_DUL, RCVD_IN_SORBS_DUL X-Spam-Level: Subject: Re: FreeBSD 6.0-BETA1 Available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 22:41:28 -0000 Scott Long wrote: > Announcement > ------------ > > The FreeBSD Release Engineering Team is pleased to announce the > availability of FreeBSD 6.0-BETA1, which marks the beginning of the > FreeBSD 6.0 Release Cycle. > > FreeBSD 6.0 will be a much less dramatic step from the FreeBSD 5 branch > than the FreeBSD 5 branch was from FreeBSD 4. Much of the work that has > gone into 6.0 development has focused on polishing and improving the > work from 5.x These changes include streamlining direct device access > in the kernel, providing a multi-threaded SMP-safe UFS/VFS filesystem > layer, implementing WPA and Host-AP 802.11 features, as well as > countless bugfixes and device driver improvements. Major updates and > improvements have been made to ACPI power and thermal management, ATA, > and many aspects of the network infrastructure. 32bit application > support for AMD64 is also greatly improved, as is compatiblity with > certain Athlon64 motherboards. This release is also the first to > feature experimental PowerPC support for the Macintosh G3 and G4 > platforms. Can anyone direct me to more information about the new WPA and Host-AP 802.11 features? / Carl From owner-freebsd-stable@FreeBSD.ORG Sun Jul 17 23:20:57 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C86FB16A41C for ; Sun, 17 Jul 2005 23:20:57 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A33043D45 for ; Sun, 17 Jul 2005 23:20:57 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id 6D050A246A5 for ; Sun, 17 Jul 2005 20:20:52 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 02737-09 for ; Sun, 17 Jul 2005 23:20:52 +0000 (GMT) Received: from ganymede.hub.org (blk-224-176-51.eastlink.ca [24.224.176.51]) by hub.org (Postfix) with ESMTP id 0A1ABA246A3 for ; Sun, 17 Jul 2005 20:20:52 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id F105C3C849; Sun, 17 Jul 2005 20:20:53 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id F045D37148 for ; Sun, 17 Jul 2005 20:20:53 -0300 (ADT) Date: Sun, 17 Jul 2005 20:20:53 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-stable@freebsd.org Message-ID: <20050717201956.B1035@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Subject: 6.x Performance note in /usr/src/UPDATING ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jul 2005 23:20:57 -0000 NOTE TO PEOPLE WHO THINK THAT FreeBSD 6.x IS SLOW: FreeBSD 6.x has many debugging features turned on, in both the kernel and userland. These features attempt to detect incorrect use of system primitives, and encourage loud failure through extra sanity checking and fail stop semantics. They also substantially impact system performance. If you want to do performance measurement, benchmarking, and optimization, you'll want to turn them off. This includes various WITNESS- related kernel options, INVARIANTS, malloc debugging flags in userland, and various verbose features in the kernel. Many developers choose to disable these features on build machines to maximize performance. Can someone add a pointer to this as to how to actually do this? For instance, I know from 5.x about the 'ln -s aj /etc/malloc.conf' for malloc ... but what about the rest? ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 01:08:40 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D07C16A41C for ; Mon, 18 Jul 2005 01:08:40 +0000 (GMT) (envelope-from steinex@arcor.de) Received: from mail-in-08.arcor-online.net (mail-in-08.arcor-online.net [151.189.21.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91BB843D45 for ; Mon, 18 Jul 2005 01:08:39 +0000 (GMT) (envelope-from steinex@arcor.de) Received: from mail-in-01-z2.arcor-online.net (mail-in-01-z2.arcor-online.net [151.189.8.13]) by mail-in-08.arcor-online.net (Postfix) with ESMTP id 0AE735888E for ; Mon, 18 Jul 2005 03:08:38 +0200 (CEST) Received: from mail-in-05.arcor-online.net (mail-in-05.arcor-online.net [151.189.21.45]) by mail-in-01-z2.arcor-online.net (Postfix) with ESMTP id F366540061 for ; Mon, 18 Jul 2005 03:08:37 +0200 (CEST) Received: from arcor.de (mezzo.htnsrv.org [81.169.174.29]) (Authenticated sender: steinex@arcor.de) by mail-in-05.arcor-online.net (Postfix) with ESMTP id C37633D1EF for ; Mon, 18 Jul 2005 03:08:37 +0200 (CEST) Received: by arcor.de (nbSMTP-0.99) for uid 1003 steinex@arcor.de; Mon, 18 Jul 2005 03:08:37 +0200 (CEST) Date: Mon, 18 Jul 2005 03:08:37 +0200 From: Frank Steinborn To: freebsd-stable@freebsd.org Message-ID: <20050718010837.GA9862@mezzo.htnsrv.org> Mail-Followup-To: freebsd-stable@freebsd.org References: <20050717201956.B1035@ganymede.hub.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050717201956.B1035@ganymede.hub.org> User-Agent: Mutt/1.5.8i Subject: Re: 6.x Performance note in /usr/src/UPDATING ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 01:08:40 -0000 Marc G. Fournier schrieb: > Can someone add a pointer to this as to how to actually do this? For > instance, I know from 5.x about the 'ln -s aj /etc/malloc.conf' for malloc > ... but what about the rest? Check your kernel config for INVARIANTS and WITNESS and disable these options. Besides malloc, these are all debugging features I'm aware of. bye, steinex From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 08:52:58 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 72B6316A41F for ; Mon, 18 Jul 2005 08:52:58 +0000 (GMT) (envelope-from jw@innerewut.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5025C43D46 for ; Mon, 18 Jul 2005 08:52:56 +0000 (GMT) (envelope-from jw@innerewut.de) Received: (qmail 25161 invoked from network); 18 Jul 2005 08:52:53 -0000 Received: from unknown (HELO [192.168.0.200]) (068076@[85.178.201.245]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Jul 2005 08:52:53 -0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Mon, 18 Jul 2005 10:50:57 +0200 From: Jonathan Weiss To: FreeBSD-Stable Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re:RELENG_6 has problems with booting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 08:52:58 -0000 > >> What happens if you drop ATAPICAM and do you have a good reason why you >> are including GEOM_BDE? >> >> Thanks >> S. > > I will try a kernel without ATAPICAM. > > I need GEOM_BDE for my encrypted disk but I can also try a kernel without > it. A kernel without ATAPICAM will also result in a hang during normal/verbose boot. With a kernel without GEOM_BDE I'm able to boot normally but the machine hanged some minutes later. Again no panic, the machine just hangs. When I do a boot in safe mode, everything is ok. Attachted is the dmesg from the verbose boot. Jonathan Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: on acpi0 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: irq 12 on acpi0 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 12 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 12 N 0 3 4 5 6 7 10 11 12 14 15 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: irq 11 on acpi0 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: irq 11 on acpi0 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 10 11 12 14 15 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link8: on acpi0 pci_link8: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link8: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link8: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link9: irq 12 on acpi0 pci_link9: Links after initial probe: Index IRQ Rtd Ref IRQs 0 12 N 0 3 4 5 6 7 10 11 12 14 15 pci_link9: Links after initial validation: Index IRQ Rtd Ref IRQs 0 12 N 0 3 4 5 6 7 10 11 12 14 15 pci_link9: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link10: on acpi0 pci_link10: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link10: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link10: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link11: irq 5 on acpi0 pci_link11: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 6 7 10 11 12 14 15 pci_link11: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 6 7 10 11 12 14 15 pci_link11: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link12: irq 5 on acpi0 pci_link12: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 6 7 10 11 12 14 15 pci_link12: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 6 7 10 11 12 14 15 pci_link12: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link13: on acpi0 pci_link13: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link13: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link13: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link14: on acpi0 pci_link14: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link14: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link14: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link15: on acpi0 pci_link15: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link15: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link15: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 10 11 12 14 15 pci_link16: irq 16 on acpi0 pci_link16: Links after initial probe: Index IRQ Rtd Ref IRQs 0 16 N 0 16 pci_link16: Links after initial validation: Index IRQ Rtd Ref IRQs 0 16 N 0 16 pci_link16: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 16 pci_link17: irq 17 on acpi0 pci_link17: Links after initial probe: Index IRQ Rtd Ref IRQs 0 17 N 0 17 pci_link17: Links after initial validation: Index IRQ Rtd Ref IRQs 0 17 N 0 17 pci_link17: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 17 pci_link18: irq 18 on acpi0 pci_link18: Links after initial probe: Index IRQ Rtd Ref IRQs 0 18 N 0 18 pci_link18: Links after initial validation: Index IRQ Rtd Ref IRQs 0 18 N 0 18 pci_link18: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 18 pci_link19: irq 19 on acpi0 pci_link19: Links after initial probe: Index IRQ Rtd Ref IRQs 0 19 N 0 19 pci_link19: Links after initial validation: Index IRQ Rtd Ref IRQs 0 19 N 0 19 pci_link19: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 19 pci_link20: irq 16 on acpi0 pci_link20: Links after initial probe: Index IRQ Rtd Ref IRQs 0 16 N 0 16 pci_link20: Links after initial validation: Index IRQ Rtd Ref IRQs 0 16 N 0 16 pci_link20: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 16 pci_link21: irq 0 on acpi0 pci_link21: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link21: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link21: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link22: irq 0 on acpi0 pci_link22: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link22: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link22: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link23: irq 0 on acpi0 pci_link23: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link23: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link23: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link24: irq 0 on acpi0 pci_link24: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link24: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link24: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link25: irq 0 on acpi0 pci_link25: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link25: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link25: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link26: irq 0 on acpi0 pci_link26: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link26: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link26: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link27: irq 23 on acpi0 pci_link27: Links after initial probe: Index IRQ Rtd Ref IRQs 0 23 N 0 23 pci_link27: Links after initial validation: Index IRQ Rtd Ref IRQs 0 23 N 0 23 pci_link27: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 23 pci_link28: irq 0 on acpi0 pci_link28: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link28: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link28: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link29: irq 0 on acpi0 pci_link29: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link29: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link29: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link30: irq 0 on acpi0 pci_link30: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link30: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link30: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link31: irq 0 on acpi0 pci_link31: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link31: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 pci_link31: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 20 21 22 ACPI timer: 1/1 1/2 1/2 1/1 1/1 1/1 1/1 1/1 1/2 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x10de, dev=0x01e0, revid=0xc1 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base d8000000, size 26, enabled found-> vendor=0x10de, dev=0x01ea, revid=0xc1 bus=0, slot=0, func=1 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x01ee, revid=0xc1 bus=0, slot=0, func=2 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x01ed, revid=0xc1 bus=0, slot=0, func=3 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x01ec, revid=0xc1 bus=0, slot=0, func=4 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x01ef, revid=0xc1 bus=0, slot=0, func=5 class=05-00-00, hdrtype=0x00, mfdev=1 cmdreg=0x0000, statreg=0x0020, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0060, revid=0xa4 bus=0, slot=1, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x10de, dev=0x0064, revid=0xa2 bus=0, slot=1, func=1 class=0c-05-00, hdrtype=0x00, mfdev=1 cmdreg=0x0001, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=5 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000e400, size 5, enabled pcib0: matched entry for 0.1.INTA (src \\_SB_.PCI0.APCS:0) ioapic0: Changing polarity for pin 23 to high pcib0: slot 1 INTA routed to irq 23 via \\_SB_.PCI0.APCS found-> vendor=0x10de, dev=0x0067, revid=0xa4 bus=0, slot=2, func=0 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=a, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e0003000, size 12, enabled pcib0: matched entry for 0.2.INTA (src \\_SB_.PCI0.APCF:0) pci_link21: Picked IRQ 20 with weight 0 ioapic0: Changing polarity for pin 20 to high pcib0: slot 2 INTA routed to irq 20 via \\_SB_.PCI0.APCF found-> vendor=0x10de, dev=0x0067, revid=0xa4 bus=0, slot=2, func=1 class=0c-03-10, hdrtype=0x00, mfdev=1 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=b, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e0004000, size 12, enabled pcib0: matched entry for 0.2.INTB (src \\_SB_.PCI0.APCG:0) pci_link22: Picked IRQ 21 with weight 0 ioapic0: Changing polarity for pin 21 to high pcib0: slot 2 INTB routed to irq 21 via \\_SB_.PCI0.APCG found-> vendor=0x10de, dev=0x0068, revid=0xa4 bus=0, slot=2, func=2 class=0c-03-20, hdrtype=0x00, mfdev=1 cmdreg=0x0006, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) intpin=c, irq=5 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e0005000, size 8, enabled pcib0: matched entry for 0.2.INTC (src \\_SB_.PCI0.APCL:0) pci_link28: Picked IRQ 22 with weight 0 ioapic0: Changing polarity for pin 22 to high pcib0: slot 2 INTC routed to irq 22 via \\_SB_.PCI0.APCL found-> vendor=0x10de, dev=0x0066, revid=0xa1 bus=0, slot=4, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x01 (250 ns), maxlat=0x14 (5000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base e0000000, size 12, enabled map[14]: type 4, range 32, base 0000d000, size 3, enabled pcib0: matched entry for 0.4.INTA (src \\_SB_.PCI0.APCH:0) pci_link23: Picked IRQ 20 with weight 1 pcib0: slot 4 INTA routed to irq 20 via \\_SB_.PCI0.APCH found-> vendor=0x10de, dev=0x006a, revid=0xa1 bus=0, slot=6, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=12 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000d400, size 8, enabled map[14]: type 4, range 32, base 0000d800, size 7, enabled map[18]: type 1, range 32, base e0001000, size 12, enabled pcib0: matched entry for 0.6.INTA (src \\_SB_.PCI0.APCJ:0) pci_link25: Picked IRQ 21 with weight 1 pcib0: slot 6 INTA routed to irq 21 via \\_SB_.PCI0.APCJ found-> vendor=0x10de, dev=0x006c, revid=0xa3 bus=0, slot=8, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x02 (500 ns) found-> vendor=0x10de, dev=0x0065, revid=0xa2 bus=0, slot=9, func=0 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x00b0, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x03 (750 ns), maxlat=0x01 (250 ns) powerspec 2 supports D0 D3 current D0 map[20]: type 4, range 32, base 0000f000, size 4, enabled found-> vendor=0x10de, dev=0x01e8, revid=0xc1 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) agp0: mem 0xd8000000-0xdbffffff at device 0.0 on pci0 agp0: Reserved 0x4000000 bytes for rid 0x10 type 3 at 0xd8000000 agp0: allocating GATT for aperture of size 64M pci0: at device 0.1 (no driver attached) pci0: at device 0.2 (no driver attached) pci0: at device 0.3 (no driver attached) pci0: at device 0.4 (no driver attached) pci0: at device 0.5 (no driver attached) isab0: at device 1.0 on pci0 isa0: on isab0 pci0: at device 1.1 (no driver attached) pci0:1:1: Transition from D0 to D3 ohci0: mem 0xe0003000-0xe0003fff irq 20 at device 2.0 on pci0 ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe0003000 ohci0: [GIANT-LOCKED] usb0: OHCI version 1.0, legacy support usb0: on ohci0 usb0: USB revision 1.0 uhub0: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xe0004000-0xe0004fff irq 21 at device 2.1 on pci0 ohci1: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe0004000 ohci1: [GIANT-LOCKED] usb1: OHCI version 1.0, legacy support usb1: on ohci1 usb1: USB revision 1.0 uhub1: nVidia OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 3 ports with 3 removable, self powered ehci0: mem 0xe0005000-0xe00050ff irq 22 at device 2.2 on pci0 ehci0: Reserved 0x100 bytes for rid 0x10 type 3 at 0xe0005000 ehci0: [GIANT-LOCKED] usb2: EHCI version 1.0 usb2: companion controllers, 4 ports each: usb0 usb1 usb2: on ehci0 usb2: USB revision 2.0 uhub2: nVidia EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub2: 6 ports with 6 removable, self powered ulpt0: Brother HL-5040, rev 2.00/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode nve0: port 0xd000-0xd007 mem 0xe0000000-0xe0000fff irq 20 at device 4.0 on pci0 nve0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xe0000000 nve0: Ethernet address 00:0c:6e:57:5a:25 miibus0: on nve0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nve0: bpf attached nve0: Ethernet address: 00:0c:6e:57:5a:25 nve0: [GIANT-LOCKED] pci0: at device 6.0 (no driver attached) pci0:6:0: Transition from D0 to D3 pcib1: at device 8.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xde000000-0xdfffffff pcib1: prefetched decode 0xfff00000-0xfffff ACPI: Found matching pin for 0.6.INTA at func 0: 21 pci_link16: BIOS IRQ 21 for 0.6.INTA is invalid pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x10ec, dev=0x8029, revid=0x00 bus=1, slot=8, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0003, statreg=0x0200, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=5 map[10]: type 4, range 32, base 0000c000, size 5, enabled pcib1: (null) requested I/O range 0xc000-0xc01f: in range pcib1: matched entry for 1.8.INTA (src \\_SB_.PCI0.APC3:0) ioapic0: Changing polarity for pin 18 to high pcib1: slot 8 INTA routed to irq 18 via \\_SB_.PCI0.APC3 found-> vendor=0x1282, dev=0x9102, revid=0x31 bus=1, slot=10, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0210, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x14 (5000 ns), maxlat=0x28 (10000 ns) intpin=a, irq=12 powerspec 1 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000c400, size 8, enabled pcib1: (null) requested I/O range 0xc400-0xc4ff: in range map[14]: type 1, range 32, base df000000, size 8, enabled pcib1: (null) requested memory range 0xdf000000-0xdf0000ff: good pcib1: matched entry for 1.10.INTA (src \\_SB_.PCI0.APC1:0) ioapic0: Changing polarity for pin 16 to high pcib1: slot 10 INTA routed to irq 16 via \\_SB_.PCI0.APC1 ed0: port 0xc000-0xc01f irq 18 at device 8.0 on pci1 ed0: Reserved 0x20 bytes for rid 0x10 type 4 at 0xc000 ed0: [GIANT-LOCKED] ed0: bpf attached ed0: Ethernet address: 00:a0:d2:14:f5:33 ed0: if_start running deferred for Giant ed0: type NE2000 (16 bit) dc0: port 0xc400-0xc4ff mem 0xdf000000-0xdf0000ff irq 16 at device 10.0 on pci1 dc0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xc400 miibus1: on dc0 ukphy0: on miibus1 ukphy0: OUI 0x00606e, model 0x0004, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto dc0: bpf attached dc0: Ethernet address: 00:80:ad:04:c6:78 dc0: if_start running deferred for Giant dc0: [GIANT-LOCKED] atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xf000-0xf00f at device 9.0 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xf000 ata0: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 ata0: reset tp1 mask=03 ostat0=50 ostat1=50 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=50 devices=0x3 ata0: [MPSAFE] ata1: on atapci0 atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 ata1: reset tp1 mask=03 ostat0=50 ostat1=50 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: reset tp2 stat0=00 stat1=00 devices=0xc ata1: [MPSAFE] pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xf000-0xfff pcib2: memory decode 0xdc000000-0xddffffff pcib2: prefetched decode 0xd0000000-0xd7ffffff pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x10de, dev=0x0110, revid=0xa1 bus=2, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x02b0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x05 (1250 ns), maxlat=0x01 (250 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base dc000000, size 24, enabled pcib2: (null) requested memory range 0xdc000000-0xdcffffff: good map[14]: type 3, range 32, base d0000000, size 27, enabled pcib2: (null) requested memory range 0xd0000000-0xd7ffffff: good pcib2: matched entry for 2.0.INTA (src \\_SB_.PCI0.APC4:0) ioapic0: Changing polarity for pin 19 to high pcib2: slot 0 INTA routed to irq 19 via \\_SB_.PCI0.APC4 pci2: at device 0.0 (no driver attached) fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] sio0: irq maps: 0x1821 0x1831 0x1821 0x1821 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A sio1: irq maps: 0x1821 0x1829 0x1821 0x1821 sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x378-0x37f,0x778-0x77b irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 plip0: bpf attached lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0067 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: unable to allocate IRQ ex_isa_identify() ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it ed: ed0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sio: sio0 already exists; skipping it sio: sio1 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it vga: vga0 already exists; skipping it unknown: status reg test failed fe unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff unknown: status reg test failed ff isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcb7ff,0xcc000-0xcd7ff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 vt0: not probed (disabled) isa_probe_children: probing PnP devices Device configuration finished. procfs registered lapic: Divisor 2, Frequency 166364231 hz Timecounter "TSC" frequency 1830009538 Hz quality 800 Timecounters tick every 1.000 msec pflog0: bpf attached lo0: bpf attached pfsync0: bpf attached fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout fdc0: output ready timeout ata0-slave: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on nVidia nForce2 chip ad0: setting UDMA100 on nVidia nForce2 chip ad0: 76319MB at ata0-master UDMA100 ad0: 156301488 sectors [155061C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ad0: nVidia check1 failed ad0: Adaptec check1 failed ad0: LSI (v3) check1 failed ad0: LSI (v2) check1 failed ad0: FreeBSD check1 failed ad1: setting PIO4 on nVidia nForce2 chip ad1: setting UDMA100 on nVidia nForce2 chip ad1: 190782MB at ata0-slave UDMA100 ad1: 390721968 sectors [387621C/16H/63S] 16 sectors/interrupt 1 depth queue ad1: nVidia check1 failed ad1: Adaptec check1 failedGEOM: new disk ad1 ad1: LSI (v3) check1 failed ad1: LSI (v2) check1 failed ad1: FreeBSD check1 failed ata1-slave: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=80 wire ata1-master: pio=PIO4 wdma=WDMA2 udma=BIOSDMA cable=40 wire acd0: setting PIO4 on nVidia nForce2 chip acd0: CDRW drive at ata1 as master acd0: read 5512KB/s (5512KB/s) write 2067KB/s (2067KB/s), 2048KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acd1: setting PIO4 on nVidia nForce2 chip acd1: setting UDMA33 on nVidia nForce2 chip acd1: DVDROM drive at ata1 as slave acd1: read 8268KB/s (8268KB/s), 128KB buffer, UDMA33 acd1: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, DVDRAM, packet acd1: Writes: acd1: Audio: play, 16 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc ATA PseudoRAID loaded ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 3 (ISA IRQ 3) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 6 (ISA IRQ 6) to cluster 0 ioapic0: routing intpin 7 (ISA IRQ 7) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 16 (PCI IRQ 16) to cluster 0 ioapic0: routing intpin 18 (PCI IRQ 18) to cluster 0 ioapic0: routing intpin 20 (PCI IRQ 20) to cluster 0 ioapic0: routing intpin 21 (PCI IRQ 21) to cluster 0 ioapic0: routing intpin 22 (PCI IRQ 22) to cluster 0 Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout fdc0: output ready timeout fdc0: input ready timeout fdc0: input ready timeout dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state dc0: failed to force tx and rx to idle state tun0: bpf attached WARNING: attempt to net_add_domain(netgraph) after domainfinalize() Linux ELF exec handler installed -- Jonathan Weiss http://blog.innerewut.de From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 09:59:01 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0F93116A41C; Mon, 18 Jul 2005 09:59:01 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id B400543D46; Mon, 18 Jul 2005 09:59:00 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from eirik.unicore.no ([213.225.74.166] helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DuSOo-000J4U-Th; Mon, 18 Jul 2005 11:58:58 +0200 Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0EE3DE95-7DDA-483D-8B31-38D90FE24202@anduin.net> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Eirik_=D8verby?= Date: Mon, 18 Jul 2005 11:58:54 +0200 To: stable@freebsd.org X-Mailer: Apple Mail (2.733) Cc: Robert Watson Subject: Serious issue with serial console in 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 09:59:01 -0000 Hi, I reported this before, but I am very surprised that it is still the case: (This is from the last time it happened; this time the box rebooted and cleared the serial console before I had time to cut/paste it. > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 00 > fault virtual address = 0x1c > fault code = supervisor write, page not present > instruction pointer = 0x8:0xc0620b5f > stack pointer = 0x10:0xdadbd988 > frame pointer = 0x10:0xdadbd994 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 51999 (getty) > trap number = 12 > panic: page fault > cpuid = 1 > boot() called on cpu#0 > Uptime: 66d11h24m50s The above panic will show up occasionally when logging out from a serial console (i.e. ctrl-D, logout, exit, whatever). This is EXTREMELY BAD, as it will crash an otherwise perfectly healthy box at random - and renders the serial console useless. Robert Watson confirmed this to be an issue on the 10th of April. Anyone?? /Eirik From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 12:43:05 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F1A2616A41C for ; Mon, 18 Jul 2005 12:43:05 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 54FF143D45 for ; Mon, 18 Jul 2005 12:43:04 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (zcdsdy@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j6ICh3hl011957 for ; Mon, 18 Jul 2005 14:43:03 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j6ICh3Q8011955; Mon, 18 Jul 2005 14:43:03 +0200 (CEST) (envelope-from olli) Date: Mon, 18 Jul 2005 14:43:03 +0200 (CEST) Message-Id: <200507181243.j6ICh3Q8011955@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <1121427687.295.12.camel@localhost.das.netz> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: reducing shutdown time X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 12:43:06 -0000 Marc Santhoff wrote: > I was searching for a way to shorten the stopping time in general. Have a look at ``sysctl kern.shutdown''. If you have only read-only filesystems, you can probably safely set them to zero. I haven't tried that myself, though. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. PI: int f[9814],b,c=9814,g,i;long a=1e4,d,e,h; main(){for(;b=c,c-=14;i=printf("%04d",e+d/a),e=d%a) while(g=--b*2)d=h*b+a*(i?f[b]:a/5),h=d/--g,f[b]=d%g;} From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 12:51:22 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7168216A41C for ; Mon, 18 Jul 2005 12:51:22 +0000 (GMT) (envelope-from interscan-noreply@admin.bmw.at) Received: from mailr3.de.ignite.net (mailr3.de.ignite.net [62.134.11.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 984F143D48 for ; Mon, 18 Jul 2005 12:51:21 +0000 (GMT) (envelope-from interscan-noreply@admin.bmw.at) Received: from mail.bmw-net.at (komp1.bmw.at [62.180.104.134]) by mailr3.de.ignite.net (Switch-2.2.8/Switch-2.2.8) with ESMTP id j6ICpJW06060 for ; Mon, 18 Jul 2005 14:51:19 +0200 (MEST) Received: from localhost (root@localhost) by mail.bmw-net.at (8.12.11/8.12.11) with SMTP id j6ICpGT5025192 for ; Mon, 18 Jul 2005 14:51:17 +0200 (MET DST) Message-Id: <200507181251.j6ICpGT5025192@mail.bmw-net.at> From: interscan-noreply@admin.bmw.at To: freebsd-stable@freebsd.org Date: Mon, 18 Jul 2005 14:51:17 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Virus Alert X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 12:51:22 -0000 The mail message (file: manuela.marazzato@gielle.conc-bmw.com.zip) you sent to contains a virus. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 13:02:48 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8A0C16A41C for ; Mon, 18 Jul 2005 13:02:48 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 238BA43D46 for ; Mon, 18 Jul 2005 13:02:47 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (wfgjaj@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j6ID2kls012520 for ; Mon, 18 Jul 2005 15:02:46 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j6ID2k3M012519; Mon, 18 Jul 2005 15:02:46 +0200 (CEST) (envelope-from olli) Date: Mon, 18 Jul 2005 15:02:46 +0200 (CEST) Message-Id: <200507181302.j6ID2k3M012519@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <20050715210320.01E215D07@ptavv.es.net> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 13:02:48 -0000 Kevin Oberman wrote: > [...] > I believe that the Windows solution to this problem is to put a really, > really long delay between when the system is finished syncing and when > the power is turned off. Definitely not. When I compare Windows XP and FreeBSD on the same hardware (notebook with ATA disk), then Windows' shutdown process is a lot faster than FreeBSD's. In fact, when I shut it down under XP for the first time, the power was off so quickly that I thought someting must have gone wrong. But everything was OK and normal. > This might be the best solution for FreeBSD, as > well, but it will irritate people. It is already irritating that FreeBSD sits there doing nothing for ~ 5 seconds before turning power off. Windows doesn't do that. (Yes I know, there's a sysctl for that, but I suspect that it's not save to modify it in FreeBSD.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Emacs ist für mich kein Editor. Für mich ist das genau das gleiche, als wenn ich nach einem Fahrrad (für die Sonntagbrötchen) frage und einen pangalaktischen Raumkreuzer mit 10 km Gesamtlänge bekomme. Ich weiß nicht, was ich damit soll." -- Frank Klemm, de.comp.os.unix.discussion From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 13:48:21 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 41A3216A41C for ; Mon, 18 Jul 2005 13:48:21 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91F1B43D48 for ; Mon, 18 Jul 2005 13:48:20 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (ipknwl@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j6IDmIgJ014073 for ; Mon, 18 Jul 2005 15:48:19 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j6IDmIFX014072; Mon, 18 Jul 2005 15:48:18 +0200 (CEST) (envelope-from olli) Date: Mon, 18 Jul 2005 15:48:18 +0200 (CEST) Message-Id: <200507181348.j6IDmIFX014072@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <20050715162214.GA665@drjekyll.mkbuelow.net> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 13:48:21 -0000 Matthias Buelow wrote: > Sorry folks, have I somehow dropped into a parallel universe, > or is there some serious misunderstanding going on? Seems so. > To the OP: There is no "sync" process that is being killed by > shutdown Yes, there is a kernel process called "syncer". During shutdown, each of the kernel processes (including the syncer) has 60 seconds to terminate. If it doesn't, "timed out" is printed on the console. This timeout can be changed using a sysctl tunable (kern.shutdown.kproc_shutdown_wait). > The kernel writes out all dirty buffers as part of its > shutdown procedure. When you shut down a machine, the kernel flushes all dirty buffers to disk. While it is doing that, it displays the number of remaining buffers, with increasing time intervals between them. If there are still buffers left after a certain number of intervals without change, the kernel gives up. If that is really the problem, then the best solution would be to make the number of flushing intervals and/or the increasing interval a sysctl tunable. They're currently hardcoded at 20 and 50ms, respectively; see the boot() function in src/sys/kern/kern_shutdown.c. That means that the timeout will happen after 10 seconds. Doubling the number of intervals (i.e. 40 instead of 20) will make the timeout happen after 40 seconds, which should be sufficient. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "C++ is the only current language making COBOL look good." -- Bertrand Meyer From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 14:35:36 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 547DE16A41C for ; Mon, 18 Jul 2005 14:35:36 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id E565143D4C for ; Mon, 18 Jul 2005 14:35:35 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from drjekyll.mkbuelow.net (p54AA9CC3.dip0.t-ipconnect.de [84.170.156.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id AEDBA3299C for ; Mon, 18 Jul 2005 16:38:22 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j6IEZVWG000889 for ; Mon, 18 Jul 2005 16:35:31 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Message-Id: <200507181435.j6IEZVWG000889@drjekyll.mkbuelow.net> From: Matthias Buelow To: freebsd-stable@freebsd.org In-Reply-To: Message from Oliver Fromme of "Mon, 18 Jul 2005 15:48:18 +0200." <200507181348.j6IDmIFX014072@lurza.secnetix.de> X-Mailer: MH-E 7.84; nmh 1.0.4; XEmacs 21.4 (patch 17) Date: Mon, 18 Jul 2005 16:35:31 +0200 Sender: mkb@mkbuelow.net Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 14:35:36 -0000 Oliver Fromme writes: >buffers to disk. While it is doing that, it displays the >number of remaining buffers, with increasing time intervals >between them. If there are still buffers left after a >certain number of intervals without change, the kernel >gives up. Why is it doing this? Can't it just enumerate the buffers and write them, one by one? mkb. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 14:58:15 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84E9316A41C for ; Mon, 18 Jul 2005 14:58:15 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 194EC43D46 for ; Mon, 18 Jul 2005 14:58:14 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DuX4N-0008JI-6W for freebsd-stable@freebsd.org; Mon, 18 Jul 2005 16:58:11 +0200 Received: from kvip88.kvi.nl ([129.125.15.152]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jul 2005 16:58:11 +0200 Received: from A.S.Usov by kvip88.kvi.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 18 Jul 2005 16:58:11 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Alexander S. Usov" Date: Mon, 18 Jul 2005 16:56:35 +0200 Organization: KVI Lines: 30 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: kvip88.kvi.nl User-Agent: KNode/0.9.1 Sender: news Subject: Strange top(1) output on 5.4-RELEASE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 14:58:15 -0000 Hi! I have just noticed this strange thing: % top last pid: 50566; load averages: 0.28, 0.26, 0.23 up 1+18:25:52 16:48:31 90 processes: 3 running, 87 sleeping CPU states: 4.3% user, 0.0% nice, 6.2% system, 1.9% interrupt, 87.5% idle Mem: 315M Active, 39M Inact, 120M Wired, 18M Cache, 60M Buf, 984K Free Swap: 512M Total, 31M Used, 480M Free, 6% Inuse PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND 48650 root 91 -5 77028K 33408K select 2:34 6.05% 6.05% Xorg 50520 usov 96 0 28268K 17564K select 0:01 0.93% 0.93% kdeinit ..... some output skipped ....... 49961 usov 96 0 31600K 18076K RUN 0:08 0.00% 0.00% kdeinit 48740 usov 20 -76 11772K 6560K kserel 0:07 0.00% 0.00% artsd 464 root 96 0 3080K 844K select 0:06 0.00% 0.00% ntpd Note the -76 as a NICE value for artsd. In the same time "ps axl" shows NICE value of 0, which is also quite strange as I have artswrapper installes and "artsshell status" reports real-time status. I observe this on 5.4-RELEASE-p3. Top & ps binaries are supposed to be in sync with the kernel I run (I have already tried rebuilding libkvm & top, but this changes nothing). Any ideas? -- Best regards, Alexander. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 14:59:51 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 00F2116A41C for ; Mon, 18 Jul 2005 14:59:51 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 869C243D45 for ; Mon, 18 Jul 2005 14:59:48 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-151-199-7-31.ROA.east.verizon.net [151.199.7.31]) by gromit.dlib.vt.edu (8.13.3/8.13.3) with ESMTP id j6IExkFB068347 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2005 10:59:47 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.4/8.13.4) with ESMTP id j6IExe60051859 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2005 10:59:40 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.4/8.13.4/Submit) id j6IExduH051858; Mon, 18 Jul 2005 10:59:39 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Matthias Buelow In-Reply-To: <200507181435.j6IEZVWG000889@drjekyll.mkbuelow.net> References: <200507181435.j6IEZVWG000889@drjekyll.mkbuelow.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 18 Jul 2005 10:59:39 -0400 Message-Id: <1121698779.51580.15.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-stable@freebsd.org Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 14:59:51 -0000 On Mon, 2005-07-18 at 16:35 +0200, Matthias Buelow wrote: > Oliver Fromme writes: > > >buffers to disk. While it is doing that, it displays the > >number of remaining buffers, with increasing time intervals > >between them. If there are still buffers left after a > >certain number of intervals without change, the kernel > >gives up. > > Why is it doing this? Can't it just enumerate the buffers and write > them, one by one? Why would that necessarily be more successful? If the outstanding buffers count is not reducing between time intervals, it is most likely because there is some underlying hardware problem (e.g., a bad block). If the count still persists in staying put, it likely means whatever the hardware is doing to try and fix things (e.g., write reallocation) isn't working, and so the kernel may as well give up. You can enumerate the buffers and *try* to write them, but that doesn't guarantee they will be written successfully any more than observing the relative number left outstanding. Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 15:10:12 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FB3F16A41F for ; Mon, 18 Jul 2005 15:10:12 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C23043D45 for ; Mon, 18 Jul 2005 15:10:10 +0000 (GMT) (envelope-from mv@roq.com) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 0732D4CAB1; Mon, 18 Jul 2005 15:10:06 +0000 (GMT) Received: from vault.mel.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by p4.roq.com (Postfix) with ESMTP id 63F434CAA0; Mon, 18 Jul 2005 15:10:05 +0000 (GMT) Received: from vault.mel.jumbuck.com (localhost [127.0.0.1]) by vault.mel.jumbuck.com (Postfix) with ESMTP id 5B04E8A02D; Tue, 19 Jul 2005 01:09:49 +1000 (EST) Received: from [10.0.1.8] (adsl-143-85.swiftdsl.com.au [218.214.143.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vault.mel.jumbuck.com (Postfix) with ESMTP id 75FA68A02B; Tue, 19 Jul 2005 01:09:48 +1000 (EST) Message-ID: <42DBC648.3040703@roq.com> Date: Tue, 19 Jul 2005 01:10:00 +1000 From: Michael VInce User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.8) Gecko/20050524 X-Accept-Language: en-us, en To: Claus Guttesen References: <1121099976.62346.48.camel@opus.cse.buffalo.edu> <20050711215527.D29110@fledge.watson.org> <6.2.1.2.0.20050711222106.0350cb10@64.7.153.2> In-Reply-To: Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-stable@freebsd.org Subject: Re: FYI - RELENG_6 branch has been created. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 15:10:12 -0000 Wow thats a big jump from what I got in a test I did a couple of months ago, here is a copy and paste of an older email Are you using AMD64 mode or i386? Dell 1850 Dual CPU with 4 Gigs of ram, thats in idle CPU: Intel(R) Xeon(TM) CPU 3.20GHz (3192.23-MHz 686-class CPU) FreeBSD 5.4-RELEASE-p1 FreeBSD 5.4-RELEASE-p1 #0: Sun May 22 12:23:00 EST 2005 root@dagobah:/usr/obj/usr/src/sys/SMP i386 Ubench CPU: 170748 Ubench MEM: 172775 -------------------- Ubench AVG: 171761 Claus Guttesen wrote: As a further FYI, a variety of debugging features are still enabled by default in RELENG_6, including INVARINTS, WITNESS, and user space malloc debugging. These will remain enabled through the first snapshot from the Not very scientific but here is my ubench on a dual nocona @ 2.8 GHz and 4 GB RAM on a Dell 2850: Sched_ule: Current from July 6'th 2005: Ubench CPU: 241149 Ubench MEM: 182695 -------------------- Ubench AVG: 211922 6.0 stable pr. July 12'th 2005: Ubench CPU: 243058 Ubench MEM: 186918 -------------------- Ubench AVG: 214988 So slight increase in both cpu and ram in stable. SCHED_4BSD and 6.0 stable pr. July 12'th 2005: Ubench CPU: 260315 Ubench MEM: 189686 -------------------- Ubench AVG: 225000 Here sched_4bsd performs approx. 5 % better on ubench. regards Claus _______________________________________________ [1]freebsd-stable@freebsd.org mailing list [2]http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [3]"freebsd-stable-unsubscribe@freebsd.org" References 1. mailto:freebsd-stable@freebsd.org 2. http://lists.freebsd.org/mailman/listinfo/freebsd-stable 3. mailto:freebsd-stable-unsubscribe@freebsd.org From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 15:14:11 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C885216A41C for ; Mon, 18 Jul 2005 15:14:11 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 639CB43D46 for ; Mon, 18 Jul 2005 15:14:11 +0000 (GMT) (envelope-from mkb@mkbuelow.net) Received: from drjekyll.mkbuelow.net (p54AA9CC3.dip0.t-ipconnect.de [84.170.156.195]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 6D32632973; Mon, 18 Jul 2005 17:17:03 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j6IFEBoR001237; Mon, 18 Jul 2005 17:14:12 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Message-Id: <200507181514.j6IFEBoR001237@drjekyll.mkbuelow.net> From: Matthias Buelow To: Paul Mather In-Reply-To: Message from Paul Mather of "Mon, 18 Jul 2005 10:59:39 EDT." <1121698779.51580.15.camel@zappa.Chelsea-Ct.Org> X-Mailer: MH-E 7.84; nmh 1.0.4; XEmacs 21.4 (patch 17) Date: Mon, 18 Jul 2005 17:14:11 +0200 Sender: mkb@mkbuelow.net Cc: freebsd-stable@freebsd.org, Matthias Buelow Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 15:14:11 -0000 Paul Mather writes: >Why would that necessarily be more successful? If the outstanding >buffers count is not reducing between time intervals, it is most likely >because there is some underlying hardware problem (e.g., a bad block). >If the count still persists in staying put, it likely means whatever the >hardware is doing to try and fix things (e.g., write reallocation) isn't >working, and so the kernel may as well give up. So the kernel is relying on guesswork whether the buffers are flushed or not... >You can enumerate the buffers and *try* to write them, but that doesn't >guarantee they will be written successfully any more than observing the >relative number left outstanding. That's rather nonsensical. If I write each buffer synchronously (and wait for the disk's response) this is for sure a lot more reliable than observing changes in the number of remaining buffers. I mean, where's the sense in the latter? It would be analogous to, in userspace, having to monitor write(2) continuously over a given time interval and check whether the number it returns eventually reaches zero. That's complete madness, imho. mkb. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 15:26:58 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A34C16A41C for ; Mon, 18 Jul 2005 15:26:58 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7BC0943D46 for ; Mon, 18 Jul 2005 15:26:57 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (tojuzm@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j6IFQt1b017263 for ; Mon, 18 Jul 2005 17:26:55 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j6IFQtYp017262; Mon, 18 Jul 2005 17:26:55 +0200 (CEST) (envelope-from olli) Date: Mon, 18 Jul 2005 17:26:55 +0200 (CEST) Message-Id: <200507181526.j6IFQtYp017262@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <200507181435.j6IEZVWG000889@drjekyll.mkbuelow.net> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 15:26:58 -0000 Matthias Buelow wrote: > Oliver Fromme writes: > > buffers to disk. While it is doing that, it displays the > > number of remaining buffers, with increasing time intervals > > between them. If there are still buffers left after a > > certain number of intervals without change, the kernel > > gives up. > > Why is it doing this? Can't it just enumerate the buffers and write > them, one by one? I don't think that the boot() function in kern_shutdown.c can do that. It has got nothing to do with the syncing business itself. It can only trigger the syncing (similar to the sync(8) tool), which basically means performing a vfs_sync with flag MNT_NOWAIT for every mounted filesystem. Then it has to wait for the appropriate kernel process to do its job. See the source. I don't think there's an easy way to change that. If you see such a way, I'd suggest you code it up and use send-pr. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "Python tricks" is a tough one, cuz the language is so clean. E.g., C makes an art of confusing pointers with arrays and strings, which leads to lotsa neat pointer tricks; APL mistakes everything for an array, leading to neat one-liners; and Perl confuses everything period, making each line a joyous adventure . -- Tim Peters From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 16:00:19 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 60EF316A41C for ; Mon, 18 Jul 2005 16:00:19 +0000 (GMT) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: from mail23.sea5.speakeasy.net (mail23.sea5.speakeasy.net [69.17.117.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BD6543D46 for ; Mon, 18 Jul 2005 16:00:18 +0000 (GMT) (envelope-from freebsd-stable-local@be-well.ilk.org) Received: (qmail 18611 invoked from network); 18 Jul 2005 16:00:18 -0000 Received: from dsl092-078-145.bos1.dsl.speakeasy.net (HELO be-well.ilk.org) ([66.92.78.145]) (envelope-sender ) by mail23.sea5.speakeasy.net (qmail-ldap-1.03) with SMTP for ; 18 Jul 2005 16:00:18 -0000 Received: by be-well.ilk.org (Postfix, from userid 1147) id 4245F30; Mon, 18 Jul 2005 12:00:17 -0400 (EDT) Sender: lowell@be-well.ilk.org To: Matthias Buelow References: <20050715224650.GA48516@outcold.yadt.co.uk> <200507152342.j6FNg5Tx015427@drjekyll.mkbuelow.net> <20050716133710.GA71580@outcold.yadt.co.uk> <20050716141630.GB752@drjekyll.mkbuelow.net> <1121530912.17757.32.camel@zappa.Chelsea-Ct.Org> <44k6jqof72.fsf@be-well.ilk.org> <20050716172632.GG752@drjekyll.mkbuelow.net> From: Lowell Gilbert Date: 18 Jul 2005 12:00:16 -0400 In-Reply-To: <20050716172632.GG752@drjekyll.mkbuelow.net> Message-ID: <44u0is6r5b.fsf@be-well.ilk.org> Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 16:00:19 -0000 Matthias Buelow writes: > Lowell Gilbert wrote: > > >Well, break it down a little bit. If an ATA drive properly implements > >the cache flush command, then none of the ongoing discussion is > > Are you sure this is the case? Are there sequence points in softupdates > where it issues a flush request and by this guarantees fs integrity? No, you're right. I meant write completions, not cache flushes. I don't know of any drives that do one properly and not the other, but they're certainly not the same thing. > I've read thru McKusick's paper in search for an answer but haven't > found any. All I've read so far on mailing lists and from googling > was that softupdates doesn't work if the wb-cache is enabled. On a lot of "ATA" drives that don't implement the spec properly. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 16:19:01 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD8DD16A41C for ; Mon, 18 Jul 2005 16:19:01 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5933E43D45 for ; Mon, 18 Jul 2005 16:19:01 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-151-199-7-31.ROA.east.verizon.net [151.199.7.31]) by gromit.dlib.vt.edu (8.13.3/8.13.3) with ESMTP id j6IGIxav068543 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2005 12:19:00 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.4/8.13.4) with ESMTP id j6IGIrJg052046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 18 Jul 2005 12:18:53 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.4/8.13.4/Submit) id j6IGIrkM052045; Mon, 18 Jul 2005 12:18:53 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Matthias Buelow In-Reply-To: <200507181514.j6IFEBoR001237@drjekyll.mkbuelow.net> References: <200507181514.j6IFEBoR001237@drjekyll.mkbuelow.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Mon, 18 Jul 2005 12:18:52 -0400 Message-Id: <1121703532.51580.35.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-stable@freebsd.org Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 16:19:01 -0000 On Mon, 2005-07-18 at 17:14 +0200, Matthias Buelow wrote: > Paul Mather writes: > > >Why would that necessarily be more successful? If the outstanding > >buffers count is not reducing between time intervals, it is most likely > >because there is some underlying hardware problem (e.g., a bad block). > >If the count still persists in staying put, it likely means whatever the > >hardware is doing to try and fix things (e.g., write reallocation) isn't > >working, and so the kernel may as well give up. > > So the kernel is relying on guesswork whether the buffers are flushed > or not... I don't know if you are just deliberately trying to be contentious, but that is a serious misrepresentation of what is happening. Quite obviously the kernel knows whether a buffer has successfully been flushed, otherwise a count of outstanding buffers would be meaningless. (Surely you're not saying the kernel simply guesses if a buffer has been flushed in maintaining its count of outstanding buffers? What would be the point of that?) If you calm down and think about it for a little, you'll realise what you suggest to do and what is actually done amount to the same thing in practical terms. It's all very easy to say to "write each buffer synchronously (and wait for the disk's response)," but what do you do when the buffer *does* get stuck and won't complete (e.g., because someone removed the floppy or USB disk, or your remote ggate server disappeared, or your hard disk is going bad, etc.)? Do you just bail immediately at that point? Or do you keep retrying in the hope it will complete? In the end, it comes down to waiting a certain amount of time for drivers to do their best and then giving up. The only real question is how long you wait, and maybe whether syncer is not waiting long enough (and hence how to extend the amount of time it is willing to wait until it gives up on buffers being unflushable). I'm not sure why that is fundamentally "madness." Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 16:19:16 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47FFB16A41C for ; Mon, 18 Jul 2005 16:19:16 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 8949D43D45 for ; Mon, 18 Jul 2005 16:19:14 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 18 Jul 2005 16:19:13 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp013) with SMTP; 18 Jul 2005 18:19:13 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-stable@freebsd.org Date: Mon, 18 Jul 2005 18:18:52 +0200 User-Agent: KMail/1.8.1 References: <42D79676.6040606@samsco.org> <20050715152744.GA67970@kierun.org> <20050717200728.Q19319@fledge.watson.org> In-Reply-To: <20050717200728.Q19319@fledge.watson.org> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1515620.3zJ6xr5KR6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507181819.06036@harrymail> X-Y-GMX-Trusted: 0 Cc: Robert Watson Subject: cua*x naming? [Was: Re: FreeBSD 6.0-BETA1 Available] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 16:19:16 -0000 --nextPart1515620.3zJ6xr5KR6 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 17. Juli 2005 21:12 CEST schrieb Robert Watson: > (2) /dev/cuaa* has been renamed to /dev/cuad* I saw that cuaa got cuad and ucom0 got cuaU0. Now what is the meaning of=20 cua? tty AFAIK is TeleTYpe... Thanks, =2DHarry --nextPart1515620.3zJ6xr5KR6 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC29Z5Bylq0S4AzzwRAkgKAJkBdIdXQhOWLoIherEQUpFup+pn9wCfWUyP iJKm2SNQD+8KXVnZizytdqc= =k0Jf -----END PGP SIGNATURE----- --nextPart1515620.3zJ6xr5KR6-- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 16:23:26 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 89DA116A41C for ; Mon, 18 Jul 2005 16:23:26 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F98C43D45 for ; Mon, 18 Jul 2005 16:23:26 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from pyanfar.ece.cmu.edu (PYANFAR.ECE.CMU.EDU [128.2.136.40]) by bache.ece.cmu.edu (Postfix) with ESMTP id 14E2C81 for ; Mon, 18 Jul 2005 12:23:25 -0400 (EDT) From: "Brandon S. Allbery KF8NH" To: freebsd-stable@freebsd.org In-Reply-To: <200507181819.06036@harrymail> References: <42D79676.6040606@samsco.org> <20050715152744.GA67970@kierun.org> <20050717200728.Q19319@fledge.watson.org> <200507181819.06036@harrymail> Content-Type: text/plain Date: Mon, 18 Jul 2005 12:23:24 -0400 Message-Id: <1121703804.4401.0.camel@pyanfar.ece.cmu.edu> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: cua*x naming? [Was: Re: FreeBSD 6.0-BETA1 Available] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 16:23:26 -0000 On Mon, 2005-07-18 at 18:18 +0200, Emanuel Strobl wrote: > Am Sonntag, 17. Juli 2005 21:12 CEST schrieb Robert Watson: > > > (2) /dev/cuaa* has been renamed to /dev/cuad* > > I saw that cuaa got cuad and ucom0 got cuaU0. Now what is the meaning of > cua? tty AFAIK is TeleTYpe... Call(-out) Unit Access, IIRC. -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon univ. KF8NH From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 17:58:53 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C6E816A41C; Mon, 18 Jul 2005 17:58:53 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id D35FA43D45; Mon, 18 Jul 2005 17:58:52 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id DA8929978ED; Mon, 18 Jul 2005 19:58:51 +0200 (CEST) Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 25919-03; Mon, 18 Jul 2005 19:58:48 +0200 (CEST) Received: from [80.98.156.20] (catv-50629c14.catv.broadband.hu [80.98.156.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.t-hosting.hu (Postfix) with ESMTP id 6C9869975B9; Mon, 18 Jul 2005 19:58:48 +0200 (CEST) Message-ID: <42DBEDD3.60906@t-hosting.hu> Date: Mon, 18 Jul 2005 19:58:43 +0200 From: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at t-hosting.hu Cc: Subject: rcNG issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 17:58:53 -0000 Hello, I have a problem with my rcNG scripts. There are three scripts: named.sh, apache2.sh and proftpd.sh. Apache and ProFTPd require hostname resolving thus named should start firstly. The headers of my scripts are: named.sh: #!/bin/sh # # PROVIDE: named # REQUIRE: SERVERS # BEFORE: apache2 proftpd mysqld # KEYWORD: FreeBSD shutdown . /etc/rc.subr apache2.sh: #!/bin/sh # # PROVIDE: apache2 # REQUIRE: NETWORKING SERVERS named # BEFORE: DAEMON # KEYWORD: FreeBSD shutdown . /etc/rc.subr proftpd.sh: #!/bin/sh # # PROVIDE: proftpd # REQUIRE: DAEMON # BEFORE: LOGIN # KEYWORD: FreeBSD shutdown . /etc/rc.subr And when I enable all the three scripts in rc.conf, the apache hangs because it can't resolve the computer's hostname. It's really annoying, I have to manually start it after a reboot, or wait for the cronscript that checks whether it is running. What's wrong? Thanks in advance, Gábor Kövesdán From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 18:17:15 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63E2616A41C for ; Mon, 18 Jul 2005 18:17:15 +0000 (GMT) (envelope-from jmelo@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 86A2243D45 for ; Mon, 18 Jul 2005 18:17:12 +0000 (GMT) (envelope-from jmelo@freebsdbrasil.com.br) Received: (qmail 36187 invoked by uid 0); 18 Jul 2005 15:17:11 -0300 Received: from jmelo@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (uvscan: v4.3.20/v4537. spamassassin: 2.64. Clear:RC:1(201.17.165.147):. Processed in 0.514535 secs); 18 Jul 2005 18:17:11 -0000 Received: from unknown (HELO ?10.69.69.2?) (201.17.165.147) by capeta.freebsdbrasil.com.br with SMTP; 18 Jul 2005 15:17:10 -0300 Message-ID: <42DBF250.1060405@freebsdbrasil.com.br> Date: Mon, 18 Jul 2005 15:17:52 -0300 From: Jean Milanez Melo User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: small@freebsd.org, stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: TinyBSD Call For Testers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 18:17:15 -0000 Hello gentlemen, In the last saturday a new port has been added under sysutils/ category, ports/sysutils/tinybsd. TinyBSD is a tool which was meant to allow an easy way to build embedded systems based on FreeBSD. It is based on userland copying, library dependencies check/copy and kernel build. We did our best to make the embedded system creation an easy and specially fast proccess. The main (default) system generates an embedded system image which is about 20MB in size, which is a very generic approach, with a number of wired NIC support, and also the most popular wireless support (including atheros), divert, bridge, dummynet, firewall, etc; and CPU_ELAN (for soekris devices). If the "generic" system gets tighten up the final result can be as low as an 8MB embedded system. We are giving you this intro to ask you please to test TinyBSD out, the most that you can, and send every possible feedback regarding it. The main tinybsd goal is to make embedded systems creation a process which must be 1 - fast 2 - easy 3 - 100% functional If you can test it, we would appreciate your thoughts. If you think any of those 3 goals can't be reached for you, or could be improved, also let me know. Thanks for testing -- Atenciosamente Jean Milanez Melo FreeBSD Brasil LTDA. Fone: (31) 3281-9633 http://www.freebsdbrasil.com.br From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 18:17:27 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 876A616A421 for ; Mon, 18 Jul 2005 18:17:27 +0000 (GMT) (envelope-from cedric@virtual-globe.net) Received: from dd2030.kasserver.com (dd2030.kasserver.com [81.209.148.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25E9A43D46 for ; Mon, 18 Jul 2005 18:17:26 +0000 (GMT) (envelope-from cedric@virtual-globe.net) Received: from ganymed.decemplex.loc (83-134-161-209.Liege.GoPlus.FastDSL.tiscali.be [83.134.161.209]) by dd2030.kasserver.com (Postfix) with ESMTP id EDBDCF4883 for ; Mon, 18 Jul 2005 20:17:24 +0200 (CEST) Date: Mon, 18 Jul 2005 20:17:13 +0200 From: =?ISO-8859-1?Q?C=E9dric?= Jonas To: freebsd-stable@freebsd.org Message-ID: <20050718201713.757a9f58@ganymed.decemplex.loc> In-Reply-To: <42DBEDD3.60906@t-hosting.hu> References: <42DBEDD3.60906@t-hosting.hu> X-Mailer: Sylpheed-Claws 1.9.12 (GTK+ 2.6.8; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: rcNG issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 18:17:27 -0000 On Mon, 18 Jul 2005 19:58:43 +0200 K=F6vesd=E1n G=E1bor wrote: > Hello, >=20 > I have a problem with my rcNG scripts. There are three scripts:=20 > named.sh, apache2.sh and proftpd.sh. Apache and ProFTPd require hostname= =20 > resolving thus named should start firstly. The headers of my scripts are: >=20 > named.sh: >=20 > #!/bin/sh > # >=20 > # PROVIDE: named > # REQUIRE: SERVERS > # BEFORE: apache2 proftpd mysqld > # KEYWORD: FreeBSD shutdown >=20 > . /etc/rc.subr >=20 >=20 >=20 >=20 >=20 > apache2.sh: >=20 > #!/bin/sh > # >=20 > # PROVIDE: apache2 > # REQUIRE: NETWORKING SERVERS named > # BEFORE: DAEMON > # KEYWORD: FreeBSD shutdown >=20 > . /etc/rc.subr >=20 >=20 >=20 > proftpd.sh: >=20 > #!/bin/sh > # >=20 > # PROVIDE: proftpd > # REQUIRE: DAEMON > # BEFORE: LOGIN > # KEYWORD: FreeBSD shutdown >=20 > . /etc/rc.subr >=20 >=20 >=20 >=20 >=20 > And when I enable all the three scripts in rc.conf, the apache hangs=20 > because it can't resolve the computer's hostname. It's really annoying,=20 > I have to manually start it after a reboot, or wait for the cronscript=20 > that checks whether it is running. > What's wrong? I had similar problems these days, and I found out that rcNG seems to be only active for /etc/rc.d/ (see rc.subr(8) and rcorder(8) + files in /etc/). So put your scripts there, and it will do what you want. >=20 > Thanks in advance, >=20 > G=E1bor K=F6vesd=E1n > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >=20 --=20 Best regards,=20 C=E9dric Jonas From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 18:32:13 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DBCF16A41C for ; Mon, 18 Jul 2005 18:32:13 +0000 (GMT) (envelope-from matt@atopia.net) Received: from neptune.atopia.net (neptune.atopia.net [209.128.231.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8360143D6E for ; Mon, 18 Jul 2005 18:32:09 +0000 (GMT) (envelope-from matt@atopia.net) Received: by neptune.atopia.net (Postfix, from userid 1001) id 37D96618D; Mon, 18 Jul 2005 14:32:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by neptune.atopia.net (Postfix) with ESMTP id 35F7F6186; Mon, 18 Jul 2005 14:32:09 -0400 (EDT) Date: Mon, 18 Jul 2005 14:32:09 -0400 (EDT) From: Matt Juszczak To: Blaz Zupan In-Reply-To: <20050717131610.T29059@titanic.medinet.si> Message-ID: <20050718143155.T74874@neptune.atopia.net> References: <42BF8815.6090909@atopia.net> <20050627081933.GA97832@cell.sick.ru> <42C16394.4040904@atopia.net> <1119971279.36316.45.camel@buffy.york.ac.uk> <42C16C0E.9090002@atopia.net> <20050629100535.GC27557@xor.obsecurity.org> <20050701184352.GA177@xor.obsecurity.org> <20050706093012.M3376@titanic.medinet.si> <20050706104344.U4718@titanic.medinet.si> <20050712141639.U72892@neptune.atopia.net> <20050717131610.T29059@titanic.medinet.si> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD -STABLE servers repeatedly crashing. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 18:32:13 -0000 > For me, 5 days up time after switching from IPF to PF. Before the switch a > couple of hours of uptime was the maximum. Seems like the crashes are caused > by ipfilter. Still same for me :) Uptime almost 20 days now after switching to PF. From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 18:36:22 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5200A16A41C for ; Mon, 18 Jul 2005 18:36:22 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from ptb-relay03.plus.net (ptb-relay03.plus.net [212.159.14.214]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED69043D45 for ; Mon, 18 Jul 2005 18:36:21 +0000 (GMT) (envelope-from jay@codegurus.org) Received: from jayton.plus.com ([84.92.156.191] helo=[127.0.0.1]) by ptb-relay03.plus.net with esmtp (Exim) id 1DuaTM-0002LU-EL; Mon, 18 Jul 2005 19:36:12 +0100 Message-ID: <42DBF699.7000906@codegurus.org> Date: Mon, 18 Jul 2005 19:36:09 +0100 From: Jayton Garnett User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org, olli@lurza.secnetix.de References: <200507181302.j6ID2k3M012519@lurza.secnetix.de> In-Reply-To: <200507181302.j6ID2k3M012519@lurza.secnetix.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jay@codegurus.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 18:36:22 -0000 Oliver Fromme wrote: >Definitely not. When I compare Windows XP and FreeBSD on >the same hardware (notebook with ATA disk), then Windows' >shutdown process is a lot faster than FreeBSD's. In fact, >when I shut it down under XP for the first time, the power >was off so quickly that I thought someting must have gone >wrong. But everything was OK and normal. > > > Yes XP's shutdown time is quicker on a fresh install, but give it a few weeks or months (depending on how you use XP) and you will notice that the shutdown time increases. Right now my XP pro takes about 20 or more seconds to shutdown. I am sure this is due to the MFT under a NTFS installation, FreeBSD does not appear to have this problem over extended use, and there is no way of stopping the MTF growth problem (as far as I know) >It is already irritating that FreeBSD sits there doing >nothing for ~ 5 seconds before turning power off. Windows >doesn't do that. (Yes I know, there's a sysctl for that, >but I suspect that it's not save to modify it in FreeBSD.) > >Best regards > Oliver > > > -- Kind regards, Jayton Garnett email: jay@codegurus.org Main : www.uberhacker.co.uk Test server: jayton.plus.com From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 19:47:47 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFFB916A41C for ; Mon, 18 Jul 2005 19:47:46 +0000 (GMT) (envelope-from msch@snafu.de) Received: from waikiki.visp.de (waikiki.visp.de [84.23.254.155]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CD1943D5C for ; Mon, 18 Jul 2005 19:47:44 +0000 (GMT) (envelope-from msch@snafu.de) X-Trace: 507c6d73636840736e6166752e64657c38342e3139302e3133322e38317c314475 6261582d303030377a452d4a727c31313231373136303632 Received: from waikiki.visp.de ([10.155.10.19] helo=localhost) by waikiki.visp.de with esmtpa (Exim 4.51 id 1DubaX-0007zE-Jr) for freebsd-stable@freebsd.org; Mon, 18 Jul 2005 21:47:42 +0200 Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <04D55966-A390-45AE-A7B8-0828A9655053@snafu.de> References: <04D55966-A390-45AE-A7B8-0828A9655053@snafu.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0ADFD10A-D5EE-401F-9ECA-7E7D0719843B@snafu.de> Content-Transfer-Encoding: 7bit From: Matthias Schuendehuette Date: Mon, 18 Jul 2005 21:47:30 +0200 To: freebsd-stable@freebsd.org X-Pgp-Agent: GPGMail 1.1 (Tiger) X-Mailer: Apple Mail (2.733) Subject: Re: mpt + gvinum on 6.0-BETA (dmesg) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 19:47:47 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 15.07.2005 um 15:45 schrieb Matthias Schuendehuette: > I tried 6.0-BETA on one of our FUJITSU-SIEMENS RX300 S2 servers and > it seems that I have problems with the disk subsystem, even after > Scotts major overhaul of the mpt drivers... > > I'm not able to post detailed dmesg output in the moment (IMHO > there isn't anything to notice, mpt0 and mpt1 are attached without > any errors) but the symtoms are: > > - - very slow write performace: 'dd if=/dev/zero of=/dev/da0s2 > bs=512 count=32768' reports a throughput of 80 k(!)Bytes/s. Read > performance is somewhat better, 'dd' reports here about 2 MB/s... > better, but not what I would expect from a RAID1 with two U320 SCSI- > disks (Seagate BTW). > [...] Here the promised 'dmesg'-output: Jul 18 11:54:41 blnn204x syslogd: kernel boot file is /boot/kernel/ kernel Jul 18 11:54:41 blnn204x kernel: Copyright (c) 1992-2005 The FreeBSD Project. Jul 18 11:54:41 blnn204x kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 18 11:54:41 blnn204x kernel: The Regents of the University of California. All rights reserved. Jul 18 11:54:41 blnn204x kernel: FreeBSD 6.0-BETA #0: Thu Jul 14 10:13:50 CEST 2005 Jul 18 11:54:41 blnn204x kernel: root@blnn204x.bln7.siemens.de:/usr/obj/usr/src/sys/BLNN204X Jul 18 11:54:41 blnn204x kernel: ACPI APIC Table: Jul 18 11:54:41 blnn204x kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jul 18 11:54:41 blnn204x kernel: CPU: Intel(R) Xeon(TM) CPU 2.80GHz (2800.11-MHz 686-class CPU) Jul 18 11:54:41 blnn204x kernel: Origin = "GenuineIntel" Id = 0xf41 Stepping = 1 Jul 18 11:54:41 blnn204x kernel: Features=0xbfebfbff Jul 18 11:54:41 blnn204x kernel: Features2=0x641d> Jul 18 11:54:41 blnn204x kernel: AMD Features=0x20100000 Jul 18 11:54:41 blnn204x kernel: real memory = 2146959360 (2047 MB) Jul 18 11:54:41 blnn204x kernel: avail memory = 2096025600 (1998 MB) Jul 18 11:54:41 blnn204x kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Jul 18 11:54:41 blnn204x kernel: cpu0 (BSP): APIC ID: 0 Jul 18 11:54:41 blnn204x kernel: cpu1 (AP): APIC ID: 6 Jul 18 11:54:41 blnn204x kernel: ioapic0 irqs 0-23 on motherboard Jul 18 11:54:41 blnn204x kernel: ioapic1 irqs 24-47 on motherboard Jul 18 11:54:41 blnn204x kernel: ioapic2 irqs 48-71 on motherboard Jul 18 11:54:41 blnn204x kernel: ioapic3 irqs 72-95 on motherboard Jul 18 11:54:41 blnn204x kernel: ioapic4 irqs 96-119 on motherboard Jul 18 11:54:41 blnn204x kernel: npx0: [FAST] Jul 18 11:54:41 blnn204x kernel: npx0: on motherboard Jul 18 11:54:41 blnn204x kernel: npx0: INT 16 interface Jul 18 11:54:41 blnn204x kernel: acpi0: on motherboard Jul 18 11:54:41 blnn204x kernel: acpi0: Power Button (fixed) Jul 18 11:54:41 blnn204x kernel: pci_link0: irq 11 on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link1: irq 9 on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link2: irq 5 on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link3: irq 10 on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link4: on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link5: on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link6: on acpi0 Jul 18 11:54:41 blnn204x kernel: pci_link7: irq 9 on acpi0 Jul 18 11:54:41 blnn204x kernel: Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 Jul 18 11:54:41 blnn204x kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0xf008- 0xf00b on acpi0 Jul 18 11:54:41 blnn204x kernel: cpu0: on acpi0 Jul 18 11:54:41 blnn204x kernel: cpu1: on acpi0 Jul 18 11:54:41 blnn204x kernel: acpi_button0: on acpi0 Jul 18 11:54:41 blnn204x kernel: pcib0: port 0xcf8-0xcff on acpi0 Jul 18 11:54:41 blnn204x kernel: pci0: on pcib0 Jul 18 11:54:41 blnn204x kernel: pcib1: irq 16 at device 2.0 on pci0 Jul 18 11:54:41 blnn204x kernel: pci1: on pcib1 Jul 18 11:54:41 blnn204x kernel: pcib2: at device 0.0 on pci1 Jul 18 11:54:41 blnn204x kernel: pci2: on pcib2 Jul 18 11:54:41 blnn204x kernel: mpt0: port 0x3000-0x30ff mem 0xde110000-0xde11ffff,0xde100000-0xde10ffff irq 24 at device 8.0 on pci2 Jul 18 11:54:41 blnn204x kernel: mpt0: [GIANT-LOCKED] Jul 18 11:54:41 blnn204x kernel: mpt0: MPI Version=1.2.14.0 Jul 18 11:54:41 blnn204x kernel: mpt0: Unhandled Event Notify Frame. Event 0xa. Jul 18 11:54:41 blnn204x kernel: mpt0: Capabilities: ( RAID-1E RAID-1 SAFTE ) Jul 18 11:54:41 blnn204x kernel: mpt0: 1 Active Volume (1 Max) Jul 18 11:54:41 blnn204x kernel: mpt0: 2 Hidden Drive Members (6 Max) Jul 18 11:54:41 blnn204x kernel: mpt1: port 0x3400-0x34ff mem 0xde130000-0xde13ffff,0xde120000-0xde12ffff irq 25 at device 8.1 on pci2 Jul 18 11:54:41 blnn204x kernel: mpt1: [GIANT-LOCKED] Jul 18 11:54:41 blnn204x kernel: mpt1: MPI Version=1.2.14.0 Jul 18 11:54:41 blnn204x kernel: mpt1: Unhandled Event Notify Frame. Event 0xa. Jul 18 11:54:41 blnn204x kernel: mpt1: Capabilities: ( RAID-1E RAID-1 SAFTE ) Jul 18 11:54:41 blnn204x kernel: mpt1: 0 Active Volumes (0 Max) Jul 18 11:54:41 blnn204x kernel: mpt1: 0 Hidden Drive Members (0 Max) Jul 18 11:54:41 blnn204x kernel: pcib3: at device 0.2 on pci1 Jul 18 11:54:41 blnn204x kernel: pci3: on pcib3 Jul 18 11:54:41 blnn204x kernel: pcib4: irq 16 at device 4.0 on pci0 Jul 18 11:54:41 blnn204x kernel: pci4: on pcib4 Jul 18 11:54:41 blnn204x kernel: bge0: mem 0xde200000-0xde20ffff irq 16 at device 0.0 on pci4 Jul 18 11:54:41 blnn204x kernel: miibus0: on bge0 Jul 18 11:54:41 blnn204x kernel: brgphy0: on miibus0 Jul 18 11:54:41 blnn204x kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto Jul 18 11:54:41 blnn204x kernel: bge0: Ethernet address: 00:30:05:83:db:a9 Jul 18 11:54:41 blnn204x kernel: pcib5: irq 16 at device 5.0 on pci0 Jul 18 11:54:41 blnn204x kernel: pci5: on pcib5 Jul 18 11:54:41 blnn204x kernel: bge1: mem 0xde300000-0xde30ffff irq 16 at device 0.0 on pci5 Jul 18 11:54:41 blnn204x kernel: miibus1: on bge1 Jul 18 11:54:41 blnn204x kernel: brgphy1: on miibus1 Jul 18 11:54:41 blnn204x kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto Jul 18 11:54:41 blnn204x kernel: bge1: Ethernet address: 00:30:05:94:7e:ee Jul 18 11:54:41 blnn204x kernel: pcib6: irq 16 at device 6.0 on pci0 Jul 18 11:54:41 blnn204x kernel: pci6: on pcib6 Jul 18 11:54:41 blnn204x kernel: pcib7: mem 0xde400000-0xde400fff irq 16 at device 0.0 on pci6 Jul 18 11:54:41 blnn204x kernel: pci7: on pcib7 Jul 18 11:54:41 blnn204x kernel: pcib8: mem 0xde401000-0xde401fff irq 17 at device 0.2 on pci6 Jul 18 11:54:41 blnn204x kernel: pci8: on pcib8 Jul 18 11:54:41 blnn204x kernel: uhci0: port 0x1000-0x101f irq 16 at device 29.0 on pci0 Jul 18 11:54:41 blnn204x kernel: uhci0: [GIANT-LOCKED] Jul 18 11:54:41 blnn204x kernel: usb0: on uhci0 Jul 18 11:54:41 blnn204x kernel: usb0: USB revision 1.0 Jul 18 11:54:41 blnn204x kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jul 18 11:54:41 blnn204x kernel: uhub0: 2 ports with 2 removable, self powered Jul 18 11:54:41 blnn204x kernel: uhci1: port 0x1400-0x141f irq 19 at device 29.1 on pci0 Jul 18 11:54:41 blnn204x kernel: uhci1: [GIANT-LOCKED] Jul 18 11:54:41 blnn204x kernel: usb1: on uhci1 Jul 18 11:54:41 blnn204x kernel: usb1: USB revision 1.0 Jul 18 11:54:41 blnn204x kernel: uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jul 18 11:54:41 blnn204x kernel: uhub1: 2 ports with 2 removable, self powered Jul 18 11:54:41 blnn204x kernel: uhci2: port 0x1800-0x181f irq 18 at device 29.2 on pci0 Jul 18 11:54:41 blnn204x kernel: uhci2: [GIANT-LOCKED] Jul 18 11:54:41 blnn204x kernel: usb2: on uhci2 Jul 18 11:54:41 blnn204x kernel: usb2: USB revision 1.0 Jul 18 11:54:41 blnn204x kernel: uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jul 18 11:54:41 blnn204x kernel: uhub2: 2 ports with 2 removable, self powered Jul 18 11:54:41 blnn204x kernel: uhci3: port 0x1c00-0x1c1f irq 16 at device 29.3 on pci0 Jul 18 11:54:41 blnn204x kernel: uhci3: [GIANT-LOCKED] Jul 18 11:54:41 blnn204x kernel: usb3: on uhci3 Jul 18 11:54:41 blnn204x kernel: usb3: USB revision 1.0 Jul 18 11:54:41 blnn204x kernel: uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jul 18 11:54:41 blnn204x kernel: uhub3: 2 ports with 2 removable, self powered Jul 18 11:54:41 blnn204x kernel: ehci0: mem 0xde000000- 0xde0003ff irq 23 at device 29.7 on pci0 Jul 18 11:54:41 blnn204x kernel: ehci0: [GIANT-LOCKED] Jul 18 11:54:41 blnn204x kernel: usb4: EHCI version 1.0 Jul 18 11:54:41 blnn204x kernel: usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 Jul 18 11:54:41 blnn204x kernel: usb4: on ehci0 Jul 18 11:54:41 blnn204x kernel: usb4: USB revision 2.0 Jul 18 11:54:41 blnn204x kernel: uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 Jul 18 11:54:41 blnn204x kernel: uhub4: 8 ports with 8 removable, self powered Jul 18 11:54:41 blnn204x kernel: pcib9: at device 30.0 on pci0 Jul 18 11:54:41 blnn204x kernel: pci9: on pcib9 Jul 18 11:54:41 blnn204x kernel: pci9: at device 5.0 (no driver attached) Jul 18 11:54:41 blnn204x kernel: isab0: at device 31.0 on pci0 Jul 18 11:54:41 blnn204x kernel: isa0: on isab0 Jul 18 11:54:41 blnn204x kernel: atapci0: port 0x1f0- 0x1f7,0x3f6,0x170-0x177,0x376,0x2400-0x240f at device 31.1 on pci0 Jul 18 11:54:41 blnn204x kernel: ata0: on atapci0 Jul 18 11:54:41 blnn204x kernel: ata1: on atapci0 Jul 18 11:54:41 blnn204x kernel: pci0: at device 31.3 (no driver attached) Jul 18 11:54:41 blnn204x kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jul 18 11:54:41 blnn204x kernel: atkbd0: irq 1 on atkbdc0 Jul 18 11:54:41 blnn204x kernel: kbd0 at atkbd0 Jul 18 11:54:41 blnn204x kernel: atkbd0: [GIANT-LOCKED] Jul 18 11:54:41 blnn204x kernel: psm0: irq 12 on atkbdc0 Jul 18 11:54:41 blnn204x kernel: psm0: [GIANT-LOCKED] Jul 18 11:54:41 blnn204x kernel: psm0: model Generic PS/2 mouse, device ID 0 Jul 18 11:54:41 blnn204x kernel: fdc0: port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0 Jul 18 11:54:41 blnn204x kernel: fdc0: [FAST] Jul 18 11:54:41 blnn204x kernel: fd0: <1440-KB 3.5" drive> on fdc0 drive 0 Jul 18 11:54:41 blnn204x kernel: ppc0: port 0x378-0x37b irq 7 on acpi0 Jul 18 11:54:41 blnn204x kernel: ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode Jul 18 11:54:41 blnn204x kernel: ppbus0: on ppc0 Jul 18 11:54:41 blnn204x kernel: lpt0: on ppbus0 Jul 18 11:54:41 blnn204x kernel: lpt0: Interrupt-driven port Jul 18 11:54:41 blnn204x kernel: sio0: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 flags 0x10 on acpi0 Jul 18 11:54:41 blnn204x kernel: sio0: type 16550A Jul 18 11:54:41 blnn204x kernel: sio1: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 on acpi0 Jul 18 11:54:41 blnn204x kernel: sio1: type 16550A Jul 18 11:54:41 blnn204x kernel: pmtimer0 on isa0 Jul 18 11:54:41 blnn204x kernel: orm0: at iomem 0xc0000-0xc8fff,0xc9000- 0xccfff on isa0 Jul 18 11:54:41 blnn204x kernel: sc0: at flags 0x100 on isa0 Jul 18 11:54:41 blnn204x kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jul 18 11:54:41 blnn204x kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000- 0xbffff on isa0 Jul 18 11:54:41 blnn204x kernel: Timecounters tick every 1.000 msec Jul 18 11:54:41 blnn204x kernel: Waiting 5 seconds for SCSI devices to settle Jul 18 11:54:41 blnn204x kernel: acd0: DVDROM at ata1- master UDMA33 Jul 18 11:54:41 blnn204x kernel: mpt0:vol0(mpt0:0:0): Settings ( ) Jul 18 11:54:41 blnn204x kernel: mpt0:vol0(mpt0:0:0): Using Spare Pool: 0 Jul 18 11:54:41 blnn204x kernel: mpt0:vol0(mpt0:0:0): 2 Members: Jul 18 11:54:41 blnn204x kernel: (mpt0:0:0): Primary Jul 18 11:54:41 blnn204x kernel: (mpt0:0:3): Secondary Jul 18 11:54:41 blnn204x kernel: mpt0:vol0(mpt0:0:0): RAID-1 - Optimal Jul 18 11:54:41 blnn204x kernel: mpt0:vol0(mpt0:0:0): Status ( Enabled ) Jul 18 11:54:41 blnn204x kernel: (mpt0:vol0:0): Physical (mpt0:0:0), Pass-thru (mpt0:1:0) Jul 18 11:54:41 blnn204x kernel: (mpt0:vol0:0): Online Jul 18 11:54:41 blnn204x kernel: (mpt0:vol0:1): Physical (mpt0:0:3), Pass-thru (mpt0:1:1) Jul 18 11:54:41 blnn204x kernel: (mpt0:vol0:1): Online Jul 18 11:54:41 blnn204x kernel: ses0 at mpt0 bus 0 target 8 lun 0 Jul 18 11:54:41 blnn204x kernel: ses0: Fixed Processor SCSI-2 device Jul 18 11:54:41 blnn204x kernel: ses0: 3.300MB/s transfers Jul 18 11:54:41 blnn204x kernel: ses0: SAF-TE Compliant Device Jul 18 11:54:41 blnn204x kernel: pass2 at mpt0 bus 1 target 0 lun 0 Jul 18 11:54:41 blnn204x kernel: pass2: Fixed unknown SCSI-3 device Jul 18 11:54:41 blnn204x kernel: pass2: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled Jul 18 11:54:41 blnn204x kernel: pass3 at mpt0 bus 1 target 1 lun 0 Jul 18 11:54:41 blnn204x kernel: pass3: Fixed unknown SCSI-3 device Jul 18 11:54:41 blnn204x kernel: pass3: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled Jul 18 11:54:41 blnn204x kernel: da0 at mpt0 bus 0 target 0 lun 0 Jul 18 11:54:41 blnn204x kernel: da0: Fixed Direct Access SCSI-2 device Jul 18 11:54:41 blnn204x kernel: da0: 320.000MB/s transfers (160.000MHz, offset 63, 16bit), Tagged Queueing Enabled Jul 18 11:54:41 blnn204x kernel: da0: 69400MB (142131200 512 byte sectors: 255H 63S/T 8847C) Jul 18 11:54:41 blnn204x kernel: ATA PseudoRAID loaded Jul 18 11:54:41 blnn204x kernel: SMP: AP CPU #1 Launched! Jul 18 11:54:41 blnn204x kernel: Trying to mount root from ufs:/dev/ da0s1a Jul 18 11:54:41 blnn204x savecore: unable to open bounds file, using 0 Jul 18 11:54:41 blnn204x savecore: no dumps found Jul 18 11:54:43 blnn204x kernel: bge0: link state changed to UP - -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC3Adaf1BNcN37Cl8RAoc+AJwLQhgc8ozahMJyag8zJ0qZh87BSACfQJZl ECiwmGtRPddjTlmznUkAT/E= =rpOa -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 19:52:20 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54B6816A423 for ; Mon, 18 Jul 2005 19:52:20 +0000 (GMT) (envelope-from msch@snafu.de) Received: from tequila.visp.de (tequila.visp.de [84.23.254.157]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2A3D43D48 for ; Mon, 18 Jul 2005 19:52:16 +0000 (GMT) (envelope-from msch@snafu.de) X-Trace: 507c6d73636840736e6166752e64657c38342e3139302e3133322e38317c314475 6265772d303030504f722d4d497c31313231373136333335 Received: from tequila.visp.de ([10.157.10.19] helo=localhost) by tequila.visp.de with esmtpa (Exim 4.51 id 1Dubew-000POr-MI) for freebsd-stable@freebsd.org; Mon, 18 Jul 2005 21:52:15 +0200 Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <04D55966-A390-45AE-A7B8-0828A9655053@snafu.de> References: <04D55966-A390-45AE-A7B8-0828A9655053@snafu.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <982D24FB-1834-48E8-80CD-E6C5ED7F35A3@snafu.de> Content-Transfer-Encoding: 7bit From: Matthias Schuendehuette Date: Mon, 18 Jul 2005 21:52:06 +0200 To: freebsd-stable@freebsd.org X-Pgp-Agent: GPGMail 1.1 (Tiger) X-Mailer: Apple Mail (2.733) Subject: Re: mpt + gvinum on 6.0-BETA (boot -v) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 19:52:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 15.07.2005 um 15:45 schrieb Matthias Schuendehuette: > I tried 6.0-BETA on one of our FUJITSU-SIEMENS RX300 S2 servers and > it seems that I have problems with the disk subsystem, even after > Scotts major overhaul of the mpt drivers... > > I'm not able to post detailed dmesg output in the moment (IMHO > there isn't anything to notice, mpt0 and mpt1 are attached without > any errors) but the symtoms are: > > - - very slow write performace: 'dd if=/dev/zero of=/dev/da0s2 > bs=512 count=32768' reports a throughput of 80 k(!)Bytes/s. Read > performance is somewhat better, 'dd' reports here about 2 MB/s... > better, but not what I would expect from a RAID1 with two U320 SCSI- > disks (Seagate BTW). If I try to 'boot -v', the system ends up in an endless loop with the following messages: Jul 18 11:52:37 blnn204x syslogd: kernel boot file is /boot/kernel/ kernel Jul 18 11:52:37 blnn204x kernel: fset 0x00 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00001000 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 04 12 9f 08 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63bf3000 FlagsLength=0xd1001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x00 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00000800 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 06 4e 7b 04 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63af6000 FlagsLength=0xd1000800 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x10 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00004000 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 06 99 7f 20 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63bc2000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x63be3000 FlagsLength=0x90001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT Jul 18 11:52:37 blnn204x kernel: CE32 0xe6bab040: Addr=0x7d745048 NxtChnO=0x0 Flgs=0x30 Len=0x10 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab048: Addr=0x63aa4000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab050: Addr=0x63be5000 FlagsLength=0xd1001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x10 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00010000 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 04 65 1f 80 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63cef000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x63c30000 FlagsLength=0x90001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT Jul 18 11:52:37 blnn204x kernel: CE32 0xe6bab040: Addr=0x7d745048 NxtChnO=0x0 Flgs=0x30 Len=0x58 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab048: Addr=0x63fb1000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab050: Addr=0x63bd2000 FlagsLength=0x10003000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab058: Addr=0x63b55000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab060: Addr=0x63b16000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab068: Addr=0x63ab7000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab070: Addr=0x63f78000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab078: Addr=0x63af9000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab080: Addr=0x63bda000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab088: Addr=0x63abb000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab090: Addr=0x63a9c000 FlagsLength=0x10002000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab098: Addr=0x63bde000 FlagsLength=0xd1001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x00 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00001800 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 04 17 5f 0c 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63a1c000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x63b3d000 FlagsLength=0xd1000800 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x00 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00002800 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 07 45 bf 14 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63960000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x63aa1000 FlagsLength=0xd1001800 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x10 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00004000 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 06 03 5f 20 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63aab000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x63b0c000 FlagsLength=0x90001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT Jul 18 11:52:37 blnn204x kernel: CE32 0xe6bab040: Addr=0x7d745048 NxtChnO=0x0 Flgs=0x30 Len=0x10 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab048: Addr=0x63acd000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab050: Addr=0x63cee000 FlagsLength=0xd1001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x10 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00004000 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 07 4d bf 20 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63f2a000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x63e6b000 FlagsLength=0x90001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT Jul 18 11:52:37 blnn204x kernel: CE32 0xe6bab040: Addr=0x7d745048 NxtChnO=0x0 Flgs=0x30 Len=0x10 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab048: Addr=0x63b6c000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab050: Addr=0x63b4d000 FlagsLength=0xd1001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x10 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00004000 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 07 4d df 20 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63d0e000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x63c0f000 FlagsLength=0x90001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT Jul 18 11:52:37 blnn204x kernel: CE32 0xe6bab040: Addr=0x7d745048 NxtChnO=0x0 Flgs=0x30 Len=0x10 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab048: Addr=0x63bd0000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab050: Addr=0x63c31000 FlagsLength=0xd1001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x00 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00000800 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 00 11 47 04 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63a73000 FlagsLength=0xd1000800 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x00 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00000800 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 06 57 d7 04 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x63af0000 FlagsLength=0xd1000800 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x10 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00005a00 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 04 5f 1f 2d 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x6392d000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x63b8e000 FlagsLength=0x90001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT Jul 18 11:52:37 blnn204x kernel: CE32 0xe6bab040: Addr=0x7d745048 NxtChnO=0x0 Flgs=0x30 Len=0x20 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab048: Addr=0x63a6f000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab050: Addr=0x63a90000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab058: Addr=0x63a71000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab060: Addr=0x63a12000 FlagsLength=0xd1000a00 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x10 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00010000 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 04 7e 3f 80 00 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab030: Addr=0x638a7000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab038: Addr=0x639c8000 FlagsLength=0x90001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT Jul 18 11:52:37 blnn204x kernel: CE32 0xe6bab040: Addr=0x7d745048 NxtChnO=0x16 Flgs=0x30 Len=0x60 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab048: Addr=0x638c9000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab050: Addr=0x6396a000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab058: Addr=0x638cb000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab060: Addr=0x639cc000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab068: Addr=0x6388d000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab070: Addr=0x63b6e000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab078: Addr=0x63a2f000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab080: Addr=0x639f0000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab088: Addr=0x639d1000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab090: Addr=0x63932000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab098: Addr=0x638d3000 FlagsLength=0x90001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT Jul 18 11:52:37 blnn204x kernel: CE32 0xe6bab0a0: Addr=0x7d7450a8 NxtChnO=0x0 Flgs=0x30 Len=0x18 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab0a8: Addr=0x63a34000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab0b0: Addr=0x63935000 FlagsLength=0x10001000 Jul 18 11:52:37 blnn204x kernel: SE32 0xe6bab0b8: Addr=0x63896000 FlagsLength=0xd1001000 Jul 18 11:52:37 blnn204x kernel: LAST_ELEMENT END_OF_BUFFER END_OF_LIST Jul 18 11:52:37 blnn204x kernel: SCSI IO Request @ 0xe6b4b9ac Jul 18 11:52:37 blnn204x kernel: Chain Offset 0x10 Jul 18 11:52:37 blnn204x kernel: MsgFlags 0x00 Jul 18 11:52:37 blnn204x kernel: MsgContext 0x000100f0 Jul 18 11:52:37 blnn204x kernel: Bus: 0 Jul 18 11:52:37 blnn204x kernel: TargetID 0 Jul 18 11:52:37 blnn204x kernel: SenseBufferLength 32 Jul 18 11:52:37 blnn204x kernel: LUN: 0x0 Jul 18 11:52:37 blnn204x kernel: Control 0x02000000 READ SIMPLEQ Jul 18 11:52:37 blnn204x kernel: DataLength 0x00004000 Jul 18 11:52:37 blnn204x kernel: SenseBufAddr 0x7d7451e0 Jul 18 11:52:37 blnn204x kernel: CDB[0:6] 08 04 22 ff 20 00 [...] - -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC3Ahrf1BNcN37Cl8RArevAJ4vZozrnt8jjZafG+Rf7Pt/LvAJjQCfes6T Gm9xaxp4WB6XCtA6J1Tnnl8= =x5HO -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 20:07:58 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A318D16A41C for ; Mon, 18 Jul 2005 20:07:58 +0000 (GMT) (envelope-from dick@nagual.st) Received: from nagual.st (cc20684-a.assen1.dr.home.nl [82.74.2.254]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC1B043D46 for ; Mon, 18 Jul 2005 20:07:57 +0000 (GMT) (envelope-from dick@nagual.st) Received: from pooh.nagual.st (pooh.nagual.st [192.168.11.22]) by nagual.st with esmtp; Mon, 18 Jul 2005 22:07:56 +0200 Date: Mon, 18 Jul 2005 22:08:07 +0200 From: dick hoogendijk To: freebsd-stable@freebsd.org Message-Id: <20050718220807.450b629e.dick@nagual.st> In-Reply-To: <20050718143155.T74874@neptune.atopia.net> References: <42BF8815.6090909@atopia.net> <20050627081933.GA97832@cell.sick.ru> <42C16394.4040904@atopia.net> <1119971279.36316.45.camel@buffy.york.ac.uk> <42C16C0E.9090002@atopia.net> <20050629100535.GC27557@xor.obsecurity.org> <20050701184352.GA177@xor.obsecurity.org> <20050706093012.M3376@titanic.medinet.si> <20050706104344.U4718@titanic.medinet.si> <20050712141639.U72892@neptune.atopia.net> <20050717131610.T29059@titanic.medinet.si> <20050718143155.T74874@neptune.atopia.net> Organization: de nagual X-Mailer: Sylpheed version 1.0.5 (GTK+ 1.2.10; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD -STABLE servers repeatedly crashing. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 20:07:58 -0000 On Mon, 18 Jul 2005 14:32:09 -0400 (EDT) Matt Juszczak wrote: > > For me, 5 days up time after switching from IPF to PF. Before the switch a > > couple of hours of uptime was the maximum. Seems like the crashes are caused > > by ipfilter. > > > Still same for me :) Uptime almost 20 days now after switching to PF. I find this messages kind of weird. Are you saying your servers only run long periods of uptime with pf and *not* with ipf? I run a server and almost never put it down. IPF performs very well, including a lot of natting for my home network. -- dick -- http://nagual.st/ -- PGP/GnuPG key: F86289CE ++ Running FreeBSD 4.11-stable ++ FreeBSD 5.4 + Nai tiruvantel ar vayuvantel i Valar tielyanna nu vilja From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 20:09:59 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E94D16A41C for ; Mon, 18 Jul 2005 20:09:59 +0000 (GMT) (envelope-from matt@atopia.net) Received: from neptune.atopia.net (neptune.atopia.net [209.128.231.90]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38C0943D46 for ; Mon, 18 Jul 2005 20:09:59 +0000 (GMT) (envelope-from matt@atopia.net) Received: by neptune.atopia.net (Postfix, from userid 1001) id B27896178; Mon, 18 Jul 2005 16:09:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by neptune.atopia.net (Postfix) with ESMTP id B0A02614E; Mon, 18 Jul 2005 16:09:58 -0400 (EDT) Date: Mon, 18 Jul 2005 16:09:58 -0400 (EDT) From: Matt Juszczak To: dick hoogendijk In-Reply-To: <20050718220807.450b629e.dick@nagual.st> Message-ID: <20050718160922.O76819@neptune.atopia.net> References: <42BF8815.6090909@atopia.net> <20050627081933.GA97832@cell.sick.ru> <42C16394.4040904@atopia.net> <1119971279.36316.45.camel@buffy.york.ac.uk> <42C16C0E.9090002@atopia.net> <20050629100535.GC27557@xor.obsecurity.org> <20050701184352.GA177@xor.obsecurity.org> <20050706093012.M3376@titanic.medinet.si> <20050706104344.U4718@titanic.medinet.si> <20050712141639.U72892@neptune.atopia.net> <20050717131610.T29059@titanic.medinet.si> <20050718143155.T74874@neptune.atopia.net> <20050718220807.450b629e.dick@nagual.st> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD -STABLE servers repeatedly crashing. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 20:09:59 -0000 > I find this messages kind of weird. Are you saying your servers only run long periods of uptime with pf and *not* with ipf? I run a server and almost never put it down. IPF performs very well, including a lot of natting for my home network. Correct. IPF is unstable with our SMP (most of the time) - based 5.x boxes. VERY unstable. VERY VERY unstable. -Matt From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 20:45:06 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D317816A41C for ; Mon, 18 Jul 2005 20:45:06 +0000 (GMT) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6471C43D45 for ; Mon, 18 Jul 2005 20:45:06 +0000 (GMT) (envelope-from pawmal-posting@freebsd.lublin.pl) Received: by shellma.zin.lublin.pl (Postfix, from userid 1018) id 7F012347E0B; Mon, 18 Jul 2005 22:43:24 +0200 (CEST) Date: Mon, 18 Jul 2005 22:43:24 +0200 From: Pawel Malachowski To: freebsd-stable@freebsd.org Message-ID: <20050718204324.GA37192@shellma.zin.lublin.pl> References: <20050629100535.GC27557@xor.obsecurity.org> <20050701184352.GA177@xor.obsecurity.org> <20050706093012.M3376@titanic.medinet.si> <20050706104344.U4718@titanic.medinet.si> <20050712141639.U72892@neptune.atopia.net> <20050717131610.T29059@titanic.medinet.si> <20050718143155.T74874@neptune.atopia.net> <20050718220807.450b629e.dick@nagual.st> <20050718160922.O76819@neptune.atopia.net> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20050718160922.O76819@neptune.atopia.net> User-Agent: Mutt/1.4.2i Subject: Re: FreeBSD -STABLE servers repeatedly crashing. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 20:45:06 -0000 On Mon, Jul 18, 2005 at 04:09:58PM -0400, Matt Juszczak wrote: > Correct. IPF is unstable with our SMP (most of the time) - based 5.x > boxes. VERY unstable. VERY VERY unstable. Hm, this sounds bad. What is debug.mpsafenet set to? How big is traffic? I have one SMP box with ipnat, routing some megabits (even during night it's more than 30-40Mbps) without problems, however, ipnat is used only for very small group of hosts right now. But we plan to use ipnat more heavily so it sounds a bit scary. ;) -- Pawe³ Ma³achowski From owner-freebsd-stable@FreeBSD.ORG Mon Jul 18 21:39:42 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FC4816A41C for ; Mon, 18 Jul 2005 21:39:42 +0000 (GMT) (envelope-from gmulder@infotechfl.com) Received: from pigeon.infotechfl.com (mailrelay.infotechfl.com [209.251.147.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id D7A6343D46 for ; Mon, 18 Jul 2005 21:39:41 +0000 (GMT) (envelope-from gmulder@infotechfl.com) Received: from localhost (gmulder@localhost) by pigeon.infotechfl.com (8.11.6/8.11.6) with ESMTP id j6ILde606880 for ; Mon, 18 Jul 2005 17:39:40 -0400 Date: Mon, 18 Jul 2005 17:39:40 -0400 (EDT) From: Gary Mulder To: freebsd-stable@freebsd.org In-Reply-To: <20050718204324.GA37192@shellma.zin.lublin.pl> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: FreeBSD -STABLE servers repeatedly crashing. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jul 2005 21:39:42 -0000 On Mon, 18 Jul 2005, Pawel Malachowski wrote: > On Mon, Jul 18, 2005 at 04:09:58PM -0400, Matt Juszczak wrote: > > > Correct. IPF is unstable with our SMP (most of the time) - based 5.x > > boxes. VERY unstable. VERY VERY unstable. > > Hm, this sounds bad. What is debug.mpsafenet set to? How big is traffic? > > I have one SMP box with ipnat, routing some megabits (even during night > it's more than 30-40Mbps) without problems, however, ipnat is used only > for very small group of hosts right now. > But we plan to use ipnat more heavily so it sounds a bit scary. ;) >From personal experience I can repeat what Matt has stated. It seems to be related to what NIC you have. I have had crashes with fxp (Intel Pro 100MBit) and bge (Broadcom Gigabit) NICs under moderate network load. Removing ipf reduced but did not eliminate the crashes. debug.mpsafe also reduced but did not eliminate the crashes. Another person on the freebsd-amd64 list reported similar network-related crashes until he switched to em (Intel Gigabit Ethernet) NICs. Gary From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 03:31:07 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6A87716A41C for ; Tue, 19 Jul 2005 03:31:07 +0000 (GMT) (envelope-from rees@ddcom.co.jp) Received: from proxy.ddcom.co.jp (proxy.ddcom.co.jp [211.121.191.163]) by mx1.FreeBSD.org (Postfix) with SMTP id BB04E43D45 for ; Tue, 19 Jul 2005 03:31:06 +0000 (GMT) (envelope-from rees@ddcom.co.jp) Received: (qmail 32686 invoked by alias); 19 Jul 2005 03:40:38 -0000 Received: from unknown (HELO ?172.16.1.133?) (10.10.10.11) by mail.ddcom.local with SMTP; 19 Jul 2005 03:40:38 -0000 Mime-Version: 1.0 (Apple Message framework v730) In-Reply-To: <20050715210320.01E215D07@ptavv.es.net> References: <20050715210320.01E215D07@ptavv.es.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <30C8CD81-73BF-4823-9B41-E8DA23F1EC43@ddcom.co.jp> Content-Transfer-Encoding: 7bit From: Joel Rees Date: Tue, 19 Jul 2005 12:30:12 +0900 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.730) Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 03:31:07 -0000 Comment from out in left field -- On 2005/07/16, at 6:03, Kevin Oberman wrote: > [...] > I believe that the Windows solution to this problem is to put a > really, > really long delay between when the system is finished syncing and when > the power is turned off. That's what I vote for. If the system has ATA on it, send a line to the console that says waiting for ATA technology drives to quit lying after the final sync, and then wait 30 seconds to cut power. > This might be the best solution for FreeBSD, as > well, but it will irritate people. My impression is that in this case irritation is recommended. (I'm half wondering if Microsoft and the drive manufacturer's haven't defined some hidden API for forcing the drive electronics to be truthful.) From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 05:52:09 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A60BF16A41C for ; Tue, 19 Jul 2005 05:52:09 +0000 (GMT) (envelope-from proforg@tic-tac.ru) Received: from tic-tac.ru (tic-tac.ru [82.138.36.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F31C43D45 for ; Tue, 19 Jul 2005 05:52:08 +0000 (GMT) (envelope-from proforg@tic-tac.ru) Received: from [217.74.32.163] (HELO am) by tic-tac.ru (CommuniGate Pro SMTP 4.2.7) with SMTP id 2077374; Tue, 19 Jul 2005 09:52:06 +0400 Message-ID: <0eae01c58c25$fedf1ac0$7601540a@am> From: "Alexander Markov" To: "Rong-En Fan" References: <08f401c58881$bb0f7bc0$7601540a@am> <6eb82e05071409007a97d193@mail.gmail.com> Date: Tue, 19 Jul 2005 09:34:42 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Cc: stable@freebsd.org Subject: Re: IBM xSeries 335 and FreeBSD 5 STABLE. SMP problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 05:52:09 -0000 >If you unload kernel and load it again at boot manually, can 335 boot? >I have one 336 with 5.4 that must use this trick to boot, otherwise >it hangs after ipfw2 initialized. On the other hand, I have 3 335 installed >with 5.4 running SMP smoothly. Nope, this trick doesn't work for me :-( And btw, do you have LSI Logic SCSI controller on your 335? I'll try to upgrade BIOS today, for it seems to be the only difference between my and people in the list's hardware. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 05:52:11 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 949AC16A41C for ; Tue, 19 Jul 2005 05:52:11 +0000 (GMT) (envelope-from proforg@tic-tac.ru) Received: from tic-tac.ru (tic-tac.ru [82.138.36.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49E7343D45 for ; Tue, 19 Jul 2005 05:52:10 +0000 (GMT) (envelope-from proforg@tic-tac.ru) Received: from [217.74.32.163] (HELO am) by tic-tac.ru (CommuniGate Pro SMTP 4.2.7) with SMTP id 2077375; Tue, 19 Jul 2005 09:52:06 +0400 Message-ID: <0eaf01c58c25$fee890a0$7601540a@am> From: "Alexander Markov" To: "Joseph Koshy" References: <08f401c58881$bb0f7bc0$7601540a@am> <84dead7205071408142bce46b3@mail.gmail.com> Date: Tue, 19 Jul 2005 09:49:30 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="ISO-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Cc: stable@freebsd.org Subject: Re: IBM xSeries 335 and FreeBSD 5 STABLE. SMP problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 05:52:11 -0000 > boot -v output would be useful. There's a lot of mpt errors, but I don't think this is the hang reason (as I googled, there's performance problems with RAID1 over LSI Logic in FreeBSD due to its driver, but nobody told this resulted in hang) Jul 15 17:00:51 ibm335 syslogd: kernel boot file is /boot/kernel/kernel Jul 15 17:00:51 ibm335 kernel: Copyright (c) 1992-2005 The FreeBSD Project. Jul 15 17:00:51 ibm335 kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jul 15 17:00:51 ibm335 kernel: The Regents of the University of California. All rights reserved. Jul 15 17:00:51 ibm335 kernel: FreeBSD 5.4-STABLE #2: Thu Jul 14 14:20:40 MSD 2005 Jul 15 17:00:51 ibm335 kernel: root@ibm335:/usr/obj/usr/src/sys/SMP-CUSTOM Jul 15 17:00:51 ibm335 kernel: Preloaded elf kernel "/boot/kernel/kernel" at 0xc07f1000. Jul 15 17:00:51 ibm335 kernel: Preloaded elf module "/boot/modules/acpi.ko" at 0xc07f11cc. Jul 15 17:00:51 ibm335 kernel: Calibrating clock(s) ... i8254 clock: 1193191 Hz Jul 15 17:00:51 ibm335 kernel: CLK_USE_I8254_CALIBRATION not specified - using default frequency Jul 15 17:00:51 ibm335 kernel: Timecounter "i8254" frequency 1193182 Hz quality 0 Jul 15 17:00:51 ibm335 kernel: Calibrating TSC clock ... TSC clock: 2392253816 Hz Jul 15 17:00:51 ibm335 kernel: CPU: Intel(R) XEON(TM) CPU 2.40GHz (2392.25-MHz 686-class CPU) Jul 15 17:00:51 ibm335 kernel: Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Jul 15 17:00:51 ibm335 kernel: Features=0x3febfbff Jul 15 17:00:51 ibm335 kernel: real memory = 536850432 (511 MB) Jul 15 17:00:51 ibm335 kernel: Physical memory chunk(s): Jul 15 17:00:51 ibm335 kernel: 0x0000000000001000 - 0x000000000009cfff, 638976 bytes (156 pages) Jul 15 17:00:51 ibm335 kernel: 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) Jul 15 17:00:51 ibm335 kernel: 0x0000000000828000 - 0x000000001f6cafff, 518664192 bytes (126627 pages) Jul 15 17:00:51 ibm335 kernel: avail memory = 519860224 (495 MB) Jul 15 17:00:51 ibm335 kernel: bios32: Found BIOS32 Service Directory header at 0xc00fd7d0 Jul 15 17:00:51 ibm335 kernel: bios32: Entry = 0xfd7e1 (c00fd7e1) Rev = 0 Len = 1 Jul 15 17:00:51 ibm335 kernel: pcibios: PCI BIOS entry at 0xf0000+0xd81c Jul 15 17:00:51 ibm335 kernel: pnpbios: Found PnP BIOS data at 0xc00fdf90 Jul 15 17:00:51 ibm335 kernel: pnpbios: Entry = f0000:5225 Rev = 1.0 Jul 15 17:00:51 ibm335 kernel: Other BIOS signatures found: Jul 15 17:00:51 ibm335 kernel: mem: Jul 15 17:00:51 ibm335 kernel: Pentium Pro MTRR support enabled Jul 15 17:00:51 ibm335 kernel: io: Jul 15 17:00:51 ibm335 kernel: null: Jul 15 17:00:51 ibm335 kernel: random: Jul 15 17:00:51 ibm335 kernel: npx0: [FAST] Jul 15 17:00:51 ibm335 kernel: npx0: on motherboard Jul 15 17:00:51 ibm335 kernel: npx0: INT 16 interface Jul 15 17:00:51 ibm335 kernel: acpi0: on motherboard Jul 15 17:00:51 ibm335 kernel: acpi0: [MPSAFE] Jul 15 17:00:51 ibm335 kernel: pci_open(1): mode 1 addr port (0x0cf8) is 0x80007890 Jul 15 17:00:51 ibm335 kernel: pci_open(1a): mode1res=0x80000000 (0x80000000) Jul 15 17:00:51 ibm335 kernel: pci_cfgcheck: device 0 [class=060000] [hdr=80] is there (id=00121166) Jul 15 17:00:51 ibm335 kernel: pcibios: BIOS version 2.10 Jul 15 17:00:51 ibm335 kernel: AcpiOsDerivePciId: bus 0 dev 15 func 2 Jul 15 17:00:51 ibm335 kernel: acpi0: Power Button (fixed) Jul 15 17:00:51 ibm335 kernel: AcpiOsDerivePciId: bus 0 dev 0 func 0 Jul 15 17:00:51 ibm335 kernel: AcpiOsDerivePciId: bus 0 dev 17 func 0 Jul 15 17:00:51 ibm335 kernel: AcpiOsDerivePciId: bus 0 dev 17 func 2 Jul 15 17:00:51 ibm335 kernel: ACPI timer: 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 0/3 -> 0 Jul 15 17:00:51 ibm335 kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000 Jul 15 17:00:51 ibm335 kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x488-0x48b on acpi0 Jul 15 17:00:51 ibm335 kernel: unknown: not probed (disabled) Jul 15 17:00:51 ibm335 last message repeated 27 times Jul 15 17:00:51 ibm335 kernel: cpu0: on acpi0 Jul 15 17:00:51 ibm335 kernel: pcib0: on acpi0 Jul 15 17:00:51 ibm335 kernel: ACPI PCI link initial configuration: Jul 15 17:00:51 ibm335 kernel: \LP0A irq 0: [10] 10+ low,level,sharable 0.1.0 Jul 15 17:00:51 ibm335 kernel: \LPUS irq 0: [11] 11+ low,level,sharable 0.15.0 Jul 15 17:00:51 ibm335 kernel: pci0: on pcib0 Jul 15 17:00:51 ibm335 kernel: pci0: physical bus=0 Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x1166, dev=0x0012, revid=0x13 Jul 15 17:00:51 ibm335 kernel: bus=0, slot=0, func=0 Jul 15 17:00:51 ibm335 kernel: class=06-00-00, hdrtype=0x00, mfdev=1 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x1166, dev=0x0012, revid=0x00 Jul 15 17:00:51 ibm335 kernel: bus=0, slot=0, func=1 Jul 15 17:00:51 ibm335 kernel: class=06-00-00, hdrtype=0x00, mfdev=1 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x1166, dev=0x0000, revid=0x00 Jul 15 17:00:51 ibm335 kernel: bus=0, slot=0, func=2 Jul 15 17:00:51 ibm335 kernel: class=06-00-00, hdrtype=0x00, mfdev=1 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0000, statreg=0x0000, cachelnsz=16 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jul 15 17:00:51 ibm335 kernel: map[10]: type 1, range 32, base fd000000, size 24, enabled Jul 15 17:00:51 ibm335 kernel: map[14]: type 4, range 32, base 00002200, size 8, enabled Jul 15 17:00:51 ibm335 kernel: map[18]: type 1, range 32, base febff000, size 12, enabled Jul 15 17:00:51 ibm335 kernel: pcib0: matched entry for 0.1.INTA (src \LP0A) Jul 15 17:00:51 ibm335 kernel: pcib0: possible interrupts: 10 Jul 15 17:00:51 ibm335 kernel: ACPI PCI link arbitrated settings: Jul 15 17:00:51 ibm335 kernel: \LP0A (references 1, priority 10): Jul 15 17:00:51 ibm335 kernel: interrupts: 10 Jul 15 17:00:51 ibm335 kernel: penalty: 10 Jul 15 17:00:51 ibm335 kernel: \LPUS (references 1, priority 10): Jul 15 17:00:51 ibm335 kernel: interrupts: 11 Jul 15 17:00:51 ibm335 kernel: penalty: 10 Jul 15 17:00:51 ibm335 kernel: pcib0: slot 1 INTA routed to irq 10 via \LP0A Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x1002, dev=0x4752, revid=0x27 Jul 15 17:00:51 ibm335 kernel: bus=0, slot=1, func=0 Jul 15 17:00:51 ibm335 kernel: class=03-00-00, hdrtype=0x00, mfdev=0 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0087, statreg=0x0290, cachelnsz=8 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) Jul 15 17:00:51 ibm335 kernel: intpin=a, irq=10 Jul 15 17:00:51 ibm335 kernel: powerspec 2 supports D0 D1 D2 D3 current D0 Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x1166, dev=0x0201, revid=0x93 Jul 15 17:00:51 ibm335 kernel: bus=0, slot=15, func=0 Jul 15 17:00:51 ibm335 kernel: class=06-00-00, hdrtype=0x00, mfdev=1 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0147, statreg=0x2200, cachelnsz=0 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jul 15 17:00:51 ibm335 kernel: map[20]: type 4, range 32, base 00000700, size 4, enabled Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x1166, dev=0x0212, revid=0x93 Jul 15 17:00:51 ibm335 kernel: bus=0, slot=15, func=1 Jul 15 17:00:51 ibm335 kernel: class=01-01-8a, hdrtype=0x00, mfdev=1 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0155, statreg=0x0200, cachelnsz=8 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jul 15 17:00:51 ibm335 kernel: map[10]: type 1, range 32, base febfe000, size 12, enabled Jul 15 17:00:51 ibm335 kernel: pcib0: matched entry for 0.15.INTA (src \LPUS) Jul 15 17:00:51 ibm335 kernel: pcib0: possible interrupts: 11 Jul 15 17:00:51 ibm335 kernel: ACPI PCI link arbitrated settings: Jul 15 17:00:51 ibm335 kernel: \LPUS (references 1, priority 20): Jul 15 17:00:51 ibm335 kernel: interrupts: 11 Jul 15 17:00:51 ibm335 kernel: penalty: 20 Jul 15 17:00:51 ibm335 kernel: pcib0: slot 15 INTA routed to irq 11 via \LPUS Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x1166, dev=0x0220, revid=0x05 Jul 15 17:00:51 ibm335 kernel: bus=0, slot=15, func=2 Jul 15 17:00:51 ibm335 kernel: class=0c-03-10, hdrtype=0x00, mfdev=1 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0157, statreg=0x0280, cachelnsz=8 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x50 (20000 ns) Jul 15 17:00:51 ibm335 kernel: intpin=a, irq=11 Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x1166, dev=0x0225, revid=0x00 Jul 15 17:00:51 ibm335 kernel: bus=0, slot=15, func=3 Jul 15 17:00:51 ibm335 kernel: class=06-01-00, hdrtype=0x00, mfdev=1 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0144, statreg=0x0200, cachelnsz=0 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x1166, dev=0x0101, revid=0x03 Jul 15 17:00:51 ibm335 kernel: bus=0, slot=17, func=0 Jul 15 17:00:51 ibm335 kernel: class=06-00-00, hdrtype=0x00, mfdev=1 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0142, statreg=0x2230, cachelnsz=0 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x1166, dev=0x0101, revid=0x03 Jul 15 17:00:51 ibm335 kernel: bus=0, slot=17, func=2 Jul 15 17:00:51 ibm335 kernel: class=06-00-00, hdrtype=0x00, mfdev=1 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0142, statreg=0x2230, cachelnsz=0 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) Jul 15 17:00:51 ibm335 kernel: pci0: at device 1.0 (no driver attached) Jul 15 17:00:51 ibm335 kernel: atapci0: port 0x700-0x70f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 15.1 on pci0 Jul 15 17:00:51 ibm335 kernel: atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0x700 Jul 15 17:00:51 ibm335 kernel: ata0: channel #0 on atapci0 Jul 15 17:00:51 ibm335 kernel: atapci0: Reserved 0x8 bytes for rid 0x10 type 4 at 0x1f0 Jul 15 17:00:51 ibm335 kernel: atapci0: Reserved 0x1 bytes for rid 0x14 type 4 at 0x3f6 Jul 15 17:00:51 ibm335 kernel: ata0: reset tp1 mask=00 ostat0=ff ostat1=ff Jul 15 17:00:51 ibm335 kernel: ata0: [MPSAFE] Jul 15 17:00:51 ibm335 kernel: ata1: channel #1 on atapci0 Jul 15 17:00:51 ibm335 kernel: atapci0: Reserved 0x8 bytes for rid 0x18 type 4 at 0x170 Jul 15 17:00:51 ibm335 kernel: atapci0: Reserved 0x1 bytes for rid 0x1c type 4 at 0x376 Jul 15 17:00:51 ibm335 kernel: ata1: reset tp1 mask=03 ostat0=50 ostat1=01 Jul 15 17:00:51 ibm335 kernel: ata1-master: stat=0x00 err=0x01 lsb=0x14 msb=0xeb Jul 15 17:00:51 ibm335 kernel: ata1-slave: stat=0x00 err=0x04 lsb=0x00 msb=0x00 Jul 15 17:00:51 ibm335 kernel: ata1: reset tp2 stat0=00 stat1=00 devices=0x4 Jul 15 17:00:51 ibm335 kernel: ata1: [MPSAFE] Jul 15 17:00:51 ibm335 kernel: ohci0: mem 0xfebfe000-0xfebfefff irq 11 at device 15.2 on pci0 Jul 15 17:00:51 ibm335 kernel: ohci0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfebfe000 Jul 15 17:00:51 ibm335 kernel: ohci0: (New OHCI DeviceId=0x02201166) Jul 15 17:00:51 ibm335 kernel: ohci0: [GIANT-LOCKED] Jul 15 17:00:51 ibm335 kernel: usb0: OHCI version 1.0, legacy support Jul 15 17:00:51 ibm335 kernel: usb0: on ohci0 Jul 15 17:00:51 ibm335 kernel: usb0: USB revision 1.0 Jul 15 17:00:51 ibm335 kernel: uhub0: (0x1166) OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Jul 15 17:00:51 ibm335 kernel: uhub0: 4 ports with 4 removable, self powered Jul 15 17:00:51 ibm335 kernel: isab0: at device 15.3 on pci0 Jul 15 17:00:51 ibm335 kernel: isa0: on isab0 Jul 15 17:00:51 ibm335 kernel: pcib1: on acpi0 Jul 15 17:00:51 ibm335 kernel: ACPI PCI link initial configuration: Jul 15 17:00:51 ibm335 kernel: \LP06 irq 0: [ 9] 9+ low,level,sharable 1.1.0 Jul 15 17:00:51 ibm335 kernel: pci1: on pcib1 Jul 15 17:00:51 ibm335 kernel: pci1: physical bus=1 Jul 15 17:00:51 ibm335 kernel: map[10]: type 4, range 32, base 00002300, size 8, enabled Jul 15 17:00:51 ibm335 kernel: map[14]: type 1, range 64, base fbff0000, size 16, enabled Jul 15 17:00:51 ibm335 kernel: map[1c]: type 1, range 64, base fbfe0000, size 16, enabled Jul 15 17:00:51 ibm335 kernel: pcib1: matched entry for 1.1.INTA (src \LP06) Jul 15 17:00:51 ibm335 kernel: pcib1: possible interrupts: 9 Jul 15 17:00:51 ibm335 kernel: ACPI PCI link arbitrated settings: Jul 15 17:00:51 ibm335 kernel: \LP06 (references 1, priority 10): Jul 15 17:00:51 ibm335 kernel: interrupts: 9 Jul 15 17:00:51 ibm335 kernel: penalty: 10 Jul 15 17:00:51 ibm335 kernel: pcib1: slot 1 INTA routed to irq 9 via \LP06 Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x1000, dev=0x0030, revid=0x07 Jul 15 17:00:51 ibm335 kernel: bus=1, slot=1, func=0 Jul 15 17:00:51 ibm335 kernel: class=01-00-00, hdrtype=0x00, mfdev=0 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0157, statreg=0x0230, cachelnsz=8 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x48 (2160 ns), mingnt=0x11 (4250 ns), maxlat=0x12 (4500 ns) Jul 15 17:00:51 ibm335 kernel: intpin=a, irq=9 Jul 15 17:00:51 ibm335 kernel: powerspec 2 supports D0 D1 D2 D3 current D0 Jul 15 17:00:51 ibm335 kernel: MSI supports 1 message, 64 bit Jul 15 17:00:51 ibm335 kernel: mpt0: port 0x2300-0x23ff mem 0xfbfe0000-0xfbfeffff,0xfbff0000-0xfbffffff irq 9 at device 1.0 on pci1 Jul 15 17:00:51 ibm335 kernel: mpt0: Reserved 0x10000 bytes for rid 0x14 type 3 at 0xfbff0000 Jul 15 17:00:51 ibm335 kernel: mpt0: [GIANT-LOCKED] Jul 15 17:00:51 ibm335 kernel: mpt0: soft reset Jul 15 17:00:51 ibm335 kernel: pcib2: on acpi0 Jul 15 17:00:51 ibm335 kernel: ACPI PCI link initial configuration: Jul 15 17:00:51 ibm335 kernel: \LP08 irq 0: [ 3] 3+ low,level,sharable 2.1.0 Jul 15 17:00:51 ibm335 kernel: \LP09 irq 0: [ 4] 4+ low,level,sharable 2.2.0 Jul 15 17:00:51 ibm335 kernel: pci2: on pcib2 Jul 15 17:00:51 ibm335 kernel: pci2: physical bus=2 Jul 15 17:00:51 ibm335 kernel: map[10]: type 1, range 64, base f9ff0000, size 16, enabled Jul 15 17:00:51 ibm335 kernel: pcib2: matched entry for 2.1.INTA (src \LP08) Jul 15 17:00:51 ibm335 kernel: pcib2: possible interrupts: 3 Jul 15 17:00:51 ibm335 kernel: ACPI PCI link arbitrated settings: Jul 15 17:00:51 ibm335 kernel: \LP08 (references 1, priority 5010): Jul 15 17:00:51 ibm335 kernel: interrupts: 3 Jul 15 17:00:51 ibm335 kernel: penalty: 5010 Jul 15 17:00:51 ibm335 kernel: \LP09 (references 1, priority 5010): Jul 15 17:00:51 ibm335 kernel: interrupts: 4 Jul 15 17:00:51 ibm335 kernel: penalty: 5010 Jul 15 17:00:51 ibm335 kernel: pcib2: slot 1 INTA routed to irq 3 via \LP08 Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x14e4, dev=0x16a7, revid=0x02 Jul 15 17:00:51 ibm335 kernel: bus=2, slot=1, func=0 Jul 15 17:00:51 ibm335 kernel: class=02-00-00, hdrtype=0x00, mfdev=0 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0156, statreg=0x02b0, cachelnsz=8 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) Jul 15 17:00:51 ibm335 kernel: intpin=a, irq=3 Jul 15 17:00:51 ibm335 kernel: powerspec 2 supports D0 D3 current D0 Jul 15 17:00:51 ibm335 kernel: MSI supports 8 messages, 64 bit Jul 15 17:00:51 ibm335 kernel: map[10]: type 1, range 64, base f9fe0000, size 16, enabled Jul 15 17:00:51 ibm335 kernel: pcib2: matched entry for 2.2.INTA (src \LP09) Jul 15 17:00:51 ibm335 kernel: pcib2: possible interrupts: 4 Jul 15 17:00:51 ibm335 kernel: ACPI PCI link arbitrated settings: Jul 15 17:00:51 ibm335 kernel: \LP09 (references 1, priority 5020): Jul 15 17:00:51 ibm335 kernel: interrupts: 4 Jul 15 17:00:51 ibm335 kernel: penalty: 5020 Jul 15 17:00:51 ibm335 kernel: pcib2: slot 2 INTA routed to irq 4 via \LP09 Jul 15 17:00:51 ibm335 kernel: found-> vendor=0x14e4, dev=0x16a7, revid=0x02 Jul 15 17:00:51 ibm335 kernel: bus=2, slot=2, func=0 Jul 15 17:00:51 ibm335 kernel: class=02-00-00, hdrtype=0x00, mfdev=0 Jul 15 17:00:51 ibm335 kernel: cmdreg=0x0156, statreg=0x02b0, cachelnsz=8 (dwords) Jul 15 17:00:51 ibm335 kernel: lattimer=0x00 (0 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) Jul 15 17:00:51 ibm335 kernel: intpin=a, irq=4 Jul 15 17:00:51 ibm335 kernel: powerspec 2 supports D0 D3 current D0 Jul 15 17:00:51 ibm335 kernel: MSI supports 8 messages, 64 bit Jul 15 17:00:51 ibm335 kernel: bge0: mem 0xf9ff0000-0xf9ffffff irq 3 at device 1.0 on pci2 Jul 15 17:00:51 ibm335 kernel: bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf9ff0000 Jul 15 17:00:51 ibm335 kernel: miibus0: on bge0 Jul 15 17:00:51 ibm335 kernel: brgphy0: on miibus0 Jul 15 17:00:51 ibm335 kernel: brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto Jul 15 17:00:51 ibm335 kernel: bge0: bpf attached Jul 15 17:00:51 ibm335 kernel: bge0: Ethernet address: 00:02:55:67:1e:58 Jul 15 17:00:51 ibm335 kernel: bge0: [MPSAFE] Jul 15 17:00:51 ibm335 kernel: bge1: mem 0xf9fe0000-0xf9feffff irq 4 at device 2.0 on pci2 Jul 15 17:00:51 ibm335 kernel: bge1: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xf9fe0000 Jul 15 17:00:51 ibm335 kernel: miibus1: on bge1 Jul 15 17:00:51 ibm335 kernel: brgphy1: on miibus1 Jul 15 17:00:51 ibm335 kernel: brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto Jul 15 17:00:51 ibm335 kernel: bge1: bpf attached Jul 15 17:00:51 ibm335 kernel: bge1: Ethernet address: 00:02:55:67:1e:59 Jul 15 17:00:51 ibm335 kernel: bge1: [MPSAFE] Jul 15 17:00:51 ibm335 kernel: atkbdc0: port 0x60,0x64 irq 1 on acpi0 Jul 15 17:00:51 ibm335 kernel: atkbd0: irq 1 on atkbdc0 Jul 15 17:00:51 ibm335 kernel: atkbd: the current kbd controller command byte 0065 Jul 15 17:00:51 ibm335 kernel: atkbd: unable to set the command byte. Jul 15 17:00:51 ibm335 kernel: kbd0 at atkbd0 Jul 15 17:00:51 ibm335 kernel: kbd0: atkbd0, generic (0), config:0x0, flags:0x3d0000 Jul 15 17:00:51 ibm335 kernel: atkbd0: [GIANT-LOCKED] Jul 15 17:00:51 ibm335 kernel: unknown: not probed (disabled) Jul 15 17:00:51 ibm335 last message repeated 41 times Jul 15 17:00:51 ibm335 kernel: ata: ata0 already exists; skipping it Jul 15 17:00:51 ibm335 kernel: ata: ata1 already exists; skipping it Jul 15 17:00:51 ibm335 kernel: atkbdc: atkbdc0 already exists; skipping it Jul 15 17:00:51 ibm335 kernel: Trying Read_Port at 203 Jul 15 17:00:51 ibm335 kernel: Trying Read_Port at 243 Jul 15 17:00:51 ibm335 kernel: Trying Read_Port at 283 Jul 15 17:00:51 ibm335 kernel: Trying Read_Port at 2c3 Jul 15 17:00:51 ibm335 kernel: Trying Read_Port at 303 Jul 15 17:00:51 ibm335 kernel: Trying Read_Port at 343 Jul 15 17:00:51 ibm335 kernel: Trying Read_Port at 383 Jul 15 17:00:51 ibm335 kernel: Trying Read_Port at 3c3 Jul 15 17:00:51 ibm335 kernel: sc: sc0 already exists; skipping it Jul 15 17:00:51 ibm335 kernel: vga: vga0 already exists; skipping it Jul 15 17:00:51 ibm335 kernel: isa_probe_children: disabling PnP devices Jul 15 17:00:51 ibm335 kernel: isa_probe_children: probing non-PnP devices Jul 15 17:00:51 ibm335 kernel: orm0: at iomem 0xcc000-0xcd7ff,0xc8000-0xcbfff,0xc0000-0xc7fff on isa0 Jul 15 17:00:51 ibm335 kernel: pmtimer0 on isa0 Jul 15 17:00:51 ibm335 kernel: adv0: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: aha0: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: aic0: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: bt0: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: cs0: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: ed0: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 Jul 15 17:00:51 ibm335 kernel: fe0: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: ie0: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: lnc0: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: pcic0 failed to probe at port 0x3e0 iomem 0xd0000 on isa0 Jul 15 17:00:51 ibm335 kernel: pcic1: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: ppc0 failed to probe at irq 7 on isa0 Jul 15 17:00:51 ibm335 kernel: sc0: at flags 0x100 on isa0 Jul 15 17:00:51 ibm335 kernel: sc0: VGA <16 virtual consoles, flags=0x300> Jul 15 17:00:51 ibm335 kernel: sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) Jul 15 17:00:51 ibm335 kernel: sio0: configured irq 4 not in bitmap of probed irqs 0 Jul 15 17:00:51 ibm335 kernel: sio0: port may not be enabled Jul 15 17:00:51 ibm335 kernel: sio0: irq maps: 0x1 0x1 0x1 0x1 Jul 15 17:00:51 ibm335 kernel: sio0: probe failed test(s): 0 1 2 4 6 7 9 Jul 15 17:00:51 ibm335 kernel: sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 Jul 15 17:00:51 ibm335 kernel: sio0: type 8250 or not responding Jul 15 17:00:51 ibm335 kernel: sio1: configured irq 3 not in bitmap of probed irqs 0 Jul 15 17:00:51 ibm335 kernel: sio1: port may not be enabled Jul 15 17:00:51 ibm335 kernel: sio1: irq maps: 0x1 0x1 0x1 0x1 Jul 15 17:00:51 ibm335 kernel: sio1: probe failed test(s): 0 1 2 4 6 7 9 Jul 15 17:00:51 ibm335 kernel: sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 Jul 15 17:00:51 ibm335 kernel: sio2: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: sio3: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: sn0: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 Jul 15 17:00:51 ibm335 kernel: fb0: vga0, vga, type:VGA (5), flags:0x7007f Jul 15 17:00:51 ibm335 kernel: fb0: port:0x3c0-0x3df, crtc:0x3d4, mem:0xa0000 0x20000 Jul 15 17:00:51 ibm335 kernel: fb0: init mode:24, bios mode:3, current mode:24 Jul 15 17:00:51 ibm335 kernel: fb0: window:0xc00b8000 size:32k gran:32k, buf:0 size:32k Jul 15 17:00:51 ibm335 kernel: VGA parameters upon power-up Jul 15 17:00:51 ibm335 kernel: 50 18 10 00 00 00 03 00 02 67 5f 4f 50 82 55 81 Jul 15 17:00:51 ibm335 kernel: bf 1f 00 4f 0d 0e 00 00 07 80 9c 8e 8f 28 1f 96 Jul 15 17:00:51 ibm335 kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c Jul 15 17:00:51 ibm335 kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff Jul 15 17:00:51 ibm335 kernel: VGA parameters in BIOS for mode 24 Jul 15 17:00:51 ibm335 kernel: 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 Jul 15 17:00:51 ibm335 kernel: bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 Jul 15 17:00:51 ibm335 kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c Jul 15 17:00:51 ibm335 kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff Jul 15 17:00:51 ibm335 kernel: EGA/VGA parameters to be used for mode 24 Jul 15 17:00:51 ibm335 kernel: 50 18 10 00 10 00 03 00 02 67 5f 4f 50 82 55 81 Jul 15 17:00:51 ibm335 kernel: bf 1f 00 4f 0d 0e 00 00 00 00 9c 8e 8f 28 1f 96 Jul 15 17:00:51 ibm335 kernel: b9 a3 ff 00 01 02 03 04 05 14 07 38 39 3a 3b 3c Jul 15 17:00:51 ibm335 kernel: 3d 3e 3f 0c 00 0f 08 00 00 00 00 00 10 0e 00 ff Jul 15 17:00:51 ibm335 kernel: vt0: not probed (disabled) Jul 15 17:00:51 ibm335 kernel: isa_probe_children: probing PnP devices Jul 15 17:00:51 ibm335 kernel: Device configuration finished. Jul 15 17:00:51 ibm335 kernel: Timecounter "TSC" frequency 2392253816 Hz quality 800 Jul 15 17:00:51 ibm335 kernel: Timecounters tick every 10.000 msec Jul 15 17:00:51 ibm335 kernel: DUMMYNET initialized (011031) Jul 15 17:00:51 ibm335 kernel: ipfw2 initialized, divert disabled, rule-based forwarding disabled, default to accept, logging disabled Jul 15 17:00:51 ibm335 kernel: lo0: bpf attached Jul 15 17:00:51 ibm335 kernel: ata1-master: pio=0x0c wdma=0x22 udma=0x42 cable=40pin Jul 15 17:00:51 ibm335 kernel: ata1-master: setting PIO4 on ServerWorks CSB5 chip Jul 15 17:00:51 ibm335 kernel: acd0: CDROM drive at ata1 as master Jul 15 17:00:51 ibm335 kernel: acd0: read 4125KB/s (4125KB/s), 128KB buffer, PIO4 Jul 15 17:00:51 ibm335 kernel: acd0: Reads: CDR, CDRW, CDDA stream, packet Jul 15 17:00:51 ibm335 kernel: acd0: Writes: Jul 15 17:00:51 ibm335 kernel: acd0: Audio: play, 255 volume levels Jul 15 17:00:51 ibm335 kernel: acd0: Mechanism: ejectable tray, unlocked Jul 15 17:00:51 ibm335 kernel: acd0: Medium: no/blank disc Jul 15 17:00:51 ibm335 kernel: Waiting 15 seconds for SCSI devices to settle Jul 15 17:00:51 ibm335 kernel: (probe0:mpt0:0:0:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe0:mpt0:0:0:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe0:mpt0:0:0:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe0:mpt0:0:0:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe1:mpt0:0:1:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe1:mpt0:0:1:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe2:mpt0:0:2:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe2:mpt0:0:2:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe3:mpt0:0:3:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe3:mpt0:0:3:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe4:mpt0:0:4:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe4:mpt0:0:4:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe5:mpt0:0:5:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe5:mpt0:0:5:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe6:mpt0:0:6:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe6:mpt0:0:6:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe8:mpt0:0:9:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe8:mpt0:0:9:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe9:mpt0:0:10:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe9:mpt0:0:10:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe10:mpt0:0:11:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe10:mpt0:0:11:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe11:mpt0:0:12:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe11:mpt0:0:12:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe12:mpt0:0:13:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe12:mpt0:0:13:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe13:mpt0:0:14:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe13:mpt0:0:14:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: (probe14:mpt0:0:15:0): error 22 Jul 15 17:00:51 ibm335 kernel: (probe14:mpt0:0:15:0): Unretryable Error Jul 15 17:00:51 ibm335 kernel: ses0 at mpt0 bus 0 target 8 lun 0 Jul 15 17:00:51 ibm335 kernel: ses0: Fixed Processor SCSI-2 device Jul 15 17:00:51 ibm335 kernel: ses0: Serial Number 1 Jul 15 17:00:51 ibm335 kernel: ses0: 3.300MB/s transfers Jul 15 17:00:51 ibm335 kernel: ses0: SAF-TE Compliant Device Jul 15 17:00:51 ibm335 kernel: pass0 at mpt0 bus 0 target 0 lun 0 Jul 15 17:00:51 ibm335 kernel: pass0: Fixed Direct Access SCSI-2 device Jul 15 17:00:51 ibm335 kernel: pass0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled Jul 15 17:00:51 ibm335 kernel: pass1 at mpt0 bus 0 target 8 lun 0 Jul 15 17:00:51 ibm335 kernel: pass1: Fixed Processor SCSI-2 device Jul 15 17:00:51 ibm335 kernel: pass1: Serial Number 1 Jul 15 17:00:51 ibm335 kernel: pass1: 3.300MB/s transfers Jul 15 17:00:51 ibm335 kernel: da0 at mpt0 bus 0 target 0 lun 0 Jul 15 17:00:51 ibm335 kernel: da0: Fixed Direct Access SCSI-2 device Jul 15 17:00:51 ibm335 kernel: da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled Jul 15 17:00:51 ibm335 kernel: da0: 34702MB (71071561 512 byte sectors: 255H 63S/T 4424C) Jul 15 17:00:51 ibm335 kernel: GEOM: new disk da0 Jul 15 17:00:51 ibm335 kernel: [0] f:80 typ:165 s(CHS):0/1/1 e(CHS):1023/254/63 s:63 l:71071497 Jul 15 17:00:51 ibm335 kernel: [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Jul 15 17:00:51 ibm335 kernel: [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Jul 15 17:00:51 ibm335 kernel: [3] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Jul 15 17:00:51 ibm335 kernel: GEOM: Configure da0s1, start 32256 length 36388606464 end 36388638719 Jul 15 17:00:51 ibm335 kernel: GEOM: Configure da0s1a, start 0 length 268435456 end 268435455 Jul 15 17:00:51 ibm335 kernel: GEOM: Configure da0s1b, start 268435456 length 2147483648 end 2415919103 Jul 15 17:00:51 ibm335 kernel: GEOM: Configure da0s1c, start 0 length 36388606464 end 36388606463 Jul 15 17:00:51 ibm335 kernel: GEOM: Configure da0s1d, start 2415919104 length 1073741824 end 3489660927 Jul 15 17:00:51 ibm335 kernel: GEOM: Configure da0s1e, start 3489660928 length 32898945536 end 36388606463 Jul 15 17:00:51 ibm335 kernel: [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Jul 15 17:00:51 ibm335 kernel: [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Jul 15 17:00:51 ibm335 kernel: [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Jul 15 17:00:51 ibm335 kernel: [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 Jul 15 17:00:51 ibm335 kernel: [0] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Jul 15 17:00:51 ibm335 kernel: [1] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Jul 15 17:00:51 ibm335 kernel: [2] f:00 typ:0 s(CHS):0/0/0 e(CHS):0/0/0 s:0 l:0 Jul 15 17:00:51 ibm335 kernel: [3] f:80 typ:165 s(CHS):0/0/1 e(CHS):1023/254/63 s:0 l:50000 Jul 15 17:00:51 ibm335 kernel: Mounting root from ufs:/dev/da0s1a Jul 15 17:00:51 ibm335 kernel: start_init: trying /sbin/init Jul 15 17:00:53 ibm335 kernel: bge0: gigabit link up Jul 15 17:00:53 ibm335 kernel: bge1: gigabit link up Jul 15 17:00:55 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:00:55 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:00:55 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:00:55 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:00:55 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:00:55 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:00:56 ibm335 kernel: splash: image decoder found: dragon_saver Jul 15 17:00:59 ibm335 kernel: Linux ELF exec handler installed Jul 15 17:01:18 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:18 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:18 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:18 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:18 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:18 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:18 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:18 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:18 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:18 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:18 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:18 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:19 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:19 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:19 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:19 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:19 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:19 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:19 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:19 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:21 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:26 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:48 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:48 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:50 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:50 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:50 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:50 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:50 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:01:50 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:01:56 ibm335 sudo: good : TTY=ttyv0 ; PWD=/usr/home/good ; USER=root ; COMMAND=/bin/bash Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): CAM Status 0x5 Jul 15 17:02:02 ibm335 kernel: (da0:mpt0:0:0:0): Retrying Command -- hang -- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 06:41:30 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD15D16A41C; Tue, 19 Jul 2005 06:41:30 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BFCE43D49; Tue, 19 Jul 2005 06:41:30 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 543D287FF9; Tue, 19 Jul 2005 08:41:29 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14733-02; Tue, 19 Jul 2005 08:41:24 +0200 (CEST) Received: from firewall.demig (p5083995B.dip0.t-ipconnect.de [80.131.153.91]) by server.absolute-media.de (Postfix) with ESMTP id 777E0891DC; Tue, 19 Jul 2005 08:41:24 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j6J6cHE9059790; Tue, 19 Jul 2005 08:38:17 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "Jean Milanez Melo" , , Date: Tue, 19 Jul 2005 09:38:06 +0200 Message-ID: <002e01c58c34$cd5ded00$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 In-Reply-To: <42DBF250.1060405@freebsdbrasil.com.br> Importance: Normal X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: Subject: RE: TinyBSD Call For Testers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 06:41:30 -0000 Hello, thank you for your posting. Can you explain, how it compares to minibsd [https://neon1.net/misc/minibsd.html]? Norbert From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 07:17:32 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3BAF16A423 for ; Tue, 19 Jul 2005 07:17:32 +0000 (GMT) (envelope-from michiel@boland.org) Received: from neerbosch.nijmegen.internl.net (neerbosch.nijmegen.internl.net [217.149.193.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53B9643D46 for ; Tue, 19 Jul 2005 07:17:31 +0000 (GMT) (envelope-from michiel@boland.org) Received: from brakkenstein.nijmegen.internl.net by neerbosch.nijmegen.internl.net via brakkenstein.nijmegen.internl.net [217.149.193.41] with ESMTP for id j6J7HUDv002222 (8.13.2/1.4); Tue, 19 Jul 2005 09:17:30 +0200 (MET DST) Received: from localhost by brakkenstein.nijmegen.internl.net via mboland@localhost with ESMTP for id j6J7HToS008334 (8.13.2/2.02); Tue, 19 Jul 2005 09:17:29 +0200 (MEST) X-Authentication-Warning: brakkenstein.nijmegen.internl.net: mboland owned process doing -bs Date: Tue, 19 Jul 2005 09:17:29 +0200 (MEST) From: Michiel Boland To: freebsd-stable@freebsd.org In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: 5.4-RELEASE-p4: shutdown hangs after rebuiding gmirror X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 07:17:33 -0000 [recap: machine hangs on shutdown - see original message for more details] > Syncing disks, vnodes remaining...1 1 0 1 1 0 0 0 done > No buffers busy after final sync > Uptime: 55m39s > GEOM_MIRROR: Device raid1: provider mirror/raid1 destroyed. > GEOM_MIRROR: Device raid1 destroyed. FWIW the hangs occur regardless of whether I rebuild a mirror. The problem is that the box sometimes hangs and sometimes not. Of course this makes the whole gmirror totally useless (as opposed to a bit of a nuisance) It appears that the hang occurs somewhere between destruction of raid1 and 'raid1.sync'. (whatever that is) Does anyone have any clue as to what is going on or how I can debug this further? Please don't make me put solaris on this box. :) Cheers Michiel From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 09:28:07 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D87716A41C for ; Tue, 19 Jul 2005 09:28:07 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id BE6D043D49 for ; Tue, 19 Jul 2005 09:28:05 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 01CFCA2FDD; Tue, 19 Jul 2005 11:28:04 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id D493D6462; Tue, 19 Jul 2005 11:28:03 +0200 (CEST) Date: Tue, 19 Jul 2005 11:28:03 +0200 From: Marc Olzheim To: Mike Tancsa Message-ID: <20050719092803.GA10127@stack.nl> References: <20050608001306.3FB1F43D5C@mx1.FreeBSD.org> <42A6C7CE.9000002@incubus.de> <200506080908.02478.fcash@ocis.net> <42A71AE1.8020300@incubus.de> <6.2.1.2.0.20050608134054.06b8ccb0@64.7.153.2> <20050608180428.GA42445@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="BXVAT5kNtrzKuDFl" Content-Disposition: inline In-Reply-To: <20050608180428.GA42445@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Matthias Buelow , freebsd-stable@freebsd.org Subject: Re: FreeBSD 5.4: Is it generally unstable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 09:28:07 -0000 --BXVAT5kNtrzKuDFl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 08, 2005 at 08:04:28PM +0200, Marc Olzheim wrote: > > >I remember 5.2.1 panicking left and right, on several machines, it was > > >completely unusable. Maybe we just live in different universes. > >=20 > > Me too, but a lot has changed since 5.2.1 which at the time was I think= was=20 > > called a preview. The topic is 5.4R. What parts of the OS do you feel= are=20 > > not production ready as compared to 4.X ? >=20 > Personnally, when upgrading from 4.x to 5.x, we ran into the following > 3 issues that are still not fixed in 5.4: >=20 > kern/80617: > Hangup writing large blocks to NFS mounted FS (Patches available) > Not exremely important: just don't do that. >=20 > kern/79208: > i387 libm's floorf(), ceilf() and truncf() (Fixed in RELENG_5) > PITA when running threaded calculations. >=20 > kern/78824 > socketpair()/close() race condition (Fixed in CURRENT) > Patch will be MFC'd to RELENG_5 soon. >=20 > Anyway: you won't catch me running an unpatched 5.4 system... I'd say > stick with RELENG_5 for the time being. Since I can't seem to keep any recent RELENG_5 kernel up and running atm. I'd change my viewpoint to run 5.4 and apply all necessary stability patches yourself. I'll prepare a patchset... Marc --BXVAT5kNtrzKuDFl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3MejezjnobFOgrERAlyPAJ9VF3v4Q1qbJx0Ng2M2Kz1H9GAdlQCfcoYM YdcHgY92C3BP5sblSUvFh0s= =zBzG -----END PGP SIGNATURE----- --BXVAT5kNtrzKuDFl-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 09:37:45 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3336216A41C for ; Tue, 19 Jul 2005 09:37:45 +0000 (GMT) (envelope-from freebsd-current@byrnehq.com) Received: from schubert.byrnehq.com (dsl-33-12.dsl.netsource.ie [213.79.33.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E86243D46 for ; Tue, 19 Jul 2005 09:37:44 +0000 (GMT) (envelope-from freebsd-current@byrnehq.com) Received: from localhost (mauer.directski.com. [212.147.140.194]) by schubert.byrnehq.com (8.13.3/8.13.3) with ESMTP id j6JAatpx053689 for ; Tue, 19 Jul 2005 10:36:56 GMT (envelope-from freebsd-current@byrnehq.com) Date: Tue, 19 Jul 2005 10:37:40 +0100 From: Tony Byrne Organization: ByrneHQ X-Priority: 3 (Normal) Message-ID: <151574576.20050719103740@byrnehq.com> To: freebsd-stable@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ByrneHQ-SA-Hits: -1.635 X-Scanned-By: MIMEDefang 2.51 on 192.168.10.254 Subject: ATA Woes. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tony Byrne List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 09:37:45 -0000 Folks, I'm seeing something very unusual on one of our FreeBSD 5.4 Stable boxes which I'm having a hard time getting to the bottom of. You may recall that a few weeks ago I posted regarding a server that was having trouble with WRITE_DMA and READ_DMA timeouts on it's SATA disk. We finally decided to migrate to a new disk, so we purchased a brand new Western Digital 250GB SATA drive and transferred the data across, before removing the old drive. We got about two days of trouble free access to this new disk before it too started throwing READ_DMA problems. This time they were error 40. Running SmartCtl on the disk showed a number of errors and there were specific files on the disk that could not be read. We moved the disk to a desktop box to confirm the problem and noted that fsck couldn't fix the errors on the drive. Assuming a dud drive, we purchased a replacement and this time we spurned SATA in favour of a PATA drive (Western Digital 200GB). We installed the drive yesterday using a brand new UDMA cable. Imagine my surprise when I came in this morning to find that this new drive was also now suffering from UNCORRECTABLE READ_DMA failures and SmartCtl confirmed that the drive wasn't happy. What are the odds of getting two dud disks from two separate batches of drives from, a reputable brand? The server itself is a 1U high rack mount installed in an AC'd machine room. It is powered from a UPS. There is space around the drive and a pair of fans draw air over the drive casing, to the casings are cool to the touch. The motherboard is an Intel S875PWP3 equipped with an Intel ICH5 chipset. Is there any known problem with using WD SATA / PATA disks with FreeBSD 5.4 Stable with the above mainboard? Is it possible that a FreeBSD bug is causing problems with these drives, including the problems reported by SmartCtl? Regards, Tony. -- Tony Byrne From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 09:46:20 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D43416A41C for ; Tue, 19 Jul 2005 09:46:20 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FA0743D4C for ; Tue, 19 Jul 2005 09:46:19 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id B98D1A2FF5; Tue, 19 Jul 2005 11:46:18 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 903DC6462; Tue, 19 Jul 2005 11:46:18 +0200 (CEST) Date: Tue, 19 Jul 2005 11:46:18 +0200 From: Marc Olzheim To: Mike Tancsa Message-ID: <20050719094618.GB10127@stack.nl> References: <20050608001306.3FB1F43D5C@mx1.FreeBSD.org> <42A6C7CE.9000002@incubus.de> <200506080908.02478.fcash@ocis.net> <42A71AE1.8020300@incubus.de> <6.2.1.2.0.20050608134054.06b8ccb0@64.7.153.2> <20050608180428.GA42445@stack.nl> <20050719092803.GA10127@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WYTEVAkct0FjGQmd" Content-Disposition: inline In-Reply-To: <20050719092803.GA10127@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org, Matthias Buelow Subject: Re: FreeBSD 5.4: Is it generally unstable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 09:46:20 -0000 --WYTEVAkct0FjGQmd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2005 at 11:28:03AM +0200, Marc Olzheim wrote: > On Wed, Jun 08, 2005 at 08:04:28PM +0200, Marc Olzheim wrote: > > > >I remember 5.2.1 panicking left and right, on several machines, it w= as > > > >completely unusable. Maybe we just live in different universes. > > >=20 > > > Me too, but a lot has changed since 5.2.1 which at the time was I thi= nk was=20 > > > called a preview. The topic is 5.4R. What parts of the OS do you fe= el are=20 > > > not production ready as compared to 4.X ? > >=20 > > Personnally, when upgrading from 4.x to 5.x, we ran into the following > > 3 issues that are still not fixed in 5.4: > >=20 > > kern/80617: > > Hangup writing large blocks to NFS mounted FS (Patches available) > > Not exremely important: just don't do that. > >=20 > > kern/79208: > > i387 libm's floorf(), ceilf() and truncf() (Fixed in RELENG_5) > > PITA when running threaded calculations. > >=20 > > kern/78824 > > socketpair()/close() race condition (Fixed in CURRENT) > > Patch will be MFC'd to RELENG_5 soon. > >=20 > > Anyway: you won't catch me running an unpatched 5.4 system... I'd say > > stick with RELENG_5 for the time being. >=20 > Since I can't seem to keep any recent RELENG_5 kernel up and running > atm. I'd change my viewpoint to run 5.4 and apply all necessary > stability patches yourself. I'll prepare a patchset... ARGH, nevermind, 5.4-release-p4 crashes on: kern/83375 Fatal trap 12 cloning a pty (Broken in 5.4-7.x) I'll have to revert to 4.10 or 4.11 for our servers, until I can manage to keep a single test machine up and rnuning... :-( Marc --WYTEVAkct0FjGQmd Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3MvqezjnobFOgrERAqyUAJ4kG+amY2u/wB7nG2eHUdzXA9V6fQCfffyM khGhtwRr2w+ZvFR/YNTivEU= =8Q4p -----END PGP SIGNATURE----- --WYTEVAkct0FjGQmd-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 11:51:05 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9686C16A41C; Tue, 19 Jul 2005 11:51:05 +0000 (GMT) (envelope-from matthew@thebunker.net) Received: from male.aldigital.co.uk (male.thebunker.net [213.129.64.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10CEA43D46; Tue, 19 Jul 2005 11:51:04 +0000 (GMT) (envelope-from matthew@thebunker.net) Received: from lack-of-gravitas.thebunker.net (gateway.ash.thebunker.net [213.129.64.4]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by male.aldigital.co.uk (Postfix) with ESMTP id ECA0497746; Tue, 19 Jul 2005 12:51:03 +0100 (BST) Received: from lack-of-gravitas.thebunker.net (localhost [127.0.0.1]) by lack-of-gravitas.thebunker.net (8.13.4/8.13.4) with ESMTP id j6JBp32s012152; Tue, 19 Jul 2005 12:51:03 +0100 (BST) (envelope-from matthew@lack-of-gravitas.thebunker.net) Received: (from matthew@localhost) by lack-of-gravitas.thebunker.net (8.13.4/8.13.4/Submit) id j6JBp2f6012151; Tue, 19 Jul 2005 12:51:02 +0100 (BST) (envelope-from matthew) Date: Tue, 19 Jul 2005 12:51:02 +0100 From: Matthew Seaman To: Robert Watson Message-ID: <20050719115102.GB82554@lack-of-gravitas.thebunker.net> Mail-Followup-To: Robert Watson , freebsd-stable@freebsd.org, Ken Smith References: <1121099976.62346.48.camel@opus.cse.buffalo.edu> <20050711215527.D29110@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aM3YZ0Iwxop3KEKx" Content-Disposition: inline In-Reply-To: <20050711215527.D29110@fledge.watson.org> User-Agent: Mutt/1.5.9i Cc: Ken Smith , freebsd-stable@FreeBSD.org Subject: Re: FYI - RELENG_6 branch has been created. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 11:51:05 -0000 --aM3YZ0Iwxop3KEKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2005 at 10:04:36PM +0100, Robert Watson wrote: >=20 > On Mon, 11 Jul 2005, Ken Smith wrote: >=20 > >Just a quick note to say that as part of the FreeBSD-6.0 Release Cycle= =20 > >the RELENG_6 branch tag has just been created in the CVS repository.=20 > >In preparation for the release some places in the tree now say that this= =20 > >branch is -STABLE but there is still work to do before this branch will= =20 > >be ready for release. People who are not in a position to help work out= =20 > >the remaining bugs in the RELENG_6 branch as we work towards the=20 > >FreeBSD-6.0 Release should definitely continue using RELENG_5_4 or=20 > >RELENG_5 as appropriate. >=20 > As a further FYI, a variety of debugging features are still enabled by=20 > default in RELENG_6, including INVARINTS, WITNESS, and user space malloc= =20 > debugging. These will remain enabled through the first snapshot from the= =20 > release candidate series in order to assist in debugging problems.=20 > However, anyone running RELENG_6 until that time should be aware that=20 > these debugging features result in a loss of 1/2 or more performance for= =20 > many common workloads. Depending on workload and hardware, this might or= =20 > might not present a problem for your environment -- the features are=20 > invaluable in diagnosing problems, however, so if it's possible to leave= =20 > them on in testing, that would be useful. Obviously, tesing without them= =20 > is also desired, as they significantly perturb timing, but the first=20 > question you'll get is "can you reproduce them with debugging features=20 > enabled?" :-). It's a trivial thing, I know, but is there any chance of someone committing the following to RELENG_6? lack-of-gravitas:/usr/src:% diff -u share/examples/cvsup/stable-supfile{.or= ig,} --- share/examples/cvsup/stable-supfile.orig Tue Jul 19 12:40:25 2005 +++ share/examples/cvsup/stable-supfile Tue Jul 19 12:41:40 2005 @@ -68,9 +68,10 @@ *default host=3DCHANGE_THIS.FreeBSD.org *default base=3D/var/db *default prefix=3D/usr -# The following line is for 5-stable. If you want 4-stable, 3-stable, or -# 2.2-stable, change to "RELENG_4", "RELENG_3", or "RELENG_2_2" respectiv= ely. -*default release=3Dcvs tag=3DRELENG_5 +# The following line is for 6-stable. If you want 5-stable, 4-stable, +# 3-stable, or 2.2-stable, change to "RELENG_5", "RELENG_4", +# "RELENG_3", or "RELENG_2_2" respectively. +*default release=3Dcvs tag=3DRELENG_6 *default delete use-rel-suffix =20 # If you seem to be limited by CPU rather than network or disk bandwidth, = try Cheers, Matthew --=20 Dr Matthew J Seaman MA, D.Phil. 8 Dane Court Manor School Rd PGP: http://www.infracaninophile.co.uk/pgpkey Tilmanstone Tel: +44 1304 617253 Kent, CT14 0JL UK --aM3YZ0Iwxop3KEKx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iQCVAwUBQtzpJpr7OpndfbmCAQJDNwP+LJxthSMqbceBp01dQjUkJO348lOusaPG a2wlmEDaozmzqsVttLAFtDh9zGDLoDTdbDjnFipshoLXbw2R8/mPrSdnLW9KxoAk eji+BitNMpRrDNl+hEFDMCEsvEJn0XGVFW17kjmmrpwR340CFzy3EgVjSWNjE/bO WA03AiwZHvg= =xBI0 -----END PGP SIGNATURE----- --aM3YZ0Iwxop3KEKx-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 11:53:16 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91A0A16A41C for ; Tue, 19 Jul 2005 11:53:16 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB67743D48 for ; Tue, 19 Jul 2005 11:53:15 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 48ECFA2FC9; Tue, 19 Jul 2005 13:53:14 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 2691C6462; Tue, 19 Jul 2005 13:53:14 +0200 (CEST) Date: Tue, 19 Jul 2005 13:53:14 +0200 From: Marc Olzheim To: Kris Kennaway Message-ID: <20050719115314.GD11846@stack.nl> References: <20050711143216.GA25523@stack.nl> <20050713092939.GA65261@stack.nl> <20050713120030.GB23629@xor.obsecurity.org> <20050713125522.GA62977@stack.nl> <20050713184118.GD42067@xor.obsecurity.org> <20050714130520.GB26456@stack.nl> <20050714174403.GC19081@xor.obsecurity.org> <20050715094027.GA35516@stack.nl> <20050715100539.GC35516@stack.nl> <20050715120522.GA20426@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0vzXIDBeUiKkjNJl" Content-Disposition: inline In-Reply-To: <20050715120522.GA20426@xor.obsecurity.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , freebsd-stable@freebsd.org Subject: Re: Today's RELENG_5_4 and 'lock cmpxchgl' X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 11:53:16 -0000 --0vzXIDBeUiKkjNJl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 15, 2005 at 08:05:23AM -0400, Kris Kennaway wrote: > > Ok, even non-SMP 7-CURRENT crashes on it, so I do not believe that I'm > > the only one seeing this... >=20 > You're not..as noted, it's been widely reported. Could you give me any pointers to where this has been discussed before ? Would placing all of the ptsopen() and ptcclose() code under a giant lock help ? Or is the problem somewhere else ? Marc --0vzXIDBeUiKkjNJl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3OmpezjnobFOgrERAseGAJwIawEnAd302ssPRdjjEMw8CkHLbQCfWXlP wGM07g6ObC72lxE9tEH/Y2c= =ZJwG -----END PGP SIGNATURE----- --0vzXIDBeUiKkjNJl-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 12:18:20 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2471716A41F for ; Tue, 19 Jul 2005 12:18:20 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 55EDE43D55 for ; Tue, 19 Jul 2005 12:18:19 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 7BFE5A3017; Tue, 19 Jul 2005 14:18:18 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 689D66462; Tue, 19 Jul 2005 14:18:18 +0200 (CEST) Date: Tue, 19 Jul 2005 14:18:18 +0200 From: Marc Olzheim To: Kris Kennaway Message-ID: <20050719121818.GA12675@stack.nl> References: <20050713092939.GA65261@stack.nl> <20050713120030.GB23629@xor.obsecurity.org> <20050713125522.GA62977@stack.nl> <20050713184118.GD42067@xor.obsecurity.org> <20050714130520.GB26456@stack.nl> <20050714174403.GC19081@xor.obsecurity.org> <20050715094027.GA35516@stack.nl> <20050715100539.GC35516@stack.nl> <20050715120522.GA20426@xor.obsecurity.org> <20050719115314.GD11846@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="KsGdsel6WgEHnImy" Content-Disposition: inline In-Reply-To: <20050719115314.GD11846@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , freebsd-stable@freebsd.org Subject: Re: Today's RELENG_5_4 and 'lock cmpxchgl' X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 12:18:20 -0000 --KsGdsel6WgEHnImy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2005 at 01:53:14PM +0200, Marc Olzheim wrote: > On Fri, Jul 15, 2005 at 08:05:23AM -0400, Kris Kennaway wrote: > > > Ok, even non-SMP 7-CURRENT crashes on it, so I do not believe that I'm > > > the only one seeing this... > >=20 > > You're not..as noted, it's been widely reported. >=20 > Could you give me any pointers to where this has been discussed before ? >=20 > Would placing all of the ptsopen() and ptcclose() code under a giant > lock help ? Or is the problem somewhere else ? Ah, nevermind, it already operates under GIANT, so something else is molesting the tty's t_line array. Perhaps some kind of use after free issue ? Marc --KsGdsel6WgEHnImy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3O+KezjnobFOgrERAiqIAJ0XzHedDZcmFDO0nfVbHdzagms6AQCfeUFV 5l8euKGfKud0PdyA0BfTDL4= =wim3 -----END PGP SIGNATURE----- --KsGdsel6WgEHnImy-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 12:21:22 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9625916A41F for ; Tue, 19 Jul 2005 12:21:22 +0000 (GMT) (envelope-from freebsd@byrnehq.com) Received: from schubert.byrnehq.com (dsl-33-12.dsl.netsource.ie [213.79.33.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id D647343D46 for ; Tue, 19 Jul 2005 12:21:21 +0000 (GMT) (envelope-from freebsd@byrnehq.com) Received: from localhost (mauer.directski.com. [212.147.140.194]) by schubert.byrnehq.com (8.13.3/8.13.3) with ESMTP id j6JDKYvZ053982 for ; Tue, 19 Jul 2005 13:20:35 GMT (envelope-from freebsd@byrnehq.com) Date: Tue, 19 Jul 2005 13:21:19 +0100 From: Tony Byrne Organization: ByrneHQ X-Priority: 3 (Normal) Message-ID: <1591154927.20050719132119@byrnehq.com> To: freebsd-stable@freebsd.org In-Reply-To: <151574576.20050719103740@byrnehq.com> References: <151574576.20050719103740@byrnehq.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ByrneHQ-SA-Hits: -1.635 X-Scanned-By: MIMEDefang 2.51 on 192.168.10.254 Subject: Re: ATA Woes. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tony Byrne List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 12:21:22 -0000 Hello Tony, Tuesday, July 19, 2005, 10:37:40 AM, you wrote: TB> Folks, TB> I'm seeing something very unusual on one of our FreeBSD 5.4 Stable TB> boxes which I'm having a hard time getting to the bottom of. Further information from my server logs: Jul 19 13:01:48 roo kernel: ad0: FAILURE - READ_DMA status=51 error=40 LBA=288810495 Jul 19 13:01:59 roo kernel: ad0: FAILURE - READ_DMA status=51 error=1 LBA=288810495 Jul 19 13:02:05 roo kernel: ad0: FAILURE - READ_DMA status=51 error=40 LBA=288810495 Jul 19 13:02:16 roo kernel: ad0: FAILURE - READ_DMA status=51 error=40 LBA=288810495 Jul 19 13:04:36 roo last message repeated 4 times With this disk it appears to be the same LBA each time. How can I translate that LBA offset into something indicating the file affected? I installed the *other* disk into a Windows box an ran the Western Digital Drive Tools SMART test on it. It found some sectors needing reallocation and successfully performed the reallocation. The tests (both short and long) now pass, but the drive's SMART Status remains at 'fail'. When I examine the attributes, the Raw Read Error Rate is flagged. I'm totally confused. I don't know enough about SMART to know whether I'm looking at real failing drives or some bug exposed by the interaction between drive firmware, hd controller and FreeBSD. Regards, Tony. -- Tony Byrne From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 12:42:49 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8AE8516A420 for ; Tue, 19 Jul 2005 12:42:49 +0000 (GMT) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id C4E4B43D46 for ; Tue, 19 Jul 2005 12:42:47 +0000 (GMT) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 82681 invoked by uid 0); 19 Jul 2005 09:42:46 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (uvscan: v4.3.20/v4537. spamassassin: 2.64. Clear:RC:1(201.17.165.147):. Processed in 0.437064 secs); 19 Jul 2005 12:42:46 -0000 Received: from unknown (HELO ?10.69.69.69?) (201.17.165.147) by capeta.freebsdbrasil.com.br with SMTP; 19 Jul 2005 09:42:46 -0300 Message-ID: <42DCF541.6070703@freebsdbrasil.com.br> Date: Tue, 19 Jul 2005 09:42:41 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050420 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Norbert Koch References: <002e01c58c34$cd5ded00$4801a8c0@ws-ew-3.W2KDEMIG> In-Reply-To: <002e01c58c34$cd5ded00$4801a8c0@ws-ew-3.W2KDEMIG> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, small@freebsd.org Subject: Re: TinyBSD Call For Testers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 12:42:49 -0000 Norbert Koch wrote: > Hello, > > thank you for your posting. > Can you explain, how it compares to minibsd > [https://neon1.net/misc/minibsd.html]? > > Norbert It is similar to minibsd in the "copy" proccess, but different in the configuration and image creation stages. TinyBSD does not heavily depend on chroot enviroment, it works directly in a "work" directory, where files copying, kernel build and hier(7) definitions are used in such an usual FreeBSD building enviroment, including mtree definitions in /etc/mtree/, using "make DESTDIR" and "make DISTRIBUTION" whenever it is possible. In fact it is pretty much closer to NanoBSD in the whole proccess, while only similar to minibsd in the "copy" idea. -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 sip://316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 13:24:51 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.ORG Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E1AC16A421 for ; Tue, 19 Jul 2005 13:24:51 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (lurza.secnetix.de [83.120.8.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4074743D4C for ; Tue, 19 Jul 2005 13:24:50 +0000 (GMT) (envelope-from olli@lurza.secnetix.de) Received: from lurza.secnetix.de (liforg@localhost [127.0.0.1]) by lurza.secnetix.de (8.13.1/8.13.1) with ESMTP id j6JDOlqG060004 for ; Tue, 19 Jul 2005 15:24:48 +0200 (CEST) (envelope-from oliver.fromme@secnetix.de) Received: (from olli@localhost) by lurza.secnetix.de (8.13.1/8.13.1/Submit) id j6JDOlMC060003; Tue, 19 Jul 2005 15:24:47 +0200 (CEST) (envelope-from olli) Date: Tue, 19 Jul 2005 15:24:47 +0200 (CEST) Message-Id: <200507191324.j6JDOlMC060003@lurza.secnetix.de> From: Oliver Fromme To: freebsd-stable@FreeBSD.ORG In-Reply-To: <1121703804.4401.0.camel@pyanfar.ece.cmu.edu> X-Newsgroups: list.freebsd-stable User-Agent: tin/1.5.4-20000523 ("1959") (UNIX) (FreeBSD/4.11-RELEASE (i386)) Cc: Subject: Re: cua*x naming? [Was: Re: FreeBSD 6.0-BETA1 Available] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-stable@FreeBSD.ORG List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 13:24:51 -0000 Brandon S. Allbery KF8NH wrote: > On Mon, 2005-07-18 at 18:18 +0200, Emanuel Strobl wrote: > > Am Sonntag, 17. Juli 2005 21:12 CEST schrieb Robert Watson: > > > (2) /dev/cuaa* has been renamed to /dev/cuad* > > > > I saw that cuaa got cuad and ucom0 got cuaU0. Now what is the meaning of > > cua? tty AFAIK is TeleTYpe... > > Call(-out) Unit Access, IIRC. Yes. I remember that some systems (Solaris) used the term ACU for "automatic call unit", which just means a modem. I've also seen interpretations saying that "cua" is related to UART (universal asynchronous receiver/transmitter), which is the basic function description of a serial controller. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co KG, Marktplatz 29, 85567 Grafing Any opinions expressed in this message may be personal to the author and may not necessarily reflect the opinions of secnetix in any way. "... there are two ways of constructing a software design: One way is to make it so simple that there are _obviously_ no deficiencies and the other way is to make it so complicated that there are no _obvious_ deficiencies." -- C.A.R. Hoare, ACM Turing Award Lecture, 1980 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 14:13:09 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CD1416A41F for ; Tue, 19 Jul 2005 14:13:09 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EE0643D45 for ; Tue, 19 Jul 2005 14:13:08 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 978EBA301C; Tue, 19 Jul 2005 16:13:02 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 755266462; Tue, 19 Jul 2005 16:13:02 +0200 (CEST) Date: Tue, 19 Jul 2005 16:13:02 +0200 From: Marc Olzheim To: Mike Tancsa Message-ID: <20050719141302.GB12675@stack.nl> References: <20050608001306.3FB1F43D5C@mx1.FreeBSD.org> <42A6C7CE.9000002@incubus.de> <200506080908.02478.fcash@ocis.net> <42A71AE1.8020300@incubus.de> <6.2.1.2.0.20050608134054.06b8ccb0@64.7.153.2> <20050608180428.GA42445@stack.nl> <20050719092803.GA10127@stack.nl> <20050719094618.GB10127@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ftEhullJWpWg/VHq" Content-Disposition: inline In-Reply-To: <20050719094618.GB10127@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Matthias Buelow , freebsd-stable@freebsd.org Subject: Re: FreeBSD 5.4: Is it generally unstable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 14:13:09 -0000 --ftEhullJWpWg/VHq Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jul 19, 2005 at 11:46:18AM +0200, Marc Olzheim wrote: > > Since I can't seem to keep any recent RELENG_5 kernel up and running > > atm. I'd change my viewpoint to run 5.4 and apply all necessary > > stability patches yourself. I'll prepare a patchset... >=20 > ARGH, nevermind, 5.4-release-p4 crashes on: >=20 > kern/83375 > Fatal trap 12 cloning a pty (Broken in 5.4-7.x) I put a list of my issues with FreeBSD 5.4 together: http://www.ipv4.stack.nl/~marcolz/FreeBSD/showstoppers.html Marc --ftEhullJWpWg/VHq Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3QpuezjnobFOgrERAn1fAJ0U7Drv31xXp000eMVL8H6Zfq1MeQCfdl4X 8aX63ZPdzZgX2ByFK6u2Sgo= =tZiJ -----END PGP SIGNATURE----- --ftEhullJWpWg/VHq-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 14:17:29 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B07AE16A41F for ; Tue, 19 Jul 2005 14:17:29 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67D8C43D4C for ; Tue, 19 Jul 2005 14:17:27 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.7.103] (host-103.int.kcilink.com [192.168.7.103]) by yertle.kcilink.com (Postfix) with ESMTP id 1EEE1B833 for ; Tue, 19 Jul 2005 10:17:26 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Vivek Khera Date: Tue, 19 Jul 2005 10:17:24 -0400 To: freebsd-stable@freebsd.org X-Mailer: Apple Mail (2.733) Subject: Re: FreeBSD -STABLE servers repeatedly crashing. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 14:17:29 -0000 On Jul 18, 2005, at 5:39 PM, Gary Mulder wrote: > Another person on the freebsd-amd64 list reported similar network- > related > crashes until he switched to em (Intel Gigabit Ethernet) NICs. > that was probably me... but I don't have any firewall on these boxes as they are not hooked up to the internet -- just internal back-end DB servers. Vivek Khera, Ph.D. +1-301-869-4449 x806 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 15:06:32 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C938F16A41F for ; Tue, 19 Jul 2005 15:06:32 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7917E43D45 for ; Tue, 19 Jul 2005 15:06:32 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id j6JF6VoS052942 for ; Tue, 19 Jul 2005 08:06:31 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id j6JF6VHu052941 for freebsd-stable@freebsd.org; Tue, 19 Jul 2005 08:06:31 -0700 (PDT) (envelope-from david) Date: Tue, 19 Jul 2005 08:06:31 -0700 From: David Wolfskill To: freebsd-stable@freebsd.org Message-ID: <20050719150631.GM26920@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , freebsd-stable@freebsd.org References: <1121703804.4401.0.camel@pyanfar.ece.cmu.edu> <200507191324.j6JDOlMC060003@lurza.secnetix.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507191324.j6JDOlMC060003@lurza.secnetix.de> User-Agent: Mutt/1.4.2.1i Subject: Re: cua*x naming? [Was: Re: FreeBSD 6.0-BETA1 Available] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 15:06:32 -0000 On Tue, Jul 19, 2005 at 03:24:47PM +0200, Oliver Fromme wrote: > Brandon S. Allbery KF8NH wrote: > > On Mon, 2005-07-18 at 18:18 +0200, Emanuel Strobl wrote: > > > Am Sonntag, 17. Juli 2005 21:12 CEST schrieb Robert Watson: > > > > (2) /dev/cuaa* has been renamed to /dev/cuad* > > > > > > I saw that cuaa got cuad and ucom0 got cuaU0. Now what is the meaning of > > > cua? tty AFAIK is TeleTYpe... > > > > Call(-out) Unit Access, IIRC. > > Yes. I remember that some systems (Solaris) used the term > ACU for "automatic call unit", which just means a modem. Actually, Way Back When, ACUs and MODEMs were separate boxen. :-} Peace, david (who did work at an installation that had them, ca. 1976) -- David H. Wolfskill david@catwhisker.org Any given sequence of letters is a misspelling of a great many English words. See http://www.catwhisker.org/~david/publickey.gpg for public key. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 15:34:26 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8172816A41F for ; Tue, 19 Jul 2005 15:34:26 +0000 (GMT) (envelope-from patfbsds@davenulle.org) Received: from smtp.lamaiziere.net (lamaiziere.net [213.41.172.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 049DC43D45 for ; Tue, 19 Jul 2005 15:34:25 +0000 (GMT) (envelope-from patfbsds@davenulle.org) Received: from localhost (unknown [192.168.1.2]) by smtp.lamaiziere.net (Postfix) with ESMTP id C2FF226D1D2 for ; Tue, 19 Jul 2005 17:34:23 +0200 (CEST) Received: from smtp.lamaiziere.net ([192.168.1.2]) by localhost (malpractice-12.lamaiziere.net [192.168.1.2]) (amavisd-new, port 10024) with ESMTP id 94126-03 for ; Tue, 19 Jul 2005 17:34:22 +0200 (CEST) Received: from feelgood (unknown [192.168.0.1]) by smtp.lamaiziere.net (Postfix) with ESMTP id 14DC526D156 for ; Tue, 19 Jul 2005 17:34:22 +0200 (CEST) From: Patrick =?iso-8859-1?q?Lamaizi=E8re?= Organization: >dave/nulle To: freebsd-stable@freebsd.org Date: Tue, 19 Jul 2005 17:34:21 +0200 User-Agent: KMail/1.8.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200507191734.21553.patfbsds@davenulle.org> X-Virus-Scanned: by amavisd-new at lamaiziere.net Subject: Re: RELENG_6 has problems with booting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 15:34:26 -0000 Le Lundi 18 Juillet 2005 10:50, Jonathan Weiss a écrit : Hi, > When I do a boot in safe mode, everything is ok. > > Attachted is the dmesg from the verbose boot. Did you try without acpi ? I've got a similar problem with a nforce2 based mother board. Regards. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 16:28:06 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 54B5916A41F for ; Tue, 19 Jul 2005 16:28:06 +0000 (GMT) (envelope-from shock@cs.ucr.edu) Received: from barrichello.cs.ucr.edu (barrichello.cs.ucr.edu [138.23.169.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CA9643D53 for ; Tue, 19 Jul 2005 16:28:06 +0000 (GMT) (envelope-from shock@cs.ucr.edu) Received: from localhost (localhost.localdomain [127.0.0.1]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id 08E8B1240F4; Tue, 19 Jul 2005 15:59:17 +0000 (America/Los_Angeles) Received: from barrichello.cs.ucr.edu ([127.0.0.1]) by localhost (barrichello.cs.ucr.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14137-03; Tue, 19 Jul 2005 08:59:11 -0700 (PDT) Received: from [10.10.238.88] (wg03.ucr.edu [138.23.2.196]) by barrichello.cs.ucr.edu (Postfix) with ESMTP id E7BB3124078; Tue, 19 Jul 2005 15:59:10 +0000 (America/Los_Angeles) In-Reply-To: <63c3899e05070909363077ca9c@mail.gmail.com> References: <63c3899e05070807487e0891de@mail.gmail.com> <20050708233854.GA64117@ratchet.nebcorp.com> <63c3899e05070909363077ca9c@mail.gmail.com> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Stephen Hock Date: Tue, 19 Jul 2005 09:27:58 -0700 To: Chris Hodgins X-Mailer: Apple Mail (2.733) X-Virus-Scanned: amavisd-new at cs.ucr.edu Cc: freebsd-stable@freebsd.org Subject: Re: gmirror, sparc and SCSI problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 16:28:06 -0000 On Jul 9, 2005, at 9:36 AM, Chris Hodgins wrote: > Danny, > > Thanks for the link. This was actually the first link we tried to get > working and after it failed to work we followed the link on the page > to http://people.freebsd.org/~rse/mirror/. > > Everything worked fine until we arrived at this step below. > # mount /dev/mirror/gm0s1a /mnt > > It seems that gmirror does not give us any partitions. A listing of > the mirror directory shows only the gm0 node even though da0 is > partitioned. When mounting the mirror it seems that /dev/mirror/gm0 > only represents the root partition. How can we get the mirror to > recognise the other partitions? > > Thanks > Chris > _______________________________________________ > Chris, Based on my experience, it doesn't work to partition the underlying disk device da0, but rather the mirror device gm0. I've had a lot of success writing out new labels with # bsdlabel -w /dev/mirror/gm0 # bsdlabel -e /dev/mirror/gm0 Editing the partition table by hand is a bummer, but for now, since mirror devices don't show up in fdisk/disklabel tools in /stand/ sysinstall, this is the only way I know of to do it. -Stephen From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 17:03:24 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C9F2F16A41F for ; Tue, 19 Jul 2005 17:03:24 +0000 (GMT) (envelope-from pavel@ctk.ru) Received: from zeus.nordnet.ru (ns.ctk.ru [213.150.64.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF7A543D46 for ; Tue, 19 Jul 2005 17:03:21 +0000 (GMT) (envelope-from pavel@ctk.ru) Received: from zeus.nordnet.ru (localhost [127.0.0.1]) by zeus.nordnet.ru (Postfix) with SMTP id A3E95136849 for ; Tue, 19 Jul 2005 21:03:19 +0400 (MSD) Received: from crasotin.nordnet-local.ru (crasotin.office.ctk.ru [10.41.0.29]) by zeus.nordnet.ru (Postfix) with ESMTP id 64317136848 for ; Tue, 19 Jul 2005 21:03:19 +0400 (MSD) Date: Tue, 19 Jul 2005 21:03:09 +0400 From: Pavel A Crasotin X-Mailer: The Bat! (v3.5) Professional Organization: OJSC SeverTransCom X-Priority: 3 (Normal) Message-ID: <81030364.20050719210309@ctk.ru> To: stable@freebsd.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----------C6149F81B4029D2" X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.2/RELEASE, bases: 19072005 #130940, status: notchecked Cc: Subject: Perl 5.8.7 dumps core on quotewords X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 17:03:24 -0000 ------------C6149F81B4029D2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello - I've just installed perl5.8.7 and now my cricket 1.0.5 does not work correctly. Perl abnormally exits with 'Bus error' message and throws core. After little investigation I have found out the problem is in Text::ParseWords::quotewords procedure. Test perl script which produces error is attached. If it's neccesary i will send the core file of perl. It dumps core with # perl -V Summary of my perl5 (revision 5 version 8 subversion 7) configuration: Platform: osname=freebsd, osvers=5.4-stable, archname=i386-freebsd-64int uname='freebsd zeus.nordnet.ru 5.4-stable freebsd 5.4-stable #1: sat may 14 12:26:53 msd 2005 root@zeus.nordnet.ru:usrobjusrsrcsyszeus i386 ' config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.8.7/mach -Dprivlib=/usr/local/lib/perl5/5.8.7 -Dman3dir=/usr/local/lib/perl5/5.8.7/perl/man/man3 -Dman1dir=/usr/local/man/man1 -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.7/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.8.7 -Dscriptdir=/usr/local/bin -Dsiteman3dir=/usr/local/lib/perl5/5.8.7/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dcc=cc -Duseshrplib -Dccflags=-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.7/BSDPAN" -Doptimize=-O -pipe -march=pentiumpro -Ud_dosuid -Ui_gdbm -Dusethreads=n -Dusemymalloc=y -Duse64bitint' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.7/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include', optimize='-O -pipe -march=pentiumpro', cppflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.7/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.4.2 [FreeBSD] 20040728', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags ='-pthread -Wl,-E -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lm -lcrypt -lutil perllibs=-lm -lcrypt -lutil libc=, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-R/usr/local/lib/perl5/5.8.7/mach/CORE' cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_64_BIT_INT USE_LARGE_FILES Locally applied patches: defined-or Built under freebsd Compiled at Jul 19 2005 10:23:40 @INC: /usr/local/lib/perl5/site_perl/5.8.7/mach /usr/local/lib/perl5/site_perl/5.8.7 /usr/local/lib/perl5/site_perl/5.8.6 /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.8.7/BSDPAN /usr/local/lib/perl5/5.8.7/mach /usr/local/lib/perl5/5.8.7 . But works good with # perl -V Summary of my perl5 (revision 5 version 8 subversion 6) configuration: Platform: osname=freebsd, osvers=5.4-release, archname=i386-freebsd-64int uname='freebsd freebsd.org 5.4-release freebsd 5.4-release #0: sun apr 3 15:13:31 pdt 2005 kris@freebsd.org:usrsrcsysmagickernelpath i386 ' config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.8.6/mach -Dprivlib=/usr/local/lib/perl5/5.8.6 -Dman3dir=/usr/local/lib/perl5/5.8.6/perl/man/man3 -Dman1dir=/usr/local/man/man1 -Dsitearch=/usr/local/lib/perl5/site_perl/5.8.6/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.8.6 -Dscriptdir=/usr/local/bin -Dsiteman3dir=/usr/local/lib/perl5/5.8.6/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Ui_malloc -Ui_iconv -Uinstallusrbinperl -Dcc=cc -Doptimize=-O -pipe -Duseshrplib -Dccflags=-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.6/BSDPAN" -Ud_dosuid -Ui_gdbm -Dusethreads=n -Dusemymalloc=y -Duse64bitint' hint=recommended, useposix=true, d_sigaction=define usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef useperlio=define d_sfio=undef uselargefiles=define usesocks=undef use64bitint=define use64bitall=undef uselongdouble=undef usemymalloc=y, bincompat5005=undef Compiler: cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.6/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include', optimize='-O -pipe ', cppflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.6/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -I/usr/local/include' ccversion='', gccversion='3.4.2 [FreeBSD] 20040728', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=12345678 d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12 ivtype='long long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8 alignbytes=4, prototype=define Linker and Libraries: ld='cc', ldflags =' -Wl,-E -L/usr/local/lib' libpth=/usr/lib /usr/local/lib libs=-lm -lcrypt -lutil perllibs=-lm -lcrypt -lutil libc=, so=so, useshrplib=true, libperl=libperl.so gnulibc_version='' Dynamic Linking: dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' -Wl,-R/usr/local/lib/perl5/5.8.6/mach/CORE' cccdlflags='-DPIC -fPIC', lddlflags='-shared -L/usr/local/lib' Characteristics of this binary (from libperl): Compile-time options: USE_64_BIT_INT USE_LARGE_FILES Locally applied patches: SUIDPERLIO0 - fix PERLIO_DEBUG local root exploit (CAN-2005-0155) SUIDPERLIO1 - fix PERLIO_DEBUG buffer overflow (CAN-2005-0156) Built under freebsd Compiled at Apr 3 2005 22:17:29 @INC: /usr/local/lib/perl5/site_perl/5.8.6/mach /usr/local/lib/perl5/site_perl/5.8.6 /usr/local/lib/perl5/site_perl /usr/local/lib/perl5/5.8.6/BSDPAN /usr/local/lib/perl5/5.8.6/mach /usr/local/lib/perl5/5.8.6 . Can anyone help me fix this problem? -- With respect, Pavel A Crasotin OJSC SeverTransCom Tel: +7 (0852) 58-41-03, 58-01-01 Fax: +7 (0852) 58-01-01 ------------C6149F81B4029D2 Content-Type: application/octet-stream; name="test_quotawords.pl" Content-transfer-encoding: base64 Content-Disposition: attachment; filename="test_quotawords.pl" IyEvdXNyL2Jpbi9wZXJsCgp1c2Ugc3RyaWN0Owp1c2UgVGV4dDo6UGFyc2VXb3JkczsKCm15 ICR0ZXN0X3N0cmluZyA9IDw8RU9UOwp0YXJnZXQgIGFsbAogICAgICAgIHRhcmdldHMgICAg ICAgICA9ICIvcm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTgwNi04MDIt MXE7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1m YXN0ZXRoZXJuZXQwLTEtOTE4LTgwMi0xcTsKICAgICAgICAgICAgICAgICAgICAgICAgICAg L3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS04MDQtODAyLTFxOwogICAg ICAgICAgICAgICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVy bmV0MC0xLTYxNi04MDItMXE7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJz L2xpbmtzL240MS1yMS1mYXN0ZXRoZXJuZXQwLTEtNzA0LTgwMi0xcTsKICAgICAgICAgICAg ICAgICAgICAgICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS05 MTYtODAyLTFxOwogICAgICAgICAgICAgICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9u NDEtcjEtZmFzdGV0aGVybmV0MC0xLTQzOS04MDItMXE7CiAgICAgICAgICAgICAgICAgICAg ICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRoZXJuZXQwLTEtOTE5LTgwMi0x cTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZh c3RldGhlcm5ldDAtMS04MDEtODAyLTFxOwogICAgICAgICAgICAgICAgICAgICAgICAgICAv cm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTgwMi04MDItMXE7CiAgICAg ICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRoZXJu ZXQwLTEtNDQ0LTgwMi0xcTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgL3JvdXRlcnMv bGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS05MTQtODAyLTFxOwogICAgICAgICAgICAg ICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTgx MC04MDItMXE7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240 MS1yMS1mYXN0ZXRoZXJuZXQwLTEtNDM1LTgwMi0xcTsKICAgICAgICAgICAgICAgICAgICAg ICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS02MjItODAyLTFx OwogICAgICAgICAgICAgICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFz dGV0aGVybmV0MC0xLTgwNy04MDItMXE7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC9y b3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRoZXJuZXQwLTEtNDIyLTgwMi0xcTsKICAgICAg ICAgICAgICAgICAgICAgICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5l dDAtMS05MTUtODAyLTFxOwogICAgICAgICAgICAgICAgICAgICAgICAgICAvcm91dGVycy9s aW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTQxMi04MDItMXE7CiAgICAgICAgICAgICAg ICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRoZXJuZXQwLTEtNDE5 LTgwMi0xcTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgL3JvdXRlcnMvbGlua3MvbjQx LXIxLWZhc3RldGhlcm5ldDAtMS00MzctODAyLTFxOwogICAgICAgICAgICAgICAgICAgICAg ICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTQyNC04MDItMXE7 CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0 ZXRoZXJuZXQwLTEtNDE1LTgwMi0xcTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgL3Jv dXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS04MDgtODAyLTFxOwogICAgICAg ICAgICAgICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0 MC0xLTkwNS04MDItMXE7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xp bmtzL240MS1yMS1mYXN0ZXRoZXJuZXQwLTEtNDI3LTgwMi0xcTsKICAgICAgICAgICAgICAg ICAgICAgICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS00MzIt ODAyLTFxOwogICAgICAgICAgICAgICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9uNDEt cjEtZmFzdGV0aGVybmV0MC0xLTkwMi04MDItMXE7CiAgICAgICAgICAgICAgICAgICAgICAg ICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRoZXJuZXQwLTEtOTExLTgwMi0xcTsK ICAgICAgICAgICAgICAgICAgICAgICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3Rl dGhlcm5ldDAtMS00MjAtODAyLTFxOwogICAgICAgICAgICAgICAgICAgICAgICAgICAvcm91 dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTgwNS04MDItMXE7CiAgICAgICAg ICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRoZXJuZXQw LTEtNjE5LTgwMi0xcTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgL3JvdXRlcnMvbGlu a3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS00NDItODAyLTFxOwogICAgICAgICAgICAgICAg ICAgICAgICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTQxMC04 MDItMXE7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1y MS1mYXN0ZXRoZXJuZXQwLTEtODA5LTgwMi0xcTsKICAgICAgICAgICAgICAgICAgICAgICAg ICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS05MTctODAyLTFxOwog ICAgICAgICAgICAgICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0 aGVybmV0MC0xLTkxMi04MDItMXE7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC9yb3V0 ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRoZXJuZXQwLTEtNDQxLTgwMi0xcTsKICAgICAgICAg ICAgICAgICAgICAgICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAt MS03MDYtODAyLTFxOwogICAgICAgICAgICAgICAgICAgICAgICAgICAvcm91dGVycy9saW5r cy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTYxNy04MDItMXE7CiAgICAgICAgICAgICAgICAg ICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRoZXJuZXQwLTEtOTA5LTgw Mi0xcTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIx LWZhc3RldGhlcm5ldDAtMS03MDMtODAyLTFxOwogICAgICAgICAgICAgICAgICAgICAgICAg ICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTYyMS04MDItMXE7CiAg ICAgICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRo ZXJuZXQwLTEtNDMxLTgwMi0xcTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgL3JvdXRl cnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS05MDYtODAyLTFxOwogICAgICAgICAg ICAgICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0x LTkwMS04MDItMXE7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtz L240MS1yMS1mYXN0ZXRoZXJuZXQwLTEtNjI0LTgwMi0xcTsKICAgICAgICAgICAgICAgICAg ICAgICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS02MTQtODAy LTFxOwogICAgICAgICAgICAgICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEt ZmFzdGV0aGVybmV0MC0xLTcwMS04MDItMXE7CiAgICAgICAgICAgICAgICAgICAgICAgICAg IC9yb3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRoZXJuZXQwLTEtNDQwLTgwMi0xcTsKICAg ICAgICAgICAgICAgICAgICAgICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhl cm5ldDAtMS02MjMtODAyLTFxOwogICAgICAgICAgICAgICAgICAgICAgICAgICAvcm91dGVy cy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTQzOC04MDItMXE7CiAgICAgICAgICAg ICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRoZXJuZXQwLTEt NzAyLTgwMi0xcTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgL3JvdXRlcnMvbGlua3Mv bjQxLXIxLWZhc3RldGhlcm5ldDAtMS05MDctODAyLTFxOwogICAgICAgICAgICAgICAgICAg ICAgICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTYyMC04MDIt MXE7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1m YXN0ZXRoZXJuZXQwLTEtNjEyLTgwMi0xcTsKICAgICAgICAgICAgICAgICAgICAgICAgICAg L3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS00MTMtODAyLTFxOwogICAg ICAgICAgICAgICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVy bmV0MC0xLTYyNS04MDItMXE7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJz L2xpbmtzL240MS1yMS1mYXN0ZXRoZXJuZXQwLTEtOTA4LTgwMi0xcTsKICAgICAgICAgICAg ICAgICAgICAgICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS05 MDQtODAyLTFxOwogICAgICAgICAgICAgICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9u NDEtcjEtZmFzdGV0aGVybmV0MC0xLTQxNy04MDItMXE7CiAgICAgICAgICAgICAgICAgICAg ICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRoZXJuZXQwLTEtNjE1LTgwMi0x cTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZh c3RldGhlcm5ldDAtMS02MTgtODAyLTFxOwogICAgICAgICAgICAgICAgICAgICAgICAgICAv cm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTQyMy04MDItMXE7CiAgICAg ICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240MS1yMS1mYXN0ZXRoZXJu ZXQwLTEtNzA1LTgwMi0xcTsKICAgICAgICAgICAgICAgICAgICAgICAgICAgL3JvdXRlcnMv bGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS00MjEtODAyLTFxOwogICAgICAgICAgICAg ICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFzdGV0aGVybmV0MC0xLTQ0 My04MDItMXE7CiAgICAgICAgICAgICAgICAgICAgICAgICAgIC9yb3V0ZXJzL2xpbmtzL240 MS1yMS1mYXN0ZXRoZXJuZXQwLTEtOTEzLTgwMi0xcTsKICAgICAgICAgICAgICAgICAgICAg ICAgICAgL3JvdXRlcnMvbGlua3MvbjQxLXIxLWZhc3RldGhlcm5ldDAtMS05MTAtODAyLTFx OwogICAgICAgICAgICAgICAgICAgICAgICAgICAvcm91dGVycy9saW5rcy9uNDEtcjEtZmFz dGV0aGVybmV0MC0xLTQzNi04MDItMXEiCkVPVAoKbXkgQHdvcmRzID0gKCk7CkB3b3JkcyA9 IHF1b3Rld29yZHMoJ1tccz1dKycsIDAsICR0ZXN0X3N0cmluZyk7CgojcHJpbnQgam9pbign LCcsQHdvcmRzKSwiXG4iOwo= ------------C6149F81B4029D2-- From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 17:47:02 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A79216A41F; Tue, 19 Jul 2005 17:47:02 +0000 (GMT) (envelope-from igor@doom.homeunix.org) Received: from voodoo.oberon.net (voodoo.oberon.net [212.118.165.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id B649943D45; Tue, 19 Jul 2005 17:47:01 +0000 (GMT) (envelope-from igor@doom.homeunix.org) Received: from dialup84114-183.ip.peterstar.net ([84.204.114.183] helo=doom.homeunix.org) by voodoo.oberon.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.51 (FreeBSD)) id 1DuwAc-000NVL-GS; Tue, 19 Jul 2005 19:46:25 +0200 Received: from doom.homeunix.org (localhost [127.0.0.1]) by doom.homeunix.org (8.13.3/8.13.3) with ESMTP id j6JHjMlY002659; Tue, 19 Jul 2005 21:45:23 +0400 (MSD) (envelope-from igor@doom.homeunix.org) Received: (from igor@localhost) by doom.homeunix.org (8.13.3/8.13.3/Submit) id j6JHjMXq002658; Tue, 19 Jul 2005 21:45:22 +0400 (MSD) (envelope-from igor) Date: Tue, 19 Jul 2005 21:45:00 +0400 From: Igor Pokrovsky To: Jean Milanez Melo Message-ID: <20050719174500.GA1594@doom.homeunix.org> Mail-Followup-To: Jean Milanez Melo , small@freebsd.org, stable@freebsd.org References: <42DBF250.1060405@freebsdbrasil.com.br> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42DBF250.1060405@freebsdbrasil.com.br> User-Agent: Mutt/1.4.2.1i Cc: stable@freebsd.org, small@freebsd.org Subject: Re: TinyBSD Call For Testers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 17:47:02 -0000 On Mon, Jul 18, 2005 at 03:17:52PM -0300, Jean Milanez Melo wrote: > Hello gentlemen, > > In the last saturday a new port has been added under sysutils/ category, > ports/sysutils/tinybsd. TinyBSD is a tool which was meant to allow an > easy way to build embedded systems based on FreeBSD. It is based on > userland copying, library dependencies check/copy and kernel build. What's wrong with PicoBSD? -ip -- Consumer assistance doesn't. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 18:19:15 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 032DF16A41F for ; Tue, 19 Jul 2005 18:19:15 +0000 (GMT) (envelope-from nalists@scls.lib.wi.us) Received: from mail.scls.lib.wi.us (mail.scls.lib.wi.us [198.150.40.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id AA42A43D48 for ; Tue, 19 Jul 2005 18:19:14 +0000 (GMT) (envelope-from nalists@scls.lib.wi.us) Received: from [172.26.2.238] ([172.26.2.238]) by mail.scls.lib.wi.us (8.12.9p2/8.12.9) with ESMTP id j6JIItG1028331; Tue, 19 Jul 2005 13:18:55 -0500 (CDT) (envelope-from nalists@scls.lib.wi.us) Message-ID: <42DD4369.9070407@scls.lib.wi.us> Date: Tue, 19 Jul 2005 13:16:09 -0500 From: Greg Barniskis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pavel A Crasotin References: <81030364.20050719210309@ctk.ru> In-Reply-To: <81030364.20050719210309@ctk.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Perl 5.8.7 dumps core on quotewords X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 18:19:15 -0000 Pavel A Crasotin wrote: > Hello - > > I've just installed perl5.8.7 and now my cricket 1.0.5 does not work > correctly. > Perl abnormally exits with 'Bus error' message and throws core. > > After little investigation I have found out the problem is in > Text::ParseWords::quotewords procedure. [details snipped] Did you upgrade perl using the ports collection? If so, did you run the provided perl-after-upgrade script? If not, can you do that and test again? See ports/UPDATING for more information on upgrading perl. -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) , (608) 266-6348 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 18:22:44 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 257D916A41F for ; Tue, 19 Jul 2005 18:22:44 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABD6643D45 for ; Tue, 19 Jul 2005 18:22:43 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: by wproxy.gmail.com with SMTP id i14so1280023wra for ; Tue, 19 Jul 2005 11:22:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SdoWJiq5LG8jqGsULyUBePXxfRwcWU1vOgEU2fn9mUaXnGatNsmRvY1Q8/n61uiYhGGbub37M60s7Vx0ecjaY8sgohSqSXl4jQKNdg76aBMl/jwlIAONNA2P0Nmz3vRTwe6Y07HOBJ8K9RcsHbQzCNFoKtOXQTiNIkBZMlrdSZg= Received: by 10.54.2.57 with SMTP id 57mr841861wrb; Tue, 19 Jul 2005 11:22:01 -0700 (PDT) Received: by 10.54.39.65 with HTTP; Tue, 19 Jul 2005 11:22:01 -0700 (PDT) Message-ID: <8eea04080507191122225bd9ac@mail.gmail.com> Date: Tue, 19 Jul 2005 11:22:01 -0700 From: Jon Simola To: Tony Byrne In-Reply-To: <1591154927.20050719132119@byrnehq.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <151574576.20050719103740@byrnehq.com> <1591154927.20050719132119@byrnehq.com> Cc: freebsd-stable@freebsd.org Subject: Re: ATA Woes. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jon@abccomm.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 18:22:44 -0000 On 7/19/05, Tony Byrne wrote: > Jul 19 13:01:48 roo kernel: ad0: FAILURE - READ_DMA status=3D51 error=3D40 LBA=3D288810495 > Jul 19 13:01:59 roo kernel: ad0: FAILURE - READ_DMA status=3D51 error=3D1 LBA=3D288810495 > Jul 19 13:02:05 roo kernel: ad0: FAILURE - READ_DMA status=3D51 error=3D40 LBA=3D288810495 > Jul 19 13:02:16 roo kernel: ad0: FAILURE - READ_DMA status=3D51 error=3D40 LBA=3D288810495 > Jul 19 13:04:36 roo last message repeated 4 times > I'm totally confused. I don't know enough about SMART to know whether > I'm looking at real failing drives or some bug exposed by the > interaction between drive firmware, hd controller and FreeBSD. What I've recently learned the hard way is that desktop drives have no place in a server. I've now failed 4 of 10 SATA drives (Maxtor and WD) in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives (which claim to be low-end server). --=20 Jon Simola Systems Administrator ABC Communications From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 18:35:53 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A6B8016A425 for ; Tue, 19 Jul 2005 18:35:53 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from smtp-vbr9.xs4all.nl (smtp-vbr9.xs4all.nl [194.109.24.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4CF9D43D49 for ; Tue, 19 Jul 2005 18:35:50 +0000 (GMT) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (freebie.xs4all.nl [213.84.32.253]) by smtp-vbr9.xs4all.nl (8.13.3/8.13.3) with ESMTP id j6JIZfOW060552; Tue, 19 Jul 2005 20:35:42 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: from freebie.xs4all.nl (localhost [127.0.0.1]) by freebie.xs4all.nl (8.13.3/8.13.3) with ESMTP id j6JIZe5E097673; Tue, 19 Jul 2005 20:35:40 +0200 (CEST) (envelope-from wb@freebie.xs4all.nl) Received: (from wb@localhost) by freebie.xs4all.nl (8.13.3/8.13.1/Submit) id j6JIZekb097672; Tue, 19 Jul 2005 20:35:40 +0200 (CEST) (envelope-from wb) Date: Tue, 19 Jul 2005 20:35:40 +0200 From: Wilko Bulte To: jon@abccomm.com Message-ID: <20050719183540.GA97643@freebie.xs4all.nl> References: <151574576.20050719103740@byrnehq.com> <1591154927.20050719132119@byrnehq.com> <8eea04080507191122225bd9ac@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8eea04080507191122225bd9ac@mail.gmail.com> X-OS: FreeBSD 5.4-STABLE User-Agent: Mutt/1.5.9i X-Virus-Scanned: by XS4ALL Virus Scanner Cc: freebsd-stable@freebsd.org, Tony Byrne Subject: Re: ATA Woes. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 18:35:54 -0000 On Tue, Jul 19, 2005 at 11:22:01AM -0700, Jon Simola wrote.. > On 7/19/05, Tony Byrne wrote: > > > Jul 19 13:01:48 roo kernel: ad0: FAILURE - READ_DMA status=51 error=40 LBA=288810495 > > Jul 19 13:01:59 roo kernel: ad0: FAILURE - READ_DMA status=51 error=1 LBA=288810495 > > Jul 19 13:02:05 roo kernel: ad0: FAILURE - READ_DMA status=51 error=40 LBA=288810495 > > Jul 19 13:02:16 roo kernel: ad0: FAILURE - READ_DMA status=51 error=40 LBA=288810495 > > Jul 19 13:04:36 roo last message repeated 4 times > > > I'm totally confused. I don't know enough about SMART to know whether > > I'm looking at real failing drives or some bug exposed by the > > interaction between drive firmware, hd controller and FreeBSD. > > What I've recently learned the hard way is that desktop drives have no > place in a server. I've now failed 4 of 10 SATA drives (Maxtor and WD) > in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives > (which claim to be low-end server). Properly cooled? -- Wilko Bulte wilko@FreeBSD.org From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 18:41:32 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F61316A41F for ; Tue, 19 Jul 2005 18:41:32 +0000 (GMT) (envelope-from pavel@ctk.ru) Received: from zeus.nordnet.ru (ns.ctk.ru [213.150.64.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id E13B843D6A for ; Tue, 19 Jul 2005 18:41:25 +0000 (GMT) (envelope-from pavel@ctk.ru) Received: from zeus.nordnet.ru (localhost [127.0.0.1]) by zeus.nordnet.ru (Postfix) with SMTP id C6C71136862; Tue, 19 Jul 2005 22:41:23 +0400 (MSD) Received: from crasotin.nordnet-local.ru (crasotin.office.ctk.ru [10.41.0.29]) by zeus.nordnet.ru (Postfix) with ESMTP id 938BB13683F; Tue, 19 Jul 2005 22:41:23 +0400 (MSD) Date: Tue, 19 Jul 2005 22:41:27 +0400 From: Pavel A Crasotin X-Mailer: The Bat! (v3.5) Professional Organization: OJSC SeverTransCom X-Priority: 3 (Normal) Message-ID: <25430339.20050719224127@ctk.ru> To: Greg Barniskis In-Reply-To: <42DD4369.9070407@scls.lib.wi.us> References: <81030364.20050719210309@ctk.ru> <42DD4369.9070407@scls.lib.wi.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Anti-Virus: Kaspersky Anti-Virus for MailServers 5.5.2/RELEASE, bases: 19072005 #130940, status: notchecked Cc: stable@freebsd.org Subject: Re[2]: Perl 5.8.7 dumps core on quotewords X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 18:41:32 -0000 Yes, i have installed perl5.8.7 from ports And yes, i have run the perl-after-upgrade script with -f option GB> Pavel A Crasotin wrote: >> Hello - >> >> I've just installed perl5.8.7 and now my cricket 1.0.5 does not work >> correctly. >> Perl abnormally exits with 'Bus error' message and throws core. >> >> After little investigation I have found out the problem is in >> Text::ParseWords::quotewords procedure. GB> [details snipped] GB> Did you upgrade perl using the ports collection? GB> If so, did you run the provided perl-after-upgrade script? GB> If not, can you do that and test again? GB> See ports/UPDATING for more information on upgrading perl. -- With respect, Pavel A Crasotin OJSC SeverTransCom Tel: +7 (0852) 58-41-03, 58-01-01 Fax: +7 (0852) 58-01-01 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 18:53:54 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 33E2F16A41F for ; Tue, 19 Jul 2005 18:53:54 +0000 (GMT) (envelope-from freebsd-current@byrnehq.com) Received: from schubert.byrnehq.com (dsl-33-12.dsl.netsource.ie [213.79.33.12]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C8B643D45 for ; Tue, 19 Jul 2005 18:53:53 +0000 (GMT) (envelope-from freebsd-current@byrnehq.com) Received: from localhost (mauer.directski.com. [212.147.140.194]) by schubert.byrnehq.com (8.13.3/8.13.3) with ESMTP id j6JJqaJd054910; Tue, 19 Jul 2005 19:52:37 GMT (envelope-from freebsd-current@byrnehq.com) Date: Tue, 19 Jul 2005 19:53:22 +0100 From: Tony Byrne Organization: ByrneHQ X-Priority: 3 (Normal) Message-ID: <14963954.20050719195322@byrnehq.com> To: Wilko Bulte In-Reply-To: <20050719183540.GA97643@freebie.xs4all.nl> References: <151574576.20050719103740@byrnehq.com> <1591154927.20050719132119@byrnehq.com> <8eea04080507191122225bd9ac@mail.gmail.com> <20050719183540.GA97643@freebie.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ByrneHQ-SA-Hits: -1.635 X-Scanned-By: MIMEDefang 2.51 on 192.168.10.254 Cc: freebsd-stable@freebsd.org, Tony Byrne , jon@abccomm.com Subject: Re[2]: ATA Woes. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Tony Byrne List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 18:53:54 -0000 Hello Wilko, Tuesday, July 19, 2005, 7:35:40 PM, you wrote: WB> On Tue, Jul 19, 2005 at 11:22:01AM -0700, Jon Simola wrote.. >> What I've recently learned the hard way is that desktop drives have no >> place in a server. I've now failed 4 of 10 SATA drives (Maxtor and WD) >> in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives >> (which claim to be low-end server). WB> Properly cooled? I can't speak for Jon, but the two disks that 'failed' sequentially on me in the last 48 hours took turns in a housing that had fans installed to draw air over the drive. Smartctl reported the drive temp. as 26 Deg.C. Regards, Tony. -- Tony Byrne From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 19:10:01 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 77CD216A41F for ; Tue, 19 Jul 2005 19:10:01 +0000 (GMT) (envelope-from jfarmer@goldsword.com) Received: from audi.websitewelcome.com (audi.websitewelcome.com [67.19.210.130]) by mx1.FreeBSD.org (Postfix) with ESMTP id 182E843D45 for ; Tue, 19 Jul 2005 19:10:01 +0000 (GMT) (envelope-from jfarmer@goldsword.com) Received: from adsl-065-013-105-239.sip.tys.bellsouth.net ([65.13.105.239]:3082 helo=[192.168.1.33]) by audi.websitewelcome.com with esmtpa (Exim 4.50) id 1DuxTW-0002Em-Pu for freebsd-stable@freebsd.org; Tue, 19 Jul 2005 14:09:55 -0500 Message-ID: <42DD5026.7050902@goldsword.com> Date: Tue, 19 Jul 2005 15:10:30 -0400 From: "J. T. Farmer" Organization: GoldSword Systems User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.7) Gecko/20050414 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: <151574576.20050719103740@byrnehq.com> <1591154927.20050719132119@byrnehq.com> <8eea04080507191122225bd9ac@mail.gmail.com> <20050719183540.GA97643@freebie.xs4all.nl> <14963954.20050719195322@byrnehq.com> In-Reply-To: <14963954.20050719195322@byrnehq.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - audi.websitewelcome.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - goldsword.com X-Source: X-Source-Args: X-Source-Dir: Subject: Re: ATA Woes. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 19:10:01 -0000 Tony Byrne wrote: >Hello Wilko, > >Tuesday, July 19, 2005, 7:35:40 PM, you wrote: > >WB> On Tue, Jul 19, 2005 at 11:22:01AM -0700, Jon Simola wrote.. > > > >>>What I've recently learned the hard way is that desktop drives have no >>>place in a server. I've now failed 4 of 10 SATA drives (Maxtor and WD) >>>in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives >>>(which claim to be low-end server). >>> >>> > >WB> Properly cooled? > >I can't speak for Jon, but the two disks that 'failed' sequentially on >me in the last 48 hours took turns in a housing that had fans >installed to draw air over the drive. Smartctl reported the drive >temp. as 26 Deg.C. > I don't think it's a problem of proper cooling or bad drives. I have a _desktop_ box with an 80G WDC drive in it, brand new. It installs WinXP and Linux just fine. It will not get through writing the superblocks for FreeBSD during the install _unless_ I boot the install kernel in "save" mode. This is installing 5.4-RELEASE, _and_ 5-Stable (several different snapshots, the most recent 8 July). This is a PATA drive, nothing special about it. The CPU is an AlthonXP 2200, mb has the VIA KT266A chipset. Out of the box, I'm having a lot of trouble installing 5.anything on this configuration. These same READ_DMA errors appear to be occurring with both SATA and PATA drives. (The drive checks out as fine. I'm about to run WDC diagnostics on it again.) John ---------------------------------------------------------------------- John T. Farmer Owner & CTO GoldSword Systems jfarmer@goldsword.com 865-691-6498 Knoxville TN Consulting, Design, & Development of Networks & Software From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 19:11:09 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C759F16A41F for ; Tue, 19 Jul 2005 19:11:09 +0000 (GMT) (envelope-from joe@osoft.us) Received: from mailbox.flagandbanner.com (adsl-208-189-15-88.flagandbanner.com [208.189.15.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5249B43D46 for ; Tue, 19 Jul 2005 19:11:09 +0000 (GMT) (envelope-from joe@osoft.us) Received: from localhost (localhost.flagandbanner.com [127.0.0.1]) by mailbox.flagandbanner.com (Postfix) with ESMTP id 5A6635520; Tue, 19 Jul 2005 14:11:07 -0500 (CDT) Received: from mailbox.flagandbanner.com ([127.0.0.1]) by localhost (mailbox.flagandbanner.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 29828-02-4; Tue, 19 Jul 2005 14:11:06 -0500 (CDT) Received: from [10.1.0.184] (unknown [10.1.0.184]) by mailbox.flagandbanner.com (Postfix) with ESMTP id 07A81551C; Tue, 19 Jul 2005 14:11:06 -0500 (CDT) Message-ID: <42DD4FC9.4050304@osoft.us> Date: Tue, 19 Jul 2005 14:08:57 -0500 From: Joe Koberg User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: jon@abccomm.com References: <151574576.20050719103740@byrnehq.com> <1591154927.20050719132119@byrnehq.com> <8eea04080507191122225bd9ac@mail.gmail.com> In-Reply-To: <8eea04080507191122225bd9ac@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at flagandbanner.com Cc: freebsd-stable@freebsd.org, Tony Byrne Subject: Re: ATA Woes. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 19:11:09 -0000 Jon Simola wrote: > On 7/19/05, Tony Byrne wrote: >>I'm totally confused. I don't know enough about SMART to know whether >>I'm looking at real failing drives or some bug exposed by the >>interaction between drive firmware, hd controller and FreeBSD. > > > What I've recently learned the hard way is that desktop drives have no > place in a server. I've now failed 4 of 10 SATA drives (Maxtor and WD) > in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives > (which claim to be low-end server). > I have to agree with this opinion, I recently had a WD1600JD SATA fail within a couple months of installation, and the warranty replacement failed within a week. First drive failed autodetection and made servo ticking noises. Second drive had many bad sectors. Add this to the pile of dead 3yr-old 40GB WD drives from all the workstations around here. I install SATA drives in duplicate and triplicate for this reason. Preferably in removable bays with a fan. I assume they're bad out of the box... I write them full of zeros with DD, then read it all back, then do it again. If I don't get read errors then I install them. Joe Koberg joe at osoft dot us From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 19:28:34 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B11A616A41F for ; Tue, 19 Jul 2005 19:28:34 +0000 (GMT) (envelope-from grafan@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02AA943D5D for ; Tue, 19 Jul 2005 19:28:33 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by wproxy.gmail.com with SMTP id 50so413909wri for ; Tue, 19 Jul 2005 12:28:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kSUniqwJDEfEFwhXdwZqVI3JHBV1PwPUktS+OD+F9gjYxuglYagU/xKesoYq/6xjkCldCC2sqK49g+wy+FcV7G8DxDamwGtV0g6CSGOXqp7jdnzRkrrjgA7Swcausor+kOKvM45aSgcvu7fk77MqognFh/FJL23cP1tcbz5vWmY= Received: by 10.54.92.2 with SMTP id p2mr856684wrb; Tue, 19 Jul 2005 12:27:39 -0700 (PDT) Received: by 10.54.7.20 with HTTP; Tue, 19 Jul 2005 12:27:39 -0700 (PDT) Message-ID: <6eb82e0507191227109c49e7@mail.gmail.com> Date: Wed, 20 Jul 2005 03:27:39 +0800 From: Rong-En Fan To: Alexander Markov In-Reply-To: <0eae01c58c25$fedf1ac0$7601540a@am> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <08f401c58881$bb0f7bc0$7601540a@am> <6eb82e05071409007a97d193@mail.gmail.com> <0eae01c58c25$fedf1ac0$7601540a@am> Cc: stable@freebsd.org Subject: Re: IBM xSeries 335 and FreeBSD 5 STABLE. SMP problem X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rong-En Fan List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 19:28:34 -0000 On 7/19/05, Alexander Markov wrote: > >If you unload kernel and load it again at boot manually, can 335 boot? > >I have one 336 with 5.4 that must use this trick to boot, otherwise > >it hangs after ipfw2 initialized. On the other hand, I have 3 335 instal= led > >with 5.4 running SMP smoothly. >=20 > Nope, this trick doesn't work for me :-( > And btw, do you have LSI Logic SCSI controller on your 335? Sure. It is mpt0: port 0x2300-0x23ff mem 0xfbfe0000-0xfb= fefff I have tried it with RAID1 (with patch, performance is fine) and It can boot with/without the patch. Anyway, I use gmirror now. > I'll try to upgrade BIOS today, for it seems to be the only difference > between my and people in the list's hardware. From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 20:15:19 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE9AD16A41F for ; Tue, 19 Jul 2005 20:15:19 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7609143D48 for ; Tue, 19 Jul 2005 20:15:19 +0000 (GMT) (envelope-from jsimola@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1307511wra for ; Tue, 19 Jul 2005 13:15:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=IPNpArf334ysVbvQQYbKFMVqgpz5W/4Dywjdz2AeNQT1UAFbf7bv2eu5qsmLFFBJgIied2p+hmfAs1UHpffvlA+MtvBcMoRtVfav8X9vA+p5tA8BRJM0mjlBv2cB87e7vVWuokhs6U4f6Mn8/hNyyoEpO9JE2+pRl1kEqN7Tthg= Received: by 10.54.109.14 with SMTP id h14mr876291wrc; Tue, 19 Jul 2005 13:14:41 -0700 (PDT) Received: by 10.54.39.65 with HTTP; Tue, 19 Jul 2005 13:14:41 -0700 (PDT) Message-ID: <8eea04080507191314304ceaa3@mail.gmail.com> Date: Tue, 19 Jul 2005 13:14:41 -0700 From: Jon Simola To: Wilko Bulte In-Reply-To: <20050719183540.GA97643@freebie.xs4all.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <151574576.20050719103740@byrnehq.com> <1591154927.20050719132119@byrnehq.com> <8eea04080507191122225bd9ac@mail.gmail.com> <20050719183540.GA97643@freebie.xs4all.nl> Cc: freebsd-stable@freebsd.org Subject: Re: ATA Woes. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jon@abccomm.com List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 20:15:20 -0000 On 7/19/05, Wilko Bulte wrote: > On Tue, Jul 19, 2005 at 11:22:01AM -0700, Jon Simola wrote.. > > I've now failed 4 of 10 SATA drives (Maxtor and WD) > > in 1U rackmounts, and am moving on to trying the WD Raptor SATA drives > > (which claim to be low-end server). >=20 > Properly cooled? Yeah, they're in the Supermicro 811 chassis with hotswap SATA sleds. There's a decent amount of air flowing over the drives, and SMART says they're running about 26C. Compared to my 10Krpm SCSI array that I've burned my fingers on, frequently. --=20 Jon Simola Systems Administrator ABC Communications From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 20:28:04 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47B1A16A41F for ; Tue, 19 Jul 2005 20:28:04 +0000 (GMT) (envelope-from nalists@scls.lib.wi.us) Received: from mail.scls.lib.wi.us (mail.scls.lib.wi.us [198.150.40.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id ECF7A43D48 for ; Tue, 19 Jul 2005 20:28:03 +0000 (GMT) (envelope-from nalists@scls.lib.wi.us) Received: from [172.26.2.238] ([172.26.2.238]) by mail.scls.lib.wi.us (8.12.9p2/8.12.9) with ESMTP id j6JKRwG1032805; Tue, 19 Jul 2005 15:27:59 -0500 (CDT) (envelope-from nalists@scls.lib.wi.us) Message-ID: <42DD61A9.9070601@scls.lib.wi.us> Date: Tue, 19 Jul 2005 15:25:13 -0500 From: Greg Barniskis User-Agent: Mozilla Thunderbird 1.0.5 (Windows/20050711) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pavel A Crasotin References: <81030364.20050719210309@ctk.ru> <42DD4369.9070407@scls.lib.wi.us> <25430339.20050719224127@ctk.ru> In-Reply-To: <25430339.20050719224127@ctk.ru> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: Re: Perl 5.8.7 dumps core on quotewords X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 20:28:04 -0000 Pavel A Crasotin wrote: > Yes, i have installed perl5.8.7 from ports > And yes, i have run the perl-after-upgrade script with -f option > Sorry then that it's not a simple thing. I just started looking at cricket myself, and don't have a fully working installation yet (I still need to tweak the Apache config to match the local environment, or else tweak the local env to match cricket's assumptions). However, I can report that using compile, collector and graph.cgi from the command line works fine for me. On the other hand... I just ran your test script and got: Bus error (core dumped) Anyone else have clues? Since it's easily repeatable in different environments, maybe send-pr it as a demonstrable bug? -- Greg Barniskis, Computer Systems Integrator South Central Library System (SCLS) Library Interchange Network (LINK) , (608) 266-6348 From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 22:03:00 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2CF3816A41F for ; Tue, 19 Jul 2005 22:03:00 +0000 (GMT) (envelope-from john.vansickle@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7509E43D48 for ; Tue, 19 Jul 2005 22:02:59 +0000 (GMT) (envelope-from john.vansickle@gmail.com) Received: by rproxy.gmail.com with SMTP id f1so1735106rne for ; Tue, 19 Jul 2005 15:02:58 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=ANKnZw6eIgonqTtrImnRTnudIjn7qRsmUrUwy0ejKg2cD1mcUV6jU2ltG+lK80NckpASHFzChq/LwsTznz0uL88FkSlY1joT4lfKW1WQlae5lh8Uy4TlOlLMLk6C5+s+3iL9+xbYfXK4juexQ7OpsilGesKXN6mMn0IjIjZqs/k= Received: by 10.38.86.42 with SMTP id j42mr3250598rnb; Tue, 19 Jul 2005 15:02:58 -0700 (PDT) Received: by 10.38.76.61 with HTTP; Tue, 19 Jul 2005 15:02:58 -0700 (PDT) Message-ID: <1386782805071915028c2553e@mail.gmail.com> Date: Tue, 19 Jul 2005 18:02:58 -0400 From: John Van Sickle To: freebsd-stable@freebsd.org In-Reply-To: <138678280507170858c1b3898@mail.gmail.com> Mime-Version: 1.0 References: <138678280507170858c1b3898@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Re: Atapicam problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John Van Sickle List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 22:03:00 -0000 On 7/17/05, John Van Sickle wrote: >=20 > Hi, >=20 > After a day or two I keep losing my /dev/cd0 and /dev/cd1 devices. When= =20 > this happens I'm able to reboot and everything works again. By that I mea= n=20 > the drives show up in /dev again and 'camcontrol devlist' lists them. I= =20 > haven't had any errors burning dvds/cds either. My log message gives me t= he=20 > following info after I lose the drives: >=20 > atapicam0: timeout waiting for ATAPI ready > atapicam0: timeout waiting for ATAPI ready > atapicam0: timeout waiting for ATAPI ready > atapicam0: timeout waiting for ATAPI ready > atapicam0: timeout waiting for ATAPI ready > atapicam0: timeout waiting for ATAPI ready > (probe2:ata1:0:0:0): Lost target 0??? >=20 > I noticed the problem about two or so weeks ago. I tried running=20 > 'camcontrol rescan all' and 'camcontrol reset all' but it didn't help. I'= d=20 > also like to note that I don't have "atapicd" in my kernel or acpi enable= d.=20 > Not sure if that matters (hasn't in the past).=20 >=20 > Thanks for your time. >=20 > uname -a=20 > FreeBSD workstation.insightbb.com =20 > 5.4-STABLE FreeBSD 5.4-STABLE #0: Fri Jul 15 20:38:58 EDT 2005=20 > root@workstation.insightbb.com:/usr/obj/usr/src/sys/SAMSON i386 >=20 >=20 > camcontrol devlist > at scbus0 target 0 lun 0 (pass0,da0) > <_NEC DVD_RW ND-3540A 1.01> at scbus2 target 0 lun 0 (pass1,cd0) > at scbus2 target 1 lun 0 (pass2,cd1) >=20 >=20 > dmesg | grep cd=20 > cd0 at ata1 bus 0 target 0 lun 0 > cd0: <_NEC DVD_RW ND-3540A 1.01> Removable CD-ROM SCSI-0 device=20 > cd0: 16.000MB/s transfers > cd0: Attempt to query device size failed: NOT READY, Medium not present > cd1 at ata1 bus 0 target 1 lun 0 > cd1: Removable CD-ROM SCSI-0 device=20 > cd1: 16.000MB/s transfers > cd1: Attempt to query device size failed: NOT READY, Medium not present >=20 > info from 'pciconf -vl' on my ata chipset: > atapci0@pci0:4:1: class=3D0x01018a card=3D0x00000000 chip=3D0x05711106 re= v=3D0x06=20 > hdr=3D0x00 > vendor =3D 'VIA Technologies Inc' > device =3D 'VT82xxxx EIDE Controller (All VIA Chipsets)' > class =3D mass storage > subclass =3D ATA >=20 > kernel config: > machine i386 > cpu I686_CPU > ident SAMSON=20 >=20 > # To statically compile in device wiring instead of /boot/device.hints > #hints "GENERIC.hints" # Default places to look for devices. >=20 > options SCHED_4BSD # 4BSD scheduler > options INET # InterNETworking > options INET6 # IPv6 communications protocols > options FFS # Berkeley Fast Filesystem > options SOFTUPDATES # Enable FFS soft updates support > options UFS_ACL # Support for access control lists > options UFS_DIRHASH # Improve performance on big directories > options MD_ROOT # MD is a potential root device > options MSDOSFS # MSDOS Filesystem > options CD9660 # ISO 9660 Filesystem > options PROCFS # Process filesystem (requires PSEUDOFS) > options PSEUDOFS # Pseudo-filesystem framework > options GEOM_GPT # GUID Partition Tables. > options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] > options COMPAT_FREEBSD4 # Compatible with FreeBSD4 > options KTRACE # ktrace(1) support > options SYSVSHM # SYSV-style shared memory > options SYSVMSG # SYSV-style message queues > options SYSVSEM # SYSV-style semaphores > options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions > options KBD_INSTALL_CDEV # install a CDEV entry in /dev > options ADAPTIVE_GIANT # Giant mutex is adaptive. >=20 > device apic # I/O APIC >=20 > # Bus support. Do not remove isa, even if you have no isa slots > device isa > device eisa > device pci >=20 > # Floppy drives > device fdc >=20 > # ATA and ATAPI devices > device ata > device atadisk # ATA disk drives > device atapifd # ATAPI floppy drives > options ATA_STATIC_ID # Static device numbering >=20 > # SCSI peripherals > device scbus # SCSI bus (required for SCSI) > device da # Direct Access (disks) > device sa # Sequential Access (tape etc) > device cd # CD > device pass # Passthrough device (direct SCSI access) >=20 > # atkbdc0 controls both the keyboard and the PS/2 mouse > device atkbdc # AT keyboard controller > device psm # PS/2 mouse >=20 > device vga # VGA video card driver >=20 > device splash # Splash screen and screen saver support >=20 > # syscons is the default console driver, resembling an SCO console > device sc >=20 > # Enable this for the pcvt (VT220 compatible) console driver > #device vt > #options XSERVER # support for X server on a vt console > #options FAT_CURSOR # start with block cursor >=20 > # Floating point support - do not disable. > device npx >=20 > # Power management support (see NOTES for more options) > #device apm > # Add suspend/resume support for the i8254. >=20 > # Parallel port > device ppbus # Parallel port bus (required) >=20 > # PCI Ethernet NICs that use the common MII bus controller code. > # NOTE: Be sure to keep the 'device miibus' line in order to use these=20 > NICs! > device miibus # MII bus support > device fxp # Intel EtherExpress PRO/100B (82557, 82558) >=20 > # Pseudo devices. > device loop # Network loopback > device mem # Memory and kernel memory devices > device io # I/O device > device random # Entropy device > device ether # Ethernet support > device tun # Packet tunnel. > device pty # Pseudo-ttys (telnet etc) > device md # Memory "disks" > device gif # IPv6 and IPv4 tunneling > device faith # IPv6-to-IPv4 relaying (translation) >=20 > # The `bpf' device enables the Berkeley Packet Filter. > # Be aware of the administrative consequences of enabling this! > device bpf # Berkeley packet filter >=20 > # USB support > device uhci # UHCI PCI->USB interface > device usb # USB Bus (required) > #device udbp # USB Double Bulk Pipe devices > device ugen # Generic > device uhid # "Human Interface Devices" > device ulpt # Printer > device umass # Disks/Mass storage - Requires scbus and da > device ukbd # Keyboard >=20 > # FireWire support > device firewire # FireWire bus code > device sbp # SCSI over FireWire (Requires scbus and da) >=20 > # Custom > device sound > device "snd_emu10k1" > device atapicam > options UDF=20 > =20 Anyone? Or is there another mailing list I should try? --=20 John Van Sickle www.johnvansickle.com From owner-freebsd-stable@FreeBSD.ORG Tue Jul 19 22:09:55 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A91D216A420 for ; Tue, 19 Jul 2005 22:09:55 +0000 (GMT) (envelope-from ronald-freebsd8@klop.yi.org) Received: from smtp-out2.tiscali.nl (smtp-out2.tiscali.nl [195.241.79.177]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E62A43D45 for ; Tue, 19 Jul 2005 22:09:55 +0000 (GMT) (envelope-from ronald-freebsd8@klop.yi.org) Received: from [82.171.39.195] (helo=guido.klop.ws) by smtp-out2.tiscali.nl with smtp (Tiscali http://www.tiscali.nl) id 1Dv0Hi-000081-8t for ; Wed, 20 Jul 2005 00:09:54 +0200 Received: (qmail 764 invoked from network); 19 Jul 2005 22:09:52 -0000 Received: from localhost (HELO outgoing.local) (127.0.0.1) by localhost with SMTP; 19 Jul 2005 22:09:52 -0000 To: freebsd-stable@freebsd.org Date: Wed, 20 Jul 2005 00:09:50 +0200 From: "Ronald Klop" Content-Type: text/plain; format=flowed; delsp=yes; charset=iso-8859-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-ID: User-Agent: Opera M2/8.01 (FreeBSD, build 1204) Subject: 6-BETA1 PAE kernel doesn't build X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jul 2005 22:09:55 -0000 Hello, The PAE kernel of 6-BETA1 only builds after disabling devices ural and ral. Ronald. PS: 6-BETA1 iso booted on a system with new hardware where my college didn't get linux booted. ;-) -- Ronald Klop Amsterdam, The Netherlands From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 00:22:32 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D98B16A41F for ; Wed, 20 Jul 2005 00:22:32 +0000 (GMT) (envelope-from cabal@u.washington.edu) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDC8643D49 for ; Wed, 20 Jul 2005 00:22:31 +0000 (GMT) (envelope-from cabal@u.washington.edu) Received: from aagaard03.u.washington.edu (aagaard03.u.washington.edu [140.142.13.114]) by mxout5.cac.washington.edu (8.13.4+UW05.04/8.13.4+UW05.05) with ESMTP id j6K0MV6t018750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Jul 2005 17:22:31 -0700 Received: from localhost (cabal@localhost) by aagaard03.u.washington.edu (8.13.4+UW05.03/8.13.4+UW05.05) with ESMTP id j6K0MUSu088670 for ; Tue, 19 Jul 2005 17:22:31 -0700 Date: Tue, 19 Jul 2005 17:22:30 -0700 (PDT) From: "J. Nyhuis" To: freebsd-stable@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Q: RT32 (Request Tracker) + jail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 00:22:32 -0000 Greetings, I would like to have RT running in a jailed environment. The challenge, it seems, will be to get sendmail running in the same jailed environment as RT and the other components. For those not so familiar with the components of RT, the jail would include apache1.3+modperl, MySQL, sendmail, and RT. That's a lot of stuff to get working in there! (but fortunately FreeBSD jails seem straightforward and easy) ^_^ I expect sendmail to be the real problem of the above bunch. Has anyone actually tried to do this with a big multi-part app like RT (I have not spotted anyone's documented attempts on Google) and would be willing to share to the list? Does anyone else wonder if I've lost it? (Don't answer that)... ^_^ Thanks, John H. Nyhuis Sr. Computer Specialist Dept. of Pediatrics HS RR349B, Box 356320 University of Washington Desk: (206)-685-3884 cabal@u.washington.edu From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 01:56:04 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 47CE616A41F for ; Wed, 20 Jul 2005 01:56:04 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: from dan.emsphone.com (dan.emsphone.com [199.67.51.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id D2CC143D45 for ; Wed, 20 Jul 2005 01:56:03 +0000 (GMT) (envelope-from dan@dan.emsphone.com) Received: (from dan@localhost) by dan.emsphone.com (8.13.1/8.13.3) id j6K1twBT093901; Tue, 19 Jul 2005 20:55:58 -0500 (CDT) (envelope-from dan) Date: Tue, 19 Jul 2005 20:55:57 -0500 From: Dan Nelson To: "J. Nyhuis" Message-ID: <20050720015557.GA94371@dan.emsphone.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-OS: FreeBSD 5.4-STABLE X-message-flag: Outlook Error User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org Subject: Re: Q: RT32 (Request Tracker) + jail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 01:56:04 -0000 In the last episode (Jul 19), J. Nyhuis said: > I would like to have RT running in a jailed environment. The > challenge, it seems, will be to get sendmail running in the same > jailed environment as RT and the other components. > For those not so familiar with the components of RT, the > jail would include apache1.3+modperl, MySQL, sendmail, and RT. > That's a lot of stuff to get working in there! (but fortunately > FreeBSD jails seem straightforward and easy) ^_^ > I expect sendmail to be the real problem of the above bunch. Sendmail should do just fine, I'd think. -- Dan Nelson dnelson@allantgroup.com From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 02:19:16 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A28E316A41F for ; Wed, 20 Jul 2005 02:19:16 +0000 (GMT) (envelope-from zanchey@ucc.gu.uwa.edu.au) Received: from asclepius.uwa.edu.au (asclepius3.uwa.edu.au [130.95.128.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1113C43D46 for ; Wed, 20 Jul 2005 02:19:15 +0000 (GMT) (envelope-from zanchey@ucc.gu.uwa.edu.au) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id A2CE0183D62 for ; Wed, 20 Jul 2005 10:19:13 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id 963DF1837AC for ; Wed, 20 Jul 2005 10:19:13 +0800 (WST) X-UWA-Client-IP: 130.95.13.9 (UWA) Received: from mooneye.ucc.gu.uwa.edu.au (mooneye.ucc.gu.uwa.edu.au [130.95.13.9]) by asclepius.input (Postfix) with ESMTP id 7B170183D62 for ; Wed, 20 Jul 2005 10:19:13 +0800 (WST) Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id EBD2C17E7D; Wed, 20 Jul 2005 10:19:12 +0800 (WST) Received: from mussel.ucc.gu.uwa.edu.au (mussel.ucc.gu.uwa.edu.au [130.95.13.18]) by mooneye.ucc.gu.uwa.edu.au (Postfix) with ESMTP id B4EEE17E78; Wed, 20 Jul 2005 10:19:12 +0800 (WST) Received: from zanchey (helo=localhost) by mussel.ucc.gu.uwa.edu.au with local-esmtp (Exim 3.36 #1 (Debian)) id 1Dv4Ay-0004b8-00; Wed, 20 Jul 2005 10:19:12 +0800 Date: Wed, 20 Jul 2005 10:19:12 +0800 (WST) From: David Adam To: John Van Sickle In-Reply-To: <1386782805071915028c2553e@mail.gmail.com> Message-ID: References: <138678280507170858c1b3898@mail.gmail.com> <1386782805071915028c2553e@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (251/050713) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release Cc: freebsd-stable@freebsd.org Subject: Re: Atapicam problems X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 02:19:16 -0000 On Tue, 19 Jul 2005, John Van Sickle wrote: > Anyone? Or is there another mailing list I should try? John, I'm afraid I can't help you myself, but you might want to try freebsd-questions@freebsd.org. Hope you have more luck there! David Adam zanchey@ucc.gu.uwa.edu.au From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 02:42:04 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 760DF16A41F for ; Wed, 20 Jul 2005 02:42:04 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7EC1E43D5C for ; Wed, 20 Jul 2005 02:42:03 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j6K2frSQ042388; Tue, 19 Jul 2005 19:41:57 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200507200241.j6K2frSQ042388@gw.catspoiler.org> Date: Tue, 19 Jul 2005 19:41:53 -0700 (PDT) From: Don Lewis To: mkb@incubus.de In-Reply-To: <200507181514.j6IFEBoR001237@drjekyll.mkbuelow.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 02:42:04 -0000 On 18 Jul, Matthias Buelow wrote: > Paul Mather writes: > >>Why would that necessarily be more successful? If the outstanding >>buffers count is not reducing between time intervals, it is most likely >>because there is some underlying hardware problem (e.g., a bad block). >>If the count still persists in staying put, it likely means whatever the >>hardware is doing to try and fix things (e.g., write reallocation) isn't >>working, and so the kernel may as well give up. > > So the kernel is relying on guesswork whether the buffers are flushed > or not... > >>You can enumerate the buffers and *try* to write them, but that doesn't >>guarantee they will be written successfully any more than observing the >>relative number left outstanding. > > That's rather nonsensical. If I write each buffer synchronously (and > wait for the disk's response) this is for sure a lot more reliable than > observing changes in the number of remaining buffers. I mean, where's > the sense in the latter? It would be analogous to, in userspace, having > to monitor write(2) continuously over a given time interval and check > whether the number it returns eventually reaches zero. That's complete > madness, imho. During syncer shutdown, the numbers being printed are actually the number of vnodes that have dirty buffers. The syncer walks the list of vnodes with dirty buffers any synchronously flushes each one to disk (modulo whatever write-caching is done by the drive). The reason that the monitors the number of dirty vnodes instead of just interating once over the list is that with softupdates, flushing one vnode to disk can cause another vnode to be dirtied and put on the list, so it can take multiple passes to flush all the dirty vnodes. Its normal to see this if the machine was at least moderately busy before being shut down. The number of dirty vnodes will start off at a high number, decrease rapidly at first, and then decrease to zero. It is not unusual to see the number bounce from zero back into the low single digits a few times before stabilizing at zero and triggering the syncer termination code. The syncer shutdown algorithm could definitely be improved to speed it up. I didn't want it to push out too many vnodes at the start of the shutdown sequence, but later in the sequence the delay intervals could be shortened and more worklist buckets could be visited per interval to speed the shutdown. One possible complication that I worry about is that the new vnodes being added to the list might not be added synchronously, so if the syncer processes the worklist and shuts down too quickly it might miss vnodes that got added too late. I've never seen a syncer shutdown timeout, though it could happen if either the underlying media became unwriteable or if a process got wedged while holding a vnode lock. In either case, it might never be possible to flush the dirty vnodes in question. The final sync code in boot() just iterated over the dirty buffers, but it was not unusual for it to get stuck on mutually dependent buffers. I would see this quite frequently if I did a shutdown immediately after running mergemaster. The final sync code would flush all but the last few buffers and finally time out. This problem was my motivation for adding the shutdown code to the syncer so that the final sync code would hopefully not have anything to do. The final sync code also gets confused if you have any ext2 file systems mounted (even read-only) and times out while waiting for the ext2 file system to release its private buffers (which only happens when the file system is unmounted). From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 03:02:04 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C979B16A41F for ; Wed, 20 Jul 2005 03:02:04 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C0E643D45 for ; Wed, 20 Jul 2005 03:02:04 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j6K31oX8042414; Tue, 19 Jul 2005 20:01:59 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200507200301.j6K31oX8042414@gw.catspoiler.org> Date: Tue, 19 Jul 2005 20:01:50 -0700 (PDT) From: Don Lewis To: davidt@yadt.co.uk In-Reply-To: <20050716133710.GA71580@outcold.yadt.co.uk> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 03:02:04 -0000 On 16 Jul, David Taylor wrote: > On Sat, 16 Jul 2005, Matthias Buelow wrote: >> David Taylor writes: >> >> >> A corrupted journal can be detected. If it's corrupted, discard >> >> the whole thing, or only the relevant entry. The filesystem will >> >> remain consistent. >> >> If track corruption occurs after the journal is written, it doesn't >> >> matter, since at boot the journal will be replayed and all operations >> >> will be performed once more. >> > >> >The track which is corrupted could contain data that wasn't written >> >to in months. How would the journal help? >> >> I don't understand this question. > > When the drive is powered off, the track being written to at that point > may be corrupted, right? That track may contain sectors that the OS > did't change. These sectors would not be mentioned in the journal. > How would a journaling fs fix the corruption? > > I suppose this could be avoided by requiring that all writes (and > journal entries) somehow correspond to a full track. (Which I suppose > they may do already, but I don't think so). The track size is not constant. There are more sectors in the outer cylinder tracks than there are in inner cylinder tracks. I'm not even sure if it is possible to extract the detailed geometry info from the drive. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 03:14:35 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1B0516A41F; Wed, 20 Jul 2005 03:14:35 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5763F43D53; Wed, 20 Jul 2005 03:14:35 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j6K3EOrj042431; Tue, 19 Jul 2005 20:14:28 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200507200314.j6K3EOrj042431@gw.catspoiler.org> Date: Tue, 19 Jul 2005 20:14:24 -0700 (PDT) From: Don Lewis To: mkb@incubus.de In-Reply-To: <20050714195253.GA23666@drjekyll.mkbuelow.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Cc: freebsd-stable@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 03:14:35 -0000 On 14 Jul, Matthias Buelow wrote: > Kevin Oberman wrote: > >>> How can I fix it on my system? >> >>SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or >>the sysctl. > > You do NOT want to do that. Not only will performance drop brutally > (example: drop to 1/5th of normal write speed for sequential writes, > probably worse for random writes) but it will also significantly > reduce the lifetime of your disk. Modern disks are designed to be > used with the write-back cache enabled, so don't turn it off. There's not much performance difference with SCSI if write caching is disabled. Typical SCSI drives can handle ~63 outstanding read and write transactions and can sort them into a somewhat optimal order if tagged command queuing is in use. >>The problem is that disks lie about whether they have actually written >>data. If the power goes off before the data is in cache, it's lost. > > No, the problem is that FreeBSD doesn't implement request barriers > and that softupdates is flawed by design and seemingly could not > make use of them, even if they were available (because, as I > understand it, it relies on a total ordering of all writes, unlike > the partial ordering necessary for a journalled fs). Softupdates only needs to be partial ordering. It just needs to be notified when the data hits the platter so that it can send any dependent writes to the disk. Wouldn't the use of barriers have the potential to force a lot of unrelated cached write data to be written much earlier than necessary? If so, there would seem to be a performance penalty under certain workloads, though performance would still be better than with write-caching disabled. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 03:22:53 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B656A16A41F; Wed, 20 Jul 2005 03:22:53 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63B2943D45; Wed, 20 Jul 2005 03:22:53 +0000 (GMT) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.13.3/8.13.3) with ESMTP id j6K3MfLR042449; Tue, 19 Jul 2005 20:22:45 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <200507200322.j6K3MfLR042449@gw.catspoiler.org> Date: Tue, 19 Jul 2005 20:22:41 -0700 (PDT) From: Don Lewis To: oberman@es.net In-Reply-To: <20050714191449.A8A615D07@ptavv.es.net> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8BIT Cc: freebsd-stable@FreeBSD.org, freebsd-questions@FreeBSD.org Subject: Re: dangerous situation with shutdown process X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 03:22:53 -0000 On 14 Jul, Kevin Oberman wrote: >> Date: Thu, 14 Jul 2005 20:38:15 +0200 >> From: Anatoliy Dmytriyev >> Sender: owner-freebsd-stable@freebsd.org >> >> Hello, everybody! >> >> I have found unusual and dangerous situation with shutdown process: >> I did a copy of 200 GB data on the 870 GB partition (softupdates is >> enabled) by cp command. >> It took a lot of time when I did umount for this partition exactly after >> cp, but procedure finished correctly. When you unmounted the file system, that should have flushed all the dirty files to the disk. >> In case, if I did “shutdown –h(r)”, also exactly after cp, the shutdown >> procedure waited for “sync” (umounting of the file system) but sync >> process was terminated by timeout, and fsck checked and did correction >> of the file system after boot. Did the timeout occur during the syncer shutdown, or at the "syncing disks ..." step. Did you have any ext2 file systems mounted? These should be manually unmounted before shutdown because they confuse the final sync code. >> System 5.4-stable, RAM 4GB, processor P-IV 3GHz. >> >> How can I fix it on my system? > > SCSI or ATA? If it's ATA, turn off write cache with (atacontrol(8) or > the sysctl. > > The problem is that disks lie about whether they have actually written > data. If the power goes off before the data is in cache, it's lost. That should only make a difference in a power-fail situation, and it only makes a difference if the only unwritten data is in the drive's write cache. > I am not sure if write-cache can be turned off on SCSI, but SCSI drives > seem less likely to lie about when the data is actually flushed to the > drive. Yes it can, and I recommend it. Use the camcontrol modepage command to set the WCE bit to 0. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 04:19:57 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 55AAD16A420 for ; Wed, 20 Jul 2005 04:19:57 +0000 (GMT) (envelope-from mi@blue.virtual-estates.net) Received: from mail25.sea5.speakeasy.net (mail25.sea5.speakeasy.net [69.17.117.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42B0043D46 for ; Wed, 20 Jul 2005 04:19:56 +0000 (GMT) (envelope-from mi@blue.virtual-estates.net) Received: (qmail 21758 invoked from network); 20 Jul 2005 04:19:55 -0000 Received: from aldan.algebra.com ([216.254.65.224]) (envelope-sender ) by mail25.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 20 Jul 2005 04:19:55 -0000 Received: from blue.virtual-estates.net ([10.0.1.140]) by aldan.algebra.com (8.13.1/8.13.1) with ESMTP id j6K4JqZt086888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Jul 2005 00:19:53 -0400 (EDT) (envelope-from mi@blue.virtual-estates.net) Received: from blue.virtual-estates.net (blue [127.0.0.1]) by blue.virtual-estates.net (8.13.3/8.13.3) with ESMTP id j6K4Jpqx083007; Wed, 20 Jul 2005 00:19:51 -0400 (EDT) (envelope-from mi@blue.virtual-estates.net) Received: (from mi@localhost) by blue.virtual-estates.net (8.13.3/8.13.3/Submit) id j6K4Jpgd083006; Wed, 20 Jul 2005 00:19:51 -0400 (EDT) (envelope-from mi) From: "Mikhail T." Message-Id: <200507200419.j6K4Jpgd083006@blue.virtual-estates.net> To: stable@FreeBSD.org, amd64@FreeBSD.org Date: Wed, 20 Jul 2005 00:19:51 -0400 (EDT) X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 04:19:57 -0000 Hello! After a couple of huge tarball extracts (`make extract' in jdk14 and jdk15) I noticed, things are a little slower. During the extracts, the mouse was moving with visible jerks. Indeed, the system seems VERY busy: 11 users Load 1.18 1.52 1.40 Jul 20 00:14 Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER Tot Share Tot Share Free in out in out Act 1060360 105932 1341624 145252 151016 count All 1750432 115908 8911872 174532 pages zfod Interrupts Proc:r p d s w Csw Trp Sys Int Sof Flt cow 1277 total 4 1146 1819 345 443k 1640 672 266572 wire 4 irq1: atkb 1204008 act 1004 irq0: clk 84.7%Sys 0.0%Intr 15.3%User 0.0%Nice 0.0%Idl 241536 inact irq6: fdc0 | | | | | | | | | | 62232 cache 128 irq8: rtc ==========================================>>>>>> 88784 free irq9: acpi daefr 113 irq12: psm Namei Name-cache Dir-cache prcfr irq15: ata Calls hits % hits % react irq16: ahc 3030 3030 100 pdwak 26 irq17: pcm pdpgs irq18: fwo Disks da0 cd0 cd1 pass0 pass1 pass2 intrn irq19: ohc KB/t 4.00 0.00 0.00 0.00 0.00 0.00 218912 buf irq27: skc tps 2 0 0 0 0 0 21 dirty 2 irq29: cis MB/s 0.01 0.00 0.00 0.00 0.00 0.00 100000 desiredvnodes % busy 0 0 0 0 0 0 92043 numvnodes The machine is idle and is not doing anything in user-space according to both top and vmstat's "pigs" display. Yet it is noticably slower. Trying to compile something pushes the load above 2. What is it doing? This is a single-CPU Opteron running: FreeBSD 5.4-STABLE #0: Fri Jun 10 09:11:30 EDT 2005 amd64 The box has 2Gb of RAM, but NO SWAP. Any ideas? Thanks! -mi From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 05:35:49 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BCCF216A41F; Wed, 20 Jul 2005 05:35:49 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (gate.funkthat.com [69.17.45.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id EDEF243D48; Wed, 20 Jul 2005 05:35:48 +0000 (GMT) (envelope-from jmg@hydrogen.funkthat.com) Received: from hydrogen.funkthat.com (localhost.funkthat.com [127.0.0.1]) by hydrogen.funkthat.com (8.13.3/8.13.3) with ESMTP id j6K5YXgK070763; Tue, 19 Jul 2005 22:34:33 -0700 (PDT) (envelope-from jmg@hydrogen.funkthat.com) Received: (from jmg@localhost) by hydrogen.funkthat.com (8.13.3/8.13.3/Submit) id j6K5YW6N070762; Tue, 19 Jul 2005 22:34:32 -0700 (PDT) (envelope-from jmg) Date: Tue, 19 Jul 2005 22:34:32 -0700 From: John-Mark Gurney To: "Mikhail T." Message-ID: <20050720053432.GA62369@funkthat.com> Mail-Followup-To: "Mikhail T." , stable@FreeBSD.org, amd64@FreeBSD.org References: <200507200419.j6K4Jpgd083006@blue.virtual-estates.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200507200419.j6K4Jpgd083006@blue.virtual-estates.net> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 5.4-RELEASE-p1 i386 X-PGP-Fingerprint: B7 EC EF F8 AE ED A7 31 96 7A 22 B3 D8 56 36 F4 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html Cc: amd64@FreeBSD.org, stable@FreeBSD.org Subject: Re: OS suddenly VERY busy X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: John-Mark Gurney List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 05:35:49 -0000 Mikhail T. wrote this message on Wed, Jul 20, 2005 at 00:19 -0400: > After a couple of huge tarball extracts (`make extract' in jdk14 and jdk15) > I noticed, things are a little slower. During the extracts, the mouse was > moving with visible jerks. Indeed, the system seems VERY busy: > > 11 users Load 1.18 1.52 1.40 Jul 20 00:14 > > Mem:KB REAL VIRTUAL VN PAGER SWAP PAGER > Tot Share Tot Share Free in out in out > Act 1060360 105932 1341624 145252 151016 count > All 1750432 115908 8911872 174532 pages > zfod Interrupts > Proc:r p d s w Csw Trp Sys Int Sof Flt cow 1277 total > 4 1146 1819 345 443k 1640 672 266572 wire 4 irq1: atkb ^^^^ well, I'd say 443k syscalls/time interval isn't doing nothing... [...] > The machine is idle and is not doing anything in user-space according to both > top and vmstat's "pigs" display. the problem is that your machine is sooooo fast that all of the processes that are running are exiting before they can be observed by pigs or top (or even accumulate enough cpu time to be worth showing)... > Yet it is noticably slower. Trying to compile something pushes the load above > 2. What is it doing? > > This is a single-CPU Opteron running: > > FreeBSD 5.4-STABLE #0: Fri Jun 10 09:11:30 EDT 2005 amd64 > > The box has 2Gb of RAM, but NO SWAP. run ps lax a few times, and notice which process is fork bombing your box by seeing which process has the most changing children... (i.e. the ppid, 3rd column, of the process that isn't in the next run)... sort -n +1 -2 + diff will help find which ones... ps lax | sort -n +1 -2 > tmpa; sleep 2; ps lax | sort -n +1 -2 > tmpb; diff tmpa tmpb look at the ppid (3rd column) of any new or missing processes, and you probably have your culprit... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 07:01:12 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3434216A428 for ; Wed, 20 Jul 2005 07:01:12 +0000 (GMT) (envelope-from dimma@torch.higis.ru) Received: from torch.higis.ru (gate.higis.ru [81.195.168.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 406D643D5D for ; Wed, 20 Jul 2005 07:01:09 +0000 (GMT) (envelope-from dimma@torch.higis.ru) Received: from localhost (localhost [127.0.0.1]) by torch.higis.ru (8.12.10/8.12.10) with ESMTP id j6K717ZZ091477 for ; Wed, 20 Jul 2005 11:01:07 +0400 (MSD) (envelope-from dimma@torch.higis.ru) Received: from torch.higis.ru ([127.0.0.1]) by localhost (torch.higis.ru [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 91088-08 for ; Wed, 20 Jul 2005 11:01:04 +0400 (MSD) Received: from torch.higis.ru (localhost [127.0.0.1]) by torch.higis.ru (8.12.10/8.12.10) with ESMTP id j6K712lx091470 for ; Wed, 20 Jul 2005 11:01:02 +0400 (MSD) (envelope-from dimma@torch.higis.ru) Received: (from dimma@localhost) by torch.higis.ru (8.12.10/8.12.10/Submit) id j6K712w6091468 for stable@freebsd.org; Wed, 20 Jul 2005 11:01:02 +0400 (MSD) (envelope-from dimma) Date: Wed, 20 Jul 2005 11:01:01 +0400 From: Dmitriy Kirhlarov To: stable@freebsd.org Message-ID: <20050720070101.GI22361@torch.higis.ru> References: <42DBF250.1060405@freebsdbrasil.com.br> <20050719174500.GA1594@doom.homeunix.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050719174500.GA1594@doom.homeunix.org> User-Agent: Mutt/1.5.6i X-Virus-Scanned: by amavisd-new at higis.ru Cc: Subject: Re: TinyBSD Call For Testers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 07:01:12 -0000 Hi Igor! On Tue, 19 Jul 2005, Igor Pokrovsky wrote: > On Mon, Jul 18, 2005 at 03:17:52PM -0300, Jean Milanez Melo wrote: > > Hello gentlemen, > > > > In the last saturday a new port has been added under sysutils/ category, > > ports/sysutils/tinybsd. TinyBSD is a tool which was meant to allow an > > easy way to build embedded systems based on FreeBSD. It is based on > > userland copying, library dependencies check/copy and kernel build. > > What's wrong with PicoBSD? AFAIR, PicoBSD not maintable on FreeBSD 5 and higher. By. Dmitriy From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 07:06:22 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B50416A41F for ; Wed, 20 Jul 2005 07:06:22 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2C0D543D45 for ; Wed, 20 Jul 2005 07:06:22 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from ranger.anduin.net ([81.0.162.52] helo=[192.168.1.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1Dv8eq-000Avj-J3; Wed, 20 Jul 2005 09:06:20 +0200 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <91151701-9D18-40D9-ACCC-48D6881167BE@anduin.net> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Eirik_=D8verby?= Date: Wed, 20 Jul 2005 09:06:15 +0200 To: J. Nyhuis X-Mailer: Apple Mail (2.733) Cc: freebsd-stable@freebsd.org Subject: Re: Q: RT32 (Request Tracker) + jail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 07:06:22 -0000 On Jul 20, 2005, at 2:22 AM, J. Nyhuis wrote: > Greetings, > > I would like to have RT running in a jailed environment. The > challenge, it seems, will be to get sendmail running in the same > jailed environment as RT and the other components. > For those not so familiar with the components of RT, the jail > would include apache1.3+modperl, MySQL, sendmail, and RT. That's a > lot of stuff to get working in there! (but fortunately FreeBSD > jails seem straightforward and easy) ^_^ > I expect sendmail to be the real problem of the above bunch. > > Has anyone actually tried to do this with a big multi-part app > like RT (I have not spotted anyone's documented attempts on Google) > and would be willing to share to the list? If I were you I would grab /usr/ports/sysutils/jailctl (ok, insert blatant self-praise here ;), create yourself one or more jails, and log into them as if they were normal fbsd installs. Everything you mention should work perfectly fine; I'm running anything between 5 and 50 jails of similiar types (with web, mail, database, cvs, subversion, you name it running in them, in various combinations) on both private and work-owned hosts, some of them performing extremely critical tasks (think CC payment handling for millions of users). Wouldn't worry about sendmail ;) > Does anyone else wonder if I've lost it? (Don't answer that)... Not at all. /Eirik > ^_^ > > Thanks, > > John H. Nyhuis > Sr. Computer Specialist > Dept. of Pediatrics > HS RR349B, Box 356320 > University of Washington > Desk: (206)-685-3884 > cabal@u.washington.edu > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" > > > From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 07:10:21 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 668DD16A420; Wed, 20 Jul 2005 07:10:21 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id F119943D46; Wed, 20 Jul 2005 07:10:20 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from ranger.anduin.net ([81.0.162.52] helo=[192.168.1.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1Dv8ih-000Axw-Rr; Wed, 20 Jul 2005 09:10:19 +0200 In-Reply-To: <42DBF250.1060405@freebsdbrasil.com.br> References: <42DBF250.1060405@freebsdbrasil.com.br> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <44C1CD9F-98FA-4CA2-83C6-903F0B19A38F@anduin.net> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Eirik_=D8verby?= Date: Wed, 20 Jul 2005 09:10:15 +0200 To: Jean Milanez Melo X-Mailer: Apple Mail (2.733) Cc: stable@freebsd.org, small@freebsd.org Subject: Re: TinyBSD Call For Testers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 07:10:21 -0000 On Jul 18, 2005, at 8:17 PM, Jean Milanez Melo wrote: > Hello gentlemen, > > In the last saturday a new port has been added under sysutils/ > category, ports/sysutils/tinybsd. TinyBSD is a tool which was meant > to allow an easy way to build embedded systems based on FreeBSD. It > is based on userland copying, library dependencies check/copy and > kernel build. > > We did our best to make the embedded system creation an easy and > specially fast proccess. The main (default) system generates an > embedded system image which is about 20MB in size, which is a very > generic approach, with a number of wired NIC support, and also the > most popular wireless support (including atheros), divert, bridge, > dummynet, firewall, etc; and CPU_ELAN (for soekris devices). If the > "generic" system gets tighten up the final result can be as low as > an 8MB embedded system. > > We are giving you this intro to ask you please to test TinyBSD out, > the most that you can, and send every possible feedback regarding > it. The main tinybsd goal is to make embedded systems creation a > process which must be > > 1 - fast > 2 - easy > 3 - 100% functional > > If you can test it, we would appreciate your thoughts. If you think > any of those 3 goals can't be reached for you, or could be > improved, also let me know. > > Thanks for testing Without having actually tried yet (time hasn't been very permitting lately), is it conceivable to use this tool to create slim-but- functional jails? Sans the kernel part, that is? /Eirik > > -- > Atenciosamente > Jean Milanez Melo > FreeBSD Brasil LTDA. > Fone: (31) 3281-9633 > http://www.freebsdbrasil.com.br > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable- > unsubscribe@freebsd.org" > > > From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 08:19:33 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3389916A422; Wed, 20 Jul 2005 08:19:33 +0000 (GMT) (envelope-from info@martenvijn.nl) Received: from martenvijn.nl (vijn.xs4all.nl [194.109.254.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5486B43D48; Wed, 20 Jul 2005 08:19:31 +0000 (GMT) (envelope-from info@martenvijn.nl) Received: from martenvijn.nl (localhost [127.0.0.1]) by martenvijn.nl (8.13.3/8.13.1) with ESMTP id j6K8KG4l057881; Wed, 20 Jul 2005 10:20:29 +0200 (CEST) (envelope-from info@martenvijn.nl) Received: (from www@localhost) by martenvijn.nl (8.13.3/8.13.1/Submit) id j6K8KAmU057880; Wed, 20 Jul 2005 10:20:10 +0200 (CEST) (envelope-from info@martenvijn.nl) X-Authentication-Warning: martenvijn.nl: www set sender to info@martenvijn.nl using -f Received: from 192.168.1.6 (SquirrelMail authenticated user mvn) by martenvijn.nl with HTTP; Wed, 20 Jul 2005 10:20:10 +0200 (CEST) Message-ID: <56065.192.168.1.6.1121847610.squirrel@martenvijn.nl> In-Reply-To: <42DBF250.1060405@freebsdbrasil.com.br> References: <42DBF250.1060405@freebsdbrasil.com.br> Date: Wed, 20 Jul 2005 10:20:10 +0200 (CEST) From: "Marten Vijn" To: "Jean Milanez Melo" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: stable@freebsd.org, small@freebsd.org Subject: Re: TinyBSD Call For Testers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: info@martenvijn.nl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 08:19:33 -0000 > Hello gentlemen, > > If you can test it, we would appreciate your thoughts. If you think any > of those 3 goals can't be reached for you, or could be improved, also > let me know. > Hi just had short look at it look nice & fast, first data from an via itx (dmesg, pciconf df) http://martenvijn.nl/tinybsd/via_board.txt for Soekris/wrap I 'll need to do to some kernel configs, I 'll let you know. I would be very nice to have some prefab menus for commom embedded hardware. Marten From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 09:03:31 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B2E4716A421 for ; Wed, 20 Jul 2005 09:03:31 +0000 (GMT) (envelope-from svein-freebsd-stable@theloosingend.net) Received: from merke.itea.ntnu.no (merke.itea.ntnu.no [129.241.7.61]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9420743D48 for ; Wed, 20 Jul 2005 09:03:28 +0000 (GMT) (envelope-from svein-freebsd-stable@theloosingend.net) Received: from localhost (localhost [127.0.0.1]) by merke.itea.ntnu.no (Postfix) with ESMTP id 5374B13C424 for ; Wed, 20 Jul 2005 11:03:27 +0200 (CEST) Received: from maren.thelosingend.net (maren.math.ntnu.no [129.241.211.48]) by merke.itea.ntnu.no (Postfix) with SMTP for ; Wed, 20 Jul 2005 11:03:26 +0200 (CEST) Received: (qmail 55973 invoked by uid 1001); 20 Jul 2005 11:03:26 +0200 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 20 Jul 2005 11:03:26 +0200 Date: Wed, 20 Jul 2005 11:03:26 +0200 (CEST) From: Svein Halvor Halvorsen X-X-Sender: sveinhal@maren.thelosingend.net To: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= In-Reply-To: <42DBEDD3.60906@t-hosting.hu> Message-ID: <20050720110027.Y48721@maren.thelosingend.net> References: <42DBEDD3.60906@t-hosting.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: rcNG issue X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: stable@freebsd.org List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 09:03:31 -0000 * K=F6vesd=E1n G=E1bor [2005-07-18 19:58 +0200] > I have a problem with my rcNG scripts. There are three scripts: named.sh= , > apache2.sh and proftpd.sh. Apache and ProFTPd require hostname resolving= thus > named should start firstly. The headers of my scripts are: : > And when I enable all the three scripts in rc.conf, the apache hangs bec= ause > it can't resolve the computer's hostname. It's really annoying, I have t= o > manually start it after a reboot, or wait for the cronscript that checks > whether it is running. > What's wrong? I think this magic only works in /etc/rc.d. Try renaming your startup=20 scripts 100.named.sh, 200.apache.sh, etc. I'm not sure, but FreeBSD used=20 to run these scripts in /usr/local/etc/rc.d in alphanumeric order, and I=20 presume that this functionality is preserved in 5.x to allow for backwards= =20 compatibility. Svein Halvor From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 09:20:56 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5729A16A41F for ; Wed, 20 Jul 2005 09:20:56 +0000 (GMT) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8294843D49 for ; Wed, 20 Jul 2005 09:20:55 +0000 (GMT) (envelope-from rb@gid.co.uk) Received: (from rb@localhost) by gidgate.gid.co.uk (8.11.7/8.11.6) id j6K9KrW54826; Wed, 20 Jul 2005 10:20:53 +0100 (BST) (envelope-from rb) Message-Id: <6.2.0.14.2.20050720101853.04c0cac8@gid.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Wed, 20 Jul 2005 10:20:49 +0100 To: Dmitriy Kirhlarov , stable@freebsd.org From: Bob Bishop In-Reply-To: <20050720070101.GI22361@torch.higis.ru> References: <42DBF250.1060405@freebsdbrasil.com.br> <20050719174500.GA1594@doom.homeunix.org> <20050720070101.GI22361@torch.higis.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Subject: Re: TinyBSD Call For Testers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 09:20:56 -0000 At 08:01 20/07/2005, Dmitriy Kirhlarov wrote: >Hi Igor! > >On Tue, 19 Jul 2005, Igor Pokrovsky wrote: >[...] > > What's wrong with PicoBSD? > >AFAIR, PicoBSD not maintable on FreeBSD 5 and higher. # sysctl kern.version kern.version: FreeBSD 5.3-RELEASE #0: Wed Jul 6 14:47:03 BST 2005 rb@spambox3.gid.co.uk:/usr/home/rb/build_dir-pxe_install/PICOBSD-pxe_install (with only very minor hacking). -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 10:49:34 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 484D016A41F for ; Wed, 20 Jul 2005 10:49:34 +0000 (GMT) (envelope-from loader@freebsdmall.com) Received: from mail.freebsdmall.com (ns1.freebsdmall.com [69.50.233.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0437E43D45 for ; Wed, 20 Jul 2005 10:49:34 +0000 (GMT) (envelope-from loader@freebsdmall.com) Received: by mail.freebsdmall.com (Postfix, from userid 2136) id E08E41CE55; Wed, 20 Jul 2005 03:49:33 -0700 (PDT) X-Mailer: emacs 22.0.50.1 (via feedmail 8 I) To: "Li Ruijiang" References: From: loader X-GPG-Public-Key: http://www.freebsdmall.com/~loader/loader.asc X-GPG-Key-ID: 1024D/0277E075 X-GPG-Key-Fingerprint: F8A0 A354 5D97 B175 7FC9 15DC 0771 07CF 0277 E075 Date: Wed, 20 Jul 2005 19:07:54 +0000 In-Reply-To: (Li Ruijiang's message of "Fri, 15 Jul 2005 23:19:53 +0800") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-stable@freebsd.org Subject: Re: HELP --a question on LOCALE X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 10:49:34 -0000 "Li Ruijiang" writes: > I am a chinese user,and today I upgraded my FreeBSD system from 5.3 > release to 6.0 > all is successful except that I can not input chinese. > The XIM needs two environment variables:LANG and LC_ALL > so I export them to zh_CN.GBK in my .xinitrc file > when the X was started I tested it using "echo $LANG"and "echo > $LC_ALL".I got the right response. > > But when when I type "locale", I got a response like this: > LANG=zh_CN.GBK > LC_CTYPE="C" > LC_COLLATE="C" > LC_TIME="C" > LC_NUMERIC="C" > LC_MONETARY="C" > LC_MESSAGES="C" > LC_ALL=zh_CN.GBK > > > So LC_CTYPE and LC_* were not modified > > then I "export LC_CTYPE=zh_CN.GBK" > when I "echo $LC_CTYPE" it said "zh_CN.GBK" > when I "locale" the result did not change at all. > > I have installed "localedata-5.4" and set PATH_LOCALE > when I "locale -a" > the result contains zh_CN.GBK > > What should I do??? > Thank you very much. > I'm running 6.0-BETA1 and recompiled all the ports installed in system. I just ran setenv LC_CTYPE zh_CN.GB2312 setenv XMODIFIERS @im=fcitx fcitx & and ran some applications like emacs, mlterm, aterm... they all worked for me. Then I tried to set the LC_CTYPE to zh_CN.GBK, the XIM still working. Only the characters can't be displayed correct, since I only have the X core fonts installed. And I didn't installed misc/localedata. Maybe you can have a try to recompile the applications which you want to use XIM with? Regards, loader From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 11:30:22 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29D4616A41F; Wed, 20 Jul 2005 11:30:22 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id BC29F43D49; Wed, 20 Jul 2005 11:30:21 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from eirik.unicore.no ([213.225.74.166] helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DvCmK-000EiB-67; Wed, 20 Jul 2005 13:30:20 +0200 In-Reply-To: <20050410124013.W4310@fledge.watson.org> References: <20050410102753.d63hhe8vpcs8wsgg@anduin.net> <20050410124013.W4310@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Eirik_=D8verby?= Date: Wed, 20 Jul 2005 13:30:15 +0200 To: Robert Watson X-Mailer: Apple Mail (2.733) Cc: stable@freebsd.org Subject: Re: Panic when logging out from serial console X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 11:30:22 -0000 On Apr 10, 2005, at 1:42 PM, Robert Watson wrote: > > On Sun, 10 Apr 2005 ltning@anduin.net wrote: > > >> warning: This report might be somewhat vague. For quite a while >> now I`ve been plagued with the problem that logging out from a >> serial console causes the box to panic. For a while I`ve been sure >> this was isolated to one of my boxen, because it`s been acting up >> in other ways as well, but today it happened on two other boxes >> too! And these boxes have been rock stable for the last two years. >> >> I`m running a fairly recent variation of RELENG-5 on all the >> boxes; one of them is amd64, the two others - including the one >> I`ve pasted from - are plain old p3 machines. They are all dual- >> CPU though. >> > > I've seen precisely this panic -- in fact, I saw it yesterday on a > RELENG_5 box, and under identical circumstances -- it looks like it > happens if a last process in a login session on a serial console > closes the tty, and then getty re-opens it while there's console > output coming from syslog. I was able to get a core dump, but > haven't made much headway on it yet. It looks like the tty > structure has been released -- the refcount on the tty is 0, and > the mutex pointers in the kqueue state have been cleared (hence the > null pointer dereference you see). Now, the question is why -- > I've added some debugging output to the local box I saw it on, and > will see if I can reproduce it. Did you ever manage to reproduce - or fix - this? I had a rather nasty incident recently due to this, even on a very recently updated 5.4. I sent a message to stable@ about it a few days ago, but have received no response. I personally think that this must be very very (very) bad - serial consoles shouldn't do this! ;) /Eirik > > Robert N M Watson > > >> >> I have no clue what I can do from here; has anyone seen this >> before? I can`t >> always reproduce it, but the risk is fairly high - around 33% I`d >> say. >> >> Anyone? >> >> Thanks for your attention, details below. >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 1; apic id = 00 >> fault virtual address = 0x1c >> fault code = supervisor write, page not present >> instruction pointer = 0x8:0xc0620b5f >> stack pointer = 0x10:0xdadbd988 >> frame pointer = 0x10:0xdadbd994 >> code segment = base 0x0, limit 0xfffff, type 0x1b >> = DPL 0, pres 1, def32 1, gran 1 >> processor eflags = interrupt enabled, resume, IOPL = 0 >> current process = 51999 (getty) >> trap number = 12 >> panic: page fault >> cpuid = 1 >> boot() called on cpu#0 >> Uptime: 66d11h24m50s >> >> >> >> /Eirik >> >> ---------------------------------------------------------------- >> This message was sent using IMP, the Internet Messaging Program. >> >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable- >> unsubscribe@freebsd.org" >> >> > > From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 12:48:42 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7729D16A41F; Wed, 20 Jul 2005 12:48:42 +0000 (GMT) (envelope-from etoll@vipstructures.com) Received: from rodan.vipstructures.com (rodan.vipstructures.com [66.195.71.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id 080FF43D4C; Wed, 20 Jul 2005 12:48:41 +0000 (GMT) (envelope-from etoll@vipstructures.com) Received: from localhost (localhost.vipstructures.com [127.0.0.1]) by rodan.vipstructures.com (Postfix) with ESMTP id 3B5151EE83E; Wed, 20 Jul 2005 08:48:41 -0400 (EDT) Received: from mothra.vipstructures.com (mothra.vipstructures.com [192.168.1.3]) by rodan.vipstructures.com (Postfix) with ESMTP id F3DC21EE83A; Wed, 20 Jul 2005 08:48:40 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 20 Jul 2005 08:50:14 -0400 Message-ID: <9BC86C67C3AF7646B9C5382020457A944E4DA9@VIP10-WIN2K> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OS suddenly VERY busy Thread-Index: AcWM4oj4bqQQhCozTZ+VpIcbq0EUdgARLMCg From: "Toll, Eric" To: , , Cc: Subject: RE: OS suddenly VERY busy X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 12:48:42 -0000 > Subject: OS suddenly VERY busy >=20 > Hello! >=20 > After a couple of huge tarball extracts (`make extract' in > jdk14 and jdk15) I noticed, things are a little slower.=20 > During the extracts, the mouse was moving with visible jerks.=20 > Indeed, the system seems VERY busy: >=20 > The machine is idle and is not doing anything in user-space=20 > according to both top and vmstat's "pigs" display. >=20 > Yet it is noticably slower. Trying to compile something=20 > pushes the load above 2. What is it doing? >=20 > This is a single-CPU Opteron running: >=20 > FreeBSD 5.4-STABLE #0: Fri Jun 10 09:11:30 EDT 2005 amd64 >=20 > The box has 2Gb of RAM, but NO SWAP. >=20 > Any ideas? Thanks! >=20 Irq 15 is your IDE disk. The slowest part of a server will always be the disk, this is your bottleneck. I tried working with jdk14: (*and still cannot install it, will you post your install sequence please?*) Some of the files where large. I noticed nothing really performance wise when working with with some of the 50M plus tar files. I do have dual 242's and a 64bit 3Ware card (in a 64Bit slot) that has harware XOR's in it so my cpu's never have to do direct disk work per se. One of the install processes recommends you have 1.4Gb of free work space. This may also be an issue. Why no swap partition? Was this intentional? Also how much RAM? I have 1Gb. What does df -h say? I have mine like this. Raid 1 Array with SATA drives. I'm worried I made /var too small... Filesystem Size Used Avail Capacity Mounted on /dev/twed0s1a 989M 93M 817M 10% / devfs 1.0K 1.0K 0B 100% /dev /dev/twed0s1d 3.9G 458K 3.6G 0% /tmp /dev/twed0s1f 178G 18G 146G 11% /usr /dev/twed0s1e 39G 882M 35G 2% /var From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 14:02:44 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69C1616A4A5 for ; Wed, 20 Jul 2005 14:02:44 +0000 (GMT) (envelope-from voovoos-stable@killfile.pl) Received: from mailhub.media4u.pl (mailhub.media4u.pl [195.136.117.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D2A743E1A for ; Wed, 20 Jul 2005 13:58:23 +0000 (GMT) (envelope-from voovoos-stable@killfile.pl) Received: from mail.media4u.pl ([212.160.180.13]:51104) by mailhub.media4u.pl with esmtp (Exim 4.51) id 1DvF7A-0009Ok-Ih for freebsd-stable@freebsd.org; Wed, 20 Jul 2005 16:00:00 +0200 Received: from media4u-do-gw.dabrowskiego247.media4u.net.pl ([195.136.117.70]:62845 helo=[192.168.9.4]) by mail.media4u.pl with esmtpa (Exim 4.51) id 1DvF7A-0009OR-6D for freebsd-stable@freebsd.org; Wed, 20 Jul 2005 16:00:00 +0200 Message-ID: <42DE5865.8010401@killfile.pl> Date: Wed, 20 Jul 2005 15:57:57 +0200 From: Maciej Wierzbicki Organization: =?ISO-8859-2?Q?=AFyjemy_W_Kraju_Cudownych_Metafor?= User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: pl, en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: FreeBSD -STABLE servers repeatedly crashing. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 14:02:45 -0000 Gary Mulder wrote on 2005-07-18 23:39: > From personal experience I can repeat what Matt has stated. It seems to be > related to what NIC you have. I have had crashes with fxp (Intel Pro > 100MBit) and bge (Broadcom Gigabit) NICs under moderate network load. It seems not. I had crashes with fxp, xl, bge and em, IIRC. > Removing ipf reduced but did not eliminate the crashes. Removing IPF elimitated crashes in every case of my SMP boxes. -- * Maciej Wierzbicki * At paranoia's poison door * * VOO1-RIPE VOO1-6BONE * From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 14:43:38 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEA4716A420 for ; Wed, 20 Jul 2005 14:43:38 +0000 (GMT) (envelope-from jmelo@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 9F81843D53 for ; Wed, 20 Jul 2005 14:43:36 +0000 (GMT) (envelope-from jmelo@freebsdbrasil.com.br) Received: (qmail 50683 invoked by uid 0); 20 Jul 2005 11:43:37 -0300 Received: from jmelo@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (uvscan: v4.3.20/v4538. spamassassin: 2.64. Clear:RC:1(201.17.165.147):. Processed in 0.389328 secs); 20 Jul 2005 14:43:37 -0000 Received: from unknown (HELO ?10.69.69.2?) (201.17.165.147) by capeta.freebsdbrasil.com.br with SMTP; 20 Jul 2005 11:43:36 -0300 Message-ID: <42DE6345.5010904@freebsdbrasil.com.br> Date: Wed, 20 Jul 2005 11:44:21 -0300 From: Jean Milanez Melo User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050614) X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Eirik_=D8verby?= References: <42DBF250.1060405@freebsdbrasil.com.br> <44C1CD9F-98FA-4CA2-83C6-903F0B19A38F@anduin.net> In-Reply-To: <44C1CD9F-98FA-4CA2-83C6-903F0B19A38F@anduin.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: stable@freebsd.org, small@freebsd.org Subject: Re: TinyBSD Call For Testers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 14:43:39 -0000 Eirik Øverby wrote: > > > Without having actually tried yet (time hasn't been very permitting > lately), is it conceivable to use this tool to create slim-but- > functional jails? Sans the kernel part, that is? > > /Eirik > The main goal is not this, but you can do that with some few changes. -- Atenciosamente Jean Milanez Melo FreeBSD Brasil LTDA. Fone: (31) 3281-9633 http://www.freebsdbrasil.com.br From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 15:57:33 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 290EB16A41F for ; Wed, 20 Jul 2005 15:57:33 +0000 (GMT) (envelope-from pczanik@fang.fa.gau.hu) Received: from mail-gw2.sa.eol.hu (mail-gw2.sa.eol.hu [212.108.200.109]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97A8C43D45 for ; Wed, 20 Jul 2005 15:57:29 +0000 (GMT) (envelope-from pczanik@fang.fa.gau.hu) Received: from [193.226.238.32] (238-032.adsl.pool.ew.hu [193.226.238.32]) by mail-gw2.sa.eol.hu (mu) with ESMTP id j6KFvNwh026150 for ; Wed, 20 Jul 2005 17:57:28 +0200 Message-ID: <42DE7461.7000606@fang.fa.gau.hu> Date: Wed, 20 Jul 2005 17:57:21 +0200 From: Peter Czanik User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit Subject: ahd problems on 5.4-STABLE and 6.0-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 15:57:33 -0000 Hello, It seems to me, that the 'ahd' driver got some problems on both 5.4-STABLE and 6.0-BETA1. My hardware is a HP Workstation 6000, with an on-board Adaptec SCSI controller, which is disabled in BIOS, as I only have IDE CD- and harddrives. I start with 6.0-BETA1, as it's the easier one: when I boot the install CD, it finds the controller, writes "Unable to read SEEPROM", it waits a few seconds, writes another 20 lines of error messages on screen, then reboots the computer, so there isn't time to read the rest of messages and can't install the beta. 5.4-STABLE: simptoms are the same on my installed 5.4-STABLE machine, I can read "Unable to read SEEPROM", it waits, prints some more messages, and reboots. When I boot an older kernel (from the 29th of June), the kernel finds the controller, and works fine. Compiling a kernel without ahd support (commenting out: '#device ahd') solves the problem as well, and the machine boots fine. This is part of dmesg from the old kernel: Jul 20 13:48:02 beech kernel: ahd0: at device 12.0 on pci5 Jul 20 13:48:02 beech kernel: aic7902: Ultra320 Wide Channel A, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs Jul 20 13:48:02 beech kernel: ahd1: at device 12.1 on pci5 Jul 20 13:48:02 beech kernel: aic7902: Ultra320 Wide Channel B, SCSI Id=7, PCI 33 or 66Mhz, 512 SCBs Bye, Peter From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 19:41:19 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7385916A41F for ; Wed, 20 Jul 2005 19:41:19 +0000 (GMT) (envelope-from destroyingculture@netspace.net.au) Received: from mail.netspace.net.au (whirlwind.netspace.net.au [203.10.110.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1BA9F43D48 for ; Wed, 20 Jul 2005 19:41:18 +0000 (GMT) (envelope-from destroyingculture@netspace.net.au) Received: from [220.253.50.133] (220-253-50-133.VIC.netspace.net.au [220.253.50.133]) by mail.netspace.net.au (Postfix) with ESMTP id 3C52C12DDD9 for ; Thu, 21 Jul 2005 05:41:16 +1000 (EST) Message-ID: <42DEA92E.7020705@netspace.net.au> Date: Thu, 21 Jul 2005 05:42:38 +1000 From: caleb User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050530) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: IrDA question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 19:41:19 -0000 Hi, I have been having some problems getting the Ir device on my laptop working. The device is listed as serial port B and a FIR device in BIOS, the laptop motherboard is an Intel 855pm (the Ir device is onboard). dmesg shows that the device is detected and listed as a serial device. Because BIOS listed it as serial port B I am assuming it is sio1; sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 onacpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 drq 1 on acpi0 sio1: type 16550A I have installed birda and can run irs. When I type the follwing irs starts but when I use my mobile phone to search for a device or send a file the phone reports 'No device found'. irs -v 1 -e -c -y /dev/ptypv -d /dev/cuaa1 I do not understand why this is happening as I have specifiede the 'c' option so irs runs as a COMM server. I also set 'y' to use a psudo terminal. Do I need a specific application like pilot-link for palm to communicatate over the Ir link that irs has initiated? Thanks, caleb -- There is no spoon. From owner-freebsd-stable@FreeBSD.ORG Wed Jul 20 22:53:35 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73E7416A421 for ; Wed, 20 Jul 2005 22:53:35 +0000 (GMT) (envelope-from jw@innerewut.de) Received: from smtprelay02.ispgateway.de (smtprelay02.ispgateway.de [80.67.18.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC88843D4C for ; Wed, 20 Jul 2005 22:53:33 +0000 (GMT) (envelope-from jw@innerewut.de) Received: (qmail 560 invoked from network); 20 Jul 2005 22:53:31 -0000 Received: from unknown (HELO [192.168.0.200]) (068076@[85.178.241.85]) (envelope-sender ) by smtprelay02.ispgateway.de (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 20 Jul 2005 22:53:31 -0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Thu, 21 Jul 2005 00:53:28 +0200 From: Jonathan Weiss To: FreeBSD-Stable Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re:RELENG_6 has problems with booting X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jul 2005 22:53:35 -0000 >> >>> What happens if you drop ATAPICAM and do you have a good reason why you >>> are including GEOM_BDE? >>> >>> Thanks >>> S. >> >> I will try a kernel without ATAPICAM. >> >> I need GEOM_BDE for my encrypted disk but I can also try a kernel without >> it. > > A kernel without ATAPICAM will also result in a hang during normal/verbose > boot. > > With a kernel without GEOM_BDE I'm able to boot normally but the machine > hanged some minutes later. Again no panic, the machine just hangs. > > When I do a boot in safe mode, everything is ok. > I also tried a GENERIC. The result is the same as without GEOM_BDE, I can boot normally but the machine will hang some minutes later. When I boot in safe mode, the machine is usable for at least one or two days (I then tried the other kernel). Any hints? Jonathan -- Jonathan Weiss http://blog.innerewut.de From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 00:44:49 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5394616A42C for ; Thu, 21 Jul 2005 00:44:49 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64DEE43D67 for ; Thu, 21 Jul 2005 00:44:35 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j6L0iL1V008965 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 21 Jul 2005 10:14:26 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Thu, 21 Jul 2005 10:14:17 +0930 User-Agent: KMail/1.8.1 References: <42DEA92E.7020705@netspace.net.au> In-Reply-To: <42DEA92E.7020705@netspace.net.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5610640.4kzN6M8Srf"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507211014.18102.doconnor@gsoft.com.au> X-Spam-Score: -2.82 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: caleb Subject: Re: IrDA question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 00:44:49 -0000 --nextPart5610640.4kzN6M8Srf Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 21 July 2005 05:12, caleb wrote: > I have installed birda and can run irs. When I type the follwing irs > starts but when I use my mobile phone to search for a device or send a > file the phone reports 'No device found'. > > irs -v 1 -e -c -y /dev/ptypv -d /dev/cuaa1 > > I do not understand why this is happening as I have specifiede the 'c' > option so irs runs as a COMM server. I also set 'y' to use a psudo > terminal. Do I need a specific application like pilot-link for palm to > communicatate over the Ir link that irs has initiated? Are you sure the port is right? Tried cuaa0? I have gotten my laptop (Dell Inspiron 8600) to talk to my phone (Nokia 821= 0)=20 and Pocket PC using IRDA. I use ircomm though, ie [inchoate 10:07] ~ >sudo ircomm -d /dev/cuad1 -y /dev/ptypv -v 2 discovered Nokia 8210, address=3D75a2, hints=3DPnP, Modem, Fax, Telephony, = IrCOMM,=20 IrOBEX query completed 115200 baud LAP connected comm connected Now I can do, say, [inchoate 10:12] ~ >cu -l /dev/ttypv -s 57600 can't open log file /var/log/aculog. Connected atz OK AT+CMGF=3D1 OK AT+CMGS=3D"0403070726" > testing 123 > =E2=96=92 +CMGS: 221 OK One this I have noticed is that my phone is *extremely* sensitive to=20 positioning which is rather annoying.. It has to be 15-20cm away otherwise = it=20 won't work (closer is as bad as far away). =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart5610640.4kzN6M8Srf Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC3u/i5ZPcIHs/zowRAlJ4AJ9GiPvjnhFymZaZtO5Hdjq1Sy47JgCaAmdN EeNutoae2lKg9wjm2CgRjGA= =VOM3 -----END PGP SIGNATURE----- --nextPart5610640.4kzN6M8Srf-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 03:43:54 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1130616A424 for ; Thu, 21 Jul 2005 03:43:54 +0000 (GMT) (envelope-from aiy@ferens.net) Received: from rwcrmhc12.comcast.net (rwcrmhc13.comcast.net [204.127.198.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CEE643D48 for ; Thu, 21 Jul 2005 03:43:44 +0000 (GMT) (envelope-from aiy@ferens.net) Received: from ferens.net ([67.188.76.62]) by comcast.net (rwcrmhc13) with ESMTP id <20050721034343015001tno6e>; Thu, 21 Jul 2005 03:43:43 +0000 Received: from [192.168.1.201] ([192.168.1.1]) (authenticated bits=0) by ferens.net (8.13.4/8.13.4) with ESMTP id j6L3hYQ0000889 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Wed, 20 Jul 2005 20:43:37 -0700 (PDT) (envelope-from aiy@ferens.net) From: Alexey Yakimovich To: freebsd-stable@freebsd.org Content-Type: text/plain Date: Wed, 20 Jul 2005 20:43:33 -0700 Message-Id: <1121917413.4895.47.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-FerensNet-MailScanner-Information: Please contact the ISP for more information X-FerensNet-MailScanner: Found to be clean X-FerensNet-MailScanner-From: aiy@ferens.net Subject: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 03:43:54 -0000 Hello, I've been using FreeBSD since 2.1 release. I really like it. I like everything: kernel, ports, development, maintenance and release process. Unfortunately I have so many problems with release 5, with ATA (FAILURE - READ_DMA, TIMEOUT - READ_DMA, etc) in particularly. Definitely I was using production releases only. Finally after so many system rebuilds I found 5.3-RELEASE-p13 very stable. But because of my previous great experience with FreeBSD I decided to upgrade my 5.3 production to 5.4 production (5.4-RELEASE-p4). Now I have the same ATA problems as I had with first 5.3 "production" release. Please don't tell me that I have bad disk or m/b or ATA controller or cable. I'm pretty sure, 90%, it's not hardware related problem. My advice to FreeBSD release engineering team: - do more testing; - have it tested with hardware what was published in "Hardware Notes"; - do not release it for production if it is not in production quality; - reread again what was written by yourself regarding 4.4 release quality. I wish to say more. This mail was written because I like FreeBSD and I want to continue using it. And wouldn't mind to wait longer for real production quality releases instead of start using something else. And please, I know, it's open source project. Best regards, Real FreeBSD fan From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 04:13:24 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7D1D16A41F for ; Thu, 21 Jul 2005 04:13:24 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7FC1843D4C for ; Thu, 21 Jul 2005 04:13:08 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j6L4D7NV014778 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 00:13:07 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j6L4D36P011638; Thu, 21 Jul 2005 00:13:04 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2FE8751202; Wed, 20 Jul 2005 14:41:17 -0400 (EDT) Date: Wed, 20 Jul 2005 14:41:17 -0400 From: Kris Kennaway To: Maciej Wierzbicki Message-ID: <20050720184116.GA53378@xor.obsecurity.org> References: <42DE5865.8010401@killfile.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sdtB3X0nJg68CQEu" Content-Disposition: inline In-Reply-To: <42DE5865.8010401@killfile.pl> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: FreeBSD -STABLE servers repeatedly crashing. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 04:13:25 -0000 --sdtB3X0nJg68CQEu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2005 at 03:57:57PM +0200, Maciej Wierzbicki wrote: > Gary Mulder wrote on 2005-07-18 23:39: >=20 > >From personal experience I can repeat what Matt has stated. It seems to = be=20 > >related to what NIC you have. I have had crashes with fxp (Intel Pro=20 > >100MBit) and bge (Broadcom Gigabit) NICs under moderate network load. >=20 > It seems not. I had crashes with fxp, xl, bge and em, IIRC. >=20 > >Removing ipf reduced but did not eliminate the crashes. >=20 > Removing IPF elimitated crashes in every case of my SMP boxes. Folks, you're talking about different things: * Panics with IPF enabled on SMP and any network card (network card is not relevant for this problem, which is IPF). This problem is understood, and the only current solution is 'don't use both of SMP and IPF'. * What Gary is talking about, which are apparently panics without IPF enabled on several NICs. Since this is a new problem, Gary needs to do some additional diagnosis work so that someone can investigate them. Let's try to keep the issue clear :-) Kris --sdtB3X0nJg68CQEu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3prMWry0BWjoQKURAoxvAKDMclOusyVLcU/q6ztd2SV8QXHb3wCgsi+g H0dojsTb9Vdc9enc2+V4B1I= =cY6J -----END PGP SIGNATURE----- --sdtB3X0nJg68CQEu-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 04:22:58 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 36D5216A41F for ; Thu, 21 Jul 2005 04:22:58 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1B5643DB5 for ; Thu, 21 Jul 2005 04:22:47 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j6L4MjNV015759 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 00:22:45 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j6L4Me6X012420; Thu, 21 Jul 2005 00:22:44 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 9692554A7F; Mon, 18 Jul 2005 19:42:02 -0400 (EDT) Date: Mon, 18 Jul 2005 19:42:02 -0400 From: Kris Kennaway To: Gary Mulder Message-ID: <20050718234202.GB68899@xor.obsecurity.org> References: <20050718204324.GA37192@shellma.zin.lublin.pl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TRYliJ5NKNqkz5bu" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@FreeBSD.org Subject: Re: FreeBSD -STABLE servers repeatedly crashing. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 04:22:58 -0000 --TRYliJ5NKNqkz5bu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 18, 2005 at 05:39:40PM -0400, Gary Mulder wrote: > On Mon, 18 Jul 2005, Pawel Malachowski wrote: >=20 > > On Mon, Jul 18, 2005 at 04:09:58PM -0400, Matt Juszczak wrote: > >=20 > > > Correct. IPF is unstable with our SMP (most of the time) - based 5.x= =20 > > > boxes. VERY unstable. VERY VERY unstable. > >=20 > > Hm, this sounds bad. What is debug.mpsafenet set to? How big is traffic? > >=20 > > I have one SMP box with ipnat, routing some megabits (even during night > > it's more than 30-40Mbps) without problems, however, ipnat is used only > > for very small group of hosts right now. > > But we plan to use ipnat more heavily so it sounds a bit scary. ;) > =20 > >From personal experience I can repeat what Matt has stated. It seems to = be=20 > related to what NIC you have. I have had crashes with fxp (Intel Pro=20 > 100MBit) and bge (Broadcom Gigabit) NICs under moderate network load.=20 > Removing ipf reduced but did not eliminate the crashes. debug.mpsafe also= =20 > reduced but did not eliminate the crashes. No, that's different then. Please report your bugs in the usual way (gdb traceback, etc). Kris --TRYliJ5NKNqkz5bu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD4DBQFC3D5KWry0BWjoQKURAihuAKDjccMjQp6NuC1DH3uvo2gzxq7sJACY0YVb 6A0YnALvYYYkGXCmk/t9Gg== =Tf9H -----END PGP SIGNATURE----- --TRYliJ5NKNqkz5bu-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 04:54:45 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 84A4816A41F for ; Thu, 21 Jul 2005 04:54:45 +0000 (GMT) (envelope-from news649@powersystemsdirect.com) Received: from sccrmhc13.comcast.net (sccrmhc13.comcast.net [204.127.202.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE30F43D70 for ; Thu, 21 Jul 2005 04:54:40 +0000 (GMT) (envelope-from news649@powersystemsdirect.com) Received: from [192.168.1.6] (c-24-1-170-82.hsd1.tx.comcast.net[24.1.170.82]) by comcast.net (sccrmhc13) with ESMTP id <2005072104544001300cro8qe>; Thu, 21 Jul 2005 04:54:40 +0000 Message-ID: <42DF2A8F.30202@powersystemsdirect.com> Date: Wed, 20 Jul 2005 23:54:39 -0500 From: Steve User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: READ_DMA, WRITE_DMA errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 04:54:46 -0000 I've found tons of emails, news messages, listserv messages, and even some bug reports of this seemingly common error. So, I had been running 5.2 on a server, and, updated to 5.3. Got the READ_DMA and WRITE_DMA error and retries. So, figuring it might be a bad update, took a new drive. put it in, loaded 5.4 for grins, and, same issue, lots of these errors, eventually destroying the FS. Played around with various settings, no avail. So, took it back, got different box, everything new. Same problem, new install of 5.4 So, took it back, got another with another MB (different model), but, same maker (ASUS). Didn't have endless time to spend on production machine. Sure enough, same problem. It's an ASUS A7V880. Controller is SATA VT8237. Played around with tons of settings, eventually, after reading various messages out there, discovered one that resolved the problem. Had to set hw.ata.ata_dma="0". Of course, there is the obvious downside to that! Speed! But it stinks to have "decent" hardware, yet, have to cripple the machine. The place I got the equipment at runs ASUS only and has thousands of them running under other OSes. Wished I had stayed with the old FreeBSD version and old hardware now. I have not seen anyone that has ever said the problem was being (or had been) solved though. I see the bug reports, I take it no one has actually pinpointed the problem though. BUT, I do hope it is understood that this is fairly widespread, for me, the likelihood of 3 pcs, 2 different MB models, and, *complete* new hardware for each of the 3 pcs kind of rules out hardware being broken, might be badly designed, but, certainly not defective hardware. I do hope someone can eventually figure this out, seems to be extremely common, and, definitely a problem for a stable release named 5.4. Steve www.powersystemsdirect.com From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 04:57:57 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C8DCF16A41F for ; Thu, 21 Jul 2005 04:57:57 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from hub.org (hub.org [200.46.204.220]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FD8243D48 for ; Thu, 21 Jul 2005 04:57:57 +0000 (GMT) (envelope-from scrappy@hub.org) Received: from localhost (unknown [200.46.204.144]) by hub.org (Postfix) with ESMTP id 94147A24656 for ; Thu, 21 Jul 2005 01:57:55 -0300 (ADT) Received: from hub.org ([200.46.204.220]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 58880-05 for ; Thu, 21 Jul 2005 04:57:55 +0000 (GMT) Received: from ganymede.hub.org (blk-224-176-51.eastlink.ca [24.224.176.51]) by hub.org (Postfix) with ESMTP id 313B1A24632 for ; Thu, 21 Jul 2005 01:57:55 -0300 (ADT) Received: by ganymede.hub.org (Postfix, from userid 1000) id B803839688; Thu, 21 Jul 2005 01:57:55 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by ganymede.hub.org (Postfix) with ESMTP id B3BBF3965A for ; Thu, 21 Jul 2005 01:57:55 -0300 (ADT) Date: Thu, 21 Jul 2005 01:57:55 -0300 (ADT) From: "Marc G. Fournier" To: freebsd-stable@freebsd.org Message-ID: <20050721015351.O36717@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: by amavisd-new at hub.org Subject: em driver "broken" in 4.11-STABLE ... X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 04:57:57 -0000 the problem doesn't exist in a Feb kernel, but on a machine that I'm running the latest code on, doing an 'ifconfig em0' doesn't appear to be sending out the arp updates properly ... to the point that I had to manually delete the arp for an IP on one of the other servers, on the same network, so that they could talk to each other ... the other 'weird behaviour' that I'm getting with this kernel is that when I do do the ifconfig to bring an IP online, the network 'hangs' for 60+ seconds ... it looks like someone MFCd something back for this driver back in May: mercury# cd /sys/dev/em mercury# ls -lt total 486 -rw-r--r-- 1 root wheel 118971 May 22 11:19 if_em_hw.h -rw-r--r-- 1 root wheel 5501 May 22 11:19 if_em_osdep.h -rw-r--r-- 1 root wheel 227691 May 22 11:19 if_em_hw.c -rw-r--r-- 1 root wheel 9619 May 22 11:19 README -rw-r--r-- 1 root wheel 97880 May 22 11:19 if_em.c -rw-r--r-- 1 root wheel 14022 May 22 11:19 if_em.h -rw-r--r-- 1 root wheel 1609 Apr 4 2003 LICENSE mercury# While the server that does work, its em driver was from Oct: neptune# ls -lt total 406 -rw-r--r-- 1 root wheel 96678 Feb 3 00:18 if_em.c -rw-r--r-- 1 root wheel 4643 Oct 22 2004 if_em_osdep.h -rw-r--r-- 1 root wheel 14117 Oct 22 2004 if_em.h -rw-r--r-- 1 root wheel 185587 Oct 22 2004 if_em_hw.c -rw-r--r-- 1 root wheel 94374 Oct 22 2004 if_em_hw.h -rw-r--r-- 1 root wheel 10837 Sep 20 2003 README -rw-r--r-- 1 root wheel 1609 Apr 4 2003 LICENSE ---- Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: scrappy@hub.org Yahoo!: yscrappy ICQ: 7615664 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 05:00:53 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 82AF416A41F; Thu, 21 Jul 2005 05:00:53 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A2AD43D48; Thu, 21 Jul 2005 05:00:53 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j6L50nNV019757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 01:00:49 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j6L50m6P015862; Thu, 21 Jul 2005 01:00:49 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 9B08951340; Thu, 21 Jul 2005 01:00:48 -0400 (EDT) Date: Thu, 21 Jul 2005 01:00:48 -0400 From: Kris Kennaway To: Eirik ?verby , stable@FreeBSD.org, Robert Watson Message-ID: <20050721050048.GU22430@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="SwC/mAzP11p89u4p" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: Serious issue with serial console in 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 05:00:53 -0000 --SwC/mAzP11p89u4p Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 18, 2005 at 11:58:54AM +0200, Eirik ?verby wrote: > Hi, >=20 > I reported this before, but I am very surprised that it is still the =20 > case: >=20 > (This is from the last time it happened; this time the box rebooted =20 > and cleared the serial console before I had time to cut/paste it. > >Fatal trap 12: page fault while in kernel mode > >cpuid =3D 1; apic id =3D 00 > >fault virtual address =3D 0x1c > >fault code =3D supervisor write, page not present > >instruction pointer =3D 0x8:0xc0620b5f > >stack pointer =3D 0x10:0xdadbd988 > >frame pointer =3D 0x10:0xdadbd994 > >code segment =3D base 0x0, limit 0xfffff, type 0x1b > > =3D DPL 0, pres 1, def32 1, gran 1 > >processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >current process =3D 51999 (getty) > >trap number =3D 12 > >panic: page fault > >cpuid =3D 1 > >boot() called on cpu#0 > >Uptime: 66d11h24m50s >=20 > The above panic will show up occasionally when logging out from a =20 > serial console (i.e. ctrl-D, logout, exit, whatever). This is =20 > EXTREMELY BAD, as it will crash an otherwise perfectly healthy box at =20 > random - and renders the serial console useless. >=20 > Robert Watson confirmed this to be an issue on the 10th of April. >=20 > Anyone?? You might have to wait until 6.0-R since fixing it seems to require infrastructure changes that cannot easily be backported to 5.x. Kris --SwC/mAzP11p89u4p Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3yv/Wry0BWjoQKURAmmXAKDsFaJXxI1QtxIcHCTJWWt8UsYOVQCfRA70 s6DLhNMSmnbbehBt6tRf5zo= =Kgb+ -----END PGP SIGNATURE----- --SwC/mAzP11p89u4p-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 07:11:32 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B7E316A41F for ; Thu, 21 Jul 2005 07:11:32 +0000 (GMT) (envelope-from destroyingculture@netspace.net.au) Received: from mail.netspace.net.au (cumulus.netspace.net.au [203.10.110.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id A533C43D46 for ; Thu, 21 Jul 2005 07:11:31 +0000 (GMT) (envelope-from destroyingculture@netspace.net.au) Received: from [220.253.50.133] (220-253-50-133.VIC.netspace.net.au [220.253.50.133]) by mail.netspace.net.au (Postfix) with ESMTP id 20F7E7AC92; Thu, 21 Jul 2005 17:11:28 +1000 (EST) Message-ID: <42DF4AF3.3000506@netspace.net.au> Date: Thu, 21 Jul 2005 17:12:51 +1000 From: caleb User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050530) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel O'Connor References: <42DEA92E.7020705@netspace.net.au> <200507211014.18102.doconnor@gsoft.com.au> In-Reply-To: <200507211014.18102.doconnor@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: IrDA question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 07:11:32 -0000 The port is definitely sio1/cuaa1. I tried to run ircomm while irs was still running and got; cannot open pty I killed irs and used; ircomm -d /dev/cuaa1 -y /dev/ptypv -v 2 and I get the following output; localhost# ircomm -d /dev/cuaa1 -y /dev/ptypv -v 2 query completed query completed query completed query completed query completed query completed query completed query completed query completed query completed No peer station found The mobile phone had Ir switched on and I have tried running the command from various distances. caleb -- There is no spoon. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 07:35:32 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7A14916A41F for ; Thu, 21 Jul 2005 07:35:32 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8847443D48 for ; Thu, 21 Jul 2005 07:35:30 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (inchoate.gsoft.com.au [203.31.81.31]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j6L7ZKOx017593 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 21 Jul 2005 17:05:25 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: caleb Date: Thu, 21 Jul 2005 17:05:03 +0930 User-Agent: KMail/1.8.1 References: <42DEA92E.7020705@netspace.net.au> <200507211014.18102.doconnor@gsoft.com.au> <42DF4AF3.3000506@netspace.net.au> In-Reply-To: <42DF4AF3.3000506@netspace.net.au> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1446894.VDZfS4nEex"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507211705.14009.doconnor@gsoft.com.au> X-Spam-Score: -2.82 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: freebsd-stable@freebsd.org Subject: Re: IrDA question X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 07:35:32 -0000 --nextPart1446894.VDZfS4nEex Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 21 July 2005 16:42, caleb wrote: > The port is definitely sio1/cuaa1. I tried to run ircomm while irs was > still running and got; Why? No offence but it's always worth trying something different when stuff isn'= t=20 working :) > cannot open pty > > I killed irs and used; > > ircomm -d /dev/cuaa1 -y /dev/ptypv -v 2 and I get the following output; Yes, only one of them will be able to run at any one time. > localhost# ircomm -d /dev/cuaa1 -y /dev/ptypv -v 2 > query completed > query completed > query completed > query completed > query completed > query completed > query completed > query completed > query completed > query completed > No peer station found > > The mobile phone had Ir switched on and I have tried running the command > from various distances. Hmm, any way you can test it besides in FreeBSD? =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1446894.VDZfS4nEex Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC31Ax5ZPcIHs/zowRAnoWAKCU6qduo5/ECCi8EwF1bTVlVkMGCgCeNM9W feKpqNM4adPFogPUrHQw9Ds= =7OXg -----END PGP SIGNATURE----- --nextPart1446894.VDZfS4nEex-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 08:57:01 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 705A316A420; Thu, 21 Jul 2005 08:57:01 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12D7B43D48; Thu, 21 Jul 2005 08:57:00 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from eirik.unicore.no ([213.225.74.166] helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DvWrT-0004eY-83; Thu, 21 Jul 2005 10:56:59 +0200 In-Reply-To: <20050721050048.GU22430@xor.obsecurity.org> References: <20050721050048.GU22430@xor.obsecurity.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> Content-Transfer-Encoding: 7bit From: =?ISO-8859-1?Q?Eirik_=D8verby?= Date: Thu, 21 Jul 2005 10:56:54 +0200 To: Kris Kennaway X-Mailer: Apple Mail (2.733) Cc: stable@FreeBSD.org, Robert Watson Subject: Re: Serious issue with serial console in 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 08:57:01 -0000 On Jul 21, 2005, at 7:00 AM, Kris Kennaway wrote: > On Mon, Jul 18, 2005 at 11:58:54AM +0200, Eirik ?verby wrote: > >> Hi, >> >> I reported this before, but I am very surprised that it is still the >> case: >> >> (This is from the last time it happened; this time the box rebooted >> and cleared the serial console before I had time to cut/paste it. >> >>> Fatal trap 12: page fault while in kernel mode >>> cpuid = 1; apic id = 00 >>> fault virtual address = 0x1c >>> fault code = supervisor write, page not present >>> instruction pointer = 0x8:0xc0620b5f >>> stack pointer = 0x10:0xdadbd988 >>> frame pointer = 0x10:0xdadbd994 >>> code segment = base 0x0, limit 0xfffff, type 0x1b >>> = DPL 0, pres 1, def32 1, gran 1 >>> processor eflags = interrupt enabled, resume, IOPL = 0 >>> current process = 51999 (getty) >>> trap number = 12 >>> panic: page fault >>> cpuid = 1 >>> boot() called on cpu#0 >>> Uptime: 66d11h24m50s >>> >> >> The above panic will show up occasionally when logging out from a >> serial console (i.e. ctrl-D, logout, exit, whatever). This is >> EXTREMELY BAD, as it will crash an otherwise perfectly healthy box at >> random - and renders the serial console useless. >> >> Robert Watson confirmed this to be an issue on the 10th of April. >> >> Anyone?? >> > > You might have to wait until 6.0-R since fixing it seems to require > infrastructure changes that cannot easily be backported to 5.x. With all due respect - if this is (and I'm assuming it is, because it happens on all the servers I'm serial-controlling) an omnipresent problem on 5.x, I daresay it should warrant some more attention. Having unsafe serial terminal support that can bring down your system like that defies much of the point of having serial terminal support in the first place. However, since I seem to be the only one who has noticed this, perhaps I'm the last person on earth to routinely use serial terminal switches instead of KVM switches to do my admin work? /Eirik > > Kris > From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 09:44:05 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C91FB16A41F; Thu, 21 Jul 2005 09:44:05 +0000 (GMT) (envelope-from hans@lambermont.dyndns.org) Received: from lambermont.dyndns.org (lambermont.dyndns.org [82.93.47.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF02A43D75; Thu, 21 Jul 2005 09:44:00 +0000 (GMT) (envelope-from hans@lambermont.dyndns.org) Received: by lambermont.dyndns.org (Postfix, from userid 1001) id 0B33A95867; Thu, 21 Jul 2005 11:43:58 +0200 (CEST) Date: Thu, 21 Jul 2005 11:43:58 +0200 To: Eirik ?verby Message-ID: <20050721094358.GA10749@leia.lambermont.dyndns.org> References: <20050721050048.GU22430@xor.obsecurity.org> <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> User-Agent: Mutt/1.4.2.1i From: hans@lambermont.dyndns.org (Hans Lambermont) Cc: stable@FreeBSD.org, Robert Watson , Kris Kennaway Subject: Re: Serious issue with serial console in 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 09:44:05 -0000 Eirik ?verby wrote: ... > However, since I seem to be the only one who has noticed this, > perhaps I'm the last person on earth to routinely use serial terminal > switches instead of KVM switches to do my admin work? No, I recently installed 3 5.4-R production machines that do not have video cards, so I'm using the serial console a lot. I didn't see any of the horror you found. (yet, fingers crossed ;-) -- Hans Lambermont From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 09:45:27 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CEFF416A422 for ; Thu, 21 Jul 2005 09:45:27 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id AECDF43D9F for ; Thu, 21 Jul 2005 09:45:00 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 02991A3059 for ; Thu, 21 Jul 2005 11:44:59 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id DDE736462; Thu, 21 Jul 2005 11:44:58 +0200 (CEST) Resent-From: marcolz@stack.nl Resent-Date: Thu, 21 Jul 2005 11:44:58 +0200 Resent-Message-ID: <20050721094458.GD52120@stack.nl> Resent-To: freebsd-stable@freebsd.org X-Original-To: marcolz@umail.stack.nl Delivered-To: marcolz@umail.stack.nl Received: from mailhost.stack.nl (vaak.nfs.stack.nl [IPv6:2001:610:1108:5012::a]) by toad.stack.nl (Postfix) with ESMTP id B2E0E80 for ; Thu, 21 Jul 2005 11:19:22 +0200 (CEST) Received: by mailhost.stack.nl (Postfix) id AA83CA3018; Thu, 21 Jul 2005 11:19:22 +0200 (CEST) Delivered-To: marcolz@stack.nl Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 969BFA300E; Thu, 21 Jul 2005 11:19:22 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 6E8986462; Thu, 21 Jul 2005 11:19:22 +0200 (CEST) Date: Thu, 21 Jul 2005 11:19:22 +0200 From: Marc Olzheim To: Eirik =?iso-8859-1?Q?=D8verby?= Message-ID: <20050721091922.GB52120@stack.nl> References: <20050721050048.GU22430@xor.obsecurity.org> <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jho1yZJdad60DJr+" Content-Disposition: inline In-Reply-To: <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i X-Annoyance-Filter-Junk-Probability: 0 X-Annoyance-Filter-Classification: Mail Cc: marcolz@stack.nl Subject: Re: Serious issue with serial console in 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 09:45:28 -0000 --jho1yZJdad60DJr+ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 10:56:54AM +0200, Eirik verby wrote: > >>>Fatal trap 12: page fault while in kernel mode > >>>cpuid =3D 1; apic id =3D 00 > >>>fault virtual address =3D 0x1c > >>>fault code =3D supervisor write, page not present > >>>instruction pointer =3D 0x8:0xc0620b5f > >>>stack pointer =3D 0x10:0xdadbd988 > >>>frame pointer =3D 0x10:0xdadbd994 > >>>code segment =3D base 0x0, limit 0xfffff, type 0x1b > >>> =3D DPL 0, pres 1, def32 1, gran 1 > >>>processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > >>>current process =3D 51999 (getty) > >>>trap number =3D 12 > >>>panic: page fault > >>>cpuid =3D 1 > >>>boot() called on cpu#0 > >>>Uptime: 66d11h24m50s > >>> > >> > >>The above panic will show up occasionally when logging out from a > >>serial console (i.e. ctrl-D, logout, exit, whatever). This is > >>EXTREMELY BAD, as it will crash an otherwise perfectly healthy box at > >>random - and renders the serial console useless. > >> > >>Robert Watson confirmed this to be an issue on the 10th of April. > >> > >>Anyone?? > >> > > > >You might have to wait until 6.0-R since fixing it seems to require > >infrastructure changes that cannot easily be backported to 5.x. >=20 > With all due respect - if this is (and I'm assuming it is, because it =20 > happens on all the servers I'm serial-controlling) an omnipresent =20 > problem on 5.x, I daresay it should warrant some more attention. =20 > Having unsafe serial terminal support that can bring down your system =20 > like that defies much of the point of having serial terminal support =20 > in the first place. >=20 > However, since I seem to be the only one who has noticed this, =20 > perhaps I'm the last person on earth to routinely use serial terminal =20 > switches instead of KVM switches to do my admin work? Nope, I use them a lot as well, but only if there are problems. Why would you login on a serial console if there's ssh ;-) So that would explain why I haven't seen the issue yet. Do you have a debugger trace ? It seems very similar to my last remaining issue (http://www.stack.nl/~marcolz/FreeBSD/showstoppers.html), namely http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/83375 i.e. someting going wrong in pty cloning and cleanup... Marc --jho1yZJdad60DJr+ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC32iaezjnobFOgrERAho7AJ4z6glZr8heXPaEG92rcJGQNhkxCwCeKiPV OxV0Zar4ThpR9edLs7YAzVo= =mqfV -----END PGP SIGNATURE----- --jho1yZJdad60DJr+-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 09:45:38 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1A0516A423 for ; Thu, 21 Jul 2005 09:45:38 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id D310F43D64 for ; Thu, 21 Jul 2005 09:45:34 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 2D763A2FE4 for ; Thu, 21 Jul 2005 11:45:34 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 09B236462; Thu, 21 Jul 2005 11:45:34 +0200 (CEST) Date: Thu, 21 Jul 2005 11:45:33 +0200 From: Marc Olzheim To: freebsd-stable@FreeBSD.org Message-ID: <20050721094533.GE52120@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7DO5AaGCk89r4vaK" Content-Disposition: inline X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Subject: background fsck, softupdates & inconsistent state on disk X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 09:45:38 -0000 --7DO5AaGCk89r4vaK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi. Having enough opportunities to do crash recovery with kern/83375 open and some of my services not yet moved back to FreeBSD 4, I noticed that often it crashes just after (or perhaps during) mirroring of a directory tree. The mirroring involves creating a directory with in it 80 subdirectories in it. Now when the machine panics on a 'screen' again, background fsck fails to properly check the filesystem and reports so in /var/log/messages. What I see on that partition is the main directory that should have contained the 80 subdirs, but now it has a link count of 0 and so doesn't even contain a . or .. , let alone the 80 directories that should have been there. The only thing a manual fsck can do after that is unlink the unreferenced inodes and clear up the mess... Shouldn't this be impossible without power loss ? Or is it inherent to SMP that the machine can crash on a process on CPU #0 while CPU #1 is updating disk structures ? Anyway, as soon as the migration of production services suffering from kern/83375 back to 4.x is done I should have a 5.x test machine ready to crash whenever people want, so I can get debug output out of it. If anyone could tell me how to get it and what they need, I'd be happy to provide it. Marc --7DO5AaGCk89r4vaK Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3269ezjnobFOgrERArKjAKC7MD0AIfrZhthDidHyLYMo6th1HQCcDp3R HhU2UPfgblhFenIqeU+HQ1Q= =uKR+ -----END PGP SIGNATURE----- --7DO5AaGCk89r4vaK-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 09:57:34 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 081D616A421 for ; Thu, 21 Jul 2005 09:57:34 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 91FBF43D66 for ; Thu, 21 Jul 2005 09:57:33 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id B3BCCA2FC3; Thu, 21 Jul 2005 11:57:32 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 943DA6462; Thu, 21 Jul 2005 11:57:32 +0200 (CEST) Date: Thu, 21 Jul 2005 11:57:32 +0200 From: Marc Olzheim To: Alexey Yakimovich Message-ID: <20050721095732.GG52120@stack.nl> References: <1121917413.4895.47.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tmoQ0UElFV5VgXgH" Content-Disposition: inline In-Reply-To: <1121917413.4895.47.camel@localhost.localdomain> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 09:57:34 -0000 --tmoQ0UElFV5VgXgH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jul 20, 2005 at 08:43:33PM -0700, Alexey Yakimovich wrote: > My advice to FreeBSD release engineering team:=20 > - do more testing; > - have it tested with hardware what was published in "Hardware Notes"; > - do not release it for production if it is not in production quality; > - reread again what was written by yourself regarding 4.4 release > quality. > I wish to say more. >=20 > This mail was written because I like FreeBSD and I want to continue > using it. And wouldn't mind to wait longer for real production quality > releases instead of start using something else. And please, I know, it's > open source project. >=20 > Best regards, > Real FreeBSD fan Thank you for expressing my exact same sentiments. I'm still a huge FreeBSD fan and switching to anything else (well, perhaps DragonFly) seems out of the question, but my faith is being tested a lot lately. Having switched some of my companies production machines to 5.4, since it was (in my eyes falsely) called a 'production release', FreeBSD's reputation within the less technical parts of the company has taken a large dent. Luckily they know as well that there's still no comparison to FreeBSD 4.x; top of my ruptime looks like: up 1124+12:15, 1 user, load 2.14, 2.10, 2.02 up 1095+06:22, 11 users, load 2.01, 2.04, 2.02 up 1095+05:31, 5 users, load 2.38, 2.31, 2.24 up 1095+05:06, 2 users, load 1.07, 1.08, 1.01 up 1095+04:46, 0 users, load 1.09, 1.08, 1.01 up 1087+21:04, 1 user, load 1.01, 1.00, 1.00 but then again, I'd really like to use the new 5.x features in a stable environment... Marc also a Real FreeBSD fan :-) --tmoQ0UElFV5VgXgH Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC33GMezjnobFOgrERAtgZAKCMwx2okw3EOzEnMphgZRCClmOB+wCfZIyD eRL58BECBh2u3/gCBzNQ+C0= =k+lR -----END PGP SIGNATURE----- --tmoQ0UElFV5VgXgH-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 10:15:56 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 73C7816A41F for ; Thu, 21 Jul 2005 10:15:56 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id C235743D4C for ; Thu, 21 Jul 2005 10:15:55 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id DEFBE46B0D; Thu, 21 Jul 2005 06:15:52 -0400 (EDT) Date: Thu, 21 Jul 2005 11:16:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-8859-1?Q?Eirik_=D8verby?= In-Reply-To: <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> Message-ID: <20050721110222.U97888@fledge.watson.org> References: <20050721050048.GU22430@xor.obsecurity.org> <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1073072043-1121940979=:97888" Cc: stable@FreeBSD.org, Kris Kennaway Subject: Re: Serious issue with serial console in 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 10:15:56 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1073072043-1121940979=:97888 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 21 Jul 2005, Eirik =D8verby wrote: >>> The above panic will show up occasionally when logging out from a >>> serial console (i.e. ctrl-D, logout, exit, whatever). This is >>> EXTREMELY BAD, as it will crash an otherwise perfectly healthy box at >>> random - and renders the serial console useless. >>>=20 >>> Robert Watson confirmed this to be an issue on the 10th of April. >>=20 >> You might have to wait until 6.0-R since fixing it seems to require=20 >> infrastructure changes that cannot easily be backported to 5.x. > > With all due respect - if this is (and I'm assuming it is, because it=20 > happens on all the servers I'm serial-controlling) an omnipresent=20 > problem on 5.x, I daresay it should warrant some more attention. Having= =20 > unsafe serial terminal support that can bring down your system like that= =20 > defies much of the point of having serial terminal support in the first= =20 > place. > > However, since I seem to be the only one who has noticed this, perhaps=20 > I'm the last person on earth to routinely use serial terminal switches=20 > instead of KVM switches to do my admin work? The concern about the 5.x backport is that it will break parts of the=20 device driver ABI, and is a significant change that involves a lot of=20 risk. Regarding the general prevalence of the problem -- I've seen a small=20 number of people reporting it's a big problem. Since I know of a great=20 many people running with serial consoles (other than a workstation, I=20 never run FreeBSD boxes any other way), this leads me to believe it's=20 something that shows up in fairly specific conditions -- perhaps relating= =20 to precise timing of a race condition. This means that if we introduce a= =20 generally destabilizing change, it may impact more people than the problem= =20 as it exists (a nasty trade-off). I've only seen the issue when logging out of a serial console session, and= =20 had previously hypothesized that it had to do with the simultaneous timing= =20 of a console message from syslog and the opening/closing of the console's= =20 tty due to logging out and getty restarting, resulting in a reference=20 count improperly hitting zero. I thought Doug White had come up with a work-around patch that prevented=20 the reference count from being allowed to hit 0 for the console by=20 artificially elevating it, which would prevent the panic, so either (a)=20 the work around wasn't committed, or (b) it didn't work. I can attempt to take another look at this problem in a week or so, but=20 have a number of things I need to finish up for FreeBSD 6.0 before then=20 that will be occupying my time. Robert N M Watson --0-1073072043-1121940979=:97888-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 10:24:45 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6208D16A41F for ; Thu, 21 Jul 2005 10:24:45 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5300543D86 for ; Thu, 21 Jul 2005 10:24:39 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id EA82646B8F; Thu, 21 Jul 2005 06:24:38 -0400 (EDT) Date: Thu, 21 Jul 2005 11:25:05 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Steve In-Reply-To: <42DF2A8F.30202@powersystemsdirect.com> Message-ID: <20050721112230.A97888@fledge.watson.org> References: <42DF2A8F.30202@powersystemsdirect.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: READ_DMA, WRITE_DMA errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 10:24:45 -0000 On Wed, 20 Jul 2005, Steve wrote: > I've found tons of emails, news messages, listserv messages, and even > some bug reports of this seemingly common error. > > So, I had been running 5.2 on a server, and, updated to 5.3. Got the > READ_DMA and WRITE_DMA error and retries. So, figuring it might be a bad > update, took a new drive. put it in, loaded 5.4 for grins, and, same > issue, lots of these errors, eventually destroying the FS. Played around > with various settings, no avail. So, took it back, got different box, > everything new. Same problem, new install of 5.4 6.0 contains a significant re-write and update of the ATA driver, and corrects a number of known problems with timeouts and reliability. This rewrite is available as patches against 5.x, but has not been committed because ATA is a very sensitive thing (lots of very diverse and very broken hardware), and has had insufficient testing. If you have test hardware available that's not in production, it would be quite helpful if you could install 6.0-BETA2, once that comes out in the next week or so, and see if the specific ATA problems you're experiencing occur there. It's not impossible that the new ATA code will be merged to 5.x, but I think we cannot do that until it has seen a lot more exposure. If you search back through the mailing archives, you should be able to find posts from Soren regarding the new ATA patches, if you want to give them a try on 5.x. Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 11:00:33 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69DE116A439 for ; Thu, 21 Jul 2005 11:00:33 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2312243D99 for ; Thu, 21 Jul 2005 11:00:04 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 8124E46B1E; Thu, 21 Jul 2005 07:00:04 -0400 (EDT) Date: Thu, 21 Jul 2005 12:00:31 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexey Yakimovich In-Reply-To: <1121917413.4895.47.camel@localhost.localdomain> Message-ID: <20050721113927.T97888@fledge.watson.org> References: <1121917413.4895.47.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 11:00:34 -0000 On Wed, 20 Jul 2005, Alexey Yakimovich wrote: > My advice to FreeBSD release engineering team: > - do more testing; > - have it tested with hardware what was published in "Hardware Notes"; > - do not release it for production if it is not in production quality; > - reread again what was written by yourself regarding 4.4 release > quality. > I wish to say more. > > This mail was written because I like FreeBSD and I want to continue > using it. And wouldn't mind to wait longer for real production quality > releases instead of start using something else. And please, I know, it's > open source project. While I agree more testing always helps, and that there are some fairly concete ways we can work to improve testing, there are also some practical realities to how software testing happens, especially for complex software products running on diverse hardware. I have a question for you though: Have you tried, and do you plan to try, our 6.0 test releases before 6.0-RELEASE goes out the door? Specifically, on the hardware you know you're having problems with 5.4 on? The way hardware gets tested is that people who have the hardware run the software on it under a variety of loads, and see if it works. Since a volunteer project of a couple of hundred developers can't buy all known past and future hardware, we have to rely on hardware vendors, software resellers, and FreeBSD users to do some of the testing. In order for that testing to affect a release, it must happen before the release goes out the door, rather than afterwards. And it has to happen sufficiently in advance of the release that someone can do something about the results of failed testing. If hardware isn't tested before the releasee, then inevitably people with that untested hardware are more likely to experience problems. This means that the best way to help us support your hardware is to run our test releases with useful workloads, and then provide feedback if/when they don't work. I realize you're providing feedback now on the 5.x branch, but what you may or may not know is that in the 6.x branch, we have a significant update to the ATA code that may get merged to 5.x, if it proves to be as much better as we hope. This means that we need you to test the future code, not the current code, in order to fix the problems you are experiencing. 90% of useful FreeBSD testing happens when large FreeBSD consumers take release of FreeBSD and deploy them in their testbeds and real-world environments, and find the bugs through the application of high levels of load and obscure hardware configurations. This is why later FreeBSD releases along a -STABLE branch are typically much more stable than earlier ones -- the code has run on millions of machines for untold amounts of load, instead of the thousand or so with a very selected load it's likely to run on during development. This is how all software vendors work, really -- be it Microsoft, or Apple, old-style UNIX vendors, or any of the Linux vendors. Some set of users sits on the bleeding edge and shakes out the early problems, and then the rest of the user base suffers through the later versions to shake out more subtle problems that gradually get resolved. The FreeBSD Project is working on moving towards a more formal testing regimen. This change will help shake out software bugs relating to workload -- i.e., IP stack bugs, file system bugs, etc. But the chances of it having a significant impact on broad hardware testing is very low. So if you have non-production instances of your production hardware, and can reproduce the workloads of your production environment on that hardware, what we would love you to do is run 6-CURRENT on it and tell us if that works better. If it does, then it's a question of back-porting the functionality (if possible) to 5.x. If it doesn't, then we can fix the problem in the active development tree, then merge as makes sense. 4.x became a great success after a quite shaking 3.x release branch, and after some bumps early in 4.x. It got there because of a lot of testing and improvement resulting from production experience. If you didn't have problems with 3.x and 4.x, it's because someone else got there first. The reason I suggest waiting for BETA2 is that BETA2 will have cleaned up support for running 5.x applications. Specifically, there are one or two system calls that have changed in 6.x, and require COMPAT_FREEBSD5 to be compiled into the kernel, which it wasn't in BETA1. Likewise, a number of library version bumps and compatibility pieces will be in BETA2. This will make it easier to test 5.x application workloads on a 6.x install. We take the concerns you've expressed seriously, and you should know that every FreeBSD developer I've talked with in the last few years has been talking about how to improve 5.x stability. The challenge has been to integrate the agressive feature set improvement in 5.x with our stability goals. Much of that improvement has happened for 6.x, and I think you'll find that you're much happier with the general level of testing and support there. This was possible because people running 5.x have provided us a lot of detailed feedback and bug reporting. 6.x is much less agressive in terms of feature set, and cleans up many of the architectural changes that made 5.x such a feature-rich releasee. Your feedback on 6.x sooner rather than latter will improve the quality of the 6.x release, and we'd appreciate it greatly if you could help us test it! Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 11:00:34 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0FB1316A455 for ; Thu, 21 Jul 2005 11:00:34 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A5AF43DA0 for ; Thu, 21 Jul 2005 11:00:27 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (ppp246-29.lns2.adl2.internode.on.net [203.122.246.29]) (authenticated bits=0) by cain.gsoft.com.au (8.13.4/8.13.4) with ESMTP id j6LAxwuC025874 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 21 Jul 2005 20:30:04 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-stable@freebsd.org Date: Thu, 21 Jul 2005 20:29:47 +0930 User-Agent: KMail/1.8.1 References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> In-Reply-To: <20050721095732.GG52120@stack.nl> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1304133.QWTOQ7Xmtk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507212029.47615.doconnor@gsoft.com.au> X-Spam-Score: 0.05 () FORGED_RCVD_HELO X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Marc Olzheim , Alexey Yakimovich Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 11:00:34 -0000 --nextPart1304133.QWTOQ7Xmtk Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 21 July 2005 19:27, Marc Olzheim wrote: > Thank you for expressing my exact same sentiments. I'm still a huge > FreeBSD fan and switching to anything else (well, perhaps DragonFly) > seems out of the question, but my faith is being tested a lot lately. > Having switched some of my companies production machines to 5.4, since > it was (in my eyes falsely) called a 'production release', FreeBSD's > reputation within the less technical parts of the company has taken a > large dent. Luckily they know as well that there's still no comparison > to FreeBSD 4.x; top of my ruptime looks like: I think the best way to rectify this is to test RC candidates on YOUR=20 hardware.. This finds the bugs you need fixed at a time when people are ver= y=20 receptive to fixing them. It's not realistic for the release engineer to test on a lot of hardware as= =20 they are very busy doing other things. =2D-=20 Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --nextPart1304133.QWTOQ7Xmtk Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC34Aj5ZPcIHs/zowRAk+PAJ4wT+J99CVTvxhgf04ZBVLy6LtcpACgkFtr ScsufxfF/vqudniTJ7Ws1BQ= =Saw9 -----END PGP SIGNATURE----- --nextPart1304133.QWTOQ7Xmtk-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 11:02:33 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 068A216A41F; Thu, 21 Jul 2005 11:02:33 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3AD7443D7E; Thu, 21 Jul 2005 11:02:13 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from eirik.unicore.no ([213.225.74.166] helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1DvYoY-0006Wu-SL; Thu, 21 Jul 2005 13:02:06 +0200 In-Reply-To: <20050721110222.U97888@fledge.watson.org> References: <20050721050048.GU22430@xor.obsecurity.org> <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> <20050721110222.U97888@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <86DDD9F6-A086-48E2-A5C5-1F5EA1C49354@anduin.net> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Eirik_=D8verby?= Date: Thu, 21 Jul 2005 13:02:01 +0200 To: Robert Watson X-Mailer: Apple Mail (2.733) Cc: stable@FreeBSD.org, Kris Kennaway Subject: Re: Serious issue with serial console in 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 11:02:33 -0000 On Jul 21, 2005, at 12:16 PM, Robert Watson wrote: > > On Thu, 21 Jul 2005, Eirik =D8verby wrote: > > >>>> The above panic will show up occasionally when logging out from a >>>> serial console (i.e. ctrl-D, logout, exit, whatever). This is >>>> EXTREMELY BAD, as it will crash an otherwise perfectly healthy =20 >>>> box at >>>> random - and renders the serial console useless. >>>> Robert Watson confirmed this to be an issue on the 10th of April. >>>> >>> You might have to wait until 6.0-R since fixing it seems to =20 >>> require infrastructure changes that cannot easily be backported =20 >>> to 5.x. >>> >> >> With all due respect - if this is (and I'm assuming it is, because =20= >> it happens on all the servers I'm serial-controlling) an =20 >> omnipresent problem on 5.x, I daresay it should warrant some more =20 >> attention. Having unsafe serial terminal support that can bring =20 >> down your system like that defies much of the point of having =20 >> serial terminal support in the first place. >> >> However, since I seem to be the only one who has noticed this, =20 >> perhaps I'm the last person on earth to routinely use serial =20 >> terminal switches instead of KVM switches to do my admin work? >> > > The concern about the 5.x backport is that it will break parts of =20 > the device driver ABI, and is a significant change that involves a =20 > lot of risk. > > Regarding the general prevalence of the problem -- I've seen a =20 > small number of people reporting it's a big problem. Since I know =20 > of a great many people running with serial consoles (other than a =20 > workstation, I never run FreeBSD boxes any other way), this leads =20 > me to believe it's something that shows up in fairly specific =20 > conditions -- perhaps relating to precise timing of a race =20 > condition. This means that if we introduce a generally =20 > destabilizing change, it may impact more people than the problem as =20= > it exists (a nasty trade-off). > > I've only seen the issue when logging out of a serial console =20 > session, and had previously hypothesized that it had to do with the =20= > simultaneous timing of a console message from syslog and the =20 > opening/closing of the console's tty due to logging out and getty =20 > restarting, resulting in a reference count improperly hitting zero. I did indeed make some changes to my syslog configuration after =20 getting the serials online. Your theory might not be entirely off. Let me know if I should post my syslog.conf file or anything else =20 here or elsewhere... Thanks, /Eirik > I thought Doug White had come up with a work-around patch that =20 > prevented the reference count from being allowed to hit 0 for the =20 > console by artificially elevating it, which would prevent the =20 > panic, so either (a) the work around wasn't committed, or (b) it =20 > didn't work. > > I can attempt to take another look at this problem in a week or so, =20= > but have a number of things I need to finish up for FreeBSD 6.0 =20 > before then that will be occupying my time. > > Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 11:04:30 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 91D9D16A420 for ; Thu, 21 Jul 2005 11:04:30 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C1B743D73 for ; Thu, 21 Jul 2005 11:04:13 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id F176C46B0C; Thu, 21 Jul 2005 07:04:12 -0400 (EDT) Date: Thu, 21 Jul 2005 12:04:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?ISO-8859-1?Q?Eirik_=D8verby?= In-Reply-To: <86DDD9F6-A086-48E2-A5C5-1F5EA1C49354@anduin.net> Message-ID: <20050721120340.S97888@fledge.watson.org> References: <20050721050048.GU22430@xor.obsecurity.org> <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> <20050721110222.U97888@fledge.watson.org> <86DDD9F6-A086-48E2-A5C5-1F5EA1C49354@anduin.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-2065818662-1121943879=:97888" Cc: stable@FreeBSD.org, Kris Kennaway Subject: Re: Serious issue with serial console in 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 11:04:30 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-2065818662-1121943879=:97888 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 21 Jul 2005, Eirik =D8verby wrote: >> I've only seen the issue when logging out of a serial console session,= =20 >> and had previously hypothesized that it had to do with the simultaneous= =20 >> timing of a console message from syslog and the opening/closing of the= =20 >> console's tty due to logging out and getty restarting, resulting in a=20 >> reference count improperly hitting zero. > > I did indeed make some changes to my syslog configuration after getting= =20 > the serials online. Your theory might not be entirely off. Let me know=20 > if I should post my syslog.conf file or anything else here or=20 > elsewhere... Since you appear to be able to reliably reproduce the problem (whereas I=20 was able to reproduce it only after several hours of quite active serial=20 console work), it would be quite interesting to answer the following=20 question: If you cause syslogd not to send any output to /dev/console, does the problem go away? Thanks, Robert N M Watson --0-2065818662-1121943879=:97888-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 11:21:02 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DE43216A41F for ; Thu, 21 Jul 2005 11:21:02 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 87D1843D83 for ; Thu, 21 Jul 2005 11:21:00 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id DC854A2FCA; Thu, 21 Jul 2005 13:20:59 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id AE3586462; Thu, 21 Jul 2005 13:20:59 +0200 (CEST) Date: Thu, 21 Jul 2005 13:20:59 +0200 From: Marc Olzheim To: Daniel O'Connor Message-ID: <20050721112059.GA52753@stack.nl> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> <200507212029.47615.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="RnlQjJ0d97Da+TV1" Content-Disposition: inline In-Reply-To: <200507212029.47615.doconnor@gsoft.com.au> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , Alexey Yakimovich , freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 11:21:03 -0000 --RnlQjJ0d97Da+TV1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 08:29:47PM +0930, Daniel O'Connor wrote: > I think the best way to rectify this is to test RC candidates on YOUR=20 > hardware.. This finds the bugs you need fixed at a time when people are v= ery=20 > receptive to fixing them. >=20 > It's not realistic for the release engineer to test on a lot of hardware = as=20 > they are very busy doing other things. Of course. That's why we test stuff first, before upgrading. However, real world situations are always different from test setups and the kind of race conditions that we're talking about that we were troubled by didn't show up until we had it in production... But that's why I always try to supply code to trigger the bug in my PRs after finding it, so that it can be tested for a next release. It's just that "this will probably not be fixed in 5.x" is not the thing I like to hear. But as said, there's always 4.x, which is the most stable OS I've seen in my open source UN*X life. Too bad that with 4.x I get responses on libc_r's uthread like "libc_r is dead, please use KSE", which don't help anyway. No need to burn your ships behind you just yet. (Or whatever the expression is in English) Marc --RnlQjJ0d97Da+TV1 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC34UbezjnobFOgrERAozzAJ4h5LadohuvyXReqqkmREsJp1zYIgCfcDnI YyHwb4e9tkhP26ZBtWZFbGk= =N9vI -----END PGP SIGNATURE----- --RnlQjJ0d97Da+TV1-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 11:37:50 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 789CD16A425; Thu, 21 Jul 2005 11:37:50 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8A3F43D8C; Thu, 21 Jul 2005 11:37:38 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id A2F50A3088; Thu, 21 Jul 2005 13:37:37 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 822696462; Thu, 21 Jul 2005 13:37:37 +0200 (CEST) Date: Thu, 21 Jul 2005 13:37:37 +0200 From: Marc Olzheim To: Robert Watson Message-ID: <20050721113737.GB52753@stack.nl> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721113927.T97888@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mojUlQ0s9EVzWg2t" Content-Disposition: inline In-Reply-To: <20050721113927.T97888@fledge.watson.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Alexey Yakimovich , freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 11:37:50 -0000 --mojUlQ0s9EVzWg2t Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Robert, First, thank you for your clear reply. > 90% of useful FreeBSD testing happens when large FreeBSD consumers take= =20 > release of FreeBSD and deploy them in their testbeds and real-world=20 > environments, and find the bugs through the application of high levels of= =20 > load and obscure hardware configurations. This is why later FreeBSD=20 > releases along a -STABLE branch are typically much more stable than=20 > earlier ones -- the code has run on millions of machines for untold=20 > amounts of load, instead of the thousand or so with a very selected load= =20 > it's likely to run on during development. This is how all software=20 > vendors work, really -- be it Microsoft, or Apple, old-style UNIX vendors= ,=20 > or any of the Linux vendors. Some set of users sits on the bleeding edge= =20 > and shakes out the early problems, and then the rest of the user base=20 > suffers through the later versions to shake out more subtle problems that= =20 > gradually get resolved. Indeed. That's why my company started taking FreeBSD 5.3 in use for production servers when it was out. Since then numerous bugs were fixed, some of which reported by us. Now that we're X bug fixes later in time and started to get a good feeling about the number of open problems, it is extremely annoying to hear the "This will (probably) not be fixed in 5.x" statements. That conflicts with 'gradually get resolved'. What do you recommend larger consumers to do ? Keep using FreeBSD 4 and start testing FreeBSD 6.x, dropping 5.x all together ? I know FreeBSD 5 was a strange exception in the relase scheduling and that a lot has been learned from it for the future and I'm certainly not unthankful for all the work that's done, but I'd like a clear answer on what to do now in regard to taking FreeBSD 5 into 'real' production... Marc --mojUlQ0s9EVzWg2t Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC34kBezjnobFOgrERAu11AJwJGySJQ46LdwYlazPvDXHks2bM8gCeP9h5 tMpOESxL4t1gbs6mzYjdV0k= =D3sJ -----END PGP SIGNATURE----- --mojUlQ0s9EVzWg2t-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 12:14:35 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE87616A41F for ; Thu, 21 Jul 2005 12:14:35 +0000 (GMT) (envelope-from nicklas@dinpris.no) Received: from dp-mail-01.dinpris.com (dp-mail-01.dinpris.com [62.73.247.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 205B943D7B for ; Thu, 21 Jul 2005 12:14:17 +0000 (GMT) (envelope-from nicklas@dinpris.no) Received: (qmail 96229 invoked by uid 1004); 21 Jul 2005 12:20:05 -0000 Received: from 62.73.247.155 by dp-mail-01.dinpris.com (envelope-from , uid 98) with qmail-scanner-1.25 (clamdscan: 0.86.1/984. spamassassin: 3.0.4. perlscan: 1.25. Clear:RC:1(62.73.247.155):. Processed in 0.050815 secs); 21 Jul 2005 12:20:05 -0000 X-Qmail-Scanner-Mail-From: nicklas@dinpris.no via dp-mail-01.dinpris.com X-Qmail-Scanner: 1.25 (Clear:RC:1(62.73.247.155):. Processed in 0.050815 secs) Received: from 529c-tbg7-5fl.oslo.dinpris.com (HELO ?62.73.247.155?) (nicklas@dinpris.no@62.73.247.155) by dp-mail-01.dinpris.com with SMTP; 21 Jul 2005 12:20:04 -0000 Message-ID: <42DF9187.3060000@dinpris.no> Date: Thu, 21 Jul 2005 14:13:59 +0200 From: "Nicklas B. Westerlund" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marc Olzheim References: <1121917413.4895.47.camel@localhost.localdomain> <20050721113927.T97888@fledge.watson.org> <20050721113737.GB52753@stack.nl> In-Reply-To: <20050721113737.GB52753@stack.nl> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Alexey Yakimovich , Robert Watson , freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 12:14:35 -0000 Marc Olzheim wrote: > >but I'd like a clear answer on >what to do now in regard to taking FreeBSD 5 into 'real' production... > > > I'd have to second this request. We rely heavily on the stability and performance of FreeBSD in our business. We've only had the occasional stupid hang on our RELENG_5_4 systems, but I've deployed both RELENG_6 and -CURRENT in our labs now to see what kind of results I can get out of it. Although I havn't seen any major problems on our servers, all using u320 scsi and smp - I don't feel as secure about my choice of upgrading to 5.x. We still have some 4.x servers in production, and judging by how this is evolving, I think I'll rather skip the 5-branch for those machines and keep testing 6.x. The last thing we need is servers with problems to disturb our sleep at night. Overall I think we're a few of the lucky ones, as alot of people seem to have huge problems which we havn't encountered, again that is because of different architectures and such. Nick. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 12:15:12 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ED68016A41F for ; Thu, 21 Jul 2005 12:15:12 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from crivens.unixoid.de (crivens.unixoid.de [81.169.171.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id B113943D4C for ; Thu, 21 Jul 2005 12:15:11 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from localhost (localhost [127.0.0.1]) by crivens.unixoid.de (Postfix) with ESMTP id EC9023F6A for ; Thu, 21 Jul 2005 03:01:17 +0200 (CEST) Received: from crivens.unixoid.de ([127.0.0.1]) by localhost (crivens.unixoid.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27603-10 for ; Thu, 21 Jul 2005 03:01:05 +0200 (CEST) Received: by crivens.unixoid.de (Postfix, from userid 1006) id B85244097; Thu, 21 Jul 2005 03:01:05 +0200 (CEST) Received: from 195.234.136.12 (SquirrelMail authenticated user mh); by ssl.unixoid.de with HTTP; Thu, 21 Jul 2005 03:01:05 +0200 (CEST) Message-ID: <13577.195.234.136.12.1121907665.squirrel@195.234.136.12> Date: Thu, 21 Jul 2005 03:01:05 +0200 (CEST) From: "Marian Hettwer" To: freebsd-stable@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: amavisd-new at unixoid.de Subject: RELENG_6 scroll wheel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 12:15:13 -0000 Hej All, I upgraded to RELENG_6 to help testing. Everything went smooth so far, but my scroll wheel in X isn't working anymore. I didn't changed anything regarding the configuration from FreeBSD RELENG_5 to RELENG_6 ... some details: [mhettwer@beastie] <~> $ uname -a FreeBSD beastie.mobile.rz 6.0-BETA1 FreeBSD 6.0-BETA1 #0: Fri Jul 15 17:00:59 CEST 2005 root@beastie.mobile.rz:/usr/obj/usr/src/sys/GENERIC i386 [mhettwer@beastie] <~> $ dmesg | grep ums ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 3, iclass 3/1 ums0: 3 buttons and Z dir. ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. from /etc/X11/xorg.conf Section "InputDevice" Identifier "Mouse0" Driver "mouse" Option "Protocol" "auto" Option "Device" "/dev/sysmouse" Option "ZAxisMapping" "4 5" EndSection [mhettwer@beastie] <~> $ ps ax | grep moused 1060 ?? Ss 0:52,38 /usr/sbin/moused -z 4 -p /dev/ums0 -t auto -I /var/run/moused.ums0.pid I'm running xorg-6.8.2 I didn't recompiled my ports, but I guess this shouldn't be the problem, hm ? Any ideas anyone ? best regards, Marian From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 12:19:49 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 014B816A425; Thu, 21 Jul 2005 12:19:49 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from anduin.net (anduin.net [212.12.46.226]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E3DA43D78; Thu, 21 Jul 2005 12:19:30 +0000 (GMT) (envelope-from ltning@anduin.net) Received: from eirik.unicore.no ([213.225.74.166] helo=[10.0.16.10]) by anduin.net with esmtpa (Exim 4.50 (FreeBSD)) id 1Dva1Q-0007UF-Vu; Thu, 21 Jul 2005 14:19:29 +0200 In-Reply-To: <20050721120340.S97888@fledge.watson.org> References: <20050721050048.GU22430@xor.obsecurity.org> <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> <20050721110222.U97888@fledge.watson.org> <86DDD9F6-A086-48E2-A5C5-1F5EA1C49354@anduin.net> <20050721120340.S97888@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?Eirik_=D8verby?= Date: Thu, 21 Jul 2005 14:19:23 +0200 To: Robert Watson X-Mailer: Apple Mail (2.733) Cc: stable@FreeBSD.org, Kris Kennaway Subject: Re: Serious issue with serial console in 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 12:19:49 -0000 On Jul 21, 2005, at 1:04 PM, Robert Watson wrote: > > On Thu, 21 Jul 2005, Eirik =D8verby wrote: > > >>> I've only seen the issue when logging out of a serial console =20 >>> session, and had previously hypothesized that it had to do with =20 >>> the simultaneous timing of a console message from syslog and the =20 >>> opening/closing of the console's tty due to logging out and getty =20= >>> restarting, resulting in a reference count improperly hitting zero. >>> >> >> I did indeed make some changes to my syslog configuration after =20 >> getting the serials online. Your theory might not be entirely off. =20= >> Let me know if I should post my syslog.conf file or anything else =20 >> here or elsewhere... >> > > Since you appear to be able to reliably reproduce the problem =20 > (whereas I was able to reproduce it only after several hours of =20 > quite active serial console work), it would be quite interesting to =20= > answer the following question: > > If you cause syslogd not to send any output to /dev/console, does =20= > the > problem go away? I'm afraid to say it doesn't.... /Eirik > > Thanks, > > Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 12:20:52 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C0A116A422 for ; Thu, 21 Jul 2005 12:20:52 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FD3743D7C for ; Thu, 21 Jul 2005 12:20:23 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 6BB0B46B2D; Thu, 21 Jul 2005 08:20:22 -0400 (EDT) Date: Thu, 21 Jul 2005 13:20:49 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Marc Olzheim In-Reply-To: <20050721113737.GB52753@stack.nl> Message-ID: <20050721125632.F97888@fledge.watson.org> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721113927.T97888@fledge.watson.org> <20050721113737.GB52753@stack.nl> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1602063093-1121948449=:97888" Cc: Alexey Yakimovich , freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 12:20:52 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1602063093-1121948449=:97888 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 21 Jul 2005, Marc Olzheim wrote: > Indeed. That's why my company started taking FreeBSD 5.3 in use for=20 > production servers when it was out. Since then numerous bugs were fixed,= =20 > some of which reported by us. Now that we're X bug fixes later in time=20 > and started to get a good feeling about the number of open problems, it= =20 > is extremely annoying to hear the "This will (probably) not be fixed in= =20 > 5.x" statements. That conflicts with 'gradually get resolved'. What do=20 > you recommend larger consumers to do ? Keep using FreeBSD 4 and start=20 > testing FreeBSD 6.x, dropping 5.x all together ? > > I know FreeBSD 5 was a strange exception in the relase scheduling and=20 > that a lot has been learned from it for the future and I'm certainly not= =20 > unthankful for all the work that's done, but I'd like a clear answer on= =20 > what to do now in regard to taking FreeBSD 5 into 'real' production... Marc, I should start out by saying I appreciate your clear and concise bug=20 reports, and the list of your company's show-stopper 5.x bugs has made the= =20 rounds among FreeBSD developers. I'm happy that at least one of the=20 issues on the list was fixed by me. :-) As you probably saw yesterday,=20 I've started bugging Poul-Henning to look at the pty problem you're=20 experiencing, and will get that on our 6.0 release show-stopper list. I=20 haven't yet had a chance to reproduce it locally, but it sounds like that= =20 should be straight forward. FreeBSD 5 has been an exception -- "normally", in as much as major=20 releases have a "normal", the set of new features is a lot less agressive,= =20 and it has been our goal with 6.x to restore the expectation of a more=20 rapid release cycle with a less agressive feature set. This should reduce= =20 the number of problems by virtue of reducing the level of change. It=20 should also make it easier for users to pick what version to run on, as=20 the amount of adaptation they have to do to slide forward a version will=20 be greatly reduced. I.e., right now it's relatively easy to move back and= =20 forward between 5.x and 6.x. With respect to 5.x vs 6.x upgrades: I've seen companies take two=20 different strategies. Most of them have been at least experimenting with= =20 deploying 5.x, and are very interested in its feature set. Support for=20 large file systems, 64-bit support on newer AMD and Intel hardware,=20 improved PAM support, etc. Some of my customers are specifically=20 interested in the support for mandatory access control, but that's=20 obviously a less common feature request :-). The biggest determining=20 factor for companies today comes from their own product schedule, since=20 most big consumers of FreeBSD treat it as a component in a "product" they= =20 deliver for others. For example, my understanding is that Yahoo is now deploying 6.0 betas=20 across their server environment with great success, but was actually=20 unable to seriously deploy 5.x because their goal was to support full=20 32-bit compatibility on 64-bit amd/intel hardware, which has only recently= =20 reached the level of maturity they require. In fact, you'll notice if you= =20 follow FreeBSD commit logs that much of that support has come from Yahoo!.= =20 Since 6.x is maturing in pretty good synch with their deployment timeline= =20 for 5.x, they are actually deploying 6.x. Of course, Yahoo! has a team of= =20 in-house OS developers who adapt FreeBSD for their needs, and is quite=20 capable of debugging a kernel or two if they run into problems. The ATA driver issue is a sticky one for many users -- we hope to get the= =20 6.x ATA code back into 5.x in the next 5.x release. However, hard-earned= =20 experience tells us that ATA driver code is notoriously difficult to get=20 right across the broad range of available hardware. Soren has been=20 lobbying to get it merged to 5.x, but given the level of testing performed= =20 so far, we can't yet justify the merge. My hope is that with 6.0 out the= =20 door and a lot of testing of that code, we can get it merged back to 5.x=20 before 5.5. Many other fixes have gone into 5.x, correcting many of the=20 most significant issues. If you compare 5.4 with 5.3, you'll find that in= =20 most cases, it's both faster and more stable. The tty issue is a sticky one also. The tty code in 6.x has been=20 substantially rewritten to better support the SMPng environment. Because= =20 the tty code "plugs in" to a number of device drivers, T1 adapter drivers,= =20 etc, changing the tty interfaces is a fairly big event, and will affect=20 third party vendors like Cronyx. This code has also not yet seen as wide= =20 deployment as I'd like, so it's also something that really isn't=20 appropriate for an MFC immediately. However, once it has seen significant= =20 6.0 deployment, it may well be. A question then will be whether it's=20 better to simply say "you're better off making the jump to 6.x, which is=20 minor" than backporting, and it's something we can't really answer until=20 we're comfortable that it's seen sufficient deployment. My hope is that=20 we can identify a workaround for 5.x that will avoid the code upheaval a=20 full backport would require. It's not as ideal as having the "right" fix,= =20 but it would stop the panics. I need to ping phk and some of the other=20 tty-centric folk to look at this some more. In terms of advice: If you have a "product" due out more than 3 months from now, I think 6.x=20 is the obvious way to go: you want to be ahead of the curve so that you=20 can have the foundation for your product in sync with the FreeBSD=20 production release cycle, and avoid jumping major releases early in the=20 product life cycle. 6.x has significant performance and stability=20 improvements -- performance especially in the area of file system=20 performance on SMP, preemption, network stack, and memory management, and= =20 stability especially in the area of tty support. By "product", I mean a=20 range of things: the OS foundation of an embedded product such as a=20 firewall or storage appliance, or deployment of an internal product, such= =20 as a virtual server product at an ISP. On the other hand, if you're deploying today, I think that unless you're=20 prepared to deal with the 6.0 bug fix cycle (both the BETA/RC cycle, and=20 the inevitable post-release fixes for a .0 release), 5.4+patches or=20 5-STABLE is the right place to sit. At least two of the critical bugs on= =20 your list were fixed in 5-STABLE after the release of 5.4, so for some,=20 5-STABLE is the best place to be. We've opted not to do a patch/errata=20 update for 5.4 for the socket error you were receiving on the basis that=20 it doesn't affect a wide audience and doesn't correct a "Critical" failure= =20 -- i.e., a crash or the like, unlike some of the NFS server fixes, for=20 which we did do an errata fix. From=20the perspective of the FreeBSD developers, if you can tolerate the= =20 6.x release process, we encourage you to jump on that bandwagon. It will= =20 help us release a better 6.0, and that's where the future lies. Our goal= =20 is to make 6.x a pretty seemless upgrade from 5.x, as it has a less=20 agressive feature set, and far fewer user-visible changes (i.e., no=20 conversion to OpenPAM, devfs,=A0UFS2, large compiler version upgrade, ... a= s=20 in 5.x). When I upgraded my personal web/shell server to 6.x from 5.x=20 last week, I didn't have to change any configuration in /etc at all, other= =20 than a painless pass through mergemaster to merge the _dhcp user and=20 group. As always, we look to the freebsd-stable users to help us test new= =20 features ahead of the release. Thanks, Robert N M Watson --0-1602063093-1121948449=:97888-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 12:25:59 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 80C9216A442; Thu, 21 Jul 2005 12:25:59 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78BD243D9A; Thu, 21 Jul 2005 12:25:49 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id BD677A2FCA; Thu, 21 Jul 2005 14:25:48 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 9DBBF66D0; Thu, 21 Jul 2005 14:25:48 +0200 (CEST) Date: Thu, 21 Jul 2005 14:25:48 +0200 From: Marc Olzheim To: Eirik =?iso-8859-1?Q?=D8verby?= Message-ID: <20050721122548.GA61946@stack.nl> References: <20050721050048.GU22430@xor.obsecurity.org> <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> <20050721110222.U97888@fledge.watson.org> <86DDD9F6-A086-48E2-A5C5-1F5EA1C49354@anduin.net> <20050721120340.S97888@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: stable@FreeBSD.org, Robert Watson , Kris Kennaway Subject: Re: Serious issue with serial console in 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 12:26:01 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 02:19:23PM +0200, Eirik verby wrote: > > If you cause syslogd not to send any output to /dev/console, does =20 > >the > > problem go away? >=20 > I'm afraid to say it doesn't.... Please, could you add: options DDB #Enable the kernel debugger options DDB_NUMSYM #Print numerical value of symbols too options KDB options KDB_TRACE options KDB_UNATTENDED to your kernel config ? Marc --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC35RMezjnobFOgrERAkY0AJ9lUY3AQcsUY6JamZmS7cksN8jTPACgkl7F /qz9o69NevgnJzTFs9jiMm4= =e1OA -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 12:30:05 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EC33916A423 for ; Thu, 21 Jul 2005 12:30:05 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id CFD7643D9B for ; Thu, 21 Jul 2005 12:29:58 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 422E146B0A; Thu, 21 Jul 2005 08:29:58 -0400 (EDT) Date: Thu, 21 Jul 2005 13:30:25 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Nicklas B. Westerlund" In-Reply-To: <42DF9187.3060000@dinpris.no> Message-ID: <20050721132752.E97888@fledge.watson.org> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721113927.T97888@fledge.watson.org> <20050721113737.GB52753@stack.nl> <42DF9187.3060000@dinpris.no> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Marc Olzheim , Alexey Yakimovich , freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 12:30:06 -0000 On Thu, 21 Jul 2005, Nicklas B. Westerlund wrote: > Although I havn't seen any major problems on our servers, all using u320 > scsi and smp - I don't feel as secure about my choice of upgrading to > 5.x. We still have some 4.x servers in production, and judging by how > this is evolving, I think I'll rather skip the 5-branch for those > machines and keep testing 6.x. The last thing we need is servers with > problems to disturb our sleep at night. > > Overall I think we're a few of the lucky ones, as alot of people seem to > have huge problems which we havn't encountered, again that is because of > different architectures and such. Actually, I think you're part of the silent majority who find it works fine in their environment. We use RELENG_5 at work on a number of machines, and I work with several companies and organizations who do, and have no problems at all. The edge cases seem to be: - High load environments, or high load testing. - Hardware that isn't part of the regular testing that FreeBSD developers do as part of their work, likely because they don't have the hardware. - Less commonly deployed features -- i.e., IPX, which has experienced serious functional problems in RELENG_5 until a few months ago. Interestingly, resulting from a compiler change, not network stack changes... Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 12:40:49 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5381C16A41F for ; Thu, 21 Jul 2005 12:40:49 +0000 (GMT) (envelope-from michael.schuh@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9348243D53 for ; Thu, 21 Jul 2005 12:40:48 +0000 (GMT) (envelope-from michael.schuh@gmail.com) Received: by nproxy.gmail.com with SMTP id g2so30250nfe for ; Thu, 21 Jul 2005 05:40:46 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=S3wiTnn4AeeQmlrHr3WdQgEhUNF/pCozXQqXr3m3OJSkBzyqrskh1JomK/Gyahyjf4O5211j/wSuciWRro6zozpg7eQYvE5yCYfVbxr6nv4tHbbEUDQ9DbcBdqz6wwoI2AFRC9CeuImI//TPm99jXqZSVqjngORyHerVwg5uByA= Received: by 10.48.4.10 with SMTP id 10mr56001nfd; Thu, 21 Jul 2005 05:40:46 -0700 (PDT) Received: by 10.48.244.19 with HTTP; Thu, 21 Jul 2005 05:40:46 -0700 (PDT) Message-ID: <1dbad31505072105401c06bee6@mail.gmail.com> Date: Thu, 21 Jul 2005 14:40:46 +0200 From: Michael Schuh To: rwatson@FreeBSD.org, aiy@ferens.net, freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Michael Schuh List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 12:40:49 -0000 Hi, at this point i musttail my paint with you and the other's. I have really made a few tests on one big issue or RELENG_5. At the time as it was early enough to change things, but the guys they have me telled someone else have to fast machines to test ( in my eyes they should test on some sloweer hardware, to become the maximum performance) I have telled some guys the problems that i have found, these Problems are= =20 really important for other issues ( performance from applications etc.) but no one would really hear what i have to say, they telled me some unrelevant ( and many bullshit), and they think not before they speak..... so that the result for me ist to wait on RELENG_6, so that i made one or two tests and if the tests do not perform in the right direction then i leave the FreeBSD and going back to Linux or switching eventually to DragonFly. Now my question to you : is the performance of ata-related disk-access under UFS-Filesystem not important for other application, so that the performance can be a half of them that RELENG_4 does? In fact under RELENG_4 i can write a GIG FIle double as fast as under RELENG_5 ! and i would not hear any thing about serial performance or that this is not really like the real world, if i syimulate that with: /usr/bin/time dd if=3D/dev/zero of=3D/zerofile bs=3D1024 count=3D1024k; this is reality poor! I know we gave all our best, but many people are more arrogant, and think not really... best regards Michael From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 12:45:48 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3A91B16A41F for ; Thu, 21 Jul 2005 12:45:48 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4B1843D46 for ; Thu, 21 Jul 2005 12:45:47 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so195292wri for ; Thu, 21 Jul 2005 05:45:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=rFxxJe97v7R76+NWKHys1KYSRJR76EXFr0eXnjjRzkQwb44Pk4NUgP2j5gFP5z473H76GaJd+qbHfMoA33zDETi/2YVnRJLywGCGnZhjwrtrDZ+OzDwG5eXhgrKkOMxsrdbjo2P28LYhB898xpYykK6/kuduhJKIyNs+Ysmmdyk= Received: by 10.54.13.67 with SMTP id 67mr501381wrm; Thu, 21 Jul 2005 05:45:15 -0700 (PDT) Received: by 10.54.38.32 with HTTP; Thu, 21 Jul 2005 05:45:15 -0700 (PDT) Message-ID: <70e8236f050721054520940895@mail.gmail.com> Date: Thu, 21 Jul 2005 13:45:15 +0100 From: Joao Barros To: freebsd-stable@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joao Barros List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 12:45:48 -0000 Hi all, Robert, I was hopping for you to mention user's feedback. I started this thread http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052288.html back with SNAP004. The problem is still present in BETA1. I haven't seen any more advances in the thread, and I know this must be a very localized issue, and that everyone is pretty busy with the upcoming release but I wouldn't want this issue forgotten. Should I submit a PR? As this is a kernel issue, I'm pretty much stuck to 5, although I would prefer start using 6. Yet, another loyal FreeBSD user :-) -- Joao Barros From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 12:50:45 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D82C416A41F for ; Thu, 21 Jul 2005 12:50:45 +0000 (GMT) (envelope-from the.lists@mgm51.com) Received: from oneyou.mcmli.com (oneyou.mcmli.com [216.194.67.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A46243D4C for ; Thu, 21 Jul 2005 12:50:45 +0000 (GMT) (envelope-from the.lists@mgm51.com) Received: from sentry.24cl.com (pcp01267574pcs.danbry01.ct.comcast.net [68.63.157.203]) by oneyou.mcmli.com (Postfix) with ESMTP id 6A1BA5B86 for ; Thu, 21 Jul 2005 08:50:44 -0400 (EDT) Received: from XPMM (unknown [63.119.50.193]) by sentry.24cl.com (Postfix) with ESMTP id B4D1A5101 for ; Thu, 21 Jul 2005 08:50:43 -0400 (EDT) Message-ID: <200507210850530519.03A3275D@sentry.24cl.com> In-Reply-To: <200507212029.47615.doconnor@gsoft.com.au> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> <200507212029.47615.doconnor@gsoft.com.au> X-Mailer: Courier 3.50.00.00.1081 (http://www.rosecitysoftware.com) (P) Date: Thu, 21 Jul 2005 08:50:53 -0400 From: "MikeM" To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="us-ascii" Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 12:50:46 -0000 On 7/21/2005 at 8:29 PM Daniel O'Connor wrote: |On Thursday 21 July 2005 19:27, Marc Olzheim wrote: |> Thank you for expressing my exact same sentiments. I'm still a huge |> FreeBSD fan and switching to anything else (well, perhaps DragonFly) |> seems out of the question, but my faith is being tested a lot lately. |> Having switched some of my companies production machines to 5.4, since |> it was (in my eyes falsely) called a 'production release', FreeBSD's |> reputation within the less technical parts of the company has taken a |> large dent. Luckily they know as well that there's still no comparison |> to FreeBSD 4.x; top of my ruptime looks like: | |I think the best way to rectify this is to test RC candidates on YOUR |hardware.. This finds the bugs you need fixed at a time when people are |very receptive to fixing them. | |It's not realistic for the release engineer to test on a lot of hardware |as they are very busy doing other things. ============= Your comment presupposes that most of the bugs are specific to one piece of hardware, I doubt that is a valid assertion. I would offer that most of the bugs are not present in source code specific to a certain piece of hardware, but are present in source code that is run across much of the hardware that FreeBSD runs on. As such, it is just a matter of setting up the correct QA testing scripts to catch the bugs. Once a bug is reported, and that bug can be reproduced on the hardware of the development team, then that bug should not reappear again, because there should be a testing script written for it. Additionally, every software bug is not only a defect in the software, but it also represents a defect in the process that created the software. Bugs should be looked at to analyze why they occurred, and what in the process might be changed to prevent the same or similar bugs from recurring. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 12:52:18 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1B0516A41F for ; Thu, 21 Jul 2005 12:52:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C58D43D5E for ; Thu, 21 Jul 2005 12:52:16 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 06EB646B3C; Thu, 21 Jul 2005 08:52:16 -0400 (EDT) Date: Thu, 21 Jul 2005 13:52:43 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Joao Barros In-Reply-To: <70e8236f050721054520940895@mail.gmail.com> Message-ID: <20050721134731.X97888@fledge.watson.org> References: <70e8236f050721054520940895@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 12:52:18 -0000 On Thu, 21 Jul 2005, Joao Barros wrote: > I was hopping for you to mention user's feedback. I started this thread > http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052288.html > back with SNAP004. The problem is still present in BETA1. I haven't seen > any more advances in the thread, and I know this must be a very > localized issue, and that everyone is pretty busy with the upcoming > release but I wouldn't want this issue forgotten. Should I submit a PR? > As this is a kernel issue, I'm pretty much stuck to 5, although I would > prefer start using 6. I would suggest always filling a PR if you worry the problem is going to get lost. While PR's can also get lost, they tend to persist more than old e-mails. There are two likely causes of problems: (1) amr driver problems (2) General PCI/interrupt/ACPI/APIC problems The last few functional changes to amr were by Paull Saab (ps@) and Scott Long (scottl@), and I'd be tempted to try to chase that option first. The first question to answer is whether you can get into the debugger using a console or serial break, as that will tell us what sort of "hang" you're seeing. You can find detailed instructions for kernel debugging in the handbook. Try adding BREAK_TO_DEBUGGER, KDB, and KDB as a first step, and see if a break gets you to the debugger or not. If you can get into the debugger, submit the information to the PR, forward me the PR receipt, and I'll try assigning it to one of the above and see if we can get someone to take some interest in it. If you can't get into the debugger, it's more likely an interrupt/etc problem. We might try John Baldwin (jhb@) as a possible first contact. Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 12:58:13 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D0BC16A41F for ; Thu, 21 Jul 2005 12:58:13 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E58D43D53 for ; Thu, 21 Jul 2005 12:58:12 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id 8E64FA2FCA; Thu, 21 Jul 2005 14:58:11 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id 6D62966D0; Thu, 21 Jul 2005 14:58:11 +0200 (CEST) Date: Thu, 21 Jul 2005 14:58:11 +0200 From: Marc Olzheim To: Don Bowman Message-ID: <20050721125811.GF61946@stack.nl> References: <2BCEB9A37A4D354AA276774EE13FB8C23A6B41@mailserver.sandvine.com> <20050412150143.GC1570@stack.nl> <20050419083808.GB95574@stack.nl> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="A6N2fC+uXW/VQSAv" Content-Disposition: inline In-Reply-To: <20050419083808.GB95574@stack.nl> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , carlos@infodrive.com.ar, freebsd-stable@FreeBSD.org, Aaron Summers Subject: Re: SuperMicro X5DP8-G2MB/(2)XEON 2.4/1GB RAM 5.4-S Freeze X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 12:58:13 -0000 --A6N2fC+uXW/VQSAv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 19, 2005 at 10:38:08AM +0200, Marc Olzheim wrote: > > > The problem is with the periodic SMM interrupt and the bios. > > >=20 > > > The attached program (ich-periodic-smm-disable.c) will fix the proble= m. > > > For more information on what it does, see the Intel ICH3 datasheet. > > >=20 > > > compile as 'gcc ich-periodic-smm-disable.c; ./a.out' and you will be > > > good. > > > Run this on each boot. > > >=20 > > > I think you only need to clear PERIODIC_EN. > >=20 > > Ok, I'll try it right away, thanks a lot! >=20 > This clearly solves it. The machines are now up for longer than a week > for the first time since I booted FreeBSD 5.x on them. Does anyone know whether this workaround is still necessary for newer 5.x's and/or 6.x and current ? Marc --A6N2fC+uXW/VQSAv Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC35vjezjnobFOgrERArU/AKDHHu5aE9J2Si7vqGYfLfcERmqslgCfaSAp o21EfWA1xrck8g3NcCpgc0g= =D6D+ -----END PGP SIGNATURE----- --A6N2fC+uXW/VQSAv-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 13:24:41 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BB2216A423 for ; Thu, 21 Jul 2005 13:24:41 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2B7643D93 for ; Thu, 21 Jul 2005 13:24:11 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so207599wri for ; Thu, 21 Jul 2005 06:24:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=fJrByEc3oh4vK9sPexqzQonJl5LGBB0HgSpSOoy+UqZgMUTa8q4h33vZJIvIs0kduaVFmPcNnWxflFt7sMYuVYevmBEcomwyqom+pqf23aeMbHatus9S0/4mhk1epzsPc6b4YwRGAbBmiMTqFue6WulpximHRAp8rrZVK62CAj0= Received: by 10.54.51.8 with SMTP id y8mr515203wry; Thu, 21 Jul 2005 06:23:36 -0700 (PDT) Received: by 10.54.38.32 with HTTP; Thu, 21 Jul 2005 06:23:36 -0700 (PDT) Message-ID: <70e8236f050721062319dbe06e@mail.gmail.com> Date: Thu, 21 Jul 2005 14:23:36 +0100 From: Joao Barros To: freebsd-stable@freebsd.org In-Reply-To: <70e8236f05072106191a1b7f3b@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <70e8236f050721054520940895@mail.gmail.com> <20050721134731.X97888@fledge.watson.org> <70e8236f05072106191a1b7f3b@mail.gmail.com> Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joao Barros List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 13:24:41 -0000 On 7/21/05, Robert Watson wrote: > > On Thu, 21 Jul 2005, Joao Barros wrote: > > > I was hopping for you to mention user's feedback. I started this thread > > http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052288.htm= l > > back with SNAP004. The problem is still present in BETA1. I haven't see= n > > any more advances in the thread, and I know this must be a very > > localized issue, and that everyone is pretty busy with the upcoming > > release but I wouldn't want this issue forgotten. Should I submit a PR? > > As this is a kernel issue, I'm pretty much stuck to 5, although I would > > prefer start using 6. > > I would suggest always filling a PR if you worry the problem is going to > get lost. While PR's can also get lost, they tend to persist more than > old e-mails. > > There are two likely causes of problems: > > (1) amr driver problems > (2) General PCI/interrupt/ACPI/APIC problems I suspect the 2nd > > The last few functional changes to amr were by Paull Saab (ps@) and Scott > Long (scottl@), and I'd be tempted to try to chase that option first. Scott replied: The kernel isn't hung, it's just forever waiting for an interrupt from the amr card that it'll never get. Again, this is almost certainly an interrupt routing problem, so please contact John Baldwin and provide him your details. Scott > The first question to answer is whether you can get into the debugger us= ing a > console or serial break, as that will tell us what sort of "hang" you're > seeing. > > You can find detailed instructions for kernel debugging in the handbook. > Try adding BREAK_TO_DEBUGGER, KDB, and KDB as a first step, and see if a > break gets you to the debugger or not. If you can get into the debugger, > submit the information to the PR, forward me the PR receipt, and I'll try > assigning it to one of the above and see if we can get someone to take > some interest in it. After reading this http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052434.html I breaked into the debugger and posted this http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052489.html Is the information there suficient to open a PR? > > If you can't get into the debugger, it's more likely an interrupt/etc > problem. We might try John Baldwin (jhb@) as a possible first contact. John started debugging this with another person with similar problems on 5 and the debugging never got to 6 (no feedback from the other person): http://lists.freebsd.org/pipermail/freebsd-current/2005-July/05272= 7.html > > Robert N M Watson > From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 13:26:47 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2A0C816A421 for ; Thu, 21 Jul 2005 13:26:47 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9DC243D55 for ; Thu, 21 Jul 2005 13:26:27 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from localhost (localhost [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id 79C9A261 for ; Thu, 21 Jul 2005 15:26:26 +0200 (CEST) Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (midgard [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72136-02 for ; Thu, 21 Jul 2005 15:26:25 +0200 (CEST) Received: from [10.0.0.23] (mini.intranet [10.0.0.23]) by maxlor.mine.nu (Postfix) with ESMTP id 3853C47 for ; Thu, 21 Jul 2005 15:26:25 +0200 (CEST) Message-ID: <42DFA261.6080401@datacomm.ch> Date: Thu, 21 Jul 2005 15:25:53 +0200 From: Benjamin Lutz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4087B68018ECAA99464A6890" X-Virus-Scanned: by amavisd-new at maxlor.mine.nu Cc: Subject: why is [acpi_task1] killable? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 13:26:47 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4087B68018ECAA99464A6890 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, I've (accidentally, because of a broken pidfile) noticed yesterday that root can kill [acpi_task1] (PID 8 on my system, FreeBSD 5.4-p5/i386). Killing it resulted in an immediate and total lockup of the system. I gather that processes with [ ] around their name are parts of the kernel. Shouldn't they be protected from kills? Note this was a standard kill, not a kill -9 or anything mean like that. Cheers Benjamin --------------enig4087B68018ECAA99464A6890 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFC36JrgShs4qbRdeQRAsmtAJ4356W9ENZPqGd/Pjd39nR8pbCiWACeOhMT f0/pQkM/WWOqI926KB8N8Zg= =0AnT -----END PGP SIGNATURE----- --------------enig4087B68018ECAA99464A6890-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 13:29:00 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 984DC16A425 for ; Thu, 21 Jul 2005 13:29:00 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id E22DD43D55 for ; Thu, 21 Jul 2005 13:28:41 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 39D9046B28; Thu, 21 Jul 2005 09:28:41 -0400 (EDT) Date: Thu, 21 Jul 2005 14:29:08 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: MikeM In-Reply-To: <200507210850530519.03A3275D@sentry.24cl.com> Message-ID: <20050721135839.K97888@fledge.watson.org> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> <200507212029.47615.doconnor@gsoft.com.au> <200507210850530519.03A3275D@sentry.24cl.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 13:29:00 -0000 On Thu, 21 Jul 2005, MikeM wrote: > Your comment presupposes that most of the bugs are specific to one piece > of hardware, I doubt that is a valid assertion. I would offer that most > of the bugs are not present in source code specific to a certain piece > of hardware, but are present in source code that is run across much of > the hardware that FreeBSD runs on. As such, it is just a matter of > setting up the correct QA testing scripts to catch the bugs. > > Once a bug is reported, and that bug can be reproduced on the hardware > of the development team, then that bug should not reappear again, > because there should be a testing script written for it. > > Additionally, every software bug is not only a defect in the software, > but it also represents a defect in the process that created the > software. Bugs should be looked at to analyze why they occurred, and > what in the process might be changed to prevent the same or similar bugs > from recurring. Some of us have actually spent quite a bit of time looking at the defect sets reported for 5.x. Depending on the release they fall into a number of categories, but here are the major ones I've identified: - ACPI-related hardware probe issues, especially in earlier 5.x releases when the ACPI code (especially Intel vendor code) started knowing how to work around common ACPI BIOS bugs. The source of these problems was often that BIOS ACPI code contained work-arounds for Windows ACPI bugs. Newer 5.x releases have blacklists of known bad BIOSes, workarounds for bugs, etc, and this is a much less reported problem now. These problems weren't present in 4.x because ACPI wasn't supported in 4.x; on the other hand, there's a broad range of modern server hardware that now requires ACPI to boot, so 4.x didn't run on that hardware, or supported it poorly. After a very large effort, ACPI problems are massively reduced. - ATA problems. Many of these, while a symptom of bugs in the ATA code running without Giant, were very specific to timing, or divergent/poor ATA hardware. As a result, they were difficult to reproduce in any environment but the original reporting environment. The same hardware might perform fine in a FreeBSD developer's system. Many of these problems have now been resolved, but some have not. Often as not, the problems have to do with retrying requests to drives. As I mentioned, we believe the ATA code in 6.x is much more resilient, but right now what it needs is testing, not merging to 5.x yet. Fixes require just as much testing as any other change, since a fix for one issue may well trigger another issue, especially in the world of cheap PC hardware. - Network stack stability under high load, especially on SMP. Many of these bugs had to do with exercising timing and race conditions "precisely right", and involved workloads not in the standard set of testing performed. In many cases, those workloads have now been added to the regression test suite. For example, there were a number of race conditions relating to the closing of sockets and network stack teardown in the protocols. These tended to turn up on systems running tens of thousands of rapidly opening and closing TCP connections on SMP hardware. Reproducing those conditions is difficult, and not something most FreeBSD developers have the resources to do, so have to wait for bug reports from people who do have those resources. However, over the past 12 months we've been working to put together a "netperf" test cluster, using hardware donated by a number of organizations, including the FreeBSD Foundation, FreeBSD Systems, IronPort Systems, as well as network connectivity and management donated by Sentex Communications. This has allowed us to apply network tests in higher performance environments, and make high end SMP hardware available to a broader range of developers. - Storage/file system related buffer starvation, deadlocks, etc, most a result of the development of snapshots and bgfsck support, changes in the I/O path, and so on. A number of these have turned out to be driver bugs, but a fair number (especially in the 5.2 time frame) had to do with resource management in the UFS code. Some still remain. - Lock and resource leak crashes, especially with 5.2 and 5.3, when large parts of the system moved from running under Giant to running without it. Our process has definitely improved here, through improved lock debugging tools, increased use of assertions, and the advent of things like Coverity's static analysis tools being run over the source tree. - ACPI-like problems having to do with migrating interrupt and hardware configuration models. These usually manifest as interrupt storms. They are required changes to support modern server class SMP hardware, but often trigger bugs in a range of motherboard revisions from about 2-3 years ago. Sometimes, fixing these problems has required figuring out how Windows does the same thing, as only the behavior used by Windows is tested by the hardware vendor. Go figure. - Threading bugs associated with the creation of a new threading model and library, especially from 5.3. Many of these have now been resolved, although further work on performance is on-going. While there's a lot to be said for software engineering and improving practices, and that we're working on that in a number of directions, I think it is inaccurate to claim that software defects are always represent solvable process defects. The reality is that all known software development processes involve software defects, especially with complex software systems. In operating system development, detecting bugs is often a property of very specific environments that are hard or impossible to reproduce or test in a formal way, at least not without huge expense. Many bugs cannot be reproduced on hardware owned by developers, because the cost (not to mention heat, time, and power constraints) would be excessive. Many testing network environments require several computers in order to reproduce even simple scenarios, as well as substantial configuration work. Combinatorics is also a practical reality, and doesn't work in our favor. For example: Soren does most of our ATA development. Last I checked, he had hundreds of ATA adapters, hundreds of storage devices, and a good dozen or more test computers with various properties (speed, notebook or not, SMP, hardware architecture, bus topology, BIOS revisions, and so on). Assuming the general accuracy of the above numbers, and assuming it took only five minutes per configuration to perform all testing, we're talking about 83 days of non-stop 24-hour testing. Of course, the basic assumptions are flawed, because it takes at least five minutes to set up a hardware configuration, let alone run the hours of testing that you'd want to run in the configuration. These are not problems that are solved through test scripts, they are fundamental to the general problem of testing device drivers and device driver frameworks. By doing a subset of the above testing, you get software that is reliable on most hardware. And indeed, that's what FreeBSD ships: software that is reliable on most hardware. A number of people have been working to improve FreeBSD testing. If you're interested in working on it, as you obviously have clear views on how it should work, we'd welcome your help. Especially if it comes to defining test cases, producing scripts or test tools that can be run mechanically, etc. There have been a couple of concerted efforts to formalize our regression test framework, and in particular, to standardize how tests are included, documented, and run. Most of these efforts peter out, because the work is hard, offers few rewards, and the attention spans of developers are limited by reality (jobs, etc). I think everyone is in agreement that this is an area where there's more work to be done, and contribution is welcomed. Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 13:30:24 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D18516A41F for ; Thu, 21 Jul 2005 13:30:24 +0000 (GMT) (envelope-from Administrator@grove.de) Received: from sparc10-1.grove.de (mx1.grove.de [81.30.96.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6954B43D49 for ; Thu, 21 Jul 2005 13:29:47 +0000 (GMT) (envelope-from Administrator@grove.de) Received: from jmx.grove.de (jmx.grove.de [81.30.97.16]) by sparc10-1.grove.de (Postfix) with ESMTP id 2D2B857FF14 for ; Thu, 21 Jul 2005 15:29:46 +0200 (CEST) Received: from j16_grove (localhost [81.30.97.16]) by stable.grove.de (Postfix) with SMTP id 631545F43EC for ; Thu, 21 Jul 2005 15:29:46 +0200 (CEST) Received: from igate.grove.de (igate.grove.de [81.30.96.254]) by jmx.grove.de (Postfix) with ESMTP id AEC4E5F434C for ; Thu, 21 Jul 2005 15:29:45 +0200 (CEST) Received: from tux.grove.home (tux.grove.intern [172.31.1.7]) by igate.grove.de (8.12.3/8.12.3) with ESMTP id j6LDDjYE030024 for ; Thu, 21 Jul 2005 15:13:45 +0200 Received: from mail pickup service by tux.grove.home with Microsoft SMTPSVC; Thu, 21 Jul 2005 15:35:34 +0200 thread-index: AcWN+RJMnhILDNTAQTK/vwFxFAQpfA== Thread-Topic: [MailServer Notification]To recipient: Message matched eManager setting and action was taken. From: Sender: To: , Date: Thu, 21 Jul 2005 15:35:34 +0200 Message-ID: <000001c58df9$12730c70$07011fac@grove.home> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft CDO for Exchange 2000 Content-Class: urn:content-classes:message Importance: normal Priority: normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830 X-OriginalArrivalTime: 21 Jul 2005 13:35:34.0802 (UTC) FILETIME=[12947720:01C58DF9] X-SpamTest-Categories: FORMAL MESSAGES X-SpamTest-Info: Profile: Formal (251/050713) X-SpamTest-Info: Profile: Detect Standard No RBL (4/030526) X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Archiving (2/030321) X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release Cc: Subject: [--Formal Message--] [MailServer Notification]To recipient: Message matched eManager setting and action was taken. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 13:30:24 -0000 **************** eManager Notification ***************** The following mail was blocked since it contains sensitive content. Source mailbox: owner-freebsd-stable@freebsd.org Destination mailbox(es): MikeM;freebsd-stable@freebsd.org Rule/Policy: NOC fun Action: Quarantine to C:\Programme\Trend\SMCF\Quarantine\2005-07-21\15\35\DFImessagebody42dfa4a6979.tmp Content filter has detected a sensitive e-mail. ******************* End of message ********************* From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 13:32:26 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7953416A41F for ; Thu, 21 Jul 2005 13:32:26 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9A9C143DA0 for ; Thu, 21 Jul 2005 13:32:01 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice6.sentex.ca (pumice6.sentex.ca [64.7.153.21]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6LDVHUL030356 for ; Thu, 21 Jul 2005 09:31:17 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice6.sentex.ca (8.13.3/8.13.3) with ESMTP id j6LDVk69056062; Thu, 21 Jul 2005 09:31:46 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j6LDVjBV028757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 09:31:45 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050721093218.06991900@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 21 Jul 2005 09:33:43 -0400 To: Joao Barros , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <70e8236f050721062319dbe06e@mail.gmail.com> References: <70e8236f050721054520940895@mail.gmail.com> <20050721134731.X97888@fledge.watson.org> <70e8236f05072106191a1b7f3b@mail.gmail.com> <70e8236f050721062319dbe06e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.21 Cc: Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 13:32:26 -0000 At 09:23 AM 21/07/2005, Joao Barros wrote: >John started debugging this with another person with similar problems >on 5 and the debugging never got to 6 (no feedback from the other >person): >http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052727.html Yes, The other person is me :) I should have some time today to try and test. ---Mike From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 13:34:31 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4EEDE16A434 for ; Thu, 21 Jul 2005 13:34:31 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from maxlor.mine.nu (c-213-160-32-54.customer.ggaweb.ch [213.160.32.54]) by mx1.FreeBSD.org (Postfix) with ESMTP id F057E43DEF for ; Thu, 21 Jul 2005 13:34:15 +0000 (GMT) (envelope-from benlutz@datacomm.ch) Received: from localhost (localhost [127.0.0.1]) by maxlor.mine.nu (Postfix) with ESMTP id 13532261 for ; Thu, 21 Jul 2005 15:34:15 +0200 (CEST) Received: from maxlor.mine.nu ([127.0.0.1]) by localhost (midgard [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72136-08 for ; Thu, 21 Jul 2005 15:34:13 +0200 (CEST) Received: from [10.0.0.23] (mini.intranet [10.0.0.23]) by maxlor.mine.nu (Postfix) with ESMTP id D473547 for ; Thu, 21 Jul 2005 15:34:13 +0200 (CEST) Message-ID: <42DFA43C.7010601@datacomm.ch> Date: Thu, 21 Jul 2005 15:33:48 +0200 From: Benjamin Lutz User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC0421F90FE96FEE194618488" X-Virus-Scanned: by amavisd-new at maxlor.mine.nu Cc: Subject: jails bring down network interface X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 13:34:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigC0421F90FE96FEE194618488 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, While tracking an issue with a jail I run, the interface to which the jail aliases it's IP to suddenly became unresponsive. My script starts the jail, then runs ifconfig alias. After starting and stopping the jail about 20 times, the interface basically froze. Ifconfig reported it as up and running, but it would no longer pass any packets. Bringing it down then back up made it work again. Since this is a production machine, I'm afraid I can't give more specific details, I don't wish to run into the problem again. I'm running FreeBSD 5.4-p5, the interface in question is a VIA VT6105 Rhine III using the vr(4) driver. Cheers Benjamin --------------enigC0421F90FE96FEE194618488 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) iD8DBQFC36Q/gShs4qbRdeQRAp+ZAJ4+tX5L/F9fgCg8/STixQ0Bb8hH2wCfX18q iA1unleMJS5tvO4IxxPjWoY= =xXEf -----END PGP SIGNATURE----- --------------enigC0421F90FE96FEE194618488-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 13:35:10 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5038816A41F; Thu, 21 Jul 2005 13:35:10 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from mailhost.stack.nl (vaak.stack.nl [131.155.140.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8E6D43D55; Thu, 21 Jul 2005 13:34:52 +0000 (GMT) (envelope-from marcolz@stack.nl) Received: from hammer.stack.nl (hammer.stack.nl [IPv6:2001:610:1108:5010::153]) by mailhost.stack.nl (Postfix) with ESMTP id CDF44A303C; Thu, 21 Jul 2005 15:34:51 +0200 (CEST) Received: by hammer.stack.nl (Postfix, from userid 333) id ADD2166D0; Thu, 21 Jul 2005 15:34:51 +0200 (CEST) Date: Thu, 21 Jul 2005 15:34:51 +0200 From: Marc Olzheim To: Robert Watson Message-ID: <20050721133451.GB77633@stack.nl> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721113927.T97888@fledge.watson.org> <20050721113737.GB52753@stack.nl> <20050721125632.F97888@fledge.watson.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline In-Reply-To: <20050721125632.F97888@fledge.watson.org> X-Operating-System: FreeBSD hammer.stack.nl 5.4-STABLE FreeBSD 5.4-STABLE X-URL: http://www.stack.nl/~marcolz/ User-Agent: Mutt/1.5.9i Cc: Marc Olzheim , Alexey Yakimovich , freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 13:35:10 -0000 --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 01:20:49PM +0100, Robert Watson wrote: > >I know FreeBSD 5 was a strange exception in the relase scheduling and=20 > >that a lot has been learned from it for the future and I'm certainly not= =20 > >unthankful for all the work that's done, but I'd like a clear answer on= =20 > >what to do now in regard to taking FreeBSD 5 into 'real' production... [snip] > In terms of advice: >=20 > If you have a "product" due out more than 3 months from now, I think 6.x= =20 > is the obvious way to go: you want to be ahead of the curve so that you= =20 > can have the foundation for your product in sync with the FreeBSD=20 > production release cycle, and avoid jumping major releases early in the= =20 > product life cycle. 6.x has significant performance and stability=20 > improvements -- performance especially in the area of file system=20 > performance on SMP, preemption, network stack, and memory management, and= =20 > stability especially in the area of tty support. By "product", I mean a= =20 > range of things: the OS foundation of an embedded product such as a=20 > firewall or storage appliance, or deployment of an internal product, such= =20 > as a virtual server product at an ISP. [snip] Robert, thanks again for your clear and straight answer. :-) We fall in the Yahoo-like category of FreeBSD users (in more than one way) and have been testing a bit with 6.x, just not as heavy as with 5.x. Since I've already experienced the easy upgrade path before (the way back to 5.x has been a bit more hairy btw.), it will be easy enough for me to upgrade some servers to 6.x and start testing that, which is excatly what I will do. Because my current 5.x machines have to run with INVARIANTS to be in production for more than a few seconds, the performance will no doubt be better anyway. I'll let the debug code enabled on most machines for now anyhow to possibly provide more useful bug reports. :-) Thanks again, your answer was of great value to me. Marc --2B/JsCI69OhZNC5r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC36R7ezjnobFOgrERAvHfAKCsCljAHuBTD0xpSZQ3RFzHRj9UzACfTvVF jXwEQEdb2gfwAZjIX1FChHM= =Tw7V -----END PGP SIGNATURE----- --2B/JsCI69OhZNC5r-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 13:38:49 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E93716A426 for ; Thu, 21 Jul 2005 13:38:49 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3C2443D8A for ; Thu, 21 Jul 2005 13:38:45 +0000 (GMT) (envelope-from joao.barros@gmail.com) Received: by wproxy.gmail.com with SMTP id 71so212453wri for ; Thu, 21 Jul 2005 06:38:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=OpLY/PBLU3lRRZ63TfxYv5e2SqF3Z4VIKwIIetxBb5PBIEm8pl4Fm6L9lDaLqpfDsPXd0B1xI1lbGZIhwPs1TNlMy3zFcFyFbZQiayZJDqLlCbRJA/ZQ/kLiIQutenAPv6gr9lfiUk0tGken6gxn2ruQrQwnx4dKWzQ+mSGaSiE= Received: by 10.54.51.8 with SMTP id y8mr519965wry; Thu, 21 Jul 2005 06:38:17 -0700 (PDT) Received: by 10.54.38.32 with HTTP; Thu, 21 Jul 2005 06:38:17 -0700 (PDT) Message-ID: <70e8236f05072106387c17bc29@mail.gmail.com> Date: Thu, 21 Jul 2005 14:38:17 +0100 From: Joao Barros To: Mike Tancsa In-Reply-To: <6.2.1.2.0.20050721093218.06991900@64.7.153.2> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <70e8236f050721054520940895@mail.gmail.com> <20050721134731.X97888@fledge.watson.org> <70e8236f05072106191a1b7f3b@mail.gmail.com> <70e8236f050721062319dbe06e@mail.gmail.com> <6.2.1.2.0.20050721093218.06991900@64.7.153.2> Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joao Barros List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 13:38:49 -0000 On 7/21/05, Mike Tancsa wrote: > At 09:23 AM 21/07/2005, Joao Barros wrote: >=20 > >John started debugging this with another person with similar problems > >on 5 and the debugging never got to 6 (no feedback from the other > >person): > >http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052727.html >=20 >=20 > Yes, The other person is me :) I should have some time today to try and = test. >=20 > ---Mike Sorry Mike for not "seeing" you ;-) I believe you were on the right track with jhb so I'm looking forward to your test results! Thanks From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 13:44:16 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EFF4C16A41F; Thu, 21 Jul 2005 13:44:16 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from mailhost.tao.org.uk (transwarp.tao.org.uk [212.135.162.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F83443D93; Thu, 21 Jul 2005 13:44:09 +0000 (GMT) (envelope-from joe@tao.org.uk) Received: from genius.tao.org.uk (genius.pact.cpes.susx.ac.uk [139.184.130.240]) by mailhost.tao.org.uk (Postfix) with ESMTP id 7C7956B2D; Thu, 21 Jul 2005 14:44:08 +0100 (BST) Received: by genius.tao.org.uk (Postfix, from userid 100) id 1E56340E4; Thu, 21 Jul 2005 14:43:45 +0100 (BST) Date: Thu, 21 Jul 2005 14:43:45 +0100 From: Josef Karthauser To: stable@FreeBSD.org, multimedia@freebsd.org Message-ID: <20050721134345.GQ73338@genius.pact.cpes.susx.ac.uk> Mail-Followup-To: Josef Karthauser , stable@FreeBSD.org, multimedia@freebsd.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WKQ7zUpzoH2KEHMN" Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: Multiple consumers of /dev/dsp X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 13:44:17 -0000 --WKQ7zUpzoH2KEHMN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In the past I'm sure that we supported the mixing of audio in the kernel so that multiple applications could open /dev/dsp at the same time. Was this a function of the audio card driver, or of the audio subsystem? Currently on my new machine I don't get any mixing, and applications fail to open /dev/dsp if it's already open by something. The current hardware is: FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0xee00, 0xe000 irq 9 bufsz 16384 kld snd_ich (1p/1r/0v channels duplex default) Am I imagining that this use to the case or isn't it enabled by default? Joe --=20 Josef Karthauser (joe@tao.org.uk) http://www.josef-k.net/ FreeBSD (cvs meister, admin and hacker) http://www.uk.FreeBSD.org/ Physics Particle Theory (student) http://www.pact.cpes.sussex.ac.uk/ =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D An eclectic mix of fact an= d theory. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --WKQ7zUpzoH2KEHMN Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iEYEARECAAYFAkLfppAACgkQXVIcjOaxUBaGLwCeNEtrs9cN3BH5gSuzhxxuIEbV D+kAniHHKfmEV636EoPR/B/drHmwsqyf =dryM -----END PGP SIGNATURE----- --WKQ7zUpzoH2KEHMN-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 13:55:32 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3D3816A420; Thu, 21 Jul 2005 13:55:32 +0000 (GMT) (envelope-from zanchey@ucc.gu.uwa.edu.au) Received: from asclepius.uwa.edu.au (asclepius3.uwa.edu.au [130.95.128.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76EF743D5E; Thu, 21 Jul 2005 13:55:21 +0000 (GMT) (envelope-from zanchey@ucc.gu.uwa.edu.au) Received: from asclepius.kas (localhost.localdomain [127.0.0.1]) by asclepius.uwa.edu.au (Postfix) with SMTP id 91535183C26; Thu, 21 Jul 2005 21:55:14 +0800 (WST) Received: from asclepius (localhost.localdomain [127.0.0.1]) by asclepius.prekas (Postfix) with SMTP id 81871183C24; Thu, 21 Jul 2005 21:55:14 +0800 (WST) X-UWA-Client-IP: 130.95.13.9 (UWA) Received: from mooneye.ucc.gu.uwa.edu.au (mooneye.ucc.gu.uwa.edu.au [130.95.13.9]) by asclepius.input (Postfix) with ESMTP id 744DE183BAE; Thu, 21 Jul 2005 21:55:14 +0800 (WST) Received: by mooneye.ucc.gu.uwa.edu.au (Postfix, from userid 801) id 6FB2A17E74; Thu, 21 Jul 2005 21:55:14 +0800 (WST) Received: from mussel.ucc.gu.uwa.edu.au (mussel.ucc.gu.uwa.edu.au [130.95.13.18]) by mooneye.ucc.gu.uwa.edu.au (Postfix) with ESMTP id 3D08C17E71; Thu, 21 Jul 2005 21:55:14 +0800 (WST) Received: from zanchey (helo=localhost) by mussel.ucc.gu.uwa.edu.au with local-esmtp (Exim 3.36 #1 (Debian)) id 1DvbW6-0001EH-00; Thu, 21 Jul 2005 21:55:14 +0800 Date: Thu, 21 Jul 2005 21:55:14 +0800 (WST) From: David Adam To: Josef Karthauser In-Reply-To: <20050721134345.GQ73338@genius.pact.cpes.susx.ac.uk> Message-ID: References: <20050721134345.GQ73338@genius.pact.cpes.susx.ac.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SpamTest-Info: Profile: Formal (251/050713) X-SpamTest-Info: Profile: Detect Hard [UCS 290904] X-SpamTest-Info: Profile: SysLog X-SpamTest-Info: Profile: Marking Spam - Subject (UCS) [02-08-04] X-SpamTest-Status: Not detected X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0125], KAS/Release Cc: stable@FreeBSD.org, multimedia@freebsd.org Subject: Re: Multiple consumers of /dev/dsp X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 13:55:33 -0000 Josef, On Thu, 21 Jul 2005, Josef Karthauser wrote: > In the past I'm sure that we supported the mixing of audio in the kernel > so that multiple applications could open /dev/dsp at the same time. Was > this a function of the audio card driver, or of the audio subsystem? > Currently on my new machine I don't get any mixing, and applications > fail to open /dev/dsp if it's already open by something. > > The current hardware is: > > FreeBSD Audio Driver (newpcm) > Installed devices: > pcm0: at io 0xee00, 0xe000 irq 9 bufsz 16384 kld > snd_ich (1p/1r/0v channels duplex default) > > Am I imagining that this use to the case or isn't it enabled by default? It's not on by default, AFAIK, but setting a couple of sysctls will allow you to have more than one program playing sound at once. # sysctl hw.snd.pcm0.vchans=4 # sysctl hw.snd.maxautovchans=4 Check out http://www.freebsd.org/doc/handbook/sound-setup.html#AEN8582 (the section titled 'Utilizing Multiple Sound Sources'). Cheers, David Adam zanchey@ucc.gu.uwa.edu.au From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 13:59:02 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D878B16A424 for ; Thu, 21 Jul 2005 13:59:02 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id A6FF643D6E for ; Thu, 21 Jul 2005 13:59:01 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 8160746B1C; Thu, 21 Jul 2005 09:58:55 -0400 (EDT) Date: Thu, 21 Jul 2005 14:59:23 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Benjamin Lutz In-Reply-To: <42DFA43C.7010601@datacomm.ch> Message-ID: <20050721145408.P97888@fledge.watson.org> References: <42DFA43C.7010601@datacomm.ch> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: stable@freebsd.org Subject: Re: jails bring down network interface X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 13:59:03 -0000 On Thu, 21 Jul 2005, Benjamin Lutz wrote: > While tracking an issue with a jail I run, the interface to which the > jail aliases it's IP to suddenly became unresponsive. > > My script starts the jail, then runs ifconfig alias. After starting and > stopping the jail about 20 times, the interface basically froze. > Ifconfig reported it as up and running, but it would no longer pass any > packets. Bringing it down then back up made it work again. > > Since this is a production machine, I'm afraid I can't give more > specific details, I don't wish to run into the problem again. > > I'm running FreeBSD 5.4-p5, the interface in question is a VIA VT6105 > Rhine III using the vr(4) driver. Should this occur again, the starting point to investigate is to determine whether it's "sending" that's broken, "receiving" that's broken, or both. I would investigate them by: - Using ping on the system to ping a remote host, see if the other system receives the ping packets using tcpdump. - Use ping on another host to ping the local host, and see if tcpdump on the local host sees the ping packets. As an FYI, ideally you'll do it using a pair of machines that already have each other in the ARP cache, or otherwise you'll need to look for ARP requests on the local area network instead of ICMP requests. Beware switches and routers that mask traffic from third parties (hence suggesting using those two machines). Also, it would be good to know if the if_vr interface receives interrupts or not when it's "wedged" -- you can check this using vmstat -i or systat -vmstat 1 and see what the interrupt count for the interface is. I prefer systat to vmstat, FYI. Finally, if you sit there and ping for a while, do you start getting ENOBUFS back from the interface? Finally, the dmesg probe output would be helpful. Thanks, Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 14:03:00 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 12DFE16A42F for ; Thu, 21 Jul 2005 14:03:00 +0000 (GMT) (envelope-from the.lists@mgm51.com) Received: from oneyou.mcmli.com (oneyou.mcmli.com [216.194.67.64]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F3C043D60 for ; Thu, 21 Jul 2005 14:02:49 +0000 (GMT) (envelope-from the.lists@mgm51.com) Received: from sentry.24cl.com (pcp01267574pcs.danbry01.ct.comcast.net [68.63.157.203]) by oneyou.mcmli.com (Postfix) with ESMTP id A516D5B86 for ; Thu, 21 Jul 2005 10:02:48 -0400 (EDT) Received: from XPMM (unknown [63.119.50.193]) by sentry.24cl.com (Postfix) with ESMTP id 2A86E5101 for ; Thu, 21 Jul 2005 10:02:48 -0400 (EDT) Message-ID: <200507211002580001.03E5249D@sentry.24cl.com> In-Reply-To: <20050721135839.K97888@fledge.watson.org> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> <200507212029.47615.doconnor@gsoft.com.au> <200507210850530519.03A3275D@sentry.24cl.com> <20050721135839.K97888@fledge.watson.org> X-Mailer: Courier 3.50.00.00.1081 (http://www.rosecitysoftware.com) (P) Date: Thu, 21 Jul 2005 10:02:58 -0400 From: "MikeM" To: freebsd-stable@freebsd.org Content-Type: text/plain; charset="us-ascii" Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 14:03:00 -0000 On 7/21/2005 at 2:29 PM Robert Watson wrote: |Some of us have actually spent quite a bit of time looking at the defect |sets reported for 5.x. Depending on the release they fall into a number |of categories, but here are the major ones I've identified: | [snip] |- Network stack stability under high load, especially on SMP. Many of | these bugs had to do with exercising timing and race conditions | "precisely right", and involved workloads not in the standard set of | testing performed. In many cases, those workloads have now been added | to the regression test suite. For example, there were a number of race | conditions relating to the closing of sockets and network stack teardown | in the protocols. These tended to turn up on systems running tens of | thousands of rapidly opening and closing TCP connections on SMP | hardware. Reproducing those conditions is difficult, and not something | most FreeBSD developers have the resources to do, so have to wait for | bug reports from people who do have those resources. | [snip] ============= Thank you for the clear answer. For the record, I am very pleased with the overall quality of FreeBSD, my comments were only meant in the sense of "everything has room for improvement", even something as excellent as FreeBSD. I snipped out one section of your reply because it illustrates a main point of my message. While it is good to have the testing in place to catch race conditions, has anyone done a post mortem to determine why and/or how the race conditions got into the code in the first place? *Someone* coded that race condition. Was it that two developers were using the same data structure without one knowing about the other? If so, then there's a problem that needs to be fixed. Chances are, though, that wasn't the problem. Only the developers would be able to look at the development process and determine why the process allowed a race condition to occur in the code. But if they took the time to do this, then the knowledge gained would be useful across a wide swath of FreeBSD development. Thank you for your offer of allowing me to contribute to the FreeBSD project, however I have professional obligations that prevent me from making the necessary commitment to the project. For the most part I just lurk here, popping my head up on occasion. In doing so, it is not my intent to to snipe at anyone or carp at anything. As such, I'll let this sub-thread die out at this point.... From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 14:12:22 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0EE116A421 for ; Thu, 21 Jul 2005 14:12:22 +0000 (GMT) (envelope-from info@martenvijn.nl) Received: from martenvijn.nl (vijn.xs4all.nl [194.109.254.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1D1B43D48 for ; Thu, 21 Jul 2005 14:12:16 +0000 (GMT) (envelope-from info@martenvijn.nl) Received: from martenvijn.nl (localhost [127.0.0.1]) by martenvijn.nl (8.13.3/8.13.1) with ESMTP id j6LED4wG068425; Thu, 21 Jul 2005 16:13:04 +0200 (CEST) (envelope-from info@martenvijn.nl) Received: (from www@localhost) by martenvijn.nl (8.13.3/8.13.1/Submit) id j6LED3AR068424; Thu, 21 Jul 2005 16:13:03 +0200 (CEST) (envelope-from info@martenvijn.nl) X-Authentication-Warning: martenvijn.nl: www set sender to info@martenvijn.nl using -f Received: from 192.168.1.4 (SquirrelMail authenticated user mvn) by martenvijn.nl with HTTP; Thu, 21 Jul 2005 16:13:02 +0200 (CEST) Message-ID: <59806.192.168.1.4.1121955182.squirrel@martenvijn.nl> In-Reply-To: <42DE6345.5010904@freebsdbrasil.com.br> References: <42DBF250.1060405@freebsdbrasil.com.br> <44C1CD9F-98FA-4CA2-83C6-903F0B19A38F@anduin.net> <42DE6345.5010904@freebsdbrasil.com.br> Date: Thu, 21 Jul 2005 16:13:02 +0200 (CEST) From: "Marten Vijn" To: "Jean Milanez Melo" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: stable@freebsd.org Subject: Re: TinyBSD Call For Testers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: info@martenvijn.nl List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 14:12:22 -0000 I tried to build tiny freebsd a 6.0 version, which currently works on my laptop ( cvs checked out to day) did a build/install world + kernel The image build doesn't exit somewhere or errors... "burned" an image to my cf-card cat my.img > /dev/ad4 Then booted the image boot stops : can't load kernel ? is the TINYBSD kernelconfig is not prepared for 6.0 an attempt to build this kernelconfig separately fails at the atheros driver: if_ath.o(.text+0x213a): In function `ath_node_alloc': : undefined reference to `ath_rate_node_init' if_ath.o(.text+0x2187): In function `ath_node_free': : undefined reference to `ath_rate_node_cleanup' if_ath.o(.text+0x21b6): In function `ath_node_free': : undefined reference to `ath_rate_node_cleanup' if_ath.o(.text+0x322a): In function `ath_start': : undefined reference to `ath_rate_setupxtxdesc' if_ath.o(.text+0x342c): In function `ath_start': : undefined reference to `ath_rate_findrate' if_ath.o(.text+0x3fa1): In function `ath_tx_processq': : undefined reference to `ath_rate_tx_complete' if_ath.o(.text+0x4764): In function `ath_detach': : undefined reference to `ath_rate_detach' if_ath.o(.text+0x4f35): In function `ath_newstate': : undefined reference to `ath_rate_newstate' if_ath.o(.text+0x4ffe): In function `ath_newstate': : undefined reference to `ath_rate_newstate' if_ath.o(.text+0x5352): In function `ath_newassoc': : undefined reference to `ath_rate_newassoc' if_ath.o(.text+0x6e3d): In function `ath_attach': : undefined reference to `ath_rate_attach' *** Error code 1 Stop in /usr/obj/usr/src/sys/TINYBSD. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. medion# Then I copied the GENERIC kernelconfig to /usr/local/share/tinybsd/TINYBSD and repated the build proces... This still leaves me boot message: can't load kernel, so someting else more is going wrong?? I mounted the cf-card on my laptop: medion# cp -v /boot/kernel/kernel /mnt/boot/kernel/ After this there is a bootable system. Next to find out is why the kernel wasn't in the image. Thougths: - something with coping the kernel went wrong (exits on errors would be fine) - atheros drivers do not like to be build in kernel but are fine to be loaded as a modules (I tested the loading of these modeles) Apart from this, opening a getty on a com port by default would safe some time on "serial only" boxes in /etc/ttys I changed : ttyd0 "/usr/libexec/getty std.9600" dialup off secure to: ttyd0 "/usr/ibexec/getty std.9600" ansi on secure Like this a had a soekris 4521 booted : https://martenvijn.nl/tinybsd/net4521.txt Marten From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 14:15:22 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6EA816A424 for ; Thu, 21 Jul 2005 14:15:22 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id C825043D92 for ; Thu, 21 Jul 2005 14:15:15 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-151-199-7-31.ROA.east.verizon.net [151.199.7.31]) by gromit.dlib.vt.edu (8.13.3/8.13.3) with ESMTP id j6LEFDR8035566 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jul 2005 10:15:14 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.4/8.13.4) with ESMTP id j6LEF74O007530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jul 2005 10:15:07 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.4/8.13.4/Submit) id j6LEF7e3007529; Thu, 21 Jul 2005 10:15:07 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Steve In-Reply-To: <42DF2A8F.30202@powersystemsdirect.com> References: <42DF2A8F.30202@powersystemsdirect.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 21 Jul 2005 10:15:06 -0400 Message-Id: <1121955306.7274.19.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-stable@freebsd.org Subject: Re: READ_DMA, WRITE_DMA errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 14:15:23 -0000 On Wed, 2005-07-20 at 23:54 -0500, Steve wrote: > I've found tons of emails, news messages, listserv messages, and even > some bug reports of this seemingly common error. > > So, I had been running 5.2 on a server, and, updated to 5.3. Got the > READ_DMA and WRITE_DMA error and retries. So, figuring it might be a bad > update, took a new drive. put it in, loaded 5.4 for grins, and, same > issue, lots of these errors, eventually destroying the FS. Played around > with various settings, no avail. So, took it back, got different box, > everything new. Same problem, new install of 5.4 > > So, took it back, got another with another MB (different model), but, > same maker (ASUS). Didn't have endless time to spend on production > machine. Sure enough, same problem. It's an ASUS A7V880. Controller is > SATA VT8237. Played around with tons of settings, eventually, after > reading various messages out there, discovered one that resolved the > problem. Had to set hw.ata.ata_dma="0". Of course, there is the obvious > downside to that! Speed! > > But it stinks to have "decent" hardware, yet, have to cripple the > machine. The place I got the equipment at runs ASUS only and has > thousands of them running under other OSes. Wished I had stayed with the > old FreeBSD version and old hardware now. I have not seen anyone that > has ever said the problem was being (or had been) solved though. I see > the bug reports, I take it no one has actually pinpointed the problem > though. BUT, I do hope it is understood that this is fairly widespread, > for me, the likelihood of 3 pcs, 2 different MB models, and, *complete* > new hardware for each of the 3 pcs kind of rules out hardware being > broken, might be badly designed, but, certainly not defective hardware. > > I do hope someone can eventually figure this out, seems to be extremely > common, and, definitely a problem for a stable release named 5.4. I was one of the people who suffered from and reported this "seemingly common error." On the systems that encountered problems, none had particularly obscure or cutting-edge hardware (e.g., Intel PIIX4 ATA controller on the motherboard). One common thread in my case is that all ran some kind of software RAID (gvinum or gmirror), though not all of my software RAIDed machines exhibited the DMA problems leading me to think perhaps it was a hardware/load/disk combination problem. Quite obviously, not all PIIX4 controller users were having this happen, and so the "it doesn't happen to me" factor might have contributed to the general notion that this was probably "operator error" or something like that, and dismissed. Anyway, as well as 5-STABLE, I also run a 6-CURRENT system that suffered the problem. Happily, after the ATA Mk.III merge, the situation improved a LOT. I occasionally still get the error reported, but it is not fatal, unlike before (where the drive would be detached, breaking my geom_mirror, necessitating a lengthy background rebuild). So, I consider the ATA Mk. III rewrite to have "fixed" the problem I had. It may be, then, that those upgrading to the upcoming 6.0-RELEASE (when it appears) might also find their ATA DMA problems solved, too. As for 5.x, I track -STABLE, and have noticed slight improvements regarding the DMA TIMEOUT problem. If you only run -RELEASE, you might miss these ongoing improvements that crop up from time to time. Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 14:17:14 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87F4316A421 for ; Thu, 21 Jul 2005 14:17:14 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEAE243DA7 for ; Thu, 21 Jul 2005 14:16:53 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id BE0F046B0C; Thu, 21 Jul 2005 10:16:52 -0400 (EDT) Date: Thu, 21 Jul 2005 15:17:20 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: MikeM In-Reply-To: <200507211002580001.03E5249D@sentry.24cl.com> Message-ID: <20050721150925.K97888@fledge.watson.org> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> <200507212029.47615.doconnor@gsoft.com.au> <200507210850530519.03A3275D@sentry.24cl.com> <20050721135839.K97888@fledge.watson.org> <200507211002580001.03E5249D@sentry.24cl.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 14:17:14 -0000 On Thu, 21 Jul 2005, MikeM wrote: > Thank you for the clear answer. For the record, I am very pleased with > the overall quality of FreeBSD, my comments were only meant in the sense > of "everything has room for improvement", even something as excellent as > FreeBSD. I think everyone agrees there's room for improvement -- many FreeBSD developers come to work on FreeBSD because they are enjoy writing software and are dissatisfied with what they find in the commercial world. However, I've found most problems in the FreeBSD development process stem from a lack of resources to implement the best processes, rather than processes being wrong "by design". I.e., there being a strong interest in producing tested code, but inadequate resources to provide the thorough testing we'd like. Or, the best of intentions (a company agrees to support development of a feature, starts work, and then goes out of business) preventing follow-through. As has already been mentioned we're intentionally going for a much less agressive 6.x feature set in order to refine some of the hard architectural work in 5.x, and to avoid over-committing resources. One of the biggest problems with the SMP work in 5.x was the dot.com crash: companies that had committed resources to manage and develop on the project ceased to be available. > I snipped out one section of your reply because it illustrates a main > point of my message. > > While it is good to have the testing in place to catch race conditions, > has anyone done a post mortem to determine why and/or how the race > conditions got into the code in the first place? *Someone* coded that > race condition. Was it that two developers were using the same data > structure without one knowing about the other? If so, then there's a > problem that needs to be fixed. Chances are, though, that wasn't the > problem. Only the developers would be able to look at the development > process and determine why the process allowed a race condition to occur > in the code. But if they took the time to do this, then the knowledge > gained would be useful across a wide swath of FreeBSD development. There's some information, FYI, on the netperf cluster: http://www.freebsd.org/projects/netperf/cluster.html It needs a bit more updating for recent hardware additions, courtesy Sentex. With respect to the network stack changes -- yes. And in some cases, the areas of problems were actually marked with comments indicating they were known, but not easily resolvable (or not thought to be bugs that were exercised in practice). In other cases, they were due to the mis-understanding of code in the stack, or the fact that data structures or code were not originally designed with parallelism in mind, and the communal discovery of unexpected or undocumented complexity. A significant part of 5.x and 6.x work has been fixing existing architectural problems present for decades, but that suddenly become more relevant as the kernel supports SMP and threading better. In several cases, they were bugs already present in FreeBSD 4.x, but only exercisable under extremely high memory load. Something you'll find in later 5.x versions is a much greater use of locking assertions than in earlier versions. > Thank you for your offer of allowing me to contribute to the FreeBSD > project, however I have professional obligations that prevent me from > making the necessary commitment to the project. For the most part I > just lurk here, popping my head up on occasion. In doing so, it is not > my intent to to snipe at anyone or carp at anything. As such, I'll let > this sub-thread die out at this point.... If only the realities of paid work didn't intervene so frequently -- sadly, I'm only too familiar with that problem :-). Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 14:37:06 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6BADB16A41F for ; Thu, 21 Jul 2005 14:37:06 +0000 (GMT) (envelope-from eksffa@freebsdbrasil.com.br) Received: from capeta.freebsdbrasil.com.br (vrrp.freebsdbrasil.com.br [200.210.70.30]) by mx1.FreeBSD.org (Postfix) with SMTP id 1696C43D5E for ; Thu, 21 Jul 2005 14:36:54 +0000 (GMT) (envelope-from eksffa@freebsdbrasil.com.br) Received: (qmail 14890 invoked by uid 0); 21 Jul 2005 11:36:54 -0300 Received: from eksffa@freebsdbrasil.com.br by capeta.freebsdbrasil.com.br by uid 82 with qmail-scanner-1.22 (uvscan: v4.3.20/v4539. spamassassin: 2.64. Clear:RC:1(201.17.165.147):. Processed in 0.386245 secs); 21 Jul 2005 14:36:54 -0000 Received: from unknown (HELO ?10.69.69.69?) (201.17.165.147) by capeta.freebsdbrasil.com.br with SMTP; 21 Jul 2005 11:36:54 -0300 Message-ID: <42DFB301.5080304@freebsdbrasil.com.br> Date: Thu, 21 Jul 2005 11:36:49 -0300 From: Patrick Tracanelli Organization: FreeBSD Brasil LTDA User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050420 X-Accept-Language: en-us, en MIME-Version: 1.0 To: info@martenvijn.nl References: <42DBF250.1060405@freebsdbrasil.com.br> <44C1CD9F-98FA-4CA2-83C6-903F0B19A38F@anduin.net> <42DE6345.5010904@freebsdbrasil.com.br> <59806.192.168.1.4.1121955182.squirrel@martenvijn.nl> In-Reply-To: <59806.192.168.1.4.1121955182.squirrel@martenvijn.nl> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Jean Milanez Melo , stable@freebsd.org Subject: Re: TinyBSD Call For Testers X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 14:37:06 -0000 Hello Marten, Thanks for your input. Yesterday sysutils/tinybsd was updated to reflect fetching the new 0.2 TinyBSD which has some improvements related to lib depends, specially pam as it was not functional on tinybsd (opie related problems) in FreeBSD 6 like it was in RELENG_5 before. Also, new entries were added to the kernel (commented, by default) with the new atheros entries (ath rate is probably what is causing your problem, uncomment it on the new 0.2 tinybsd to build your system under FreeBSD 6). Also, your change on ttys will probably be interesting for other users too. It makes me think that it is probably time to maintain a separated etc/ customized tree under tinybsd development dirs, in a PicoBSD fashion. In fact it is already added to the TODO listing for TinyBSD. I believe it is a better way than changing anything under etc/ without the embedded system developer explicity will. Please, if you get the same (or new) problems under FreeBSD 6 w/ TinyBSD 0.2, send a note. -- Patrick Tracanelli FreeBSD Brasil LTDA. (31) 3281-9633 / 3281-3547 sip://316601@sip.freebsdbrasil.com.br http://www.freebsdbrasil.com.br "Long live Hanin Elias, Kim Deal!" From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 15:47:18 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 346D316A432 for ; Thu, 21 Jul 2005 15:47:18 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 6797843DBE for ; Thu, 21 Jul 2005 15:46:55 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: (qmail invoked by alias); 21 Jul 2005 15:46:20 -0000 Received: from p5090D1F6.dip.t-dialin.net (EHLO klotz.local) [80.144.209.246] by mail.gmx.net (mp021) with SMTP; 21 Jul 2005 17:46:20 +0200 X-Authenticated: #989277 Received: from [192.168.0.2] (booky.local [192.168.0.2]) by klotz.local (8.13.3/8.13.3) with ESMTP id j6LFjw36001863; Thu, 21 Jul 2005 17:45:59 +0200 (CEST) (envelope-from nakal@nurfuerspam.de) Message-ID: <42DFC345.10205@nurfuerspam.de> Date: Thu, 21 Jul 2005 17:46:13 +0200 From: Martin User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050715) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> <200507212029.47615.doconnor@gsoft.com.au> <200507210850530519.03A3275D@sentry.24cl.com> <20050721135839.K97888@fledge.watson.org> In-Reply-To: <20050721135839.K97888@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-stable@FreeBSD.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 15:47:18 -0000 Robert Watson wrote: > - ATA problems. Many of these, while a symptom of bugs in the ATA code > running without Giant, were very specific to timing, or divergent/poor > ATA hardware. As a result, they were difficult to reproduce in any > environment but the original reporting environment. The same hardware > might perform fine in a FreeBSD developer's system. Many of these > problems have now been resolved, but some have not. Often as not, the > problems have to do with retrying requests to drives. My system is instable with latest -STABLE kernels, producing ATA DMA errors. I also think that this does have directly a connection to buggy ATA code. It seems it is something more general. > As I mentioned, > we believe the ATA code in 6.x is much more resilient, but right now > what it needs is testing, not merging to 5.x yet. Fixes require just as > much testing as any other change, since a fix for one issue may well > trigger another issue, especially in the world of cheap PC hardware. This is true for me. RELENG_6 is great, but there are still annoying bugs which prevent me from migrating the system completely. I'm using FreeBSD mainly as desktop and I really need bktr(4) to work correctly. Then there is some trouble with ath(4) making my notebook unusable. To put it straight, there is no FreeBSD branch which works well for me since about 2 months. This is frustrating for me, but I try to have patience, because you do a great job and btw, I cannot imagine to use my PCs without FreeBSD. One more thing about "cheap hardware": if you know that a piece of hardware is potentially buggy (I mean real BUGS and not missing support), please publish your opinion, because I will buy hardware FOR FREEBSD, so I avoid major problems. How about test suites for ACPI quality, e.g.? Would it be possible? There are people who spend time to test FOR YOU, you don't need to buy all the hardware in this world. Martin From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 15:55:14 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D594316A456 for ; Thu, 21 Jul 2005 15:55:14 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7603F43DF7 for ; Thu, 21 Jul 2005 15:54:23 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice6.sentex.ca (pumice6.sentex.ca [64.7.153.21]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6LFrrFt044960 for ; Thu, 21 Jul 2005 11:53:53 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice6.sentex.ca (8.13.3/8.13.3) with ESMTP id j6LFsNZE095425; Thu, 21 Jul 2005 11:54:23 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j6LFsMXT029476 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 11:54:22 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050721115305.07eb8008@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 21 Jul 2005 11:56:20 -0400 To: Joao Barros , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <70e8236f050721062319dbe06e@mail.gmail.com> References: <70e8236f050721054520940895@mail.gmail.com> <20050721134731.X97888@fledge.watson.org> <70e8236f05072106191a1b7f3b@mail.gmail.com> <70e8236f050721062319dbe06e@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.21 Cc: Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 15:55:15 -0000 At 09:23 AM 21/07/2005, Joao Barros wrote: >On 7/21/05, Robert Watson wrote: > > > > On Thu, 21 Jul 2005, Joao Barros wrote: > > > > > I was hopping for you to mention user's feedback. I started this thread > > > http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052288.html > > > > There are two likely causes of problems: > > > > (1) amr driver problems > > (2) General PCI/interrupt/ACPI/APIC problems > >I suspect the 2nd >John started debugging this with another person with similar problems >on 5 and the debugging never got to 6 (no feedback from the other >person): >http://lists.freebsd.org/pipermail/freebsd-current/2005-July/052727.html I finally got around to testing John's last suggestion, and the modification allows me to boot a RELENG_6 kernel! So there is a "work around" at least on my DELL PE6350. Take a look at the thread on current for a full dmesg. ---Mike From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 16:15:26 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E0C0016A420 for ; Thu, 21 Jul 2005 16:15:26 +0000 (GMT) (envelope-from news649@powersystemsdirect.com) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A5AA43D4C for ; Thu, 21 Jul 2005 16:15:25 +0000 (GMT) (envelope-from news649@powersystemsdirect.com) Received: from [192.168.1.6] (c-24-1-170-82.hsd1.tx.comcast.net[24.1.170.82]) by comcast.net (sccrmhc11) with ESMTP id <2005072116152301100s4u1ae>; Thu, 21 Jul 2005 16:15:24 +0000 Message-ID: <42DFCA1C.3050406@powersystemsdirect.com> Date: Thu, 21 Jul 2005 11:15:24 -0500 From: Steve User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Mather References: <42DF2A8F.30202@powersystemsdirect.com> <1121955306.7274.19.camel@zappa.Chelsea-Ct.Org> In-Reply-To: <1121955306.7274.19.camel@zappa.Chelsea-Ct.Org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: READ_DMA, WRITE_DMA errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 16:15:27 -0000 Paul Mather wrote: >One common thread in my case is that >all ran some kind of software RAID (gvinum or gmirror), though not all >of my software RAIDed machines exhibited the DMA problems leading me to >think perhaps it was a hardware/load/disk combination problem. > > I do not use RAID at all, so, not common for me. >Anyway, as well as 5-STABLE, I also run a 6-CURRENT system that suffered >the problem. Happily, after the ATA Mk.III merge, the situation >improved a LOT. I occasionally still get the error reported, but it is >not fatal, unlike before (where the drive would be detached, breaking my >geom_mirror, necessitating a lengthy background rebuild). > > Well, that's good news, I just hope that is a widespread fix, there seems to be different issues, and, hopefully, the rewrite intentionally or unintentionally resolves them all! Sounds like in your case, it's almost 100%. An occasional error (we get watchdog timeouts on network) is not bad as long as it doesn't destroy the FS, obviously, we want zero, but, things happen. It's quite conceivable that 1 error per day IS a hardware issue. But, in our case, with 4 machines and the corruption, not the case! Steve From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 16:19:09 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D98516A420; Thu, 21 Jul 2005 16:19:09 +0000 (GMT) (envelope-from news649@powersystemsdirect.com) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22E0843D8E; Thu, 21 Jul 2005 16:18:57 +0000 (GMT) (envelope-from news649@powersystemsdirect.com) Received: from [192.168.1.6] (c-24-1-170-82.hsd1.tx.comcast.net[24.1.170.82]) by comcast.net (sccrmhc12) with ESMTP id <2005072116185601200igo33e>; Thu, 21 Jul 2005 16:18:56 +0000 Message-ID: <42DFCAF1.8020701@powersystemsdirect.com> Date: Thu, 21 Jul 2005 11:18:57 -0500 From: Steve User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <42DF2A8F.30202@powersystemsdirect.com> <20050721112230.A97888@fledge.watson.org> In-Reply-To: <20050721112230.A97888@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: READ_DMA, WRITE_DMA errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 16:19:09 -0000 Robert Watson wrote: > 6.0 contains a significant re-write and update of the ATA driver, and > corrects a number of known problems with timeouts and reliability. > This rewrite is available as patches against 5.x, but has not been > committed because ATA is a very sensitive thing (lots of very diverse > and very broken hardware), and has had insufficient testing. If you > have test hardware available that's not in production, it would be > quite helpful if you could install 6.0-BETA2, once that comes out in > the next week or so, and see if the specific ATA problems you're > experiencing occur there. It's not impossible that the new ATA code > will be merged to 5.x, but I think we cannot do that until it has seen > a lot more exposure. If you search back through the mailing archives, > you should be able to find posts from Soren regarding the new ATA > patches, if you want to give them a try on 5.x. Yes, I will try and find those patches for 5, I do not have a free machine that exhibits the problem, but, I do have my disk cloned so a quick test of a patch should be simple and risk free over a weekend when I have time to mess around. If anyone has that link handy, please post. (for the patch) Steve From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 16:27:07 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B902716A42C for ; Thu, 21 Jul 2005 16:27:07 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from out2.smtp.messagingengine.com (out2.smtp.messagingengine.com [66.111.4.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BC4F43D45 for ; Thu, 21 Jul 2005 16:26:45 +0000 (GMT) (envelope-from pbowen@fastmail.fm) Received: from frontend2.messagingengine.com (frontend2.internal [10.202.2.151]) by frontend1.messagingengine.com (Postfix) with ESMTP id A3029CC1E3E for ; Thu, 21 Jul 2005 12:26:44 -0400 (EDT) X-Sasl-enc: 69F3925nkzujTL0by5achWRoZ+lpaaxG/A9rTWp6BJV9 1121963203 Received: from [192.168.1.134] (unknown [207.160.231.2]) by frontend2.messagingengine.com (Postfix) with ESMTP id CC67256F785 for ; Thu, 21 Jul 2005 12:26:43 -0400 (EDT) Message-ID: <42DFCCA1.4020808@fastmail.fm> Date: Thu, 21 Jul 2005 11:26:09 -0500 From: Patrick Bowen User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050515 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Debug output when wi0 pcccard removed X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 16:27:08 -0000 Hello, All; I recently CVSUP'd from 5.4 to 6.0BETA1. I used the instructions in UPDATING to build/install world and used GENERIC unmodified to build the kernel. The whole procedure went without a single hitch. My question concerns the meaning of a debug message which appears when I remove my Wi-Fi card (which by the way works fine...I'm using it to send this mail). Here's the output from "dmesg" when I insert the card (just for reference); wi0: at port 0x100-0x13f irq 11 function 0 config 1 on pccard1 wi0: using RF:PRISM2.5 MAC:ISL3873 wi0: Intersil Firmware: Primary (1.1.0), Station (1.4.9) wi0: Ethernet address: 00:04:e2:80:34:be When I remove the card I get the following; taskqueue_drain with the following non-sleepable locks held: exclusive sleep mutex wi0 (network driver) r = 0 (0xc2416afc) locked @ /usr/src/sys/dev/wi/if_wi.c:845 KDB: stack backtrace: kdb_backtrace(1,c1af9250,c1af9000,c1989b80,d44bfc2c) at kdb_backtrace+0x29 witness_warn(5,0,c0854d21,c1af9000,c1af9000) at witness_warn+0x18e taskqueue_drain(c1989b80,c1af9250,c1af9000,c1af9000,c1af9000) at taskqueue_drain+0x1a if_detach(c1af9000,c1af9000) at if_detach+0x1a ether_ifdetach(c1af9000,0,c2416000,d44bfc94,c05debfc) at ether_ifdetach+0x28 ieee80211_ifdetach(c2416004,c1af9000,c1af9000,0,c1c51880) at ieee80211_ifdetach+0x50 wi_detach(c1c51880) at wi_detach+0x64 device_detach(c1c51880) at device_detach+0x70 pccard_detach_card(c1aaa600) at pccard_detach_card+0x41 exca_removal(c1a6e804) at exca_removal+0x46 cbb_removal(c1a6e800) at cbb_removal+0x2c cbb_event_thread(c1a6e800,d44bfd38,c1a6e800,c0579df0,0) at cbb_event_thread+0x9a fork_exit(c0579df0,c1a6e800,d44bfd38) at fork_exit+0xa0 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd44bfd6c, ebp = 0 --- wi0: detached I don't read debug messages yet, and am wondering if this is a problem, is it just because WITNESS and INVARIANTS are enabled, or if it's normal but never seen in a non-debug kernel. I get a similar message when I shutdown, having to do mostly with ACPI, but since that's been buggy on this machine (Dell Latitude C600), I almost expected that. Thanks in advance-- Patrick Bowen From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 17:03:29 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BC75016A424 for ; Thu, 21 Jul 2005 17:03:29 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03C1743D7C for ; Thu, 21 Jul 2005 17:03:12 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6LH3BoS060230 for ; Thu, 21 Jul 2005 12:03:11 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu Jul 21 12:03:11 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6LH3BPg060228 for freebsd-stable@freebsd.org; Thu, 21 Jul 2005 12:03:11 -0500 (CDT) (envelope-from karl) Date: Thu, 21 Jul 2005 12:03:11 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050721170311.GB60080@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> <200507212029.47615.doconnor@gsoft.com.au> <200507210850530519.03A3275D@sentry.24cl.com> <20050721135839.K97888@fledge.watson.org> <42DFC345.10205@nurfuerspam.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42DFC345.10205@nurfuerspam.de> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 17:03:30 -0000 Agreed. I have a PR open on the ATA issues, particularly with SATA drives, and have had it open since before 5.4-RELEASE. It remains open. Careful selection of what's where can avoid major trouble, but this is hardware that worked properly on 4.x for a LONG time - its definitely NOT defective. This is a major sore spot, and is not a trivial issue by any means. Disk I/O is arguably THE major thing that must work right for any operating system to be usable. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind On Thu, Jul 21, 2005 at 05:46:13PM +0200, Martin wrote: > Robert Watson wrote: > >- ATA problems. Many of these, while a symptom of bugs in the ATA code > > running without Giant, were very specific to timing, or divergent/poor > > ATA hardware. As a result, they were difficult to reproduce in any > > environment but the original reporting environment. The same hardware > > might perform fine in a FreeBSD developer's system. Many of these > > problems have now been resolved, but some have not. Often as not, the > > problems have to do with retrying requests to drives. > > My system is instable with latest -STABLE kernels, producing ATA DMA > errors. I also think that this does have directly a connection to buggy > ATA code. It seems it is something more general. > > > As I mentioned, > > we believe the ATA code in 6.x is much more resilient, but right now > > what it needs is testing, not merging to 5.x yet. Fixes require just > > as > > much testing as any other change, since a fix for one issue may well > > trigger another issue, especially in the world of cheap PC hardware. > > This is true for me. RELENG_6 is great, but there are still annoying > bugs which prevent me from migrating the system completely. I'm using > FreeBSD mainly as desktop and I really need bktr(4) to work correctly. > Then there is some trouble with ath(4) making my notebook unusable. > > To put it straight, there is no FreeBSD branch which works well > for me since about 2 months. This is frustrating for me, but I try > to have patience, because you do a great job and btw, I cannot > imagine to use my PCs without FreeBSD. > > One more thing about "cheap hardware": if you know that a piece of > hardware is potentially buggy (I mean real BUGS and not missing > support), please publish your opinion, because I will buy hardware > FOR FREEBSD, so I avoid major problems. How about test suites for > ACPI quality, e.g.? Would it be possible? There are people who spend > time to test FOR YOU, you don't need to buy all the hardware in > this world. > > Martin > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 18:03:59 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C098416A421; Thu, 21 Jul 2005 18:03:59 +0000 (GMT) (envelope-from aiy@ferens.net) Received: from rwcrmhc12.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88A2943D60; Thu, 21 Jul 2005 18:03:38 +0000 (GMT) (envelope-from aiy@ferens.net) Received: from ferens.net ([67.188.76.62]) by comcast.net (rwcrmhc14) with ESMTP id <2005072118033101400a0g13e>; Thu, 21 Jul 2005 18:03:32 +0000 Received: from yoleksiyw2k (dhcp-171-69-219-50.cisco.com [171.69.219.50]) (authenticated bits=0) by ferens.net (8.13.4/8.13.4) with ESMTP id j6LI34dV005050 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 21 Jul 2005 11:03:05 -0700 (PDT) (envelope-from aiy@ferens.net) Message-Id: <200507211803.j6LI34dV005050@ferens.net> From: "Alexey Yakimovich" To: "'Robert Watson'" , "'Marc Olzheim'" Date: Thu, 21 Jul 2005 11:02:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcWN7pFWOg2a+98NQwKkHdBwJlBwgQAJ4Y8A X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <20050721125632.F97888@fledge.watson.org> X-FerensNet-MailScanner-Information: Please contact the ISP for more information X-FerensNet-MailScanner: Found to be clean X-FerensNet-MailScanner-From: aiy@ferens.net Cc: freebsd-stable@FreeBSD.org Subject: RE: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 18:03:59 -0000 First of all thank you very much all for your replies. I just want to add some comments based on previous mails. - I completely agree with MikeM - any kind of complex software could be tested with right prepared test cases, specially if they are going to be reused in the next release; - if those problems happened to 5 branch, probably it would happened = again for 6 or 7, so why I have to switch to 6 right now? Is it because 5 will never be fixed? Does word "production" mean something to FreeBSD project now?=20 - I remember some time ago you can stay on current all the time not = worrying that your box is crashed and didn't auto rebooted; - chip hardware was always in use by FreeBSD, as far as I remember, or something is changed recently, specially to US, and people buying only expensive hardware. Probably it is no longer important to support chip hardware because of more important FreeBSD clients like Yahoo or Apple = use real hardware, not the stupid one like ATA and they have these = "aggressive" project schedules. Believe me I know what "aggressive" project schedule means, with long, long list of new features. It is important for such companies like Yahoo only and I know why, because it's easy to sell = useless product with lots of new features than stable product with few ones. For regular guy better to have some stable system running all the time and = doing real work (development or providing some service) than rebooting the = box, because of some new fancy feature. It's getting close to Windows right = now. - IBM, Yahoo, Intel, Apple ..., those guys are smart, having millions of unpaid open source developers working on them. The problem is that some = day those projects will have theirs "aggressive" project schedules, then = will disappeared or changed to .com. So make sure you are still doing what = you like to do and you are having a fun of it. Thanks, Alexey > -----Original Message----- > From: Robert Watson [mailto:rwatson@FreeBSD.org]=20 > Sent: Thursday, July 21, 2005 5:21 AM > To: Marc Olzheim > Cc: Alexey Yakimovich; freebsd-stable@FreeBSD.org > Subject: Re: Quality of FreeBSD >=20 >=20 > On Thu, 21 Jul 2005, Marc Olzheim wrote: >=20 > > Indeed. That's why my company started taking FreeBSD 5.3 in use for=20 > > production servers when it was out. Since then numerous=20 > bugs were fixed,=20 > > some of which reported by us. Now that we're X bug fixes=20 > later in time=20 > > and started to get a good feeling about the number of open=20 > problems, it=20 > > is extremely annoying to hear the "This will (probably) not=20 > be fixed in=20 > > 5.x" statements. That conflicts with 'gradually get=20 > resolved'. What do=20 > > you recommend larger consumers to do ? Keep using FreeBSD 4=20 > and start=20 > > testing FreeBSD 6.x, dropping 5.x all together ? > > > > I know FreeBSD 5 was a strange exception in the relase=20 > scheduling and=20 > > that a lot has been learned from it for the future and I'm=20 > certainly not=20 > > unthankful for all the work that's done, but I'd like a=20 > clear answer on=20 > > what to do now in regard to taking FreeBSD 5 into 'real'=20 > production... >=20 > Marc, >=20 > I should start out by saying I appreciate your clear and concise bug=20 > reports, and the list of your company's show-stopper 5.x bugs=20 > has made the=20 > rounds among FreeBSD developers. I'm happy that at least one of the=20 > issues on the list was fixed by me. :-) As you probably saw=20 > yesterday,=20 > I've started bugging Poul-Henning to look at the pty problem you're=20 > experiencing, and will get that on our 6.0 release=20 > show-stopper list. I=20 > haven't yet had a chance to reproduce it locally, but it=20 > sounds like that=20 > should be straight forward. >=20 > FreeBSD 5 has been an exception -- "normally", in as much as major=20 > releases have a "normal", the set of new features is a lot=20 > less agressive,=20 > and it has been our goal with 6.x to restore the expectation=20 > of a more=20 > rapid release cycle with a less agressive feature set. This=20 > should reduce=20 > the number of problems by virtue of reducing the level of change. It=20 > should also make it easier for users to pick what version to=20 > run on, as=20 > the amount of adaptation they have to do to slide forward a=20 > version will=20 > be greatly reduced. I.e., right now it's relatively easy to=20 > move back and=20 > forward between 5.x and 6.x. >=20 > With respect to 5.x vs 6.x upgrades: I've seen companies take two=20 > different strategies. Most of them have been at least=20 > experimenting with=20 > deploying 5.x, and are very interested in its feature set. =20 > Support for=20 > large file systems, 64-bit support on newer AMD and Intel hardware,=20 > improved PAM support, etc. Some of my customers are specifically=20 > interested in the support for mandatory access control, but that's=20 > obviously a less common feature request :-). The biggest determining=20 > factor for companies today comes from their own product=20 > schedule, since=20 > most big consumers of FreeBSD treat it as a component in a=20 > "product" they=20 > deliver for others. >=20 > For example, my understanding is that Yahoo is now deploying=20 > 6.0 betas=20 > across their server environment with great success, but was actually=20 > unable to seriously deploy 5.x because their goal was to support full=20 > 32-bit compatibility on 64-bit amd/intel hardware, which has=20 > only recently=20 > reached the level of maturity they require. In fact, you'll=20 > notice if you=20 > follow FreeBSD commit logs that much of that support has come=20 > from Yahoo!.=20 > Since 6.x is maturing in pretty good synch with their=20 > deployment timeline=20 > for 5.x, they are actually deploying 6.x. Of course, Yahoo!=20 > has a team of=20 > in-house OS developers who adapt FreeBSD for their needs, and=20 > is quite=20 > capable of debugging a kernel or two if they run into problems. >=20 > The ATA driver issue is a sticky one for many users -- we=20 > hope to get the=20 > 6.x ATA code back into 5.x in the next 5.x release. However,=20 > hard-earned=20 > experience tells us that ATA driver code is notoriously=20 > difficult to get=20 > right across the broad range of available hardware. Soren has been=20 > lobbying to get it merged to 5.x, but given the level of=20 > testing performed=20 > so far, we can't yet justify the merge. My hope is that with=20 > 6.0 out the=20 > door and a lot of testing of that code, we can get it merged=20 > back to 5.x=20 > before 5.5. Many other fixes have gone into 5.x, correcting=20 > many of the=20 > most significant issues. If you compare 5.4 with 5.3, you'll=20 > find that in=20 > most cases, it's both faster and more stable. >=20 > The tty issue is a sticky one also. The tty code in 6.x has been=20 > substantially rewritten to better support the SMPng=20 > environment. Because=20 > the tty code "plugs in" to a number of device drivers, T1=20 > adapter drivers,=20 > etc, changing the tty interfaces is a fairly big event, and=20 > will affect=20 > third party vendors like Cronyx. This code has also not yet=20 > seen as wide=20 > deployment as I'd like, so it's also something that really isn't=20 > appropriate for an MFC immediately. However, once it has=20 > seen significant=20 > 6.0 deployment, it may well be. A question then will be whether it's=20 > better to simply say "you're better off making the jump to=20 > 6.x, which is=20 > minor" than backporting, and it's something we can't really=20 > answer until=20 > we're comfortable that it's seen sufficient deployment. My=20 > hope is that=20 > we can identify a workaround for 5.x that will avoid the code=20 > upheaval a=20 > full backport would require. It's not as ideal as having the=20 > "right" fix,=20 > but it would stop the panics. I need to ping phk and some of=20 > the other=20 > tty-centric folk to look at this some more. >=20 > In terms of advice: >=20 > If you have a "product" due out more than 3 months from now,=20 > I think 6.x=20 > is the obvious way to go: you want to be ahead of the curve=20 > so that you=20 > can have the foundation for your product in sync with the FreeBSD=20 > production release cycle, and avoid jumping major releases=20 > early in the=20 > product life cycle. 6.x has significant performance and stability=20 > improvements -- performance especially in the area of file system=20 > performance on SMP, preemption, network stack, and memory=20 > management, and=20 > stability especially in the area of tty support. By=20 > "product", I mean a=20 > range of things: the OS foundation of an embedded product such as a=20 > firewall or storage appliance, or deployment of an internal=20 > product, such=20 > as a virtual server product at an ISP. >=20 > On the other hand, if you're deploying today, I think that=20 > unless you're=20 > prepared to deal with the 6.0 bug fix cycle (both the BETA/RC=20 > cycle, and=20 > the inevitable post-release fixes for a .0 release), 5.4+patches or=20 > 5-STABLE is the right place to sit. At least two of the=20 > critical bugs on=20 > your list were fixed in 5-STABLE after the release of 5.4, so=20 > for some,=20 > 5-STABLE is the best place to be. We've opted not to do a=20 > patch/errata=20 > update for 5.4 for the socket error you were receiving on the=20 > basis that=20 > it doesn't affect a wide audience and doesn't correct a=20 > "Critical" failure=20 > -- i.e., a crash or the like, unlike some of the NFS server=20 > fixes, for=20 > which we did do an errata fix. >=20 > From the perspective of the FreeBSD developers, if you can=20 > tolerate the=20 > 6.x release process, we encourage you to jump on that=20 > bandwagon. It will=20 > help us release a better 6.0, and that's where the future=20 > lies. Our goal=20 > is to make 6.x a pretty seemless upgrade from 5.x, as it has a less=20 > agressive feature set, and far fewer user-visible changes (i.e., no=20 > conversion to OpenPAM, devfs,=A0UFS2, large compiler version=20 > upgrade, ... as=20 > in 5.x). When I upgraded my personal web/shell server to 6.x=20 > from 5.x=20 > last week, I didn't have to change any configuration in /etc=20 > at all, other=20 > than a painless pass through mergemaster to merge the _dhcp user and=20 > group. As always, we look to the freebsd-stable users to=20 > help us test new=20 > features ahead of the release. >=20 > Thanks, >=20 > Robert N M Watson >=20 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 18:11:53 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B8AE16A423; Thu, 21 Jul 2005 18:11:53 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fileserver.fields.utoronto.ca (fileserver.fields.utoronto.ca [128.100.216.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6491443D55; Thu, 21 Jul 2005 18:11:39 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from fields.fields.utoronto.ca (fields.localdomain [192.168.216.11]) by fileserver.fields.utoronto.ca (8.12.8/8.12.8/Fields 6.0) with ESMTP id j6LIBaNV014102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 14:11:37 -0400 Received: from obsecurity.dyndns.org (fields.fields.utoronto.ca [128.100.216.11]) by fields.fields.utoronto.ca (8.12.8/8.12.8/Fields WS 6.0) with ESMTP id j6LIBZ6P031038; Thu, 21 Jul 2005 14:11:36 -0400 Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 2F29D512B7; Thu, 21 Jul 2005 14:11:35 -0400 (EDT) Date: Thu, 21 Jul 2005 14:11:34 -0400 From: Kris Kennaway To: Eirik ?verby Message-ID: <20050721181134.GA58429@xor.obsecurity.org> References: <20050721050048.GU22430@xor.obsecurity.org> <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="sm4nu43k4a2Rpi4c" Content-Disposition: inline In-Reply-To: <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> User-Agent: Mutt/1.4.2.1i Cc: stable@FreeBSD.org, Robert Watson , Kris Kennaway Subject: Re: Serious issue with serial console in 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 18:11:53 -0000 --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 21, 2005 at 10:56:54AM +0200, Eirik ?verby wrote: > >You might have to wait until 6.0-R since fixing it seems to require > >infrastructure changes that cannot easily be backported to 5.x. >=20 > With all due respect - if this is (and I'm assuming it is, because it =20 > happens on all the servers I'm serial-controlling) an omnipresent =20 > problem on 5.x, I daresay it should warrant some more attention. =20 > Having unsafe serial terminal support that can bring down your system =20 > like that defies much of the point of having serial terminal support =20 > in the first place. It *has* received attention, and the conclusion was as above. 6.0 has some significant TTY changes relative to 5.x, which probably cannot be backported without disruption. > However, since I seem to be the only one who has noticed this, =20 > perhaps I'm the last person on earth to routinely use serial terminal =20 > switches instead of KVM switches to do my admin work? No, others have reported it too. Kris --sm4nu43k4a2Rpi4c Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFC3+VWWry0BWjoQKURAi4eAKDCWBSGkLvoxeIXoJnHgFH1GEh4qwCgnvjz CI0eCLkF5KO3JMRQhiXTF/8= =5gVc -----END PGP SIGNATURE----- --sm4nu43k4a2Rpi4c-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 18:18:44 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7BC2516A420 for ; Thu, 21 Jul 2005 18:18:44 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 12A6843D45 for ; Thu, 21 Jul 2005 18:18:43 +0000 (GMT) (envelope-from freebsd-stable@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Dvfbi-0007g9-2n for freebsd-stable@freebsd.org; Thu, 21 Jul 2005 20:17:18 +0200 Received: from gn-hgk-15cd4.adsl.wanadoo.nl ([81.69.122.212]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Jul 2005 20:17:18 +0200 Received: from A.S.Usov by gn-hgk-15cd4.adsl.wanadoo.nl with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 21 Jul 2005 20:17:18 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-stable@freebsd.org From: "Alexander S. Usov" Date: Thu, 21 Jul 2005 20:17:09 +0200 Organization: KVI Lines: 19 Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: gn-hgk-15cd4.adsl.wanadoo.nl User-Agent: KNode/0.9.1 Sender: news Subject: Strange panic X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 18:18:44 -0000 Hi! I have got a pair of very strange panics today. I didn't saw the exact panic message for the firs one, as the X was running at the time it has halted, and all I can say about it is that it was unable to reboot and there are no coredump. For the second one I saw a message (approximate -- I type it in from paper) "panic: sbflush_locked: cc 0 || mb 0xc1bfa600 || mbcnt 0", and it looks like that as soon as it has tried to dump core it has got a second panic and went to reboot. I am unsure if the machine was able to reboot automatically, as I pressed a key to write down panic message. As in the previous case there is no core, so I can't get any backtrace from it. It all has happeden on 5.4-RELEASE-p3. -- Best regards, Alexander. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 18:40:08 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 856B216A421; Thu, 21 Jul 2005 18:40:08 +0000 (GMT) (envelope-from msch@snafu.de) Received: from daiquiri.visp.de (daiquiri.visp.de [84.23.254.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id 16D7343D53; Thu, 21 Jul 2005 18:40:07 +0000 (GMT) (envelope-from msch@snafu.de) X-Trace: 507c6d73636840736e6166752e64657c38342e3139302e3136312e36367c314476 66786b2d3030303147502d30577c31313231393731323034 Received: from daiquiri.visp.de ([10.156.10.19] helo=localhost) by daiquiri.visp.de with esmtpa (Exim 4.51 id 1Dvfxk-0001GP-0W); Thu, 21 Jul 2005 20:40:04 +0200 In-Reply-To: <20050721113927.T97888@fledge.watson.org> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721113927.T97888@fledge.watson.org> Mime-Version: 1.0 (Apple Message framework v733) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1E0ACFEC-A232-4818-9175-E6D181D63DA0@snafu.de> Content-Transfer-Encoding: 7bit From: Matthias Schuendehuette Date: Thu, 21 Jul 2005 20:39:55 +0200 To: Robert Watson X-Pgp-Agent: GPGMail 1.1 (Tiger) X-Mailer: Apple Mail (2.733) Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 18:40:08 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Robert, Am 21.07.2005 um 13:00 schrieb Robert Watson: > > Have you tried, and do you plan to try, our 6.0 test releases before > 6.0-RELEASE goes out the door? Specifically, on the hardware you > know > you're having problems with 5.4 on? Yes, I did - see the thread "mpt + gvinum on 6.0-BETA". But I'm a bit disappointed, that until now there's not *one* reply on my report. It's new hardware, which doesn't even boot with 5.3/5.4-RELEASE (but with 5.2.1 :-) and probably a more popular Server (FUJITSU-SIEMENS RX300 S2)... what was my fault here? Should I post to -current instead? - -- Ciao/BSD - Matthias Matthias Schuendehuette , Berlin (Germany) PGP-Key at and ID: 0xDDFB0A5F -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC3+wAf1BNcN37Cl8RAkgOAJ9uNrNXRdoQbn8CGKGnlp6e0+aTLwCdFrzU MkbX3dKcLQhI0B2wgEN6j7w= =Iaju -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 18:45:49 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7DE1216A494 for ; Thu, 21 Jul 2005 18:45:49 +0000 (GMT) (envelope-from pcasidy@casidy.com) Received: from scotty.galacsys.net (scotty.galacsys.net [217.24.81.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B6F943E1E for ; Thu, 21 Jul 2005 18:45:09 +0000 (GMT) (envelope-from pcasidy@casidy.com) Received: from smtp.casidy.net (lns-vlq-39f-81-56-135-122.adsl.proxad.net [81.56.135.122]) by scotty.galacsys.net (Postfix) with ESMTP id 49E24C509E for ; Thu, 21 Jul 2005 20:44:59 +0200 (CEST) Received: from casidy.com (unknown [192.168.1.2]) by smtp.casidy.net (Postfix) with ESMTP id 5CEA8B86C for ; Thu, 21 Jul 2005 20:44:55 +0200 (CEST) Date: Thu, 21 Jul 2005 20:44:35 +0000 (UTC) From: pcasidy@casidy.com To: freebsd-stable@freebsd.org In-Reply-To: <20050721133451.GB77633@stack.nl> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20050721184455.5CEA8B86C@smtp.casidy.net> Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 18:45:50 -0000 Hi all! I have read this thread with a lot of interest and I have to congratulate each of you for bringing calm, clever and interesting answers. I too felt that the quality of 5.x is not what I was used to but there are new nice and promising features. Having read most of all the emails it looks like to me that there is a key element : the hardware. There are too many combinations on the market to build an "i386-like" based platform. Isn't it time to build a suggested hardware list or a hardware blacklist? I do not how to do that because maybe there is a high risk of being sued by a company making bad hardware even under the right of free speech. Perhaps it can be done by making a list of hardware company from which FreeBSD has a good support (not saying good hardware but good feedback on how to solve problems). I know of the hardware vendor and supported hardware list but I am not sure if it is up to date and I diddn't manage to get good use of it : how has it really be tested on that hardware? My main problem, and to others after seeing the question from times to times, is to know which is a good (not necessarly the best) hardware to run FreeBSD on? When I buy a new motherboard, which chipset to choose/avoid, which controllers? Twenty years ago, when you bought a computer (not a PC), the system delivered with it used to work well or had known problems with workarounds. Okay, there were simpler but in case of problems, it was easy to try to reproduce and investigate the problem. I am not saying we should choose one defined platform. I don't know if it is feasible but having a list of hardware recommendations from which we are sure to get good support from would be an added value. As it is too hard to support every combination of hardware why not focus on a few ones? Maybe the ones developpers have an esay access to? If someone use another combination, no problem : he will have the same support as today. Thanks for reading my attempt to move forward. Phil. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 19:00:19 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DFA8F16A43E for ; Thu, 21 Jul 2005 19:00:19 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 78D1543D67 for ; Thu, 21 Jul 2005 19:00:11 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 929F346B3C; Thu, 21 Jul 2005 15:00:10 -0400 (EDT) Date: Thu, 21 Jul 2005 20:00:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexey Yakimovich In-Reply-To: <200507211803.j6LI34dV005050@ferens.net> Message-ID: <20050721194500.W9208@fledge.watson.org> References: <200507211803.j6LI34dV005050@ferens.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1481328753-1121972440=:9208" Cc: 'Marc Olzheim' , freebsd-stable@FreeBSD.org Subject: RE: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 19:00:20 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1481328753-1121972440=:9208 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Thu, 21 Jul 2005, Alexey Yakimovich wrote: > First of all thank you very much all for your replies. > I just want to add some comments based on previous mails. > > - I completely agree with MikeM - any kind of complex software could be= =20 > tested with right prepared test cases, specially if they are going to be= =20 > reused in the next release; The trick is balancing the investment of time in different areas, and=20 motivating people to do the things that aren't enjoyable, don't receive=20 much appreciation, etc. Testing is both difficult and time-consuming. It= =20 works best when people are willing to dedicate all or more of their time=20 to the task, since it requires the building of frameworks, the regular=20 application of those tests, etc. People who step forward to work=20 consistently on testing and bug reporting, like Peter Holm, do the project= =20 an invaluable service. And people like Marc Olzheim who take the time to= =20 evaluate the system thoroughly, work through the bug report and fix cycle,= =20 and have the patience to deal with situations where there aren't enough=20 hours in the day to fix a problem make it all worthwhile. It's easy to=20 say that more testing should be done, but testing requires as much=20 expertise in the internals of a piece of software as writing it, and far=20 more time. > - if those problems happened to 5 branch, probably it would happened=20 > again for 6 or 7, so why I have to switch to 6 right now? Is it because= =20 > 5 will never be fixed? Does word "production" mean something to FreeBSD= =20 > project now? As has been discussed extensively in this thread and other threads, the=20 FreeBSD development model typically addresses change at the tree HEAD,=20 where the changes are tested and evaluated, and then they are back-ported.= =20 Some changes are low-risk, and are backported quickly (minor locking=20 fixes, error handling, etc). Others are higher risk, and are backported=20 only when they are felt to have received sufficient testing (driver=20 re-writes, structural changes). Other changes are considered too large to= =20 ever back backported, as you might as well move the users forward as it=20 will be less work and come to much the same thing (major architectural=20 changes, such as SMPng, new hardware platforms, new kernel subsystems).=20 I can't promise that every fix in HEAD (7.x) or the upcoming 6-STABLE=20 branch will make it to 5-STABLE, because many of the changes there won't=20 be appropriate for a backport, or would take so much work to backport that= =20 the time is better spent on other tasks. However, the hope is to bring as= =20 many changes as is sensible back. As we've already discussed, there are several important improvements=20 germinating in 6.x, and many of them will be things that can and will be=20 backported. If you look at the network stack differences between 5.x and= =20 6.x, you'll find very few, because I and others have worked to agressively= =20 merge fixes, usually on a time lag of between one week and one month. I=20 know this is also true in other areas of the system. If you're aware of=20 changes that fix something in 6.x or 7.x that haven't been backported, and= =20 it's been over a month, please contact the developer to ask about a=20 backport. > - I remember some time ago you can stay on current all the time not=20 > worrying that your box is crashed and didn't auto rebooted; Certainly. I also remember long periods of time where you didn't want to= =20 be running current unless you were a VM kernel hacker, such as leading up= =20 to the 3.x release cycle, or just after the introduction of background=20 fsck in 5.x. The 6.x/7.x HEAD branches have been quite on the stable side= =20 compared to the 3.x and 5.x development cycle, and my hope is they will=20 remain that way. > - chip hardware was always in use by FreeBSD, as far as I remember, or=20 > something is changed recently, specially to US, and people buying only=20 > expensive hardware. Probably it is no longer important to support chip=20 > hardware because of more important FreeBSD clients like Yahoo or Apple=20 > use real hardware, not the stupid one like ATA and they have these=20 > "aggressive" project schedules. Believe me I know what "aggressive"=20 > project schedule means, with long, long list of new features. It is=20 > important for such companies like Yahoo only and I know why, because=20 > it's easy to sell useless product with lots of new features than stable= =20 > product with few ones. For regular guy better to have some stable system= =20 > running all the time and doing real work (development or providing some= =20 > service) than rebooting the box, because of some new fancy feature. It's= =20 > getting close to Windows right now. All software development involves the balancing of risks and benefits.=20 That's one of the reasons why the FreeBSD Project offers several=20 development branches, which allow users to balance new features and long=20 running "stale" source code. Notice that we'll be supporting the 4.x=20 branch for several years to come. Of course, if you run 4.x, you won't be= =20 getting many new features, but it's a quite valid option. And likewise,=20 you won't be able to run properly on the newest hardware, because running= =20 on new hardware requires significant architectural changes, such as the=20 introduction of ACPI, rewrites of device driver frameworks, new file=20 systems, and so on. > - IBM, Yahoo, Intel, Apple ..., those guys are smart, having millions of= =20 > unpaid open source developers working on them. The problem is that some= =20 > day those projects will have theirs "aggressive" project schedules, then= =20 > will disappeared or changed to .com. So make sure you are still doing=20 > what you like to do and you are having a fun of it. I think you'll find many FreeBSD developers enjoy working on FreeBSD best= =20 when they receive constructive feedback on the work they do, consisting of= =20 thanks when it works, and helpful bug reports when it doesn't. Some=20 FreeBSD developers live to write new features; others live to get things=20 working "just right", answer questions on mailing lists, or give talks at= =20 conferences. If the balance doesn't seem right, that means there's room=20 for new developers who want to work on the areas that don't get enough=20 attention. :-) Robert N M Watson > > Thanks, > Alexey > >> -----Original Message----- >> From: Robert Watson [mailto:rwatson@FreeBSD.org] >> Sent: Thursday, July 21, 2005 5:21 AM >> To: Marc Olzheim >> Cc: Alexey Yakimovich; freebsd-stable@FreeBSD.org >> Subject: Re: Quality of FreeBSD >> >> >> On Thu, 21 Jul 2005, Marc Olzheim wrote: >> >>> Indeed. That's why my company started taking FreeBSD 5.3 in use for >>> production servers when it was out. Since then numerous >> bugs were fixed, >>> some of which reported by us. Now that we're X bug fixes >> later in time >>> and started to get a good feeling about the number of open >> problems, it >>> is extremely annoying to hear the "This will (probably) not >> be fixed in >>> 5.x" statements. That conflicts with 'gradually get >> resolved'. What do >>> you recommend larger consumers to do ? Keep using FreeBSD 4 >> and start >>> testing FreeBSD 6.x, dropping 5.x all together ? >>> >>> I know FreeBSD 5 was a strange exception in the relase >> scheduling and >>> that a lot has been learned from it for the future and I'm >> certainly not >>> unthankful for all the work that's done, but I'd like a >> clear answer on >>> what to do now in regard to taking FreeBSD 5 into 'real' >> production... >> >> Marc, >> >> I should start out by saying I appreciate your clear and concise bug >> reports, and the list of your company's show-stopper 5.x bugs >> has made the >> rounds among FreeBSD developers. I'm happy that at least one of the >> issues on the list was fixed by me. :-) As you probably saw >> yesterday, >> I've started bugging Poul-Henning to look at the pty problem you're >> experiencing, and will get that on our 6.0 release >> show-stopper list. I >> haven't yet had a chance to reproduce it locally, but it >> sounds like that >> should be straight forward. >> >> FreeBSD 5 has been an exception -- "normally", in as much as major >> releases have a "normal", the set of new features is a lot >> less agressive, >> and it has been our goal with 6.x to restore the expectation >> of a more >> rapid release cycle with a less agressive feature set. This >> should reduce >> the number of problems by virtue of reducing the level of change. It >> should also make it easier for users to pick what version to >> run on, as >> the amount of adaptation they have to do to slide forward a >> version will >> be greatly reduced. I.e., right now it's relatively easy to >> move back and >> forward between 5.x and 6.x. >> >> With respect to 5.x vs 6.x upgrades: I've seen companies take two >> different strategies. Most of them have been at least >> experimenting with >> deploying 5.x, and are very interested in its feature set. >> Support for >> large file systems, 64-bit support on newer AMD and Intel hardware, >> improved PAM support, etc. Some of my customers are specifically >> interested in the support for mandatory access control, but that's >> obviously a less common feature request :-). The biggest determining >> factor for companies today comes from their own product >> schedule, since >> most big consumers of FreeBSD treat it as a component in a >> "product" they >> deliver for others. >> >> For example, my understanding is that Yahoo is now deploying >> 6.0 betas >> across their server environment with great success, but was actually >> unable to seriously deploy 5.x because their goal was to support full >> 32-bit compatibility on 64-bit amd/intel hardware, which has >> only recently >> reached the level of maturity they require. In fact, you'll >> notice if you >> follow FreeBSD commit logs that much of that support has come >> from Yahoo!. >> Since 6.x is maturing in pretty good synch with their >> deployment timeline >> for 5.x, they are actually deploying 6.x. Of course, Yahoo! >> has a team of >> in-house OS developers who adapt FreeBSD for their needs, and >> is quite >> capable of debugging a kernel or two if they run into problems. >> >> The ATA driver issue is a sticky one for many users -- we >> hope to get the >> 6.x ATA code back into 5.x in the next 5.x release. However, >> hard-earned >> experience tells us that ATA driver code is notoriously >> difficult to get >> right across the broad range of available hardware. Soren has been >> lobbying to get it merged to 5.x, but given the level of >> testing performed >> so far, we can't yet justify the merge. My hope is that with >> 6.0 out the >> door and a lot of testing of that code, we can get it merged >> back to 5.x >> before 5.5. Many other fixes have gone into 5.x, correcting >> many of the >> most significant issues. If you compare 5.4 with 5.3, you'll >> find that in >> most cases, it's both faster and more stable. >> >> The tty issue is a sticky one also. The tty code in 6.x has been >> substantially rewritten to better support the SMPng >> environment. Because >> the tty code "plugs in" to a number of device drivers, T1 >> adapter drivers, >> etc, changing the tty interfaces is a fairly big event, and >> will affect >> third party vendors like Cronyx. This code has also not yet >> seen as wide >> deployment as I'd like, so it's also something that really isn't >> appropriate for an MFC immediately. However, once it has >> seen significant >> 6.0 deployment, it may well be. A question then will be whether it's >> better to simply say "you're better off making the jump to >> 6.x, which is >> minor" than backporting, and it's something we can't really >> answer until >> we're comfortable that it's seen sufficient deployment. My >> hope is that >> we can identify a workaround for 5.x that will avoid the code >> upheaval a >> full backport would require. It's not as ideal as having the >> "right" fix, >> but it would stop the panics. I need to ping phk and some of >> the other >> tty-centric folk to look at this some more. >> >> In terms of advice: >> >> If you have a "product" due out more than 3 months from now, >> I think 6.x >> is the obvious way to go: you want to be ahead of the curve >> so that you >> can have the foundation for your product in sync with the FreeBSD >> production release cycle, and avoid jumping major releases >> early in the >> product life cycle. 6.x has significant performance and stability >> improvements -- performance especially in the area of file system >> performance on SMP, preemption, network stack, and memory >> management, and >> stability especially in the area of tty support. By >> "product", I mean a >> range of things: the OS foundation of an embedded product such as a >> firewall or storage appliance, or deployment of an internal >> product, such >> as a virtual server product at an ISP. >> >> On the other hand, if you're deploying today, I think that >> unless you're >> prepared to deal with the 6.0 bug fix cycle (both the BETA/RC >> cycle, and >> the inevitable post-release fixes for a .0 release), 5.4+patches or >> 5-STABLE is the right place to sit. At least two of the >> critical bugs on >> your list were fixed in 5-STABLE after the release of 5.4, so >> for some, >> 5-STABLE is the best place to be. We've opted not to do a >> patch/errata >> update for 5.4 for the socket error you were receiving on the >> basis that >> it doesn't affect a wide audience and doesn't correct a >> "Critical" failure >> -- i.e., a crash or the like, unlike some of the NFS server >> fixes, for >> which we did do an errata fix. >> >> From the perspective of the FreeBSD developers, if you can >> tolerate the >> 6.x release process, we encourage you to jump on that >> bandwagon. It will >> help us release a better 6.0, and that's where the future >> lies. Our goal >> is to make 6.x a pretty seemless upgrade from 5.x, as it has a less >> agressive feature set, and far fewer user-visible changes (i.e., no >> conversion to OpenPAM, devfs,=A0UFS2, large compiler version >> upgrade, ... as >> in 5.x). When I upgraded my personal web/shell server to 6.x >> from 5.x >> last week, I didn't have to change any configuration in /etc >> at all, other >> than a painless pass through mergemaster to merge the _dhcp user and >> group. As always, we look to the freebsd-stable users to >> help us test new >> features ahead of the release. >> >> Thanks, >> >> Robert N M Watson >> > > --0-1481328753-1121972440=:9208-- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 19:07:23 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 973A816A41F for ; Thu, 21 Jul 2005 19:07:23 +0000 (GMT) (envelope-from vivek@khera.org) Received: from yertle.kcilink.com (yertle.kcilink.com [65.205.34.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id F2D5143DC0 for ; Thu, 21 Jul 2005 19:07:03 +0000 (GMT) (envelope-from vivek@khera.org) Received: from [192.168.1.4] (pcp04418836pcs.nrockv01.md.comcast.net [69.140.110.248]) by yertle.kcilink.com (Postfix) with ESMTP id D8B2AB820 for ; Thu, 21 Jul 2005 15:07:02 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v733) In-Reply-To: <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> References: <20050721050048.GU22430@xor.obsecurity.org> <00DD4399-4317-4579-82C4-5B64AC3F800B@anduin.net> Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <74BA9234-7775-46BA-B778-01C7283EA742@khera.org> Content-Transfer-Encoding: quoted-printable From: Vivek Khera Date: Thu, 21 Jul 2005 15:07:01 -0400 To: stable@freebsd.org X-Mailer: Apple Mail (2.733) Cc: Subject: Re: Serious issue with serial console in 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 19:07:23 -0000 On Jul 21, 2005, at 4:56 AM, Eirik =D8verby wrote: > However, since I seem to be the only one who has noticed this, =20 > perhaps I'm the last person on earth to routinely use serial =20 > terminal switches instead of KVM switches to do my admin work? > no, there are plenty of us out here... i have two 16 port cyclades =20 boxes I use for this purpose. i've never run into this problem, but =20 then I only have 3 boxes running FreeBSD 5.x and I almost never log =20 into the console: only for OS upgrades or the extremely rare panic on =20= one of the a dual proc Opteron systems. Vivek Khera, Ph.D. +1-301-869-4449 x806 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 19:19:33 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7264616A424 for ; Thu, 21 Jul 2005 19:19:33 +0000 (GMT) (envelope-from bsd@unixforge.net) Received: from mail.sectornotfound.com (mail.sectornotfound.com [209.139.233.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id 700BE43D76 for ; Thu, 21 Jul 2005 19:19:15 +0000 (GMT) (envelope-from bsd@unixforge.net) Received: from hannibal.int.sectornotfound.com (hannibal.int.sectornotfound.com [192.168.98.3]) by murdock.sectornotfound.com (8.13.1/8.13.1) with ESMTP id j6LJJEWX018885 for ; Thu, 21 Jul 2005 12:19:14 -0700 (PDT) (envelope-from bsd@unixforge.net) Received: from [192.168.3.212] (gw.activestate.com [209.17.183.249]) (authenticated bits=0) by hannibal.int.sectornotfound.com (8.13.1/8.12.10) with ESMTP id j6LJJB9l070137 for ; Thu, 21 Jul 2005 12:19:12 -0700 (PDT) (envelope-from bsd@unixforge.net) Message-ID: <42DFF582.1050406@unixforge.net> Date: Thu, 21 Jul 2005 12:20:34 -0700 From: "Eli K. Breen" User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 19:19:33 -0000 All, Does anyone have a good handle on how to replicate (read: image) a freebsd machine from one machine to an ostensibly similar machine? So far I've used countless variations and combinations of the following: dd (Slow, not usefull if the hardware isn't identical?) tar (Doesn't replicate MBR) rsync (No MBR support) Norton Ghost (Doesn't support UFS/UFS2?) G4U (little experience with this) Now whether my details are a bit off, that's fine, I don't want this to be diluted in to discussion of minute frivolous details (as these things are wont to do), but what I _am_ looking for is a tried, tested and true method of FreeBSD machine replication, specifically for the 5.3+ releases. Many thanks, -E- From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 19:26:34 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94D1A16A41F for ; Thu, 21 Jul 2005 19:26:34 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id F28EF43D7B for ; Thu, 21 Jul 2005 19:26:13 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6LJQDrl062189 for ; Thu, 21 Jul 2005 14:26:13 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu Jul 21 14:26:13 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6LJQDQo062187 for freebsd-stable@freebsd.org; Thu, 21 Jul 2005 14:26:13 -0500 (CDT) (envelope-from karl) Date: Thu, 21 Jul 2005 14:26:13 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050721192613.GA61902@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050721194500.W9208@fledge.watson.org> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 19:26:34 -0000 Ok, Robert, but then here's the question.... How come the ATA code which was very stable in 4.x was screwed with in a production release, breaking it, with no path backwards to the working code? This is a perfectly valid thing to do in -HEAD, where its "heh, you know this might go BOOM on you!" I've been told that before when reporting problems with -HEAD, and while I might not have liked hearing it, its a valid point of view. But the same thing in a production release is an entirely different matter, especially when it impacts MAINSTREAM hardware (the SII chipset is EXTREMELY common among SATA implementations, being on basically ALL PCI plug-in boards, with Hitachi and Maxtor being hardly "uncommon" disks!) I originally thought perhaps this was a Maxtor problem, given my past history with them playing a bit "fast and loose" with the rules. However, when I replicated the problem on my Hitachi Deskstar drives that theory went out the window. I understand your dissertation below, and agree with it. However, this is a case where code was tampered with in ways that broke things for a LOT of people, myself included, on a PRODUCTION release, and was let loose with inadequate testing. It is NOT a situation where obscure, little-used hardware becomes obsolete and thus ignored - eventually falling into ruin. This is a situation where current, in-service hardware on literally millions of machines becomes suddenly unstable to unusable entirely with FreeBSD. I understand and expect that if I run -HEAD, I'm asking for it. I used to do this on a fairly regular basis ANYWAY, since there were features I NEEDED in certain environments, and while I did bitch from time to time, and worked to find solutions when I could, in general this was an "ok" path for me, with my own personal resources dedicated to testing and evaluation on the specific hardware which I needed to use. This is different. The ATA problems are neither rare or difficult to reproduce. Indeed, on the PR I opened, I can take any of the SATA drives I have (from two different manufacturers - Hitachi and Maxtor), put them on ANY adapter using the most common (SII) chipset (Adaptec's and Bustek's both tested) and get the same results - DMA errors when under any significant load. It is trivially easy to reproduce the problem. I came up with a patch to prevent the disconnects on a mirrored drive (but not the errors themselves) which then led to requests that I test a bunch of related patches - a request I begrudgingly complied with. Why begrudging? Because the patch contemplated didn't address the problem - it papered over it. Now the errors still come, but they don't detach the disk. They severely impact performance though, and for non-mirrored configurations the results might be data loss instead of a complaint. Since data corruption in these circumstances is very difficult to detect until it has become catastrophic, I'm not about to attempt to provoke it on a production machine (which is likely the only way I could identify WITH CERTAINTY that corruption has taken place.) So what's going on here Robert? The PR I filed is still open, it was filed on 2/17! Last activity is from April 4th. I first noted the issue on 1/31 and failing the note of any real resolution in the codebase forward, I filed the PR on 2/17 after exhausting my own internal testing and remedy process. It is now the middle of July, the ticket is still open, and there is no path out of this box that I can see. I understand that there is concern that while ATA-GenX might fix this, it might also break other things, and thus there is reluctance to MFC it back into 5.x. That's a valid concern, but IMHO it misses the larger point. The question unaddressed is why the STABLE code in 4.x was abandoned before it was known that the replacement was as good as that which it replaced! This isn't a "gnat" - it was submitted as "serious", and I meant that when I submitted it. The only reason I didn't consider it "critical" and "high" priority is that it doesn't hit EVERY configuration - but if it hits yours, your system is severely impacted. As things stand right now I'm not even sure WHAT codeset I can CVSUP and test to have a decent shot at getting a FULLY working ATA/gmirror implementation. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind On Thu, Jul 21, 2005 at 08:00:40PM +0100, Robert Watson wrote: > > On Thu, 21 Jul 2005, Alexey Yakimovich wrote: > > >First of all thank you very much all for your replies. > >I just want to add some comments based on previous mails. > > > >- I completely agree with MikeM - any kind of complex software could be > >tested with right prepared test cases, specially if they are going to be > >reused in the next release; > > The trick is balancing the investment of time in different areas, and > motivating people to do the things that aren't enjoyable, don't receive > much appreciation, etc. Testing is both difficult and time-consuming. It > works best when people are willing to dedicate all or more of their time > to the task, since it requires the building of frameworks, the regular > application of those tests, etc. People who step forward to work > consistently on testing and bug reporting, like Peter Holm, do the > project an invaluable service. And people like Marc Olzheim who take the > time to evaluate the system thoroughly, work through the bug report and > fix cycle, and have the patience to deal with situations where there > aren't enough hours in the day to fix a problem make it all worthwhile. > It's easy to say that more testing should be done, but testing requires > as much expertise in the internals of a piece of software as writing it, > and far more time. > > >- if those problems happened to 5 branch, probably it would happened > >again for 6 or 7, so why I have to switch to 6 right now? Is it because > >5 will never be fixed? Does word "production" mean something to FreeBSD > >project now? > > As has been discussed extensively in this thread and other threads, the > FreeBSD development model typically addresses change at the tree HEAD, > where the changes are tested and evaluated, and then they are > back-ported. Some changes are low-risk, and are backported quickly (minor > locking fixes, error handling, etc). Others are higher risk, and are > backported only when they are felt to have received sufficient testing > (driver re-writes, structural changes). Other changes are considered too > large to ever back backported, as you might as well move the users > forward as it will be less work and come to much the same thing (major > architectural changes, such as SMPng, new hardware platforms, new kernel > subsystems). I can't promise that every fix in HEAD (7.x) or the upcoming > 6-STABLE branch will make it to 5-STABLE, because many of the changes > there won't be appropriate for a backport, or would take so much work to > backport that the time is better spent on other tasks. However, the hope > is to bring as many changes as is sensible back. > > As we've already discussed, there are several important improvements > germinating in 6.x, and many of them will be things that can and will be > backported. If you look at the network stack differences between 5.x and > 6.x, you'll find very few, because I and others have worked to > agressively merge fixes, usually on a time lag of between one week and > one month. I know this is also true in other areas of the system. If > you're aware of changes that fix something in 6.x or 7.x that haven't > been backported, and it's been over a month, please contact the developer > to ask about a backport. > > >- I remember some time ago you can stay on current all the time not > >worrying that your box is crashed and didn't auto rebooted; > > Certainly. I also remember long periods of time where you didn't want to > be running current unless you were a VM kernel hacker, such as leading up > to the 3.x release cycle, or just after the introduction of background > fsck in 5.x. The 6.x/7.x HEAD branches have been quite on the stable > side compared to the 3.x and 5.x development cycle, and my hope is they > will remain that way. > > >- chip hardware was always in use by FreeBSD, as far as I remember, or > >something is changed recently, specially to US, and people buying only > >expensive hardware. Probably it is no longer important to support chip > >hardware because of more important FreeBSD clients like Yahoo or Apple > >use real hardware, not the stupid one like ATA and they have these > >"aggressive" project schedules. Believe me I know what "aggressive" > >project schedule means, with long, long list of new features. It is > >important for such companies like Yahoo only and I know why, because > >it's easy to sell useless product with lots of new features than stable > >product with few ones. For regular guy better to have some stable system > >running all the time and doing real work (development or providing some > >service) than rebooting the box, because of some new fancy feature. It's > >getting close to Windows right now. > > All software development involves the balancing of risks and benefits. > That's one of the reasons why the FreeBSD Project offers several > development branches, which allow users to balance new features and long > running "stale" source code. Notice that we'll be supporting the 4.x > branch for several years to come. Of course, if you run 4.x, you won't > be getting many new features, but it's a quite valid option. And > likewise, you won't be able to run properly on the newest hardware, > because running on new hardware requires significant architectural > changes, such as the introduction of ACPI, rewrites of device driver > frameworks, new file systems, and so on. > > >- IBM, Yahoo, Intel, Apple ..., those guys are smart, having millions of > >unpaid open source developers working on them. The problem is that some > >day those projects will have theirs "aggressive" project schedules, then > >will disappeared or changed to .com. So make sure you are still doing > >what you like to do and you are having a fun of it. > > I think you'll find many FreeBSD developers enjoy working on FreeBSD best > when they receive constructive feedback on the work they do, consisting > of thanks when it works, and helpful bug reports when it doesn't. Some > FreeBSD developers live to write new features; others live to get things > working "just right", answer questions on mailing lists, or give talks at > conferences. If the balance doesn't seem right, that means there's room > for new developers who want to work on the areas that don't get enough > attention. :-) > > Robert N M Watson > > > >Thanks, > >Alexey > > > >>-----Original Message----- > >>From: Robert Watson [mailto:rwatson@FreeBSD.org] > >>Sent: Thursday, July 21, 2005 5:21 AM > >>To: Marc Olzheim > >>Cc: Alexey Yakimovich; freebsd-stable@FreeBSD.org > >>Subject: Re: Quality of FreeBSD > >> > >> > >>On Thu, 21 Jul 2005, Marc Olzheim wrote: > >> > >>>Indeed. That's why my company started taking FreeBSD 5.3 in use for > >>>production servers when it was out. Since then numerous > >>bugs were fixed, > >>>some of which reported by us. Now that we're X bug fixes > >>later in time > >>>and started to get a good feeling about the number of open > >>problems, it > >>>is extremely annoying to hear the "This will (probably) not > >>be fixed in > >>>5.x" statements. That conflicts with 'gradually get > >>resolved'. What do > >>>you recommend larger consumers to do ? Keep using FreeBSD 4 > >>and start > >>>testing FreeBSD 6.x, dropping 5.x all together ? > >>> > >>>I know FreeBSD 5 was a strange exception in the relase > >>scheduling and > >>>that a lot has been learned from it for the future and I'm > >>certainly not > >>>unthankful for all the work that's done, but I'd like a > >>clear answer on > >>>what to do now in regard to taking FreeBSD 5 into 'real' > >>production... > >> > >>Marc, > >> > >>I should start out by saying I appreciate your clear and concise bug > >>reports, and the list of your company's show-stopper 5.x bugs > >>has made the > >>rounds among FreeBSD developers. I'm happy that at least one of the > >>issues on the list was fixed by me. :-) As you probably saw > >>yesterday, > >>I've started bugging Poul-Henning to look at the pty problem you're > >>experiencing, and will get that on our 6.0 release > >>show-stopper list. I > >>haven't yet had a chance to reproduce it locally, but it > >>sounds like that > >>should be straight forward. > >> > >>FreeBSD 5 has been an exception -- "normally", in as much as major > >>releases have a "normal", the set of new features is a lot > >>less agressive, > >>and it has been our goal with 6.x to restore the expectation > >>of a more > >>rapid release cycle with a less agressive feature set. This > >>should reduce > >>the number of problems by virtue of reducing the level of change. It > >>should also make it easier for users to pick what version to > >>run on, as > >>the amount of adaptation they have to do to slide forward a > >>version will > >>be greatly reduced. I.e., right now it's relatively easy to > >>move back and > >>forward between 5.x and 6.x. > >> > >>With respect to 5.x vs 6.x upgrades: I've seen companies take two > >>different strategies. Most of them have been at least > >>experimenting with > >>deploying 5.x, and are very interested in its feature set. > >>Support for > >>large file systems, 64-bit support on newer AMD and Intel hardware, > >>improved PAM support, etc. Some of my customers are specifically > >>interested in the support for mandatory access control, but that's > >>obviously a less common feature request :-). The biggest determining > >>factor for companies today comes from their own product > >>schedule, since > >>most big consumers of FreeBSD treat it as a component in a > >>"product" they > >>deliver for others. > >> > >>For example, my understanding is that Yahoo is now deploying > >>6.0 betas > >>across their server environment with great success, but was actually > >>unable to seriously deploy 5.x because their goal was to support full > >>32-bit compatibility on 64-bit amd/intel hardware, which has > >>only recently > >>reached the level of maturity they require. In fact, you'll > >>notice if you > >>follow FreeBSD commit logs that much of that support has come > >>from Yahoo!. > >>Since 6.x is maturing in pretty good synch with their > >>deployment timeline > >>for 5.x, they are actually deploying 6.x. Of course, Yahoo! > >>has a team of > >>in-house OS developers who adapt FreeBSD for their needs, and > >>is quite > >>capable of debugging a kernel or two if they run into problems. > >> > >>The ATA driver issue is a sticky one for many users -- we > >>hope to get the > >>6.x ATA code back into 5.x in the next 5.x release. However, > >>hard-earned > >>experience tells us that ATA driver code is notoriously > >>difficult to get > >>right across the broad range of available hardware. Soren has been > >>lobbying to get it merged to 5.x, but given the level of > >>testing performed > >>so far, we can't yet justify the merge. My hope is that with > >>6.0 out the > >>door and a lot of testing of that code, we can get it merged > >>back to 5.x > >>before 5.5. Many other fixes have gone into 5.x, correcting > >>many of the > >>most significant issues. If you compare 5.4 with 5.3, you'll > >>find that in > >>most cases, it's both faster and more stable. > >> > >>The tty issue is a sticky one also. The tty code in 6.x has been > >>substantially rewritten to better support the SMPng > >>environment. Because > >>the tty code "plugs in" to a number of device drivers, T1 > >>adapter drivers, > >>etc, changing the tty interfaces is a fairly big event, and > >>will affect > >>third party vendors like Cronyx. This code has also not yet > >>seen as wide > >>deployment as I'd like, so it's also something that really isn't > >>appropriate for an MFC immediately. However, once it has > >>seen significant > >>6.0 deployment, it may well be. A question then will be whether it's > >>better to simply say "you're better off making the jump to > >>6.x, which is > >>minor" than backporting, and it's something we can't really > >>answer until > >>we're comfortable that it's seen sufficient deployment. My > >>hope is that > >>we can identify a workaround for 5.x that will avoid the code > >>upheaval a > >>full backport would require. It's not as ideal as having the > >>"right" fix, > >>but it would stop the panics. I need to ping phk and some of > >>the other > >>tty-centric folk to look at this some more. > >> > >>In terms of advice: > >> > >>If you have a "product" due out more than 3 months from now, > >>I think 6.x > >>is the obvious way to go: you want to be ahead of the curve > >>so that you > >>can have the foundation for your product in sync with the FreeBSD > >>production release cycle, and avoid jumping major releases > >>early in the > >>product life cycle. 6.x has significant performance and stability > >>improvements -- performance especially in the area of file system > >>performance on SMP, preemption, network stack, and memory > >>management, and > >>stability especially in the area of tty support. By > >>"product", I mean a > >>range of things: the OS foundation of an embedded product such as a > >>firewall or storage appliance, or deployment of an internal > >>product, such > >>as a virtual server product at an ISP. > >> > >>On the other hand, if you're deploying today, I think that > >>unless you're > >>prepared to deal with the 6.0 bug fix cycle (both the BETA/RC > >>cycle, and > >>the inevitable post-release fixes for a .0 release), 5.4+patches or > >>5-STABLE is the right place to sit. At least two of the > >>critical bugs on > >>your list were fixed in 5-STABLE after the release of 5.4, so > >>for some, > >>5-STABLE is the best place to be. We've opted not to do a > >>patch/errata > >>update for 5.4 for the socket error you were receiving on the > >>basis that > >>it doesn't affect a wide audience and doesn't correct a > >>"Critical" failure > >>-- i.e., a crash or the like, unlike some of the NFS server > >>fixes, for > >>which we did do an errata fix. > >> > >>From the perspective of the FreeBSD developers, if you can > >>tolerate the > >>6.x release process, we encourage you to jump on that > >>bandwagon. It will > >>help us release a better 6.0, and that's where the future > >>lies. Our goal > >>is to make 6.x a pretty seemless upgrade from 5.x, as it has a less > >>agressive feature set, and far fewer user-visible changes (i.e., no > >>conversion to OpenPAM, devfs,?UFS2, large compiler version > >>upgrade, ... as > >>in 5.x). When I upgraded my personal web/shell server to 6.x > >>from 5.x > >>last week, I didn't have to change any configuration in /etc > >>at all, other > >>than a painless pass through mergemaster to merge the _dhcp user and > >>group. As always, we look to the freebsd-stable users to > >>help us test new > >>features ahead of the release. > >> > >>Thanks, > >> > >>Robert N M Watson > >> > > > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 19:32:31 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 397F516A421 for ; Thu, 21 Jul 2005 19:32:31 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2522643D64 for ; Thu, 21 Jul 2005 19:32:20 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6LJWKND062281 for ; Thu, 21 Jul 2005 14:32:20 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu Jul 21 14:32:20 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6LJWKMJ062279 for freebsd-stable@freebsd.org; Thu, 21 Jul 2005 14:32:20 -0500 (CDT) (envelope-from karl) Date: Thu, 21 Jul 2005 14:32:20 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050721193220.GB61902@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <42DFF582.1050406@unixforge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42DFF582.1050406@unixforge.net> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 19:32:31 -0000 On Thu, Jul 21, 2005 at 12:20:34PM -0700, Eli K. Breen wrote: > All, > > Does anyone have a good handle on how to replicate (read: image) a > freebsd machine from one machine to an ostensibly similar machine? > > So far I've used countless variations and combinations of the following: > > dd (Slow, not usefull if the hardware isn't identical?) > tar (Doesn't replicate MBR) > rsync (No MBR support) > Norton Ghost (Doesn't support UFS/UFS2?) > G4U (little experience with this) > > Now whether my details are a bit off, that's fine, I don't want this to > be diluted in to discussion of minute frivolous details (as these things > are wont to do), but what I _am_ looking for is a tried, tested and true > method of FreeBSD machine replication, specifically for the 5.3+ releases. > > Many thanks, > > -E- Define "similar". If the disk is compatable (target disk equal or larger in size than the source), you can use "gmirror" to image a machine, quiesce the machine, force-detach the hardware (even hot-unplug it if supported) and boot the resulting disk (if you set up the gmirror system properly in the first place) Not the fastest method, but it works and copies EVERYTHING. There are other options but you need to be more specific as to what you mean by "similar". -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 19:34:34 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16F7116A41F for ; Thu, 21 Jul 2005 19:34:34 +0000 (GMT) (envelope-from gmulder@infotechfl.com) Received: from pigeon.infotechfl.com (mailrelay.infotechfl.com [209.251.147.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A09D43D6D for ; Thu, 21 Jul 2005 19:34:33 +0000 (GMT) (envelope-from gmulder@infotechfl.com) Received: from localhost (gmulder@localhost) by pigeon.infotechfl.com (8.11.6/8.11.6) with ESMTP id j6LJYOD22500; Thu, 21 Jul 2005 15:34:24 -0400 Date: Thu, 21 Jul 2005 15:34:23 -0400 (EDT) From: Gary Mulder To: "Eli K. Breen" In-Reply-To: <42DFF582.1050406@unixforge.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-stable@freebsd.org Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 19:34:34 -0000 On Thu, 21 Jul 2005, Eli K. Breen wrote: > All, > > Does anyone have a good handle on how to replicate (read: image) a > freebsd machine from one machine to an ostensibly similar machine? > > So far I've used countless variations and combinations of the following: > > dd (Slow, not usefull if the hardware isn't identical?) > tar (Doesn't replicate MBR) > rsync (No MBR support) > Norton Ghost (Doesn't support UFS/UFS2?) > G4U (little experience with this) > Try dump and restore. They seem to be fast and reliable (although not under Linux from all accounts). I usually use "tar" and "disklabel -B /dev/XXX" out of habit, but have found that tar doesn't honour the permissions on /tmp and /var/tmp. The sticky bit is set on these two dirs, but the permissions are not set to 777. This has me wondering what other (dir) perms are not correctly set. Gary From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 19:36:49 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F91316A41F for ; Thu, 21 Jul 2005 19:36:49 +0000 (GMT) (envelope-from asym@rfnj.org) Received: from mail.rfnj.org (ns1.rfnj.org [66.180.172.156]) by mx1.FreeBSD.org (Postfix) with ESMTP id BDFCC43D92 for ; Thu, 21 Jul 2005 19:36:24 +0000 (GMT) (envelope-from asym@rfnj.org) Received: by mail.rfnj.org (Postfix, from userid 65534) id 1045A214; Thu, 21 Jul 2005 15:36:12 -0400 (EDT) Received: from megalomaniac.rfnj.org (ool-45736df1.dyn.optonline.net [69.115.109.241]) by mail.rfnj.org (Postfix) with ESMTP id 7324B195; Thu, 21 Jul 2005 15:36:11 -0400 (EDT) Message-Id: <6.2.1.2.2.20050721153501.0390a668@mail.rfnj.org> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 21 Jul 2005 15:37:13 -0400 To: "Eli K. Breen" , freebsd-stable@freebsd.org From: asym In-Reply-To: <42DFF582.1050406@unixforge.net> References: <42DFF582.1050406@unixforge.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on rfnj.org X-Spam-Level: X-Spam-Status: No, score=0.0 required=20.0 tests=none autolearn=failed version=3.0.4 Cc: Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 19:36:49 -0000 At 15:20 7/21/2005, Eli K. Breen wrote: >All, > >Does anyone have a good handle on how to replicate (read: image) a freebsd >machine from one machine to an ostensibly similar machine? > >So far I've used countless variations and combinations of the following: > >dd (Slow, not usefull if the hardware isn't identical?) >tar (Doesn't replicate MBR) >rsync (No MBR support) >Norton Ghost (Doesn't support UFS/UFS2?) >G4U (little experience with this) I've found a combination of dd + tar works great, as documented. Stick the new drive in the box to be duplicated, use dd on the first (forget how many) sectors to copy the mbr and partition tables over, then use a tar pipe to copy from one drive to the other, preserving all perms and so forth. Barring that, commercial single-disk duplicators aren't THAT expensive. Hell you could just use a cheap raid card to raid-1 mirror the drive, then yank it out and toss it in another box, which I've done on occasion when pressed. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 19:47:58 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB42C16A42B for ; Thu, 21 Jul 2005 19:47:58 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D03A43D69 for ; Thu, 21 Jul 2005 19:47:56 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice3.sentex.ca (pumice3.sentex.ca [64.7.153.26]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6LJlNdD063886 for ; Thu, 21 Jul 2005 15:47:25 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice3.sentex.ca (8.13.3/8.13.3) with ESMTP id j6LJlqlu082300; Thu, 21 Jul 2005 15:47:52 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j6LJlo50030463 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 15:47:51 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050721154151.0855ae38@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 21 Jul 2005 15:49:31 -0400 To: "Eli K. Breen" , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <42DFF582.1050406@unixforge.net> References: <42DFF582.1050406@unixforge.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.26 Cc: Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 19:47:59 -0000 At 03:20 PM 21/07/2005, Eli K. Breen wrote: >All, > >Does anyone have a good handle on how to replicate (read: image) a freebsd >machine from one machine to an ostensibly similar machine? > >So far I've used countless variations and combinations of the following: > >dd (Slow, not usefull if the hardware isn't identical?) >tar (Doesn't replicate MBR) >rsync (No MBR support) >Norton Ghost (Doesn't support UFS/UFS2?) >G4U (little experience with this) g4u is a REALLY nice front end to dd basically, but works very well and is reasonably fast. If you want fast, dump | restore as it will only copy data and ignore empty blocks. You then just need to install the MBR which is easy to do via sysinstall if you are not comfortable disklabel e.g. cd /;dump -C 20 -0f - / | (cd /mnt/root-disk; restore -rf - ) cd /;dump -C 20 -0f - /usr | (cd /mnt/usr-disk; restore -rf - ) and so on. ---Mike From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 19:49:49 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A0D6516A41F for ; Thu, 21 Jul 2005 19:49:49 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9657443D72 for ; Thu, 21 Jul 2005 19:49:39 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice6.sentex.ca (pumice6.sentex.ca [64.7.153.21]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j6LJn8jT064027 for ; Thu, 21 Jul 2005 15:49:08 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice6.sentex.ca (8.13.3/8.13.3) with ESMTP id j6LJnYm9060543; Thu, 21 Jul 2005 15:49:34 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j6LJnXaP030478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 15:49:33 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 21 Jul 2005 15:51:13 -0400 To: Karl Denninger , freebsd-stable@freebsd.org From: Mike Tancsa In-Reply-To: <20050721192613.GA61902@FS.denninger.net> References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.21 Cc: Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 19:49:49 -0000 At 03:26 PM 21/07/2005, Karl Denninger wrote: >Ok, Robert, but then here's the question.... > >How come the ATA code which was very stable in 4.x was screwed with in a >production release, breaking it, with no path backwards to the working >code? I understand your frustration, but others would argue if the changes were not made that would say (and have) "How come modern and common hardware like XXXX do not work with FreeBSD. The driver is old and unmaintained and does not support feature YYYYY." I dont see Soren's work as "screwing with production drivers" as opposed to him re-writing them to take advantage of modern hardware designs. Unfortunately along the way some things might break. They have for me, but that sometimes happens in open source (and commercial code too for that matter). ---Mike From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 20:04:20 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16BE016A44A for ; Thu, 21 Jul 2005 20:04:20 +0000 (GMT) (envelope-from mack@macktronics.com) Received: from coco.macktronics.com (coco.macktronics.com [209.181.253.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5EE2743D80 for ; Thu, 21 Jul 2005 20:04:15 +0000 (GMT) (envelope-from mack@macktronics.com) Received-SPF: none (coco.macktronics.com: 209.181.253.65 is neither permitted nor denied by domain of macktronics.com) client-ip=209.181.253.65; envelope-from=mack@macktronics.com; helo=coco.macktronics.com; Received: from coco.macktronics.com (coco.macktronics.com [209.181.253.65]) by coco.macktronics.com (Postfix) with ESMTP id 3A6AE4AC11; Thu, 21 Jul 2005 15:04:01 -0500 (CDT) Date: Thu, 21 Jul 2005 15:04:01 -0500 (CDT) From: Dan Mack To: "Eli K. Breen" In-Reply-To: <42DFF582.1050406@unixforge.net> Message-ID: <20050721150151.R7966@coco.macktronics.com> References: <42DFF582.1050406@unixforge.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 20:04:20 -0000 On Thu, 21 Jul 2005, Eli K. Breen wrote: > All, > > Does anyone have a good handle on how to replicate (read: image) a freebsd > machine from one machine to an ostensibly similar machine? > > So far I've used countless variations and combinations of the following: > > dd (Slow, not usefull if the hardware isn't identical?) > tar (Doesn't replicate MBR) > rsync (No MBR support) > Norton Ghost (Doesn't support UFS/UFS2?) > G4U (little experience with this) Is there a jumpstart (solaris), kickstart (redhat linux), roboinst (irix), or ignite (hpux) like auto-installer for BSD? If there was, then I wouldn't image the disk at all, I'd instead setup up custom network images that I could blast to any system just by pxebooting it. I'm not sure if it is possible with FreeBSD though, anyone? Dan From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 20:07:13 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8230F16A44B for ; Thu, 21 Jul 2005 20:07:13 +0000 (GMT) (envelope-from mkb@incubus.de) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6B18E43E11 for ; Thu, 21 Jul 2005 20:06:18 +0000 (GMT) (envelope-from mkb@incubus.de) Received: from drjekyll.mkbuelow.net (p54AAB49A.dip0.t-ipconnect.de [84.170.180.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 59680300CB; Thu, 21 Jul 2005 22:08:54 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j6LK68RO037136; Thu, 21 Jul 2005 22:06:09 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Message-Id: <200507212006.j6LK68RO037136@drjekyll.mkbuelow.net> From: Matthias Buelow To: pcasidy@casidy.com In-Reply-To: Message from pcasidy@casidy.com of "Thu, 21 Jul 2005 20:44:35 -0000." <20050721184455.5CEA8B86C@smtp.casidy.net> X-Mailer: MH-E 7.84; nmh 1.0.4; XEmacs 21.4 (patch 17) Date: Thu, 21 Jul 2005 22:06:08 +0200 Sender: mkb@incubus.de Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 20:07:14 -0000 pcasidy@casidy.com writes: >My main problem, and to others after seeing the question from times to >times, is to know which is a good (not necessarly the best) hardware to >run FreeBSD on? >When I buy a new motherboard, which chipset to choose/avoid, which controllers >? Maybe some website like it is being done for notebooks (with Linux/FreeBSD support) would be in order. I'm thinking about something like http://www.linux-laptop.net/, only for FreeBSD and all kinds of machines, not just notebooks. (Or, if some collaboration would be ok, for *BSD in general, with people posting experience from NetBSD, OpenBSD, Dragonfly, even Darwin aswell. That way one could also compare support for hardware and see what problems the individual systems have.) Make it a Wiki, or something similar, where people can freely post experiences they have with their hardware. That could be whole machines (Dell model xxx desktop, IBM yyy laptop, HP zzz server) aswell as components (Asus blah motherboard, 3Com wlan card model foobar, etc.) and make the thing searchable, and perhaps allow one to post comments on entries (easy with a Wiki). That way people can quickly search & review hardware, awell as test suggested workarounds by the posters, without having to google for obscured mailing list entries, or problem reports. mkb. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 20:13:43 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D21216A41F for ; Thu, 21 Jul 2005 20:13:43 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.49.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id F292D43D98 for ; Thu, 21 Jul 2005 20:12:58 +0000 (GMT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (pool-151-199-7-31.ROA.east.verizon.net [151.199.7.31]) by gromit.dlib.vt.edu (8.13.3/8.13.3) with ESMTP id j6LKCr8Q036478 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jul 2005 16:12:54 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: from zappa.Chelsea-Ct.Org (localhost.Chelsea-Ct.Org [127.0.0.1]) by zappa.Chelsea-Ct.Org (8.13.4/8.13.4) with ESMTP id j6LKCmdt008452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Jul 2005 16:12:48 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) Received: (from paul@localhost) by zappa.Chelsea-Ct.Org (8.13.4/8.13.4/Submit) id j6LKCmqh008451; Thu, 21 Jul 2005 16:12:48 -0400 (EDT) (envelope-from paul@gromit.dlib.vt.edu) From: Paul Mather To: Karl Denninger In-Reply-To: <20050721192613.GA61902@FS.denninger.net> References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 21 Jul 2005 16:12:47 -0400 Message-Id: <1121976767.7274.60.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 20:13:43 -0000 On Thu, 2005-07-21 at 14:26 -0500, Karl Denninger wrote: > Ok, Robert, but then here's the question.... > > How come the ATA code which was very stable in 4.x was screwed with in a > production release, breaking it, with no path backwards to the working > code? Not to mention that this happened during the 5.x release cycle. It's one thing to have a regression creep in when moving from one major release to another (e.g., "oh, that's the fallout from introducing Big Feature XYZ" or "a big architectural revamp may have broken some things"), but it's another thing entirely to have it happen between minor releases, which are supposed to be "evolution, not revolution." (Although the whole "Early Adopter" status for early 5.x releases might mean all that is muddied when it comes to the 5.x series.) My main disappointment with the ATA DMA TIMEOUT bug is not that it crept in (these things happen), but that it did not seem to be taken seriously when it had done so. (Though, as Robert said, if the developers can't reproduce the problem, it's hard for them to work on and fix it.) Cheers, Paul. -- e-mail: paul@gromit.dlib.vt.edu "Without music to decorate it, time is just a bunch of boring production deadlines or dates by which bills must be paid." --- Frank Vincent Zappa From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 20:15:42 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5A4C516A42A for ; Thu, 21 Jul 2005 20:15:42 +0000 (GMT) (envelope-from bsd@unixforge.net) Received: from mail.sectornotfound.com (mail.sectornotfound.com [209.139.233.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id E85FF43D98 for ; Thu, 21 Jul 2005 20:15:05 +0000 (GMT) (envelope-from bsd@unixforge.net) Received: from hannibal.int.sectornotfound.com (hannibal.int.sectornotfound.com [192.168.98.3]) by murdock.sectornotfound.com (8.13.1/8.13.1) with ESMTP id j6LKF3Zj022661; Thu, 21 Jul 2005 13:15:04 -0700 (PDT) (envelope-from bsd@unixforge.net) Received: from [192.168.3.212] (gw.activestate.com [209.17.183.249]) (authenticated bits=0) by hannibal.int.sectornotfound.com (8.13.1/8.12.10) with ESMTP id j6LKF3hH070420; Thu, 21 Jul 2005 13:15:03 -0700 (PDT) (envelope-from bsd@unixforge.net) Message-ID: <42E0029A.4090204@unixforge.net> Date: Thu, 21 Jul 2005 13:16:26 -0700 From: "Eli K. Breen" User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dan Mack References: <42DFF582.1050406@unixforge.net> <20050721150151.R7966@coco.macktronics.com> In-Reply-To: <20050721150151.R7966@coco.macktronics.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 20:15:42 -0000 Just as a point of note, I'm not trying to roll out squeeky-clean new machines. Let's say I've got ten-fifteen sets of clusters, I need to be able to just rip a copy and blast it to another machine. Thanks for all the responses so far. -E- Dan Mack wrote: > On Thu, 21 Jul 2005, Eli K. Breen wrote: > >> All, >> >> Does anyone have a good handle on how to replicate (read: image) a >> freebsd machine from one machine to an ostensibly similar machine? >> >> So far I've used countless variations and combinations of the following: >> >> dd (Slow, not usefull if the hardware isn't identical?) >> tar (Doesn't replicate MBR) >> rsync (No MBR support) >> Norton Ghost (Doesn't support UFS/UFS2?) >> G4U (little experience with this) > > > > > Is there a jumpstart (solaris), kickstart (redhat linux), roboinst (irix), > or ignite (hpux) like auto-installer for BSD? > > If there was, then I wouldn't image the disk at all, I'd instead setup > up custom network images that I could blast to any system just by > pxebooting it. I'm not sure if it is possible with FreeBSD though, anyone? > > Dan From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 20:22:37 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C40E16A420 for ; Thu, 21 Jul 2005 20:22:37 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5AA643D49 for ; Thu, 21 Jul 2005 20:22:35 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6LKMYQ0062954 for ; Thu, 21 Jul 2005 15:22:35 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu Jul 21 15:22:34 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6LKMYAB062952 for freebsd-stable@freebsd.org; Thu, 21 Jul 2005 15:22:34 -0500 (CDT) (envelope-from karl) Date: Thu, 21 Jul 2005 15:22:34 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050721202234.GA62615@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 20:22:37 -0000 On Thu, Jul 21, 2005 at 03:51:13PM -0400, Mike Tancsa wrote: > At 03:26 PM 21/07/2005, Karl Denninger wrote: > >Ok, Robert, but then here's the question.... > > > >How come the ATA code which was very stable in 4.x was screwed with in a > >production release, breaking it, with no path backwards to the working > >code? > > I understand your frustration, but others would argue if the changes were > not made that would say (and have) "How come modern and common hardware > like XXXX do not work with FreeBSD. The driver is old and unmaintained > and does not support feature YYYYY." I dont see Soren's work as > "screwing with production drivers" as opposed to him re-writing them to > take advantage of modern hardware designs. Unfortunately along the way > some things might break. They have for me, but that sometimes happens in > open source (and commercial code too for that matter). > > ---Mike ATA-NG (Soren's new code) is not (from what I understand) in the 5.x codebase. One bone of contention is that apparently it IS in -HEAD, but there are no plans to MFC it to 5.x. My understanding is that the 5.x code is a half-baked version of ATA-NG, and IMHO it had no business going into a PRODUCTION release in the state that it was pushed over. The decision path on including half a loaf in this case is not something I was privvy to - but I've certainly been "privvy" to the results! I fought with unsolicited detachments of drives claimed to be "defective" (when they were and are not) and several crashes when the only remaining "good" device on the mirror was also declared "bad" - some of which came with filesystem data corruption - for over a month before I came up with a configuration that gives me both RAID 1 data protection and REASONABLE stability (meaning I have uptimes which are not controlled by unsolicited crashes!) I am however VERY leery of following -STABLE, since there are reports here on the list that more recent versions than what I'm running may have regressed once again. I DEFINITELY do not want to go through what I did back in the first part of the year again. Given that we were all "strongly" encouraged to upgrade to 5.x for production machines a few months ago it was a truly ugly surprise to find that current production hardware which ran just fine on 4.x was hosed to the point of unusability with 5.x as a consequence of serious (some would say CRITICAL) driver issues. Whether the full ATA-NG code actually fixes the problem is (to me anyway) unknown - but I am not about to devote a bunch of testing time to it when its in a codebase that I can't run AND it has been stated that there is no intent to MFC it. Now if there was a commitment to MFC the code I would be happy to engage in testing against -HEAD, and see if I can provoke the same sort of misbehavior I get on 5.x. Without that commitment, however, testing it is fruitless for me, since I have no path out of the box I'm in other than "sit on hands and wait an indeterminate amount of time", and this testing involves a significant time commitment - I not only have to replicate the 5.x production machines I've got in the field that have had trouble (not too hard), I also have to generate a synthetic load sufficient to know if the problem is truly resolved or not (that will take some effort.) I've come up with a workaround that is "functional" for my production systems, but that workaround came only with a huge time investment and IMHO this is a stability defecit that simply should not have happened. In the time I've run FreeBSD (going back a LONG ways, including using it as the OS of choice behind a major regional ISP in the mid-late 90s) this is the worst instance of regression in terms of stability across purported "RELEASE" versions I've seen - for it to be "poo-pooed" and outstanding PRs effectively ignored for six months is IMHO quite a black eye event. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 20:25:14 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F52216A421 for ; Thu, 21 Jul 2005 20:25:14 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8F5643D79 for ; Thu, 21 Jul 2005 20:25:09 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6LKP9Bg062998 for ; Thu, 21 Jul 2005 15:25:09 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu Jul 21 15:25:09 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6LKP82h062996 for freebsd-stable@freebsd.org; Thu, 21 Jul 2005 15:25:08 -0500 (CDT) (envelope-from karl) Date: Thu, 21 Jul 2005 15:25:08 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050721202508.GB62615@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <42DFF582.1050406@unixforge.net> <20050721150151.R7966@coco.macktronics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050721150151.R7966@coco.macktronics.com> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 20:25:14 -0000 I had a shell script that would replicate a machine when I ran my ISP; you put the loader and partition table, plus a minimal system on the new machine, then ran the script and pointed it at the "source". SSSSLLLLUUURRRRPPP! In about 20 minutes it was done. Not hard to do at all with a simple shell script..... Used this all the time to "push" new OS versions out to the cluster (a couple of dozen machines) when I was done testing them.... as well as adding new machines to the existing cluster as demand warranted. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind On Thu, Jul 21, 2005 at 03:04:01PM -0500, Dan Mack wrote: > On Thu, 21 Jul 2005, Eli K. Breen wrote: > > >All, > > > >Does anyone have a good handle on how to replicate (read: image) a > >freebsd machine from one machine to an ostensibly similar machine? > > > >So far I've used countless variations and combinations of the following: > > > >dd (Slow, not usefull if the hardware isn't identical?) > >tar (Doesn't replicate MBR) > >rsync (No MBR support) > >Norton Ghost (Doesn't support UFS/UFS2?) > >G4U (little experience with this) > > > > Is there a jumpstart (solaris), kickstart (redhat linux), roboinst (irix), > or ignite (hpux) like auto-installer for BSD? > > If there was, then I wouldn't image the disk at all, I'd instead setup up > custom network images that I could blast to any system just by pxebooting > it. I'm not sure if it is possible with FreeBSD though, anyone? > > Dan > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 20:31:17 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D78D416A41F for ; Thu, 21 Jul 2005 20:31:17 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3498A43D48 for ; Thu, 21 Jul 2005 20:31:16 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6LKVGV5063058 for ; Thu, 21 Jul 2005 15:31:16 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu Jul 21 15:31:16 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6LKVGr7063056 for freebsd-stable@freebsd.org; Thu, 21 Jul 2005 15:31:16 -0500 (CDT) (envelope-from karl) Date: Thu, 21 Jul 2005 15:31:16 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050721203116.GC62615@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> <1121976767.7274.60.camel@zappa.Chelsea-Ct.Org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1121976767.7274.60.camel@zappa.Chelsea-Ct.Org> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 20:31:18 -0000 On Thu, Jul 21, 2005 at 04:12:47PM -0400, Paul Mather wrote: > On Thu, 2005-07-21 at 14:26 -0500, Karl Denninger wrote: > > > Ok, Robert, but then here's the question.... > > > > How come the ATA code which was very stable in 4.x was screwed with in a > > production release, breaking it, with no path backwards to the working > > code? > > Not to mention that this happened during the 5.x release cycle. It's > one thing to have a regression creep in when moving from one major > release to another (e.g., "oh, that's the fallout from introducing Big > Feature XYZ" or "a big architectural revamp may have broken some > things"), but it's another thing entirely to have it happen between > minor releases, which are supposed to be "evolution, not revolution." > > (Although the whole "Early Adopter" status for early 5.x releases might > mean all that is muddied when it comes to the 5.x series.) > > My main disappointment with the ATA DMA TIMEOUT bug is not that it crept > in (these things happen), but that it did not seem to be taken seriously > when it had done so. (Though, as Robert said, if the developers can't > reproduce the problem, it's hard for them to work on and fix it.) > > Cheers, > > Paul. > -- > e-mail: paul@gromit.dlib.vt.edu My main disappointment is that it STILL isn't being taken seriously, six months down the road. My PR, for instance, is still open - as well it should be, as the DMA_TIMEOUT bug still exists. Fixing the retry code so that the transaction is actually retried up to three times (instead of causing the disk to be declared broken on the first instance) . The problem is very easy to reproduce; I have put forward the exact configuration necessary to do so in the original PR. I have since discovered (and others have reported) that it is not particularly sensitive to the exact hardware involved - basically any SII chipset PCI SATA adapter (which is like all of the "basic" ones, including the Adaptec and Bustek) with a pair of SATA disks appears to be all that is required. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 20:37:28 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D36316A41F for ; Thu, 21 Jul 2005 20:37:28 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC2CF43D46 for ; Thu, 21 Jul 2005 20:37:27 +0000 (GMT) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j6LKbQ4R029891; Thu, 21 Jul 2005 16:37:26 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200507210850530519.03A3275D@sentry.24cl.com> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> <200507212029.47615.doconnor@gsoft.com.au> <200507210850530519.03A3275D@sentry.24cl.com> Date: Thu, 21 Jul 2005 16:37:25 -0400 To: "MikeM" , freebsd-stable@freebsd.org From: Garance A Drosihn Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 Cc: Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 20:37:28 -0000 At 8:50 AM -0400 7/21/05, MikeM wrote: >On 7/21/2005 at 8:29 PM Daniel O'Connor wrote: >| >| I think the best way to rectify this is to test RC candidates >| on YOUR hardware.. This finds the bugs you need fixed at a >| time when people are very receptive to fixing them. >| >| It's not realistic for the release engineer to test on a lot >| of hardware as they are very busy doing other things. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >Your comment presupposes that most of the bugs are specific to >one piece of hardware, I doubt that is a valid assertion. I >would offer that most of the bugs are not present in source code >specific to a certain piece of hardware, ... Some problems are not tied to one specific piece of hardware, but to the combination of different hardware. I also went through a lot of pain with ATA problems for awhile there, and I was fed up enough that I tried to buy my way out of the problem. I ended up with three different SATA controllers, and two different SATA hard disks. The thing was, the problems I saw depended on the *combination* of a hard disk and SATA controller. My real-SATA hard drive would fail (in some ways) when connected to one SATA controller, but not to the other. And my fake-SATA drive would *work* on the controller which the real-sata drive failed on, but fail on the controller the real-sata drive worked on! There is no question that this was infuriating for me, so I can sympathize with your frustration. But I helped S=F8ren get some hardware he needed for testing, and things gradually improved. But the problems weren't specific to the hard drive I was using, or the SATA controller I was using. They depended on the combination of pieces that were in my PC. >Once a bug is reported, and that bug can be reproduced on the >hardware of the development team, then that bug should not >reappear again, In my case, "the development team" needed to *buy* hardware to reproduce some of the problems I was seeing. But their hardware still isn't *exactly* the same as mine. So, they made some fixes which solved problems on their hardware and (happily) on mine. But it is certainly possible for some future change to work perfectly fine on their hardware, and *not* work on mine. There is still no substitute for testing on your hardware, with some sort of real-world loads. The project, as such, simply can not test all combinations of hardware, on all kinds of real-world loads. Even if we had a huge collection of PC's to test on, we're not necessarily going to throw the same kinds of loads on those machines as you deal with. I should note that *all* of my SATA-based hardware is stuff that was not supported at all under 4.x. So it's awkward for me to complain too loudly, because I *do* want SATA, and the only way for FreeBSD to support these new controllers was to make changes to some previously-working code. -- Garance Alistair Drosehn =3D gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 21:08:27 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 16C0516A424 for ; Thu, 21 Jul 2005 21:08:27 +0000 (GMT) (envelope-from JANDRESE@mitre.org) Received: from smtp-bedford.mitre.org (smtp-bedford-x.mitre.org [192.160.51.76]) by mx1.FreeBSD.org (Postfix) with ESMTP id 329EB43D46 for ; Thu, 21 Jul 2005 21:08:25 +0000 (GMT) (envelope-from JANDRESE@mitre.org) Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with SMTP id j6LL8Nl08955 for ; Thu, 21 Jul 2005 17:08:23 -0400 Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (Postfix) with ESMTP id 2C22DBF00 for ; Thu, 21 Jul 2005 17:08:23 -0400 (EDT) Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.11.6/8.11.6) with ESMTP id j6LL8Ms08912; Thu, 21 Jul 2005 17:08:22 -0400 Received: from IMCSRV2.MITRE.ORG ([129.83.20.164]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.211); Thu, 21 Jul 2005 17:08:22 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Jul 2005 17:08:06 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Machine Replication Thread-Index: AcWOKglnO0VTEYYaQMuHULpmFUt/hgADd34g From: "Andresen,Jason R." To: "Eli K. Breen" X-OriginalArrivalTime: 21 Jul 2005 21:08:22.0418 (UTC) FILETIME=[53BDAF20:01C58E38] Cc: freebsd-stable@freebsd.org Subject: RE: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 21:08:27 -0000 >From: owner-freebsd-stable@freebsd.org=20 >[mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Eli K. Breen >Sent: Thursday, July 21, 2005 3:21 PM >To: freebsd-stable@freebsd.org >Subject: Machine Replication > >All, > >Does anyone have a good handle on how to replicate (read: image) a=20 >freebsd machine from one machine to an ostensibly similar machine? > >So far I've used countless variations and combinations of the=20 >following: > >dd (Slow, not usefull if the hardware isn't identical?) >tar (Doesn't replicate MBR) >rsync (No MBR support) >Norton Ghost (Doesn't support UFS/UFS2?) >G4U (little experience with this) If you need stuff replicated fast and you don't mind a bit of setup, there is emulab http://www.emulab.net/. I can push out new images to machines in less than 10 minutes including the time it takes to reboot twice (once into the imager and once back to the OS). =20 You may need to use UFS1 for your filesystems though, I don't know if the imager can handle UFS2 yet. We use UFS1 here just to be safe. =20 From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 21:13:13 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4EC116A444 for ; Thu, 21 Jul 2005 21:13:13 +0000 (GMT) (envelope-from ftigeot@wolfpond.org) Received: from ares.wolfpond.org (ns1.wolfpond.org [62.212.96.219]) by mx1.FreeBSD.org (Postfix) with ESMTP id 76B2743D8F for ; Thu, 21 Jul 2005 21:13:04 +0000 (GMT) (envelope-from ftigeot@wolfpond.org) Received: from aoi.wolfpond.org (aoi.wolfpond.org [IPv6:2001:7a8:24db:1:20c:76ff:feb4:27e1]) by ares.wolfpond.org (8.13.3/8.13.3) with ESMTP id j6LLD1a5095118; Thu, 21 Jul 2005 23:13:01 +0200 (CEST) (envelope-from ftigeot@aoi.wolfpond.org) Received: from aoi.wolfpond.org (localhost [127.0.0.1]) by aoi.wolfpond.org (8.13.3/8.13.1) with ESMTP id j6LLD5Js013012; Thu, 21 Jul 2005 23:13:05 +0200 (CEST) (envelope-from ftigeot@aoi.wolfpond.org) Received: (from ftigeot@localhost) by aoi.wolfpond.org (8.13.3/8.13.1/Submit) id j6LLD5tO013011; Thu, 21 Jul 2005 23:13:05 +0200 (CEST) (envelope-from ftigeot) Date: Thu, 21 Jul 2005 23:13:05 +0200 From: Francois Tigeot To: "Eli K. Breen" Message-ID: <20050721211305.GC10821@aoi.wolfpond.org> References: <42DFF582.1050406@unixforge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42DFF582.1050406@unixforge.net> User-Agent: Mutt/1.4.2.1i X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (ares.wolfpond.org [IPv6:2001:7a8:24db:1:204:76ff:fef2:b46f]); Thu, 21 Jul 2005 23:13:01 +0200 (CEST) Cc: freebsd-stable@freebsd.org Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 21:13:14 -0000 On Thu, Jul 21, 2005 at 12:20:34PM -0700, Eli K. Breen wrote: > > Does anyone have a good handle on how to replicate (read: image) a > freebsd machine from one machine to an ostensibly similar machine? [...] > Now whether my details are a bit off, that's fine, I don't want this to > be diluted in to discussion of minute frivolous details (as these things > are wont to do), but what I _am_ looking for is a tried, tested and true > method of FreeBSD machine replication, specifically for the 5.3+ releases. I have found the following paper to be incredibly usefull : http://www.pix.net/software/pxeboot/archive/SANE.pdf I used some of the ideas in it to clone machines in the 5.1-5.2 era. -- Francois Tigeot, CEO, Zefyris http://www.zefyris.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 21:15:32 2005 Return-Path: X-Original-To: freebsd-stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4F28916A41F; Thu, 21 Jul 2005 21:15:32 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4613A43D9C; Thu, 21 Jul 2005 21:15:13 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 81395999; Thu, 21 Jul 2005 16:14:52 -0500 (CDT) Date: Thu, 21 Jul 2005 16:14:52 -0500 To: Robert Watson Message-ID: <20050721211452.GA2412@soaustin.net> References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050721194500.W9208@fledge.watson.org> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) Cc: 'Marc Olzheim' , Alexey Yakimovich , freebsd-stable@FreeBSD.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 21:15:32 -0000 On Thu, Jul 21, 2005 at 08:00:40PM +0100, Robert Watson wrote: > [original poster wrote:] > >- I completely agree with MikeM - any kind of complex software could be > >tested with right prepared test cases, specially if they are going to be > >reused in the next release; For static problems -- yes. For dynamic problems, such as race conditions, the problem space you are trying to test is many orders of magnitude more complex. This is true of any engineering discipline, but much more so with software engineering due to the immense complexity of the constructed artifacts. > [rwatson again:] > As has been discussed extensively in this thread and other threads, the > FreeBSD development model typically addresses change at the tree HEAD, > where the changes are tested and evaluated, and then they are back-ported. > Some changes are low-risk, and are backported quickly (minor locking > fixes, error handling, etc). Others are higher risk, and are backported > only when they are felt to have received sufficient testing (driver > re-writes, structural changes). Other changes are considered too large > to ever be backported [ ... ] To add to Robert's comments, there was at least one case during the 5.2 cycle where a large backport was made that destabilized the tree for quite some time. This was not due to any lack of diligence on the developer's part; it turned out that the problems were far more subtle and complex than anyone could have reasonably anticipated. Since that time, AFAICT the sentiment has shifted away from large backports. There is always risk in any backport and the risks escalate dramatically the less compartmentalized the changes are. One of the goals for 6.X and beyond is to try to keep changes more compartmentalized; there was simply no way to do such a thing with e.g. SMP and VM changes. At the same time, the sentiment seems to be "let's debug one set of featureset changes all together and then release them as a major release". Of course, backports also require developer time both to do the initial commit and then, more onerously, the followup support. To conclude this thought, the motivation for changing the way FreeBSD is going to do releases going forwards is to try to mitigate such problems: to try to debug, and release, a smaller set of features with new major releases, and more frequently, and with a better-known schedule (every 18 months). > Notice that we'll be supporting the 4.x branch for several years to come. The limiting factor on the 4.X branch is going to be the ports tree more quickly than the base system, particularly for people running desktop installations. The FreeBSD GNOME team has already announced that they are not going to support 4.X by default in the next major GNOME release due this fall. The next major KDE release will probably not work on the 4.X gcc compiler as well IIUC. There are simply an insufficient amount of developer resources to support releases that have different toolchains, include files, and so on. Staying on 4.X indefinitely is not going to be an option at some point in the future, but when, exactly, is difficult to tell right now. It is fair to note, however, that almost no developer attention is being spent on 4.X except for security problems as they are found. Further, the more people we have stay on 4.X, the less people we have testing whichever release we consider the latest "stable" release, and therefore, the less bugs we'll get fixed on that release. One last thought. It always bears repeating that, except for a handful of cases, people who work on FreeBSD are not being paid to do so. Users should always adjust their expectations accordingly. We do our absolute best given the relatively small number of developers that we do have, but we always need more people who are willing to work on regression testing and QA activities. For the companies which view FreeBSD as 'mission-critical' (and we do welcome them!), I challenge them to consider funding development/testing efforts going forwards. (Yes, a number already do, but more would be welcome.) mcl From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 21:23:12 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3FDD16A420; Thu, 21 Jul 2005 21:23:12 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0BE243D76; Thu, 21 Jul 2005 21:22:58 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id D0F2A997952; Thu, 21 Jul 2005 23:22:56 +0200 (CEST) Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 44783-03-2; Thu, 21 Jul 2005 23:22:53 +0200 (CEST) Received: from [80.98.156.20] (catv-50629c14.catv.broadband.hu [80.98.156.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.t-hosting.hu (Postfix) with ESMTP id 648C0997947; Thu, 21 Jul 2005 23:22:53 +0200 (CEST) Message-ID: <42E01226.1020707@t-hosting.hu> Date: Thu, 21 Jul 2005 14:22:46 -0700 From: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at t-hosting.hu Cc: Subject: What to do when panic? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 21:23:13 -0000 Hello, I've never debugged FreeBSD, but now I've decided to help the testing process of FreeBSD 6. I installed it, and then I had a panic. I got a debugger prompt, but I don't know what to do with that. I don't know the debugger commands. Please let me know what should I do when I have an another panic. What should I type and what kind of information should I send as a PR. Thanks, Gábor Kövesdán From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 21:28:33 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CDD4616A41F for ; Thu, 21 Jul 2005 21:28:33 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from server.t-hosting.hu (server.t-hosting.hu [217.20.133.7]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4367243D48 for ; Thu, 21 Jul 2005 21:28:19 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from localhost (localhost [127.0.0.1]) by server.t-hosting.hu (Postfix) with ESMTP id 02DCF997947 for ; Thu, 21 Jul 2005 23:28:19 +0200 (CEST) Received: from server.t-hosting.hu ([127.0.0.1]) by localhost (server.t-hosting.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 45036-02 for ; Thu, 21 Jul 2005 23:28:15 +0200 (CEST) Received: from [80.98.156.20] (catv-50629c14.catv.broadband.hu [80.98.156.20]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by server.t-hosting.hu (Postfix) with ESMTP id 925F0997939 for ; Thu, 21 Jul 2005 23:28:15 +0200 (CEST) Message-ID: <42E0136F.2010400@t-hosting.hu> Date: Thu, 21 Jul 2005 14:28:15 -0700 From: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at t-hosting.hu Subject: Silent crash on FreeBSD 6.0-BETA1 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 21:28:34 -0000 Hi, I've installed FreeBSD 6.0-BETA1 and if I use more consoles I have a silent crash. The cursor won't move and I can't change back to another console. It has happened three times so far when I was using two consoles. (I was using make + ee in the first two cases and in the third case cvsup + less.) How can I find out what's wrong? I suspect it is some kind of hardware support issue since I have a fairly new PC. Cheers, Gábor Kövesdán From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 22:02:42 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4110516A41F for ; Thu, 21 Jul 2005 22:02:42 +0000 (GMT) (envelope-from bsd@unixforge.net) Received: from mail.sectornotfound.com (mail.sectornotfound.com [209.139.233.100]) by mx1.FreeBSD.org (Postfix) with ESMTP id E86FA43D45 for ; Thu, 21 Jul 2005 22:02:41 +0000 (GMT) (envelope-from bsd@unixforge.net) Received: from hannibal.int.sectornotfound.com (hannibal.int.sectornotfound.com [192.168.98.3]) by murdock.sectornotfound.com (8.13.1/8.13.1) with ESMTP id j6LM28lp029809; Thu, 21 Jul 2005 15:02:09 -0700 (PDT) (envelope-from bsd@unixforge.net) Received: from [192.168.3.212] (gw.activestate.com [209.17.183.249]) (authenticated bits=0) by hannibal.int.sectornotfound.com (8.13.1/8.12.10) with ESMTP id j6LM28hb070885; Thu, 21 Jul 2005 15:02:08 -0700 (PDT) (envelope-from bsd@unixforge.net) Message-ID: <42E01BB3.1040801@unixforge.net> Date: Thu, 21 Jul 2005 15:03:31 -0700 From: "Eli K. Breen" User-Agent: Mozilla Thunderbird 1.0 (X11/20050101) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Elliot Finley References: <42DFF582.1050406@unixforge.net> <20050721211305.GC10821@aoi.wolfpond.org> <010f01c58e3e$28458b50$37cba1cd@emerytelcom.com> In-Reply-To: <010f01c58e3e$28458b50$37cba1cd@emerytelcom.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Francois Tigeot , freebsd-stable@freebsd.org Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 22:02:42 -0000 I should point out, this is for replication in a running production environment. Machines cannot be taken down, and swapping hardware is not an option. I'm currently experimenting with a copy of the MBR, and the root partition on a CD, with enough tools to attach to the network to retrieve images of the rest of the partitions (which can be taken as current snapshots from various servers). This _should_ result in the following scenario: Boot new machine with CD partition drive(s) dump MBR dump root ssh foo@server 'dump -C 64 -0af - /sliceX'| (cd /usr; restore -rf -) [repeat above for all drives, could be automated] Seem reasonable? -E- Elliot Finley wrote: > ----- Original Message ----- > From: "Francois Tigeot" > >>On Thu, Jul 21, 2005 at 12:20:34PM -0700, Eli K. Breen wrote: >> >>>Does anyone have a good handle on how to replicate (read: image) a >>>freebsd machine from one machine to an ostensibly similar machine? >> >>[...] >> >> >>>Now whether my details are a bit off, that's fine, I don't want this to >>>be diluted in to discussion of minute frivolous details (as these things >>>are wont to do), but what I _am_ looking for is a tried, tested and true >>>method of FreeBSD machine replication, specifically for the 5.3+ > > releases. > >>I have found the following paper to be incredibly usefull : >> >>http://www.pix.net/software/pxeboot/archive/SANE.pdf >> >>I used some of the ideas in it to clone machines in the 5.1-5.2 era. > > > You could also just mirror the drive with a Promise RAID 1 card. I've done > that a couple of times and it works really well. > > Elliot > From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 22:11:09 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 440E616A427 for ; Thu, 21 Jul 2005 22:11:09 +0000 (GMT) (envelope-from djh@nebcorp.com) Received: from ratchet.nebcorp.com (ratchet.nebcorp.com [205.217.153.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id D634843D58 for ; Thu, 21 Jul 2005 22:10:54 +0000 (GMT) (envelope-from djh@nebcorp.com) Received: by ratchet.nebcorp.com (Postfix, from userid 1014) id B0D1AD9825; Thu, 21 Jul 2005 15:10:54 -0700 (PDT) Date: Thu, 21 Jul 2005 15:10:54 -0700 From: Danny Howard To: Dan Mack Message-ID: <20050721221054.GQ24353@ratchet.nebcorp.com> References: <42DFF582.1050406@unixforge.net> <20050721150151.R7966@coco.macktronics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050721150151.R7966@coco.macktronics.com> User-Agent: Mutt/1.4.2.1i X-Loop: djhoward@uiuc.edu Cc: freebsd-stable@freebsd.org, "Eli K. Breen" Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 22:11:09 -0000 On Thu, Jul 21, 2005 at 03:04:01PM -0500, Dan Mack wrote: > > > Is there a jumpstart (solaris), kickstart (redhat linux), roboinst (irix), > or ignite (hpux) like auto-installer for BSD? No. g4u and a script might do a good job for you if your hardware is mostly similar. > If there was, then I wouldn't image the disk at all, I'd instead setup up > custom network images that I could blast to any system just by pxebooting > it. I'm not sure if it is possible with FreeBSD though, anyone? It is possible. I have done it before. I had some of those funky VA Linux machines which need the dongle boxes to support video and keyboard. I had them booting from hard drive or DHCP, and if I wanted to re-image a machine I just had to clobber the MBR and reboot. :) Setting up the disk partition with sysinstall was the biggest bitch. If I were to set up a system like this again, I might do something with g4u to set out the basic systems, with an rc script that can pull a post-install recipe which does things like growfs /usr/local, and do machine-specific customization. Then PUBLISH your work before you get laid off. (That is how my last efforts were concluded.) Cheers, -danny -- http://dannyman.toldme.com/ From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 22:11:11 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D792616A41F for ; Thu, 21 Jul 2005 22:11:11 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id F345E43D67 for ; Thu, 21 Jul 2005 22:10:46 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so125497wri for ; Thu, 21 Jul 2005 15:10:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=oWmjDWC4UXEgMSkJ3rtkFpFO8ZmLUkKH9lYF+DfiAjBLgzOZ1UuGaBBohCKY+ckJt3s370JmHZ+ZTCOdpZzdFcRZ8VhQIELrg6xfkacUoTvu+6S0gMe4fUxq13TJff4j10N+5+xba8FSY8PsF52fm/X9XUyRzZbfoUM49SUs+iw= Received: by 10.54.97.3 with SMTP id u3mr758960wrb; Thu, 21 Jul 2005 15:10:24 -0700 (PDT) Received: by 10.54.29.26 with HTTP; Thu, 21 Jul 2005 15:10:22 -0700 (PDT) Message-ID: <790a9fff050721151053e36d22@mail.gmail.com> Date: Thu, 21 Jul 2005 17:10:22 -0500 From: Scot Hetzel To: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= In-Reply-To: <42E01226.1020707@t-hosting.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42E01226.1020707@t-hosting.hu> Cc: freebsd-stable@freebsd.org, freebsd-questions@freebsd.org Subject: Re: What to do when panic? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Scot Hetzel List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 22:11:12 -0000 On 7/21/05, K=F6vesd=E1n G=E1bor wrote: > FreeBSD 6. I installed it, and then I had a panic. I got a > debugger prompt, but I don't know what to do with that. I don't know the > debugger commands. Please let me know what should I do when I have an > another panic. What should I type and what kind of information should I > send as a PR. >=20 Look at the FreeBSD Developer HandBook on debugging: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/debugg= ing.html http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kernel= debug.html Scot --=20 DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 22:14:04 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2168D16A42A for ; Thu, 21 Jul 2005 22:14:04 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5CFEE43DCF for ; Thu, 21 Jul 2005 22:13:25 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6LMDPKA064919 for ; Thu, 21 Jul 2005 17:13:25 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu Jul 21 17:13:25 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6LMDPai064917 for freebsd-stable@freebsd.org; Thu, 21 Jul 2005 17:13:25 -0500 (CDT) (envelope-from karl) Date: Thu, 21 Jul 2005 17:13:25 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050721221325.GA64851@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <42DFF582.1050406@unixforge.net> <20050721211305.GC10821@aoi.wolfpond.org> <010f01c58e3e$28458b50$37cba1cd@emerytelcom.com> <42E01BB3.1040801@unixforge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42E01BB3.1040801@unixforge.net> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 22:14:04 -0000 Yep. Pretty much what I used to do with my ISP. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind On Thu, Jul 21, 2005 at 03:03:31PM -0700, Eli K. Breen wrote: > I should point out, this is for replication in a running production > environment. Machines cannot be taken down, and swapping hardware is not > an option. > > I'm currently experimenting with a copy of the MBR, and the root > partition on a CD, with enough tools to attach to the network to > retrieve images of the rest of the partitions (which can be taken as > current snapshots from various servers). > > This _should_ result in the following scenario: > > Boot new machine with CD > partition drive(s) > dump MBR > dump root > ssh foo@server 'dump -C 64 -0af - /sliceX'| (cd /usr; restore -rf -) > [repeat above for all drives, could be automated] > > Seem reasonable? > > -E- > > > Elliot Finley wrote: > >----- Original Message ----- > >From: "Francois Tigeot" > > > >>On Thu, Jul 21, 2005 at 12:20:34PM -0700, Eli K. Breen wrote: > >> > >>>Does anyone have a good handle on how to replicate (read: image) a > >>>freebsd machine from one machine to an ostensibly similar machine? > >> > >>[...] > >> > >> > >>>Now whether my details are a bit off, that's fine, I don't want this to > >>>be diluted in to discussion of minute frivolous details (as these > >>>things > >>>are wont to do), but what I _am_ looking for is a tried, tested and > >>>true > >>>method of FreeBSD machine replication, specifically for the 5.3+ > > > >releases. > > > >>I have found the following paper to be incredibly usefull : > >> > >>http://www.pix.net/software/pxeboot/archive/SANE.pdf > >> > >>I used some of the ideas in it to clone machines in the 5.1-5.2 era. > > > > > >You could also just mirror the drive with a Promise RAID 1 card. I've > >done > >that a couple of times and it works really well. > > > >Elliot > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 22:20:40 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5096A16A427 for ; Thu, 21 Jul 2005 22:20:40 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: from acampi.inet.it (acampi.inet.it [213.92.1.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95BEC43D82 for ; Thu, 21 Jul 2005 22:20:26 +0000 (GMT) (envelope-from andrea@acampi.inet.it) Received: by acampi.inet.it (Postfix, from userid 1000) id A12FC1F; Fri, 22 Jul 2005 00:20:24 +0200 (CEST) Date: Fri, 22 Jul 2005 00:20:24 +0200 From: Andrea Campi To: Dan Mack Message-ID: <20050721222023.GB34685@webcom.it> References: <42DFF582.1050406@unixforge.net> <20050721150151.R7966@coco.macktronics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050721150151.R7966@coco.macktronics.com> User-Agent: Mutt/1.5.9i Cc: freebsd-stable@freebsd.org, "Eli K. Breen" Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 22:20:40 -0000 On Thu, Jul 21, 2005 at 03:04:01PM -0500, Dan Mack wrote: > Is there a jumpstart (solaris), kickstart (redhat linux), roboinst (irix), > or ignite (hpux) like auto-installer for BSD? > > If there was, then I wouldn't image the disk at all, I'd instead setup up > custom network images that I could blast to any system just by pxebooting > it. I'm not sure if it is possible with FreeBSD though, anyone? Well, sysinstall is perfectly capable of doing this, as it's fully "scriptable". You can setup a pxeboot-install environment by setting up a dhcp/tftp/nfs server, copying a standard release CD, and creating a simple config file. I don't have exact details handy, but I know it's possible as it's the way we've been pressing FreeBSD boxes at $REALJOB for ages. You'll find plenty (well, some) of information in the archives as well. Bye, Andrea -- Press every key to continue. From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 23:44:38 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 944BD16A421; Thu, 21 Jul 2005 23:44:38 +0000 (GMT) (envelope-from aiy@ferens.net) Received: from sccrmhc14.comcast.net (sccrmhc14.comcast.net [204.127.202.59]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E3CA43D46; Thu, 21 Jul 2005 23:44:21 +0000 (GMT) (envelope-from aiy@ferens.net) Received: from ferens.net ([67.188.76.62]) by comcast.net (sccrmhc14) with ESMTP id <2005072123442001400mf1nke>; Thu, 21 Jul 2005 23:44:20 +0000 Received: from yoleksiyw2k (dhcp-171-69-219-50.cisco.com [171.69.219.50]) (authenticated bits=0) by ferens.net (8.13.4/8.13.4) with ESMTP id j6LNi9HU000683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Thu, 21 Jul 2005 16:44:10 -0700 (PDT) (envelope-from aiy@ferens.net) Message-Id: <200507212344.j6LNi9HU000683@ferens.net> From: "Alexey Yakimovich" To: "'Mark Linimon'" , "'Robert Watson'" Date: Thu, 21 Jul 2005 16:44:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 In-Reply-To: <20050721211452.GA2412@soaustin.net> Thread-Index: AcWOOc1iMzUTB7WVS1CGuddoRm+f/AAAtiVQ X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 X-FerensNet-MailScanner-Information: Please contact the ISP for more information X-FerensNet-MailScanner: Found to be clean X-FerensNet-MailScanner-From: aiy@ferens.net Cc: 'Marc Olzheim' , freebsd-stable@freebsd.org Subject: RE: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 23:44:38 -0000 Even for "dynamic problems" you can have your code generating detailed logs, including time, pid, thread id, cpu, function, memory ..., and have them analyzed later by some script. But this not my main point here, in this thread. All thoughts in the mails of this thread, developers as well as users, seem to me so right, so true. But I would like to repeat my main point: >From my personal experience, maybe I'm wrong, but what I see close to me, FreeBSD project is loosing a lot of users, I don't know anything about developers, but it seems to me true too. No users no developers no project. And the main problem seems to me is a quality, at least from users point of view. I don't know what caused this problem. But in my opinion, it would be good to try to re-evaluate goals of the project, including small ones like GNOME (how many people using FreeBSD as desktop? Do you know any real world desktop solutions, except for OS X or Windows?). If you want to grab everything you would probably have nothing. And if car's engine does not work, why we need GPS inside? Thank you very much again for your time. I really appreciate it. Alexey FreeBSD user > -----Original Message----- > From: owner-freebsd-stable@freebsd.org > [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Mark Linimon > Sent: Thursday, July 21, 2005 2:15 PM > To: Robert Watson > Cc: 'Marc Olzheim'; Alexey Yakimovich; freebsd-stable@freebsd.org > Subject: Re: Quality of FreeBSD > > On Thu, Jul 21, 2005 at 08:00:40PM +0100, Robert Watson wrote: > > [original poster wrote:] > > >- I completely agree with MikeM - any kind of complex > software could be > > >tested with right prepared test cases, specially if they > are going to be > > >reused in the next release; > > For static problems -- yes. For dynamic problems, such as > race conditions, > the problem space you are trying to test is many orders of > magnitude more > complex. This is true of any engineering discipline, but much more so > with software engineering due to the immense complexity of > the constructed > artifacts. > > > [rwatson again:] > > As has been discussed extensively in this thread and other > threads, the > > FreeBSD development model typically addresses change at the > tree HEAD, > > where the changes are tested and evaluated, and then they > are back-ported. > > Some changes are low-risk, and are backported quickly (minor locking > > fixes, error handling, etc). Others are higher risk, and > are backported > > only when they are felt to have received sufficient testing (driver > > re-writes, structural changes). Other changes are > considered too large > > to ever be backported [ ... ] > > To add to Robert's comments, there was at least one case > during the 5.2 > cycle where a large backport was made that destabilized the > tree for quite > some time. This was not due to any lack of diligence on the > developer's > part; it turned out that the problems were far more subtle and complex > than anyone could have reasonably anticipated. Since that > time, AFAICT > the sentiment has shifted away from large backports. > > There is always risk in any backport and the risks escalate > dramatically > the less compartmentalized the changes are. One of the goals for 6.X > and beyond is to try to keep changes more compartmentalized; there was > simply no way to do such a thing with e.g. SMP and VM changes. At the > same time, the sentiment seems to be "let's debug one set of > featureset > changes all together and then release them as a major release". > > Of course, backports also require developer time both to do > the initial > commit and then, more onerously, the followup support. > > To conclude this thought, the motivation for changing the way FreeBSD > is going to do releases going forwards is to try to mitigate such > problems: to try to debug, and release, a smaller set of features with > new major releases, and more frequently, and with a better-known > schedule (every 18 months). > > > Notice that we'll be supporting the 4.x branch for several > years to come. > > The limiting factor on the 4.X branch is going to be the ports tree > more quickly than the base system, particularly for people running > desktop installations. The FreeBSD GNOME team has already announced > that they are not going to support 4.X by default in the next major > GNOME release due this fall. The next major KDE release will probably > not work on the 4.X gcc compiler as well IIUC. There are simply an > insufficient amount of developer resources to support releases that > have different toolchains, include files, and so on. > > Staying on 4.X indefinitely is not going to be an option at some point > in the future, but when, exactly, is difficult to tell right now. It > is fair to note, however, that almost no developer attention is being > spent on 4.X except for security problems as they are found. > > Further, the more people we have stay on 4.X, the less people we have > testing whichever release we consider the latest "stable" release, and > therefore, the less bugs we'll get fixed on that release. > > One last thought. It always bears repeating that, except for > a handful > of cases, people who work on FreeBSD are not being paid to do > so. Users > should always adjust their expectations accordingly. We do > our absolute > best given the relatively small number of developers that we do have, > but we always need more people who are willing to work on regression > testing and QA activities. For the companies which view FreeBSD as > 'mission-critical' (and we do welcome them!), I challenge them to > consider funding development/testing efforts going forwards. (Yes, a > number already do, but more would be welcome.) > > mcl > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 23:44:42 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C4C016A424 for ; Thu, 21 Jul 2005 23:44:42 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51B3343D5F for ; Thu, 21 Jul 2005 23:44:35 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 1686246B2A; Thu, 21 Jul 2005 19:44:32 -0400 (EDT) Date: Fri, 22 Jul 2005 00:45:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Karl Denninger In-Reply-To: <20050721202234.GA62615@FS.denninger.net> Message-ID: <20050722004340.H16902@fledge.watson.org> References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 23:44:42 -0000 On Thu, 21 Jul 2005, Karl Denninger wrote: > ATA-NG (Soren's new code) is not (from what I understand) in the 5.x > codebase. One bone of contention is that apparently it IS in -HEAD, but > there are no plans to MFC it to 5.x. Then you misunderstand. Soren has asked to MFC it, and we've asked him to wait until it's had more testing exposure, precisely because it is a sensitive code base, and we don't want to see further regression. Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Thu Jul 21 23:58:19 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E908416A506 for ; Thu, 21 Jul 2005 23:58:18 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E50A43DD4 for ; Thu, 21 Jul 2005 23:57:58 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 331EE46B0A; Thu, 21 Jul 2005 19:57:52 -0400 (EDT) Date: Fri, 22 Jul 2005 00:58:23 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexey Yakimovich In-Reply-To: <200507212344.j6LNi9HU000683@ferens.net> Message-ID: <20050722004940.P16902@fledge.watson.org> References: <200507212344.j6LNi9HU000683@ferens.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: 'Marc Olzheim' , 'Mark Linimon' , freebsd-stable@freebsd.org Subject: RE: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jul 2005 23:58:19 -0000 On Thu, 21 Jul 2005, Alexey Yakimovich wrote: > Even for "dynamic problems" you can have your code generating detailed > logs, including time, pid, thread id, cpu, function, memory ..., and > have them analyzed later by some script. But this not my main point > here, in this thread. Instrumentation is very expensive at run-time, and substantially changes timing, especially in the network stack and network-related device drivers, so will often close race conditions by changing the timing. We have an extensive instrumentation system named KTR(9). If you're interested in giving it a try, you can find out more here: http://www.watson.org/~robert/freebsd/netperf/ktr/ This page is primarily targetted at tracing locks, memory allocation, and context switching, but you can also trace I/O, bus operations, VFS operations, and a range of other things. While my web page doesn't talk about it, as it's generally focused on micro-tracing of kernel events, you can also queue the event stream to disk using alq(9). The man pages have more information. There are some neat tools, such as Jeff Roberson's schedgraph, for managing and rendering trace results. The downside, is of course performance and perturbing of the events. Adding trace operations in rapid firing events, such as context switches, lock operations, and so on, even if they're disabled at run-time, has a huge performance cost. As a result, the trace mechanisms are added via compile-time options for the kernel. There's some interest in introducing run-time instrumentation, although the focus of that has primarily been related to run-time adaptation of kernels between UP and SMP, in order to avoid lock costs on an SMP-compiled kernel running on UP. Even then, the performance perturbance is a big issue for tracking subtle races. > All thoughts in the mails of this thread, developers as well as users, > seem to me so right, so true. But I would like to repeat my main point: > From my personal experience, maybe I'm wrong, but what I see close to > me, FreeBSD project is loosing a lot of users, I don't know anything > about developers, but it seems to me true too. No users no developers no > project. I appreciate your concern, but at least from looking at the committer count and commit rates, FreeBSD is gaining developers rather than losing them. Likewise, while users come and go, reports from organizations like Netcraft have tracked a moderate to substantial increase in FreeBSD use over the last few years. If you then throw in indirect consumers of FreeBSD as a result of FreeBSD-derived operating systems, such as Apple's Mac OS X, Juniper, etc, the numbers become rediculously large very quickly. None of this is to say quality and a focus on quality aren't important, just that while your concerns are valid, I think there's a lot of detail to this that isn't as immediately obvious. Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 00:13:16 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2DAD916A427 for ; Fri, 22 Jul 2005 00:13:16 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id B5F1843D9E for ; Fri, 22 Jul 2005 00:12:59 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6M0CrZw071535 for ; Thu, 21 Jul 2005 19:12:53 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu Jul 21 19:12:53 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6M0Crxj071533 for freebsd-stable@freebsd.org; Thu, 21 Jul 2005 19:12:53 -0500 (CDT) (envelope-from karl) Date: Thu, 21 Jul 2005 19:12:53 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050722001253.GA70277@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> <20050722004340.H16902@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050722004340.H16902@fledge.watson.org> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 00:13:16 -0000 On Fri, Jul 22, 2005 at 12:45:03AM +0100, Robert Watson wrote: > > On Thu, 21 Jul 2005, Karl Denninger wrote: > > >ATA-NG (Soren's new code) is not (from what I understand) in the 5.x > >codebase. One bone of contention is that apparently it IS in -HEAD, but > >there are no plans to MFC it to 5.x. > > Then you misunderstand. Soren has asked to MFC it, and we've asked him > to wait until it's had more testing exposure, precisely because it is a > sensitive code base, and we don't want to see further regression. > > Robert N M Watson I don't think I misunderstand at all Robert. "We" (some group) has asked him not to MFC it. Ergo, IT IS NOT THERE NOW, and there are no plans (at present) to MFC it. That's exactly what I said. However, it obviously wasn't that big of a deal (to the -committers) to commit the ORIGINAL changes which broke the implementation going from 4.x to 5.something (early 5.x "early adopter" RELEASEs were ok). What I don't understand Robert is why Soren's code is "too sensitive" to commit, but the explosive reduction in stability that the changes made between 4.x and 5.3 caused weren't enough to back THAT out until it could be fixed. Its not like these problems didn't show up almost immediately when the affected releases hit the street. They did. Six months later, the problems are still there, and I see nothing in the commit logs to suggest that the underlying issues have been addressed. Papering over the failures so that retries work properly (when they were broken before) isn't a fix. A fix would be identifying the root cause of the DMA_TIMEOUT errors and addressing them so that they no longer occur. I realize that this is likely a timing issue in the code, and therefore is difficult to debug. That does not, however, change the fact that this issue has been open for more than six months without resolution, and that one potential resolution to the problem (Soren's ATA-NG code) either (1) doesn't fix it, (2) hasn't been tested to see if it does, or (3) DOES fix it, but for whatever internal reasons has not been MFC'd. If (1), then not only should Soren's code NOT be MFC'd, but 6.x should absolutely be held until it IS identified and resolved. If (2), then how about trying to find out of if that solves the problem? If (3), I think there are a few of us (myself included) that would like an explanation. If Soren BELIEVES (2) is the case, I'll test against -BETA1, IF I can have confirmation that -BETA1 has the ATA-NG code in it. Its trivially easy for me to reproduce this problem on my sandbox machine. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 00:38:19 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DC8A316A426 for ; Fri, 22 Jul 2005 00:38:19 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 18D5843D5E for ; Fri, 22 Jul 2005 00:38:11 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 03A7F46B06; Thu, 21 Jul 2005 20:38:09 -0400 (EDT) Date: Fri, 22 Jul 2005 01:38:40 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Karl Denninger In-Reply-To: <20050722001253.GA70277@FS.denninger.net> Message-ID: <20050722013605.U16902@fledge.watson.org> References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> <20050722004340.H16902@fledge.watson.org> <20050722001253.GA70277@FS.denninger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 00:38:20 -0000 On Thu, 21 Jul 2005, Karl Denninger wrote: > If Soren BELIEVES (2) is the case, I'll test against -BETA1, IF I can > have confirmation that -BETA1 has the ATA-NG code in it. > > Its trivially easy for me to reproduce this problem on my sandbox > machine. As has already been stated, Soren's changes are in 6.x. If you are able to test this workload against 6.0-BETA1 using the hardware in question, that would be very helpful. Depending on the nature of the workload and problem, you might find you need to compile out the debugging features, as they slow things down quite a bit, so might reduce the transaction rate sufficiently to make the problem fail to occur. If it requires 5.x applications, you might find you have to wait for BETA2. Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 00:45:51 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1F84C16A4D5 for ; Fri, 22 Jul 2005 00:45:51 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 955D143E4B for ; Fri, 22 Jul 2005 00:45:37 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 77B6846B09; Thu, 21 Jul 2005 20:45:13 -0400 (EDT) Date: Fri, 22 Jul 2005 01:45:45 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Matthias Schuendehuette In-Reply-To: <1E0ACFEC-A232-4818-9175-E6D181D63DA0@snafu.de> Message-ID: <20050722014135.N16902@fledge.watson.org> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721113927.T97888@fledge.watson.org> <1E0ACFEC-A232-4818-9175-E6D181D63DA0@snafu.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 00:45:51 -0000 On Thu, 21 Jul 2005, Matthias Schuendehuette wrote: > Am 21.07.2005 um 13:00 schrieb Robert Watson: >> >> Have you tried, and do you plan to try, our 6.0 test releases before >> 6.0-RELEASE goes out the door? Specifically, on the hardware you know >> you're having problems with 5.4 on? > > Yes, I did - see the thread "mpt + gvinum on 6.0-BETA". > > But I'm a bit disappointed, that until now there's not *one* reply on my > report. > > It's new hardware, which doesn't even boot with 5.3/5.4-RELEASE (but > with 5.2.1 :-) and probably a more popular Server (FUJITSU-SIEMENS RX300 > S2)... > > what was my fault here? Should I post to -current instead? I would post to -current about 6.x issues, as it's not yet considered a -STABLE branch. If it's an mpt problem, the likely contact is Scott Long (scottl@), who most recently did cleanup and bug fixing of mpt (July 10). Lukas Ertl (le@) is probably the starting contact of choice for gvinum issues, although there's also a geom mailing list which might be a good place to send e-mail. It could, though, easily be an interrupt-related problem of some sort -- e-mail with Scott should hopefully quickly determine if it's the driver, an interrupt problem, or a problem that should be in the hands of Lukas. Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 00:57:48 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 111AC16A48E for ; Fri, 22 Jul 2005 00:57:48 +0000 (GMT) (envelope-from craig@feniz.gank.org) Received: from ion.gank.org (ion.gank.org [69.55.238.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id AB1BD43DC4 for ; Fri, 22 Jul 2005 00:57:21 +0000 (GMT) (envelope-from craig@feniz.gank.org) Received: by ion.gank.org (mail, from userid 1001) id C80AC2AA51; Thu, 21 Jul 2005 19:57:17 -0500 (CDT) Date: Thu, 21 Jul 2005 19:57:15 -0500 From: Craig Boston To: "Eli K. Breen" Message-ID: <20050722005715.GA67419@nowhere> Mail-Followup-To: Craig Boston , "Eli K. Breen" , freebsd-stable@freebsd.org References: <42DFF582.1050406@unixforge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42DFF582.1050406@unixforge.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-stable@freebsd.org Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 00:57:49 -0000 On Thu, Jul 21, 2005 at 12:20:34PM -0700, Eli K. Breen wrote: > dd (Slow, not usefull if the hardware isn't identical?) I use dd a lot for this type of thing and don't see how it could possibly be slower than any other method that duplicates the entire raw drive. Make sure to give it a "bs=1m" option as reading/writing the disk in 512 byte chunks is a lot slower than larger blocks. If your disks have a lot of free space, copying the filesystem using dump/restore can be faster, but it's not an *exact* bit-for-bit copy. The resulting filesystem is functionally equivalent though, so it's probably the best way for duplicating UFS(2) filesystems. You do have to partition manually, but you would probably want to do that if the new drive was a different size anyway. Craig From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 00:58:00 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E28F16A4CC for ; Fri, 22 Jul 2005 00:58:00 +0000 (GMT) (envelope-from kju@ajou.ac.kr) Received: from mail.ajou.ac.kr (maru.ajou.ac.kr [202.30.0.18]) by mx1.FreeBSD.org (Postfix) with SMTP id 7699343D45 for ; Fri, 22 Jul 2005 00:57:58 +0000 (GMT) (envelope-from kju@ajou.ac.kr) Received: from smtp.ajou.ac.kr ([202.30.0.9]) by maru (Crinity Message Backbone-2.8) with SMTP ID 486; Fri, 22 Jul 2005 10:02:26 +0900 (KST) Received: from 210.107.195.165 ([210.107.195.165]) by seodang.ajou.ac.kr (Spambreaker SMTP Server ); Fri, 22 Jul 2005 09:57:49 +0900 (KST) Message-ID: <42E0448C.9020403@ajou.ac.kr> Date: Fri, 22 Jul 2005 09:57:48 +0900 From: Jonguk Kim User-Agent: Mozilla Thunderbird 1.0.5 (X11/20050718) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Marian Hettwer References: <13577.195.234.136.12.1121907665.squirrel@195.234.136.12> In-Reply-To: <13577.195.234.136.12.1121907665.squirrel@195.234.136.12> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_6 scroll wheel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 00:58:00 -0000 Marian Hettwer wrote: > Hej All, > > I upgraded to RELENG_6 to help testing. > Everything went smooth so far, but my scroll wheel in X isn't working > anymore. I didn't changed anything regarding the configuration from > FreeBSD RELENG_5 to RELENG_6 ... > > some details: > [mhettwer@beastie] <~> $ uname -a > FreeBSD beastie.mobile.rz 6.0-BETA1 FreeBSD 6.0-BETA1 #0: Fri Jul 15 > 17:00:59 CEST 2005 root@beastie.mobile.rz:/usr/obj/usr/src/sys/GENERIC > i386 > [mhettwer@beastie] <~> $ dmesg | grep ums > ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 3, iclass 3/1 > ums0: 3 buttons and Z dir. > ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 2, iclass 3/1 > ums0: 3 buttons and Z dir. > ums0: Logitech USB-PS/2 Optical Mouse, rev 2.00/11.10, addr 2, iclass 3/1 > ums0: 3 buttons and Z dir. > > from /etc/X11/xorg.conf > Section "InputDevice" > Identifier "Mouse0" > Driver "mouse" > Option "Protocol" "auto" > Option "Device" "/dev/sysmouse" I think 'Option "Buttons" "5"' can help you. jonguk > Option "ZAxisMapping" "4 5" > EndSection > > [mhettwer@beastie] <~> $ ps ax | grep moused > 1060 ?? Ss 0:52,38 /usr/sbin/moused -z 4 -p /dev/ums0 -t auto -I > /var/run/moused.ums0.pid > > I'm running xorg-6.8.2 > > I didn't recompiled my ports, but I guess this shouldn't be the problem, hm ? > > Any ideas anyone ? > > best regards, > Marian > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 01:06:12 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4FB416A421 for ; Fri, 22 Jul 2005 01:06:12 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0089A43D45 for ; Fri, 22 Jul 2005 01:06:11 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6M16BJL072289 for ; Thu, 21 Jul 2005 20:06:11 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Thu Jul 21 20:06:11 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6M16Bix072287 for freebsd-stable@freebsd.org; Thu, 21 Jul 2005 20:06:11 -0500 (CDT) (envelope-from karl) Date: Thu, 21 Jul 2005 20:06:11 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050722010611.GA72234@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> <20050722004340.H16902@fledge.watson.org> <20050722001253.GA70277@FS.denninger.net> <20050722013605.U16902@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050722013605.U16902@fledge.watson.org> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 01:06:12 -0000 On Fri, Jul 22, 2005 at 01:38:40AM +0100, Robert Watson wrote: > > On Thu, 21 Jul 2005, Karl Denninger wrote: > > >If Soren BELIEVES (2) is the case, I'll test against -BETA1, IF I can > >have confirmation that -BETA1 has the ATA-NG code in it. > > > >Its trivially easy for me to reproduce this problem on my sandbox > >machine. > > As has already been stated, Soren's changes are in 6.x. If you are able > to test this workload against 6.0-BETA1 using the hardware in question, > that would be very helpful. Depending on the nature of the workload and > problem, you might find you need to compile out the debugging features, > as they slow things down quite a bit, so might reduce the transaction > rate sufficiently to make the problem fail to occur. If it requires 5.x > applications, you might find you have to wait for BETA2. > > Robert N M Watson As I pointed out in my PR, "make -j4 buildworld" is more than sufficient to demonstrate the problem. This is why I don't understand why it has been ignored - it is easily reproducable using stock Adaptec SATA controllers, standard SATA drives, and a gmirror RAID 1 configuration. This is pretty pedestrian stuff here Robert.... Two disks on one adapter, on a PCI bus..... I'll pull over 6.0-BETA1, rebuild the array (that is the time-consuming part of this test - takes 6-8 hours for the rebuild to run) and see if it fails during a buildworld. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 04:39:48 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1F4816A422; Fri, 22 Jul 2005 04:39:48 +0000 (GMT) (envelope-from ciscogeek@bgp4.net) Received: from isis.bgp4.net (isis.bgp4.net [66.246.197.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id BAE7B43D46; Fri, 22 Jul 2005 04:39:47 +0000 (GMT) (envelope-from ciscogeek@bgp4.net) Received: from [192.168.23.2] (c-67-171-8-36.hsd1.wa.comcast.net [67.171.8.36]) (authenticated bits=0) by isis.bgp4.net (8.13.3/8.13.3) with ESMTP id j6M4faNw011165 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Thu, 21 Jul 2005 21:41:50 -0700 (PDT) (envelope-from ciscogeek@bgp4.net) Message-ID: <42E0788F.50300@bgp4.net> Date: Thu, 21 Jul 2005 21:39:43 -0700 From: Janet Sullivan User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <1121917413.4895.47.camel@localhost.localdomain> <20050721113927.T97888@fledge.watson.org> <1E0ACFEC-A232-4818-9175-E6D181D63DA0@snafu.de> <20050722014135.N16902@fledge.watson.org> In-Reply-To: <20050722014135.N16902@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (isis.bgp4.net [66.246.197.72]); Thu, 21 Jul 2005 21:41:50 -0700 (PDT) Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 04:39:48 -0000 I've been a BSD user since the mid-90s, and a FreeBSD user since the days 4.0 became STABLE. Right now, I have 2 collocated servers, one home server, and a laptop all running 5.4 without any serious problems. I've watched 5.x since its creation, and while there have been some rocky times, I do think things are getting better. I refused to run 5.x on my servers until 5.4, but I have not yet regretted the move. I know that other people have had issues, but so far 5.4 has been a solid release for me. I do think some mistakes were made with the release engineering over 5.x's lifetime, but folks, what's done is done. Recently things do seem to be headed in a better direction, for which I'm thankful. I know the developers don't hear it often enough, but thanks for all you do. I'm not a programmer, and I currently don't have the funds to donate to the project, but you do have my heartfelt thanks for still turning out my favorite OS. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 05:41:40 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 873F116A420 for ; Fri, 22 Jul 2005 05:41:40 +0000 (GMT) (envelope-from pcasidy@casidy.com) Received: from spock.galacsys.net (mx2.galacsys.net [217.24.82.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96FE043D77 for ; Fri, 22 Jul 2005 05:41:39 +0000 (GMT) (envelope-from pcasidy@casidy.com) Received: from smtp.casidy.net (lns-vlq-39f-81-56-135-122.adsl.proxad.net [81.56.135.122]) by spock.galacsys.net (Postfix) with ESMTP id 74BE91010E for ; Fri, 22 Jul 2005 07:41:37 +0200 (CEST) Received: from casidy.com (unknown [192.168.1.2]) by smtp.casidy.net (Postfix) with ESMTP id 6098BB877 for ; Fri, 22 Jul 2005 07:41:33 +0200 (CEST) Date: Fri, 22 Jul 2005 07:41:13 +0000 (UTC) From: pcasidy@casidy.com To: freebsd-stable@freebsd.org In-Reply-To: <20050721150151.R7966@coco.macktronics.com> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Message-Id: <20050722054133.6098BB877@smtp.casidy.net> Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 05:41:40 -0000 On 21 Jul, Dan Mack wrote: > > Is there a jumpstart (solaris), kickstart (redhat linux), roboinst (irix), > or ignite (hpux) like auto-installer for BSD? > > If there was, then I wouldn't image the disk at all, I'd instead setup up > custom network images that I could blast to any system just by pxebooting > it. I'm not sure if it is possible with FreeBSD though, anyone? > According to its manpage, 'sysinstall' is supposed to be able to read a config file in order to be able to configure an installation with no user interaction. Philippe. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 05:51:45 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD2E116A488 for ; Fri, 22 Jul 2005 05:51:45 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5E17643D64 for ; Fri, 22 Jul 2005 05:51:11 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so116833nzo for ; Thu, 21 Jul 2005 22:51:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kn57MIqPf4yyHy+RULN185itahwBKig02hcPsUsLCtvzi/XIqBh6U8cZNbm9xFbo5upaIaYFGbvq4uFiSs/CfHADTzN3dI/kKZYgD2MH258g4d4RE3BipUOdDbR2ObtXYvSN39rzr2l4Pj26wIyVIYczeDipBZqIzEzbSBNR0jA= Received: by 10.36.129.16 with SMTP id b16mr1275365nzd; Thu, 21 Jul 2005 22:41:08 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Thu, 21 Jul 2005 22:41:08 -0700 (PDT) Message-ID: <79722fad050721224147232de2@mail.gmail.com> Date: Fri, 22 Jul 2005 08:41:08 +0300 From: Vlad GALU To: freebsd-stable@freebsd.org In-Reply-To: <200507212006.j6LK68RO037136@drjekyll.mkbuelow.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050721184455.5CEA8B86C@smtp.casidy.net> <200507212006.j6LK68RO037136@drjekyll.mkbuelow.net> Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vlad GALU List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 05:51:46 -0000 On 7/21/05, Matthias Buelow wrote: > pcasidy@casidy.com writes: >=20 > >My main problem, and to others after seeing the question from times to > >times, is to know which is a good (not necessarly the best) hardware to > >run FreeBSD on? > >When I buy a new motherboard, which chipset to choose/avoid, which contr= ollers > >? >=20 > Maybe some website like it is being done for notebooks (with > Linux/FreeBSD support) would be in order. I'm thinking about something > like http://www.linux-laptop.net/, only for FreeBSD and all kinds of > machines, not just notebooks. (Or, if some collaboration would be ok, > for *BSD in general, with people posting experience from NetBSD, > OpenBSD, Dragonfly, even Darwin aswell. That way one could also compare > support for hardware and see what problems the individual systems have.) >=20 There's this: http://gerda.univie.ac.at/freebsd-laptops/ > Make it a Wiki, or something similar, where people can freely post > experiences they have with their hardware. That could be whole machines > (Dell model xxx desktop, IBM yyy laptop, HP zzz server) aswell as > components (Asus blah motherboard, 3Com wlan card model foobar, etc.) > and make the thing searchable, and perhaps allow one to post comments on > entries (easy with a Wiki). That way people can quickly search & review > hardware, awell as test suggested workarounds by the posters, without > having to google for obscured mailing list entries, or problem reports. >=20 > mkb. > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >=20 --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 06:02:00 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A1FB916A424; Fri, 22 Jul 2005 06:02:00 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from server.absolute-media.de (server.absolute-media.de [213.239.231.9]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7709543D46; Fri, 22 Jul 2005 06:01:40 +0000 (GMT) (envelope-from NKoch@demig.de) Received: from localhost (unknown [127.0.0.1]) by server.absolute-media.de (Postfix) with ESMTP id 9D5408B602; Fri, 22 Jul 2005 08:01:34 +0200 (CEST) Received: from server.absolute-media.de ([127.0.0.1]) by localhost (server [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08721-01; Fri, 22 Jul 2005 08:01:26 +0200 (CEST) Received: from firewall.demig (p50839136.dip0.t-ipconnect.de [80.131.145.54]) by server.absolute-media.de (Postfix) with ESMTP id CDCAB8A41E; Fri, 22 Jul 2005 08:01:26 +0200 (CEST) Received: from ws-ew-3 (ws-ew-3.w2kdemig [192.168.1.72]) by firewall.demig (8.13.4/8.13.1) with SMTP id j6M60flA099753; Fri, 22 Jul 2005 08:00:41 +0200 (CEST) (envelope-from NKoch@demig.de) From: "Norbert Koch" To: "=?iso-8859-1?B?S/Z2ZXNk4W4gR+Fib3I=?=" , , Date: Fri, 22 Jul 2005 08:00:41 +0200 Message-ID: <003001c58e82$b0d6ffa0$4801a8c0@ws-ew-3.W2KDEMIG> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <42E01226.1020707@t-hosting.hu> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2120.0 Importance: Normal X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at absolute-media.de Cc: Subject: RE: What to do when panic? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 06:02:00 -0000 > I've never debugged FreeBSD, but now I've decided to help the testing > process of FreeBSD 6. I installed it, and then I had a panic. I got a > debugger prompt, but I don't know what to do with that. I don't know the > debugger commands. Please let me know what should I do when I have an > another panic. What should I type and what kind of information should I > send as a PR. You should also have a look at http://www.lemis.com/grog/Papers/Debug-tutorial/tutorial.pdf. That's Greg Lehey's script of his excellent tutorial on kernel debugging. Norbert From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 07:09:35 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5E13916A433 for ; Fri, 22 Jul 2005 07:09:35 +0000 (GMT) (envelope-from Brian.Scott@det.nsw.edu.au) Received: from itumx2.dmzs.det.nsw.edu.au (itumx2.det.nsw.edu.au [153.107.41.144]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D14343D5C for ; Fri, 22 Jul 2005 07:09:20 +0000 (GMT) (envelope-from Brian.Scott@det.nsw.edu.au) Received: from itfsmtp2.central.det.win (itfsmtp2.det.nsw.edu.au [153.107.8.32]) by itumx2.dmzs.det.nsw.edu.au (8.12.10/8.12.10) with ESMTP id j6M79IwQ287289; Fri, 22 Jul 2005 17:09:18 +1000 (EST) Received: from itfexhub2.central.det.win (Not Verified[153.107.9.29]) by itfsmtp2.central.det.win with NetIQ MailMarshal id ; Fri, 22 Jul 2005 17:09:18 +1000 Received: from alf6.riverina.det.win ([172.18.8.14]) by itfexhub2.central.det.win with Microsoft SMTPSVC(6.0.3790.211); Fri, 22 Jul 2005 17:09:18 +1000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Date: Fri, 22 Jul 2005 17:09:10 +1000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Machine Replication Thread-Index: AcWOKVz1sduBO8v5QEiPBaC8CJTKWgAYGd8Q From: "Scott, Brian" To: "Eli K. Breen" , X-OriginalArrivalTime: 22 Jul 2005 07:09:18.0184 (UTC) FILETIME=[46A6F680:01C58E8C] Cc: Subject: RE: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 07:09:35 -0000 For what its worth I use Norton Ghost to regularly set up a classroom of machines with FreeBSD 5.3, mostly because other teachers put Windoze stuff on the same boxes so the Ghost setup makes sense. Ghost doesn't understand UFS but doesn't need to. It just takes a block by block copy of the whole partition. To keep the images a reasonable size I do a dd if=3D/dev/zero bs=3D1m of=3D/junk; rm /junk (repeat for every file system) before imaging and tell ghost to do high compression. Compressing lots of zeros is really efficient so the images come out a reasonable size. Using multicasting I can dump the image in parallel onto 15 machines and have the system installed in under 10 minutes. IP configuration is done with DHCP so thats all straightforward. I use a small dhcp client hook script to change the system name based on IP so I even get unique system names The fact that the hardware on all of the target machines is the same is obviously a huge benefit because I can use a single X configuration, but FreeBSD travels to new hardware a lot better than any of the other O/Ss do. The only real issue is that I have some variety of hard disk types but providing the original partition isn't bigger than my smallest target drive, Ghost looks after everything properly. I haven't found a decent freeware alternative that I could get the same results from but hope to some day. -----Original Message----- From: owner-freebsd-stable@freebsd.org [mailto:owner-freebsd-stable@freebsd.org] On Behalf Of Eli K. Breen Sent: Friday, 22 July 2005 5:21 AM To: freebsd-stable@freebsd.org Subject: Machine Replication All, Does anyone have a good handle on how to replicate (read: image) a=20 freebsd machine from one machine to an ostensibly similar machine? So far I've used countless variations and combinations of the following: dd (Slow, not usefull if the hardware isn't identical?) tar (Doesn't replicate MBR) rsync (No MBR support) Norton Ghost (Doesn't support UFS/UFS2?) G4U (little experience with this) Now whether my details are a bit off, that's fine, I don't want this to=20 be diluted in to discussion of minute frivolous details (as these things are wont to do), but what I _am_ looking for is a tried, tested and true method of FreeBSD machine replication, specifically for the 5.3+ releases. Many thanks, -E- _______________________________________________ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" ********************************************************************** This message is intended for the addressee named and may contain privileged information or confidential information or both. If you are not the intended recipient please delete it and notify the sender. ********************************************************************** From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 07:41:48 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A87716A420 for ; Fri, 22 Jul 2005 07:41:48 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from linda-2.paradise.net.nz (bm-2a.paradise.net.nz [202.0.58.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C49343D5C for ; Fri, 22 Jul 2005 07:41:40 +0000 (GMT) (envelope-from markir@paradise.net.nz) Received: from smtp-1.paradise.net.nz (smtp-1b.paradise.net.nz [202.0.32.210]) by linda-2.paradise.net.nz (Paradise.net.nz) with ESMTP id <0IK000GNLP32TF@linda-2.paradise.net.nz> for freebsd-stable@freebsd.org; Fri, 22 Jul 2005 19:06:40 +1200 (NZST) Received: from [192.168.1.11] (218-101-13-56.paradise.net.nz [218.101.13.56]) by smtp-1.paradise.net.nz (Postfix) with ESMTP id 145AF839E4 for ; Fri, 22 Jul 2005 19:00:51 +1200 (NZST) Date: Fri, 22 Jul 2005 19:00:48 +1200 From: Mark Kirkwood In-reply-to: <1dbad31505072105401c06bee6@mail.gmail.com> To: freebsd-stable@freebsd.org Message-id: <42E099A0.3080101@paradise.net.nz> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7bit X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050511) References: <1dbad31505072105401c06bee6@mail.gmail.com> Subject: FreeBSD IO Performance (was Re: Quality of FreeBSD) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 07:41:48 -0000 I happened to have received a 'new' machine, and wanted to see what its IO system was capable of. So took the opportunity to run 4.10 and 5.4 against each other a few times. (fresh re-installs each time). Its documented at: http://homepages.paradise.net.nz/markir/freebsd/ I wanted to play with Docbook as well :-), so excuse the "book" format (might be a few typos too). But to cut to the chase, the results were overall very similar - 4.10 probably a little (4-8%) faster (allowing for run variation). So really 5.4 is reasonably fast. The actual figures weren't too bad either - 70-80Mb/s read and writes on a 2 disk ATA array. The most interesting thing discovered, was 5.4's "out of the box" sequential *read* performance was considerably less then 4.10, but could be brought up to almost the same by setting. vfs.read_max=16 Hope this provides some interest, again - gotta qualify, this is all one man's experiment on his hardware... Cheers Mark P.s : of course, it would be nice if 5.x (or perhaps more importantly 6.x) was *faster* than 4.10.... Michael Schuh wrote: > Hi, > > Now my question to you : is the performance of ata-related disk-access > under UFS-Filesystem not important for other application, so that the > performance can be a half of them that RELENG_4 does? > > In fact under RELENG_4 i can write a GIG FIle double as fast as under > RELENG_5 ! and i would not hear any thing about serial performance or > that this is not really like the real world, if i syimulate that with: > > /usr/bin/time dd if=/dev/zero of=/zerofile bs=1024 count=1024k; > this is reality poor! > From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 08:13:25 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A535516A459 for ; Fri, 22 Jul 2005 08:13:25 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from crivens.unixoid.de (crivens.unixoid.de [81.169.171.191]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD4E843DA3 for ; Fri, 22 Jul 2005 08:13:14 +0000 (GMT) (envelope-from MH@kernel32.de) Received: from localhost (localhost [127.0.0.1]) by crivens.unixoid.de (Postfix) with ESMTP id 5F29E4085; Fri, 22 Jul 2005 10:13:13 +0200 (CEST) Received: from crivens.unixoid.de ([127.0.0.1]) by localhost (crivens.unixoid.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 51403-04; Fri, 22 Jul 2005 10:13:09 +0200 (CEST) Received: from [10.38.0.10] (unknown [212.12.51.89]) by crivens.unixoid.de (Postfix) with ESMTP id 7D8D03F0F; Fri, 22 Jul 2005 10:13:09 +0200 (CEST) Message-ID: <42E0AA95.6030307@kernel32.de> Date: Fri, 22 Jul 2005 10:13:09 +0200 From: Marian Hettwer User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonguk Kim References: <13577.195.234.136.12.1121907665.squirrel@195.234.136.12> <42E0448C.9020403@ajou.ac.kr> In-Reply-To: <42E0448C.9020403@ajou.ac.kr> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at unixoid.de Cc: freebsd-stable@freebsd.org Subject: Re: RELENG_6 scroll wheel X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 08:13:25 -0000 Hej jonguk, Jonguk Kim wrote: > Marian Hettwer wrote: > >> from /etc/X11/xorg.conf >> Section "InputDevice" >> Identifier "Mouse0" >> Driver "mouse" >> Option "Protocol" "auto" >> Option "Device" "/dev/sysmouse" > > > I think 'Option "Buttons" "5"' can help you. > nope, didn't do the trick. But thanks for the suggestion anyway :) Strange thing though, same config worked under RELENG_5 without problems. best regards, Marian From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 08:16:16 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1DE7016A41F for ; Fri, 22 Jul 2005 08:16:16 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD45A43D5C for ; Fri, 22 Jul 2005 08:15:55 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-19-236.belrs4.nsw.optusnet.com.au [220.239.19.236]) by mail08.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j6M8Fq8Q011536 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 22 Jul 2005 18:15:54 +1000 Received: from cirb503493.alcatel.com.au (localhost.alcatel.com.au [127.0.0.1]) by cirb503493.alcatel.com.au (8.12.10/8.12.10) with ESMTP id j6M8FqTu006029; Fri, 22 Jul 2005 18:15:52 +1000 (EST) (envelope-from pjeremy@cirb503493.alcatel.com.au) Received: (from pjeremy@localhost) by cirb503493.alcatel.com.au (8.12.10/8.12.9/Submit) id j6M8FpbJ006028; Fri, 22 Jul 2005 18:15:51 +1000 (EST) (envelope-from pjeremy) Date: Fri, 22 Jul 2005 18:15:51 +1000 From: Peter Jeremy To: Martin Message-ID: <20050722081551.GA5387@cirb503493.alcatel.com.au> References: <1121917413.4895.47.camel@localhost.localdomain> <20050721095732.GG52120@stack.nl> <200507212029.47615.doconnor@gsoft.com.au> <200507210850530519.03A3275D@sentry.24cl.com> <20050721135839.K97888@fledge.watson.org> <42DFC345.10205@nurfuerspam.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42DFC345.10205@nurfuerspam.de> User-Agent: Mutt/1.4.2i Cc: freebsd-stable@freebsd.org Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 08:16:16 -0000 On Thu, 2005-Jul-21 17:46:13 +0200, Martin wrote: >One more thing about "cheap hardware": if you know that a piece of >hardware is potentially buggy (I mean real BUGS and not missing >support), please publish your opinion, because I will buy hardware >FOR FREEBSD, so I avoid major problems. How about test suites for >ACPI quality, e.g.? Would it be possible? In general, I'd say what you want isn't achievable. Firstly, there's the risk of legal action from a vendor who believes they have been maligned and the reliability (or lack thereof) of the supplied opinions. More critically, vendors often make (significant to FreeBSD) changes to products without any obvious external differences. For example, wireless cards that are externally identical but have different chipsets when you open the packaging. And there's no way to ensure that the BIOS and ACPI in the motherboard you bought last week bears any resemblance to the BIOS and ACPI in the supposedly identical motherboard that I buy this week. As far as the vendor is concerned, as long as it (sort of) works on Windoze when you use the vendor-supplied driver then the vendor has fulfilled their "fit-for-use" responsibility. -- Peter Jeremy From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 08:29:44 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EF83C16A421 for ; Fri, 22 Jul 2005 08:29:44 +0000 (GMT) (envelope-from arielle@taronga.com) Received: from green.syncronym.org (216-118-17-6.ip.pdq.net [216.118.17.6]) by mx1.FreeBSD.org (Postfix) with SMTP id DDA0143D6A for ; Fri, 22 Jul 2005 08:29:27 +0000 (GMT) (envelope-from arielle@taronga.com) Received: (qmail 12758 invoked from network); 22 Jul 2005 08:29:26 -0000 Received: from citadel.in.taronga.com (10.0.0.43) by green.in.taronga.com with SMTP; 22 Jul 2005 08:29:26 -0000 Received: by citadel.in.taronga.com (Postfix, from userid 101) id 78A8E413D1; Fri, 22 Jul 2005 03:29:26 -0500 (CDT) To: freebsd-stable@freebsd.org References: <20050722082845.7F3A0413C6@citadel.in.taronga.com> In-Reply-To: <20050722082845.7F3A0413C6@citadel.in.taronga.com> Precedence: junk X-Loop: arielle@taronga.com Message-Id: <20050722082926.78A8E413D1@citadel.in.taronga.com> Date: Fri, 22 Jul 2005 03:29:26 -0500 (CDT) From: arielle@taronga.com (Stephanie da Silva) Subject: Re: Mail System Error - Returned Mail X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 08:29:45 -0000 To send mail to me, you need to add [laundry] to the end of the subject line (eg: Subject: Random message [laundry]). From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 08:44:49 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D20D416A41F for ; Fri, 22 Jul 2005 08:44:49 +0000 (GMT) (envelope-from nb@ravenbrook.com) Received: from raven.ravenbrook.com (raven.ravenbrook.com [193.82.131.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id E189E43D77 for ; Fri, 22 Jul 2005 08:44:35 +0000 (GMT) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (thrush.ravenbrook.com [193.112.141.145]) by raven.ravenbrook.com (8.12.6p3/8.12.6) with ESMTP id j6M8iYXi088919; Fri, 22 Jul 2005 09:44:34 +0100 (BST) (envelope-from nb@ravenbrook.com) Received: from thrush.ravenbrook.com (localhost [127.0.0.1]) by thrush.ravenbrook.com (8.12.9p2/8.12.9) with ESMTP id j6M8iXFM077068; Fri, 22 Jul 2005 09:44:33 +0100 (BST) (envelope-from nb@thrush.ravenbrook.com) From: Nick Barnes To: "Eli K. Breen" In-Reply-To: <42DFF582.1050406@unixforge.net> from "Eli K. Breen" of "Thu, 21 Jul 2005 12:20:34 -0700" Date: Fri, 22 Jul 2005 09:44:33 +0100 Message-ID: <77067.1122021873@thrush.ravenbrook.com> Sender: nb@ravenbrook.com Cc: freebsd-stable@freebsd.org Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 08:44:49 -0000 At 2005-07-21 19:20:34+0000, "Eli K. Breen" writes: > All, > > Does anyone have a good handle on how to replicate (read: image) a > freebsd machine from one machine to an ostensibly similar machine? > > So far I've used countless variations and combinations of the following: > > dd (Slow, not usefull if the hardware isn't identical?) I have used dd | gzip -9 on many occasions. I don't find it especially slow (it will run at full disk bandwidth, typically 50 MB/sec on current ATA desktop disks, i.e. 3G/minute), and if you want an actual bit-for-bit identical replication then it's the only way to go. It's also very handy for keeping multi-boot slice images around (e.g. images of Windows partitions in various states, for testing purposes). The compressed images often end up nice and small. The disadvantage you may have is that your slice table and/or partition table will be wrong if your target machine has a larger disk. This is pretty easy to fix after the fact with a script using disklabel and/or fdisk. You will get better compression if you dd /dev/zero to your source machine before the initial installation, so that empty sectors are all zeroes. One day I will write a program which zeroes empty blocks of an unmounted filesystem.... > tar (Doesn't replicate MBR) > rsync (No MBR support) Replicating the MBR is exceptionally easy with dd: it's the first sector of the disk. Note that this first sector also includes the slice table. You could easily use dd in combination with tar and rsync. > Norton Ghost (Doesn't support UFS/UFS2?) > G4U (little experience with this) I notice that 'dump' is not in your list. Why is that? Nick Barnes Ravenbrook Limited From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 09:07:04 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86E6016A42D for ; Fri, 22 Jul 2005 09:07:04 +0000 (GMT) (envelope-from benoit-lists@fb12.de) Received: from mail.webmonster.de (datasink.webmonster.de [194.162.162.209]) by mx1.FreeBSD.org (Postfix) with SMTP id C461543D45 for ; Fri, 22 Jul 2005 09:06:52 +0000 (GMT) (envelope-from benoit-lists@fb12.de) Received: (qmail 50569 invoked by uid 1019); 22 Jul 2005 09:07:13 -0000 Date: Fri, 22 Jul 2005 11:06:51 +0159 From: Sebastian Benoit To: freebsd-stable@freebsd.org Message-ID: <20050722090713.GD47964@mail.webmonster.de> Mail-Followup-To: freebsd-stable@freebsd.org References: <42DFF582.1050406@unixforge.net> <20050721150151.R7966@coco.macktronics.com> <20050721221054.GQ24353@ratchet.nebcorp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="9Ek0hoCL9XbhcSqy" Content-Disposition: inline In-Reply-To: <20050721221054.GQ24353@ratchet.nebcorp.com> User-Agent: Mutt/1.4.2.1i Organisation: Organisation against the bulletization of popular thought as a result of the increasing prevalence of Microsoft PowerPoint(TM) X-MSMail-Priority: High x-gpg-fingerprint: D02B D0E0 3790 1AA1 DA3A B508 BF48 87BF D777 DBA7 x-gpg-key: http://wwwkeys.de.pgp.net:11371/pks/lookup?op=get&search=0xD777DBA7 x-gpg-keyid: 0xD777DBA7 Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 09:07:04 -0000 --9Ek0hoCL9XbhcSqy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Danny Howard(dannyman@toldme.com) on 2005.07.21 15:10:54 +0000: > machine-specific customization. Then PUBLISH your work before you get > laid off. (That is how my last efforts were concluded.) Oh, yeah :-) http://www.mathematik.uni-marburg.de/sys/os/freebsd/ the page is in german, sorry... Benno --=20 Sebastian Benoit My mail is GnuPG signed -- Unsigned ones are bogus -- http://www.gnupg.org/ GnuPG 0xD777DBA7 2003-09-10 D02B D0E0 3790 1AA1 DA3A B508 BF48 87BF D777 D= BA7 The man who does not read good books has no advantage over the man who can't read them. -- Mark Twain --9Ek0hoCL9XbhcSqy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFC4LdBv0iHv9d326cRAn4ZAJ9dlimJGZcm3yerR1s74vttQgGxBgCgxPGg DEFf1bemOtbteOJlyDHEOYk= =yeOk -----END PGP SIGNATURE----- --9Ek0hoCL9XbhcSqy-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 09:16:20 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3102016A420 for ; Fri, 22 Jul 2005 09:16:20 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from cs1.cs.huji.ac.il (cs1.cs.huji.ac.il [132.65.16.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82FA843D45 for ; Fri, 22 Jul 2005 09:15:36 +0000 (GMT) (envelope-from danny@cs.huji.ac.il) Received: from pampa.cs.huji.ac.il ([132.65.80.32]) by cs1.cs.huji.ac.il with esmtp id 1Dvtcu-0003iA-Cv; Fri, 22 Jul 2005 12:15:28 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: "Eli K. Breen" In-Reply-To: Message from "Eli K. Breen" of "Thu, 21 Jul 2005 13:16:26 PDT." <42E0029A.4090204@unixforge.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 22 Jul 2005 12:15:28 +0300 From: Danny Braniss Message-ID: Cc: freebsd-stable@freebsd.org Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 09:16:20 -0000 > Just as a point of note, I'm not trying to roll out squeeky-clean new > machines. Let's say I've got ten-fifteen sets of clusters, I need to be > able to just rip a copy and blast it to another machine. > > Thanks for all the responses so far. you should invest some time to set up a diskless/pxe environment, then booting diskless is zero pain, and you can then copy disks without stepping on your toes (or foot shooting). my .5$ danny From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 09:22:59 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1FD0F16A430 for ; Fri, 22 Jul 2005 09:22:59 +0000 (GMT) (envelope-from pertti.kosunen@pp.nic.fi) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0D6A543D68 for ; Fri, 22 Jul 2005 09:22:52 +0000 (GMT) (envelope-from pertti.kosunen@pp.nic.fi) Received: from [62.142.71.181] (KMMLXXXI.dsl.saunalahti.fi [62.142.71.181]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 97DEDEFB1D; Fri, 22 Jul 2005 12:22:49 +0300 (EEST) Message-ID: <42E0BAE9.1060004@pp.nic.fi> Date: Fri, 22 Jul 2005 12:22:49 +0300 From: Pertti Kosunen User-Agent: Mozilla Thunderbird 1.0.2 / FreeBSD 5.4-STABLE X-Accept-Language: en-us, en MIME-Version: 1.0 To: Steve References: <42DF2A8F.30202@powersystemsdirect.com> <20050721112230.A97888@fledge.watson.org> <42DFCAF1.8020701@powersystemsdirect.com> In-Reply-To: <42DFCAF1.8020701@powersystemsdirect.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: READ_DMA, WRITE_DMA errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 09:22:59 -0000 Steve wrote: > If anyone has that link handy, please post. (for the patch) http://people.freebsd.org/~sos/ATA/ From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 13:27:16 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0203416A448 for ; Fri, 22 Jul 2005 13:27:16 +0000 (GMT) (envelope-from marcus@corp.grupos.com.br) Received: from mail.grupos.com.br (mail.grupos.com.br [200.203.183.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id A637D43E47 for ; Fri, 22 Jul 2005 13:26:02 +0000 (GMT) (envelope-from marcus@corp.grupos.com.br) Received: from corp.grupos.com.br (unknown [150.162.166.55]) by mail.grupos.com.br (Postfix) with ESMTP id 5284811EE44 for ; Fri, 22 Jul 2005 10:25:24 -0300 (BRT) Received: from corp.grupos.com.br (localhost [127.0.0.1]) by corp.grupos.com.br (Postfix) with ESMTP id 1BA8C5615 for ; Fri, 22 Jul 2005 10:25:24 -0300 (BRT) Received: from [150.162.166.51] (noc.grupos.com.br [150.162.166.51]) by corp.grupos.com.br (Postfix) with ESMTP id BE850560C for ; Fri, 22 Jul 2005 10:25:23 -0300 (BRT) Message-ID: <42E0F3C3.1090604@corp.grupos.com.br> Date: Fri, 22 Jul 2005 10:25:23 -0300 From: Marcus Grando User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Resize UFS2 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 13:27:16 -0000 Hi List, Is possible resize UFS2? For example. I have 5 disks with RAID5, and reconstruct to 6 disks with RAID5, after that FreeBSD mount RAID perfectly, but with the same space before reconstruct RAID5. Exists one method to FreeBSD recognize more space? Hardware is: Dell PV220S + PERC4/DC (MegaRAID SCSI 320-2X) Thanks for any help -- Marcus Grando Grupos Internet S/A marcus(at)corp.grupos.com.br From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 13:50:24 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7276816A42F for ; Fri, 22 Jul 2005 13:50:24 +0000 (GMT) (envelope-from aturetta@commit.it) Received: from mail.logital.it (ip143.a.rainbownet.com [213.174.191.143]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B0AB43D79 for ; Fri, 22 Jul 2005 13:49:09 +0000 (GMT) (envelope-from aturetta@commit.it) Received: from [192.168.42.11] (81-174-12-226.f5.ngi.it [81.174.12.226]) (authenticated bits=0) by mail.logital.it (8.13.4/8.13.4) with ESMTP id j6MDmi8h018621; Fri, 22 Jul 2005 15:48:45 +0200 (CEST) (envelope-from aturetta@commit.it) Message-ID: <42E0F93E.7000108@commit.it> Date: Fri, 22 Jul 2005 15:48:46 +0200 From: Angelo Turetta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: it, en-us, en MIME-Version: 1.0 To: Karl Denninger References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> <20050722004340.H16902@fledge.watson.org> <20050722001253.GA70277@FS.denninger.net> <20050722013605.U16902@fledge.watson.org> <20050722010611.GA72234@FS.denninger.net> In-Reply-To: <20050722010611.GA72234@FS.denninger.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.86.1, clamav-milter version 0.86 on mail.logital.it X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.logital.it Cc: freebsd-stable@freebsd.org Subject: make -j as a stress test (was: Re: Quality of FreeBSD) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 13:50:25 -0000 Karl Denninger wrote: > As I pointed out in my PR, "make -j4 buildworld" is more than sufficient > to demonstrate the problem. ( ... ) > I'll pull over 6.0-BETA1, rebuild the array (that is the time-consuming > part of this test - takes 6-8 hours for the rebuild to run) and see if it > fails during a buildworld. Maybe I'm wrong, but in my tests I had the impression that RELENG_6 includes the phk's update to make which corrects the -j behaviour. In 4.x and 5.x, every submake will spawn up to n tasks (n being the number provided with -j), and a buildworld -j4 in UP hardware easily produces a 2 digits system load. That's not more the case with 6.x (if I'm not wrong), in my test buildworld -j4 puts the load right near 4. So I hope you have other ways to test the new ATA, as make buildworld might not more be the monster it used to be. Angelo Turetta From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 14:23:28 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 79CE116A41F for ; Fri, 22 Jul 2005 14:23:28 +0000 (GMT) (envelope-from jendries@pragmeta.com) Received: from mx2.pragmeta.com (mx2.pragmeta.com [216.230.164.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1C9EE43D45 for ; Fri, 22 Jul 2005 14:23:27 +0000 (GMT) (envelope-from jendries@pragmeta.com) Received: from [192.168.0.138] (host-64-246-146-151.ubr0.alb1.inoc.net [64.246.146.151]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.pragmeta.com (Postfix) with ESMTP id D14831DD15 for ; Fri, 22 Jul 2005 10:23:24 -0400 (EDT) Message-ID: <42E1005E.40100@pragmeta.com> Date: Fri, 22 Jul 2005 10:19:10 -0400 From: Josh Endries User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050405) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: ATA and SATA problems (timeouts/resetting) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 14:23:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey everyone, I hope this goes through. For some reason I get bounces saying it can't reverse my IP, though I see no problems. I'm having major issues getting FreeBSD to install on a server. It's been a couple weeks now and nothing I've tried has helped. The server in question used to be running 4-STABLE until I upgraded it to 5-STABLE, which is when I started getting ATAPI errors: ata1-master FAILURE - ATAPI_IDENTIFY timed out The only ATA/IDE device plugged in is a CD-ROM, which was in secondary master position when this error happened. I've moved it around and nothing helps, it just changes the source of the problem (ata0-master, etc.). The system also has a 3ware SATA RAID PCI card in it, twa0, which it is booting from. Both the system BIOS and 3ware firmware is fresh. After three of the above errors it gives up I guess and then I get these: twa0: Request timed out! twa0: Resetting controller twa0: INFO: 0x04 0x005e Cache synchronized after power fail twa0: INFO: 0x04 0x0001 Controller reset occurred twa0: Controller reset done! I get the same thing with the latest 6 ISO (beta 1?). I have an almost identical system that is working just fine with 5-STABLE. The only difference is that machine has a LSI MegaRAID SCSI card also. I had these problems initially with that machine, but they just disappeared and it's running/rebooting fine, which worries me a bit. I think I booted into safe mode and cvsuped, custom kernel, and it started working, but I tried that with the new machine (same kernel config file) and it didn't have the same effect. I've scoured through the BIOSes and they're set up identically. It isn't sporadic either, I get the errors every single time, just after the "timecounters tick at 1msec" line (or whatever it is, I forget). Anyway I found some into online about mkIII patches and applied those and now I just get different errors. I don't remember specifically what they were, I can reinstall again and get them, but it was similar, timeout setting transferrate (or tranfer mode), then it said "danger will robinson" and started mixing in the above twa0 errors. Booting normally doesn't work at all, neither does single-user mode. The only way I can get in (to use and/or initially install) is using safe mode. I added an option to the menu Safer Mode to try and find out what difference was causing it but tried with/without the ATA/DMA, APIC, and ACPI lines individually and it didn't change anything. I've tried GENERIC and SMP (they are DP machines) and various kernel changes, stripping it bare, disabling DMS and ACPI in /boot/loader.conf...nothing helped. I turned off DMA in the BIOS, changed the transfer speed (PIO, standard, etc.) and just about every other thing I could think of. I just successfully installed 4.11 and it boots fine, no errors whatsoever. I was wondering if it's a hardware problem, but everything seems to run fine on the other 5.x machine (after the problems went away :/) and this 4.x one, so I'm not sure. Anyone have any ideas what I can do to troubleshoot or (hopefully) fix this? I'd much rather run 5 on it than 4, but if all else fails I guess I'm stuck with what works. Thanks, Josh -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC4QBeV/+PyAj2L+IRAtmgAJ4s68SSJQjQtxQTzL+/gi2FN4Qm1gCeM0oN 2LBqpERB6cOpZCbWMG2+crQ= =wTZf -----END PGP SIGNATURE----- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 15:18:57 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3757F16A427 for ; Fri, 22 Jul 2005 15:18:57 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id E117243D6A for ; Fri, 22 Jul 2005 15:18:27 +0000 (GMT) (envelope-from swhetzel@gmail.com) Received: by wproxy.gmail.com with SMTP id 55so398280wri for ; Fri, 22 Jul 2005 08:18:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PoHyEWan+dgZGrzenI9g5yVQlvxHvYHK+T2sxYv4d8sz80gD+EDcwWrKUIKaTysoZFZZiSgLQ/LcduC+M2/GN0CLXqlHTHNjsja9iBq0MGUNCfCkR6Ik/wgcrN8BlKa4SmfraYz87NP0Mpp2BmJ5HLOix9kRujz61qrRdGy9HjA= Received: by 10.54.53.74 with SMTP id b74mr1247231wra; Fri, 22 Jul 2005 08:17:45 -0700 (PDT) Received: by 10.54.29.26 with HTTP; Fri, 22 Jul 2005 08:17:45 -0700 (PDT) Message-ID: <790a9fff050722081716ad1a21@mail.gmail.com> Date: Fri, 22 Jul 2005 10:17:45 -0500 From: Scot Hetzel To: freebsd-stable@freebsd.org In-Reply-To: <20050722001253.GA70277@FS.denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> <20050722004340.H16902@fledge.watson.org> <20050722001253.GA70277@FS.denninger.net> Cc: karl@denninger.net Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Scot Hetzel List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 15:18:57 -0000 Just to clarify the ATA code that is in FreeBSD 5.x is ATA-ng, the ATA code that is in FreeBSD 6.x+ is the ATA mkIII code. ATA-ng Preview1 http://lists.freebsd.org/mailman/htdig/freebsd-current/2003-August/00835= 1.html ATA-ng Preview2 http://lists.freebsd.org/mailman/htdig/freebsd-current/2003-August/00873= 6.html If you want to ensure that the ATA mkIII code works for your systems, you need to apply the patches that Soren had provided to your FreeBSD 5.x system. If you are still having problems with it, then let Soren know so he can fix the problems. You can get the ATA mkIII patches from here: http://people.freebsd.org/~sos/ATA/ Scot --=20 DISCLAIMER: No electrons were mamed while sending this message. Only slightly bruised. From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 16:53:48 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18A6916A420 for ; Fri, 22 Jul 2005 16:53:48 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: from mail27.sea5.speakeasy.net (mail27.sea5.speakeasy.net [69.17.117.29]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7E01E44187 for ; Fri, 22 Jul 2005 16:28:27 +0000 (GMT) (envelope-from mi+mx@aldan.algebra.com) Received: (qmail 19425 invoked from network); 22 Jul 2005 16:28:26 -0000 Received: from aldan.algebra.com ([216.254.65.224]) (envelope-sender ) by mail27.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 22 Jul 2005 16:28:24 -0000 Received: from corbulon.video-collage.com (static-151-204-231-237.bos.east.verizon.net [151.204.231.237]) by aldan.algebra.com (8.13.1/8.13.1) with ESMTP id j6MGSG4d097344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Jul 2005 12:28:21 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (195-11.customer.cloud9.net [168.100.195.11]) by corbulon.video-collage.com (8.13.4/8.13.1) with ESMTP id j6MGSA2p039297 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Jul 2005 12:28:11 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from mteterin.us.murex.com (mteterin@localhost [127.0.0.1]) by mteterin.us.murex.com (8.13.3/8.13.3) with ESMTP id j6MGS4no076848; Fri, 22 Jul 2005 12:28:04 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) Received: from localhost (localhost [[UNIX: localhost]]) by mteterin.us.murex.com (8.13.3/8.13.3/Submit) id j6MGS3pC076847; Fri, 22 Jul 2005 12:28:03 -0400 (EDT) (envelope-from mi+mx@aldan.algebra.com) X-Authentication-Warning: mteterin.us.murex.com: mteterin set sender to mi+mx@aldan.algebra.com using -f From: Mikhail Teterin Organization: Virtual Estates, Inc. To: John-Mark Gurney Date: Fri, 22 Jul 2005 12:28:03 -0400 User-Agent: KMail/1.8.1 References: <200507200419.j6K4Jpgd083006@blue.virtual-estates.net> <20050720053432.GA62369@funkthat.com> In-Reply-To: <20050720053432.GA62369@funkthat.com> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-u" Content-Transfer-Encoding: 8bit Content-Disposition: inline Message-Id: <200507221228.03573.mi+mx@aldan.algebra.com> X-Virus-Scanned: ClamAV devel-20050525/987/Thu Jul 21 10:57:41 2005 on corbulon.video-collage.com X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.43 Cc: amd64@freebsd.org, stable@freebsd.org Subject: Re: OS suddenly VERY busy X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 16:53:48 -0000 ÓÅÒÅÄÁ 20 ÌÉÐÅÎØ 2005 01:34, John-Mark Gurney ÷É ÎÁÐÉÓÁÌÉ: > > This is a single-CPU Opteron running: > > > > ššššššFreeBSD 5.4-STABLE #0: Fri Jun 10 09:11:30 EDT 2005 amd64 > > > > The box has 2Gb of RAM, but NO SWAP. > run ps lax a few times, and notice which process is fork bombing your > box by seeing which process has the most changing children... If found the culprit, and it was not fork bombing. It was vlc (multimedia/vlc-devel), that was not supposed to do anything. On the list of interrupts I posted originally, observe the 40 to 50 irqs/sec on pcm. Once I told vlc to exit, the system returned back to normal... Does not seem right :-( -mi From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 17:17:49 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC68B16A41F for ; Fri, 22 Jul 2005 17:17:49 +0000 (GMT) (envelope-from pertti.kosunen@pp.nic.fi) Received: from gw01.mail.saunalahti.fi (gw01.mail.saunalahti.fi [195.197.172.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51A1744B95 for ; Fri, 22 Jul 2005 17:17:48 +0000 (GMT) (envelope-from pertti.kosunen@pp.nic.fi) Received: from [62.142.71.181] (KMMLXXXI.dsl.saunalahti.fi [62.142.71.181]) by gw01.mail.saunalahti.fi (Postfix) with ESMTP id 0179BF0EAC for ; Fri, 22 Jul 2005 20:17:46 +0300 (EEST) Message-ID: <42E12A3B.8040804@pp.nic.fi> Date: Fri, 22 Jul 2005 20:17:47 +0300 From: Pertti Kosunen User-Agent: Mozilla Thunderbird 1.0.2 / FreeBSD 5.4-STABLE X-Accept-Language: en-us, en MIME-Version: 1.0 To: "freebsd-stable@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: dhclient: send_packet: No buffer space available X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 17:17:49 -0000 What could cause dhclient sometimes to fail renew the lease? I updated world and moved to pf from ipfw same time so i don't know which to blame. This happens from twice a day to every few days. Jul 21 03:44:55 myserver dhclient: send_packet: No buffer space available Jul 21 03:44:55 myserver dhclient: send_packet: No buffer space available Jul 21 03:45:02 myserver dhclient: New IP Address (xl0): x.x.x.x Jul 21 03:45:02 myserver dhclient: New Subnet Mask (xl0): 255.255.254.0 Jul 21 03:45:02 myserver dhclient: New Broadcast Address (xl0): x.x.x.x Jul 21 03:45:02 myserver dhclient: New Routers: x.x.x.x Pf.conf & dmesg: http://www.saunalahti.fi/~pkosunen/pf.conf http://www.saunalahti.fi/~pkosunen/dmesg From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 18:41:58 2005 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3124916A43D; Fri, 22 Jul 2005 18:41:58 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0292344EBE; Fri, 22 Jul 2005 18:06:28 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.11] (junior.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j6MIGMU1047133; Fri, 22 Jul 2005 12:16:23 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42E135AE.4090207@samsco.org> Date: Fri, 22 Jul 2005 12:06:38 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050615 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stable@freebsd.org, current@freebsd.org Content-Type: multipart/mixed; boundary="------------080004040504090205090707" X-Spam-Status: No, score=-1.0 required=3.8 tests=ALL_TRUSTED,DOMAIN_4U2 autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: Subject: FreeBSD Status Report Second Quarter 2005 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 18:41:59 -0000 This is a multi-part message in MIME format. --------------080004040504090205090707 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit --------------080004040504090205090707 Content-Type: text/plain; name="report.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="report.txt" March-June 2005 Status Report Introduction The second quarter of 2005 has again been very exciting. The BSDCan and MeetBSD conferences were both very interesting and and the sources of very good times. I highly recommend attending them again next year. The Google Summer of Code project has also generated quite a bit of excitement. FreeBSD has been granted 18 funded mentorship spots, the fourth most of all of participating organizations. Projects being worked on range from UFS Journalling to porting the new BSDInstaller to redesigning the venerable www.FreeBSD.org website. We are quite pleased to be working with so many talented students, and eagerly await the results of their work. More information and status can be found at the Wiki site at http://wikitest.freebsd.org/moin.cgi/SummerOfCode2005. The FreeBSD 6.0 release cycle is also starting up. The purpose of quickly jumping from 5.x to 6.0 is to reduce the amount of transition pain that most users and developers felt when switching from 4-STABLE to 5.x. 6.0 will feature improved performance and stability over 5.x, experimental PowerPC support, and many new WiFi/802.11 features. The 5.x series will continue for at least one more release this fall, and will then be supported by the security team for at least 2 years after that. We encourage everyone to give the 6.0-BETA snapshots a try and help us make it ready for production. We hope to release FreeBSD 6.0 by the end of August. Thanks again to everyone who submitted reports, and thanks to Max Laier for running the show and putting the reports together. Enjoy reading! _________________________________________________________________ Google summer of code * FreeBSD Summer of Code * FreeBSD website improvements * FreeSBIE toolkit integration * gjournal * gvinum 'move', 'rename' * Improve libalias * Integrate the BSD Installer into FreeBSD * launchd(8) for FreeBSD * Network Interface API Cleanup * Nsswitch / Caching daemon * SEBSD * UFSJ -- Journaling for UFS Projects * Fundraising - TCP & IP Routing Optimization * GEOM Gate rewrite * TODO list for volunteers * VFS SMP Documentation * The FreeBSD Dutch Documentation Project Kernel * Autotuning of the page queue coloring algorithm * CPU Cache Prefetching * libmemstat(3), UMA(9) and malloc(9) statistics * Low-overhead performance monitoring for FreeBSD * Removable interface improvements * SMP Network Stack * Transparent support for superpages in the FreeBSD Kernel * TrustedBSD Audit Network infrastructure * Dingo * if_bridge * IPv6 Support for IPFW * Move ARP out of routing table * TCP Reassembly Rewrite and Optimization * TTCPv2: Transactional TCP version 2 * Wireless Networking Support Userland programs * OpenBSD dhclient import. * Removing of old basesystem files and directories Architectures * PowerPC Port Ports * FreshPorts * Porting v9 of Intels C/C++ Compiler * Update of the Linux userland infrastructure Vendor / 3rd Party Software * OpenBSD packet filter - pf Miscellaneous * BSDCan * EuroBSDCon 2005 - Basel * FreeBSD Security Officer and Security Team * TrustedBSD SEBSD _________________________________________________________________ Autotuning of the page queue coloring algorithm URL: http://www.Leidinger.net/FreeBSD/current-patches/pq.diff Contact: Alexander Leidinger The VM subsystem has code to reduce the amount of cache collisions of VM pages. Currently this code needs to be tuned with a kernel option. I have a patch which changes this to auto-tuning at boot time. The auto-tuning is MI, the cache size detection is MD. Cache size detection is currently available for x86/amd64 (on other systems it uses default values). Open tasks: 1. Add cache-detection code for other arches too (Marius told me how to do this for sparc64). 2. Analyze why the cache detection on Athlons doesn't work (no problems on a P4, but it uses a different code-path). _________________________________________________________________ BSDCan URL: http://www.bsdcan.org/2005/ Contact: Dan Langille The second annual BSDCan conference was well presented, well attended, and everyone went away with good stories to tell. If you know anything that attended, get them to tell you what they did, who they met with, and talks they listened to. We had 197 people from 15 different countries. That's a strong turnout by any definition. We'll be adding more people to the program committee for BSDCan 2006. This job involves prodding and poking people from your respective projects. You get them to submit papers. There are a lot of very interesting projects out there and not all of them submit a paper. If you know someone doing interesting work, please let me know and urge them to start thinking about BSDCan 2006. _________________________________________________________________ CPU Cache Prefetching URL: http://people.freebsd.org/~andre/tcpoptimization.html URL: http://www.nrg4u.com/freebsd/tcp_reass+prefetch-20041216.patch Contact: Andre Oppermann Modern CPU's can only perform to their maximum if their working code is in fast L1-3 cache memory instead of the bulk main memory. All of today's CPU's support certain L1-3 cache prefetching instructions which cause data to be retrieved from main memory to the cache ahead of the time that it is already in place when it is eventually accessed by the CPU. CPU Cache Prefetching however is not a silver bullet and has to be used with extreme care and only in very specific places to be beneficial. Incorrect usage can lead to massive cache pollution and a drop in effective performance. Correct and very carefully usage on the other can lead to drastic performance increases in common operations. In the linked patch CPU cache prefetching has been used to prefetch the packet header (OSI layer 2 to 4) into the CPU caches right after entering into the network stack. This avoids a complete CPU stall on the first access to the packet header because packets get DMA'd into main memory and thus never are already pre-cache in the CPU caches. A second use in the patch is in the TCP input code to prefetch the entire struct tcpcb which is very large and used with a very high probability. Use in both of these places show a very significant performance gain but not yet fully quantified. The final patch will include documentation and a guide to evaluate and assess the use of CPU cache prefetch instructions in the kernel. Open tasks: 1. Need funding, see "Fundraising - TCP & IP Routing Optimization". _________________________________________________________________ Dingo URL: http://www.freebsd.org/projects/dingo/ Contact: Several <> Currently trying to restart bits of the project. Cleaning up the p4 branch. Recently more people have volunteered to help as well. Brooks Davis has completed removing the ifnet from the softc. Open tasks: 1. See the web page. _________________________________________________________________ EuroBSDCon 2005 - Basel URL: http://www.eurobsdcon.org/ URL: http://www.eurobsdcon.org/cfp.php Contact: Information The fourth European BSD conference in Basel, Switzerland is a great opportunity to present new ideas to the community and to meet some of the developers behind the different BSDs. The two day conference program (Nov 26 and 27) will be complemented by a tutorial day preceeding the conference (Nov 25). The program committee is looking for tutorial and paper submissions. For details, please see: The call for papers online. _________________________________________________________________ FreeBSD Security Officer and Security Team URL: http://www.freebsd.org/security/ URL: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/contributors/st= aff-listing.html#STAFF-SECTEAM URL: http://vuxml.freebsd.org/ Contact: Security Officer Contact: Security Team In May 2005, Remko Lodder joined the FreeBSD Security Team, followed by Christian S.J. Peron in July 2005. In the same time period, Gregory Shapiro and Josef El-Rayes resigned from the team in order to devote their time to other projects. The current Security Team membership is published on the web site. In the time since the last FreeBSD status report, twelve security advisories have been issued concerning problems in the base system of FreeBSD; of these, six problems were in "contributed" code, while five problems were in code maintained within FreeBSD. The Vulnerabilities and Exposures Markup Language (VuXML) document has continued to be updated by the Security Team and the Ports Committers documenting new vulnerabilities in the FreeBSD Ports Collection; since the last status report, 97 new entries have been added, bringing the total up to 519. The following FreeBSD releases are supported by the FreeBSD Security Team: FreeBSD 4.10, FreeBSD 4.11, FreeBSD 5.3, and FreeBSD 5.4. Their respective End of Life dates are listed on the web site. _________________________________________________________________ FreeBSD Summer of Code URL: http://wikitest.freebsd.org/moin.cgi/SummerOfCode2005 Contact: Summer of Code Mentors Google has generously funded 18 students to spend the summer working on FreeBSD related projects. Each student is working with one or more mentors to learn about how open source software development is done with FreeBSD. This development work is happening in the Perforce repository as //depot/projects/soc2005. This tree will soon be exported via CVSup -- check the Wiki for more information. _________________________________________________________________ FreeBSD website improvements Contact: Emily Boyd As part of the Google Summer of Code, I'm working on improvements to the FreeBSD website (including a proposed website redesign). My mentor for this project is Murray Stokely. _________________________________________________________________ FreeSBIE toolkit integration URL: http://www.freesbie.org URL: http://wikitest.freebsd.org/moin.cgi/DarioFreni Contact: Dario Freni My Summer of Code project is reengineering and rewrite of FreeSBIE toolkit, in order to include it in the source tree. Let's call it FreeSBIE 2 Before being accepted, I worked hard on the FreeSBIE 1 toolkit to make it more flexible. It now supports amd64 and powerpc architecture. The built filesystem can now boot from almost every media, from dvd to compact flash or hard disk. Also on i386 is possible to include the BSD Installer on the livefs. We've received reports that our toolkit is successfully used for install cd of pfSense and PC-BSD projects. My future goals are to make the toolkit even more flexible, capable to build embedded images (like nanoBSD) or big Live-DVD systems, depending on user's choice, to support all the architectures supported by FreeBSD and to write a set of tools for making a netboot server with a FreeSBIE image. _________________________________________________________________ FreshPorts URL: http://www.freshports.org/ Contact: Dan Langille The following new features have been added to FreshPorts: * Deprecated Ports * Expired Ports * Ports Set To Expire * Display relevent entries from ports/UPDATING on your watch list Open tasks: 1. I've noticed that FreshPorts is incorrectly reporting vulnerabilities under a ver y specific situation . The fix is sitting in BETA, waiting to be moved to production. 2. I've been working on added Last-Modified to the headers. At present, there are none. Most of the pages on the BETA website have been completed. I need to move this to production soon. 3. Customized news feeds are in the works. You'll be able to create a news feed for each of your watch lists This work is contingent upon finishing the Last-Modified headers. _________________________________________________________________ Fundraising - TCP & IP Routing Optimization URL: http://people.freebsd.org/~andre/tcpoptimization.html Contact: Andre Oppermann The TCP code in FreeBSD has evolved significantly since the fork from 4.4BSD-Lite2 in 1994 primarily due to new features and refinements of the TCP specifications. The TCP code now needs a general overhaul, streamlining and cleanup to make it easily comprehensible, maintainable and extensible again. In addition there are many little optimizations that can be done during such an operation, propelling FreeBSD back at the top of the best performing TCP/IP stacks again, a position it has held for the longest time in the 90's. This overhaul is a very involved and delicate matter and needs extensive formal and actual testing to ensure no regressions compared to the current code. The effort needed for this work is about three man-month of fully focused and dedicated time. To get it done I need funding to take time off my day job and to dedicate me to FreeBSD work much the way PHK did with his buffer cache and vnode rework projects. I've got the opportunity to work up to three man-month exclusively full-time on FreeBSD during the second half of 2005. That means up to 720 hours of full-steam coding (at 60 hours/week)! I will work as much time as the fundraise provides. I need to raise enough money for each month from donations from the FreeBSD community to cover my fixed cost of living, office and associated overhead. These fixed cost amount to US$6,300/month (EUR5,200 or CHF8,000). Yes, Switzerland is not the cheapest place to live. :) A detailed description of the tasks involved and the code I will write is on my FreeBSD website; Follow the link above. Open tasks: 1. Raise enough money to get all the almost finished TCP and IP code into the tree. _________________________________________________________________ GEOM Gate rewrite URL: http://cvsweb.freebsd.org/src/sys/geom/gate/ URL: http://cvsweb.freebsd.org/src/sbin/ggate/ Contact: Pawel Jakub Dawidek GGATE is a machinism for exporting storage devices over the network. It was reimplemented to be much faster and to handle network failures better. The ggatec uses two threads now: sendtd, which takes I/O request from the kernel and sends it to ggated; recvtd, which receives finished requests and forwards them to the kernel. The ggated uses three threads: recvtd, which receives I/O requests from ggatec; disktd, which executes I/O requests (reads or writes data); sendtd, which sends finished requests to ggatec. The new ggate has been committed to 6.x. The work was sponsored by Wheel Sp. z o.o. _________________________________________________________________ gjournal URL: http://wikitest.freebsd.org/moin.cgi/gjournal Contact: Ivan Voras The schedule (as stated on the wiki page) is honoured, which means that the development has started, but there's not enough code for testing. Many details have been thought-out and the development is ongoing. _________________________________________________________________ gvinum 'move', 'rename' URL: http://wikitest.freebsd.org/moin.cgi/GvinumMoveRename Contact: Chris Jones With the releases of FreeBSD 5.3 and 5.4, FreeBSD has been moving away from "old-style" vinum towards GEOM-enabled gvinum for logical volume management. While gvinum is a mostly feature-complete replacement for vinum, it does not implement the 'move' or 'rename' verbs which are rather useful when reorganizing one's volume layout, the alternative being a tedious process of deleting and recreating subdisks, plexes, or volumes. Additionally, gvinum is nearly completely undocumented, which contributes to the perception of gvinum as an unfinished project. I'm working on implementing 'move' (being able to move a subdisk from one drive to another) and 'rename' (being able to rename an subdisk, plex, volume, or drive), as well as on documentation for gvinum. So far, I've come up with a plan of attack with le@ and phk@, and implemented the bulk of the userland code for gvinum 'move' and 'rename'. Still to come are the kernel-side code and documentation. Open tasks: 1. 'move' and 'rename' userland implementation 2. 'move' and 'rename' kernel-side implementation 3. Outline new handbook section and man page 4. Implement new handbook section and man page _________________________________________________________________ if_bridge Contact: Andrew Thompson This was committed to current on 5 Jun 2005 and will first appear in the 6.0 release, thanks to everyone who tested. Recent improvements include: * IPFW layer2 filtering * DUMMYNET support * IP header alignment checking There is ongoing work to bring in some of the advanced features from OpenBSD such as IPSec bridging. People are encouraged to use if_bridge and report any problems to the mailing lists. _________________________________________________________________ Improve libalias URL: http://wikitest.freebsd.org/moin.cgi/PaoloPisati Contact: Paolo Pisati My SoC project is about improving libalias and integrating it with ipfw2, adding nat support into the firewall. Till now i ported libalias (as a kld) and ng_nat to 4.x and 5.x branches, and i've already a first working patchset that adds 'nat' action into ipfw. Next step will be to add a complete syntax to ipfw that will let us manipulate libalias operations, much like we already do with queue and pipes for dummynet. In the end the entire work will compile and work out of the box for 4.x, 5.x and 6.x. More details about the project and its status are available on wiki page. _________________________________________________________________ Integrate the BSD Installer into FreeBSD URL: http://www.bsdinstaller.org URL: http://wikitest.freebsd.org/moin.cgi/BSDInstaller URL: http://perforce.freebsd.org/depotTreeBrowser.cgi?FSPC=//depot/projects /soc2005/bsdinstaller Contact: Andrew Turner Progress towards integrating the BSD Installer for Google's Summer of Code is coming along nicely. The installation CD will boot to multi-user mode and run both the front and back ends. It can then partition a hard drive, install the base distribution and make the disk bootable. Open tasks: 1. Test in non-i386 2. Investigate installing from other media 3. Many more tasks _________________________________________________________________ IPv6 Support for IPFW Contact: Max Laier Contact: Brooks Davis At the developer summit before BSDCan it was decided to remove IP6FW from the tree as it has a couple of problems. The most pressing one is the lack of synchronization and thus the need for debug.mpsafenet=0. As a replacement Brooks Davis has imported patches to teach the existing and well-locked IPFW2 code about IPv6. Since the initial import I have added some features required to manage IPv4 and IPv6 in a single ruleset. I have also extended existing opcodes to work with IPv6. There are, however, still some opcodes that do not work with IPv6 and most of the more exotic ones haven't been tested. As long as IPFW2+v6 does not provide enough functionality and stability to work as a drop-in replacement for IP6FW, we won't remove IP6FW. In order to get the new code to that point we really need more testers with real world IPv6 deployment and interest in IPFW+v6. The lack thereof (I haven't received a single answer on my requests to various FreeBSD mailing lists) has made it hard to progress. Open tasks: 1. Properly implement O_REJECT for IPv6 2. Maybe implement O_LOG 3. Test new(er) IPFW2 opcodes with IPv6 4. Test 5. Test 6. Test _________________________________________________________________ launchd(8) for FreeBSD URL: http://wikitest.freebsd.org/moin.cgi/launchd URL: http://developer.apple.com/documentation/Darwin/Reference/ManPages/man 8/launchd.8.html Contact: R. Tyler Ballance So far progress has been slow, the autoconf build system has been removed from all of the launchd(8) code, and launchctl(1) is building and semi-functional on FreeBSD-CURRENT (i.e. CoreFoundation hooks have been removed) I'm currently working on porting "liblaunch" which is the core backend to both launchd(8) (the actual daemon) and launchctl(1), there are some mach/xnu specific hooks and calls that need to be remove and either reimplemented or worked around. We're also waiting on a response from Apple on a possible BSD-licensed version of the code (it's currently under the APSL) Progress is slow, but steady. _________________________________________________________________ libmemstat(3), UMA(9) and malloc(9) statistics URL: http://www.watson.org/~robert/freebsd/libmemstat/ Contact: Robert Watson libmemstat(3) provides a user space library API to monitor kernel memory allocators, currently uma(9) and malloc(9), with the following benefits: * ABI-robust interface making use of accessor functions, in order to divorce monitoring applications from kernel/user ABI changes. * Allocator-independent interfaces, allowing monitoring of multiple allocators using the same interface. * CPU-cache awareness, allowing tracking of memory use across multiple CPUs for allocators aware of caches. Unlike previous interfaces, libmemstat(3) coalesces per-CPU stats in user space rather than kernel, and exposes per-CPU stats to interested applications. * Ability to track memory types over multiple queries, and update existing structures, allowing easy tracking of statistics over time. libmemstat(3) and the the appropriate allocator changes for uma(9) and malloc(9) are currently in HEAD (7-CURRENT), and MFC has been approved to RELENG_6 for inclusion in 6.0-RELEASE. These changes may also be backported to 5.x. Sample applications include memstat(8), an allocator-independent statistics viewing tool, memtop(8), which provides a top(1)-like interface for monitoring kernel memory use and active memory types. None of these are "pretty". netstat -mb has also been updated to use libmemstat(3) to track network memory use using uma(9), rather than the less reliable mbuf allocator statistics interface. As a result, the statistics are now more reliable on SMP systems (this corrects the bug in which mbuf statistics sometimes "leaked", even though memory didn't), and more informative (cache information is now displayed, as well as mbuf tag information). Open tasks: 1. Teach libmemstat(3) to speak libkvm(3) in order to allow tools linked -lmemstat to interogate kernel core dumps. 2. Teach libmemstat(3) to interface with user space malloc and track malloc allocations for user space applications. 3. Update vmstat(8) -m and -z implementations to use libmemstat(3) instead of the old monitoring interfaces. Code to do this exists in the sample libmemstat(3) applications. 4. Identify how to make streams or the library endian-aware so that streams dumped from a kernel of alternative endian could be processed using libmemstat(3) on another system. 5. Identify any remaining caching allocators in the kernel, such as the sfbuf allocator, and teach libmemstat(3) how to interface with them. _________________________________________________________________ Low-overhead performance monitoring for FreeBSD URL: http://people.freebsd.org/~jkoshy/projects/perf-measurement Contact: Joseph Koshy Modern CPUs have on-chip performance monitoring counters (PMCs) that may be used to count low-level hardware events like instruction retirals, branch mispredictions, and cache misses. PMC architectures and capabilities vary between CPU vendors and between CPU generations from the same vendor, making the creation of portable applications difficult. This project implements a cross-platform PMC management API for applications, and implements the infrastructure to "virtualize" and manage these PMCs. The creation of performance analysis tools that use this infrastructure is also part of the project's goals. Work since the last status report: * Sampling mode support for P4 and AMD64 PMCs has been implemented. * A pmclog(3) API for parsing hwpmc(4) log files has been added. * A number of bugs in libpmc(3), hwpmc(4) and pmcstat(8) have been fixed. Future work: * Creating user documentation showing a few real-world uses of the currently available tools. * Testing, improving the stability of the code, and characterizing its overheads. * Implementing P5 PMC support. _________________________________________________________________ Move ARP out of routing table URL: http://people.freebsd.org/~qingli/ Contact: Qing Li I've sent the patch to jinmei@isl.rdc.toshiba.co.jp @KAME for review. I'm still waiting for feedback from Andre. There hasn't been any major change since the last report. I've kept the code in sync with CURRENT. Gleb has created a separate P4 branch and has been helping out on the locking side. Gleb is also helping out on the testing front. Open tasks: 1. I'm waiting for review feedback from my mentor Andre on the overall design and code. I'm waiting for feedback from Andre on Gleb's suggested modification. _________________________________________________________________ Network Interface API Cleanup URL: http://wikitest.freebsd.org/moin.cgi/CleanupOfNetworkIterfaceApis Contact: Anders Persson The goal of this project is to review the network interface API and try to remove references to kernel-only data structures by removing the use of libkvm and instead rely on other interfaces to provide information. If there are no adequate interfaces, they would be created. Currently netstat is being reviewed and parts of it have been modified to use sysctl rather than libkvm to provide the information. A big thank you to Brooks Davis for mentoring :-) _________________________________________________________________ Nsswitch / Caching daemon URL: http://wikitest.freebsd.org/moin.cgi/NsswitchAndCachingTechnicalDetail s URL: http://wikitest.freebsd.org/moin.cgi/MichaelBushkov Contact: Michael Bushkov The nsswitch / caching daemon project is being developed within the Google's Summer Of Code program. The first goal of this project is to implement a set of patches to extend the use of nsswitch subsystem. The second goal is the development of the caching library and daemon to add the caching ability to the nsswitch. Currently services, protocols, rpc and openssh patches are finished. Support for services, services_compat, rpc, protocols, and ssh_host_keys databases is added with 'files', 'nis' and 'compat' (for services) sources possible. The nsswitch-friendly openssh port is amlost completed. Open tasks: 1. Implement set of patches to make nsswitch support globus grid security files , MAC and audit related configuration files databases. 2. Implement the caching library and the caching daemon and patch nsdispatch function to support caching. _________________________________________________________________ OpenBSD dhclient import. Contact: Brooks Davis Contact: Sam Leffler The OpenBSD rewrite of dhclient has been imported, replacing the ISC dhclient. The OpenBSD client provides better support for roaming on wireless networks and a simpler model of operation. Instead of a single dhclient process per system, there is on per network interface. This instance automatically goes away in the even of link loss and is restarted via devd when link is reacquired. To support this change, many aspects of the network interface configuration process were overhauled. The current code works well in most circumstances, but more testing and polishing is needed. _________________________________________________________________ OpenBSD packet filter - pf Contact: Max Laier We will have pf as of OpenBSD 3.7 for RELENG_6. Import has been completed in early May and FreeBSD release 6.0 will ship with it. A few serious issues with pfsync on SMP have been discovered since CARP is around and more and more people use it on big iron. Everything that has been discovered is fixed in HEAD and (if applicable) MFCed back to RELENG_5. Some functional changes are undergoing testing right now and will be MFCed in the coming days. With the import of if_bridge from Net/OpenBSD we finally have a bridge implementation that allows for stateful filtering as well as IPv6 filtering. Please see the respective report. Open tasks: 1. Shared lock implementation? _________________________________________________________________ Porting v9 of Intels C/C++ Compiler Contact: Alexander Leidinger Intel released version 9 of its C/C++ compiler. Work to port the x86 version to FreeBSD is in progress as time permits. Porting the EM64T (amd64) version is on the TODO list too, but is subject to enough free time and access to appropriate hardware. _________________________________________________________________ PowerPC Port URL: http://www.freebsd.org/platforms/ppc.html Contact: Peter Grehan Florent Thoumie has updated the massively out-of-date platform page. Work continues to creating a 6.0 release of the PowerPC port. _________________________________________________________________ Removable interface improvements URL: http://people.freebsd.org/~brooks/pubs/eurobsdcon2004/ URL: http://www.freebsd.org/projects/dingo/ Contact: Brooks Davis This project is an attempt to clean up handling of network interfaces in order to allow interfaces to be removed reliably. Current problems include panics if Dummynet is delaying packets to an interface when it is removed. I have removed struct ifnet's and layer two common structures from device driver structures. This will eventually allow them to be managed properly upon device removal. This code has been committed and will appear in 6.0. Popular drivers have generally been fixed, but more testing is needed. _________________________________________________________________ Removing of old basesystem files and directories URL: http://www.Leidinger.net/FreeBSD/current-patches/obsolete_removal.diff Contact: Alexander Leidinger FreeBSD lacks a way to remove old/outdated files and directories in the basesystem. I have a patch which removes obsolete files in a safe way (interactively, since only the administrator really knows if there's a need to keed an old file or not; there's a switch for batch-processing). This feature may or may not be available for 6.0-RELEASE, depending on the decission from the Release Engineering team. Open tasks: 1. Respect the NO_* switches and remove those files too. This is easy to do with the current implementation, but isn't needed to commit the removal of obsolete files feature. _________________________________________________________________ SEBSD URL: http://wikitest.freebsd.org/moin.cgi/YanjunWu Contact: Yanjun Wu 1. Setup a local P4 workspace of sebsd source and Setup lxr for TrustedBSD source for studying source code. 2. Test a simple policy configuration for vsftpd. 3. Writing a HOWTO document Getting Started with SEBSD HOWTO by deriving the existing Getting Started with SELinux HOWTO . Thanks Robert Watson and Scott Long for their kind help. Open tasks: 1. When writing the document, try to figure out the sebsd userland utils that need to be ported. 2. Test and edit more policies for BSD environment. _________________________________________________________________ SMP Network Stack URL: http://www.FreeBSD.org/projects/netperf/ Contact: Robert Watson Significant work has occurred over the last few months relating to the SMP network stack work. A few of the highlights are covered here at a high level: * The UMA(9) per-CPU caches have been modified to use critical sections instead of mutexes. Recent critical section optimizations make this a performance win for both UP and SMP systems. This results in a several percent improvement in a number of user space benchmarks, and larger improvement for kernel-only network forwarding and processing benchmarks. * The malloc(9) allocator has been modified to store statistics per-CPU instead of using a cross-CPU statistics pool, with each per-CPU pool now using critical sections to synchronize access. This results in a measurable performance win, especially on SMP systems * The netnatm ATM code is now MPSAFE. * netipx MPSAFEty has been merged to RELENG_5. * The netperf cluster has now been expanded to include two additional quad-CPU systems (one dual dual-core AMD system, one quad-CPU PIII system). * libmemsetat(3) (see separate report) now corrects SMP-related races in the measuring of mbuf allocator statistics, as well as substantially improving kernel memory monitoring capabilities and tools. * A range of locking bug fixes, and general network stack bug fixes. * Significant updates to the SMPng web page (still more to do!). * Identification of all non-MPSAFE network device drivers, with ultimatum issued, on freebsd-arch. Quite a bit of new driver locking work as a result (if_ed, if_de, ...). * Lots of other stuff. In most cases, these changes will appear in FreeBSD 6.0-RELEASE; some have been, or will be, merged to FreeBSD 5.x. On-going tasks include: * Review and improvement of ifnet locking, such as address lists and flags. * Optimization of interface start hand-off. * Prototyping of queue-oriented packet hand-off in the stack. * Performance measurement and analysis. * Prototype rewrite and simplification of socket locking. _________________________________________________________________ TCP Reassembly Rewrite and Optimization URL: http://people.freebsd.org/~andre/tcpoptimization.html URL: http://www.nrg4u.com/freebsd/tcp_reass-20041213.patch URL: http://lists.freebsd.org/pipermail/freebsd-net/2004-December/005918.ht ml Contact: Andre Oppermann Currently TCP segment reassembly is implemented as a linked list of segments. With today's high bandwidth links and large bandwidth*delay products this doesn't scale and perform well. The rewrite optimizes a large number of operational aspects of the segments reassembly process. For example it is very likely that the just arrived segment attaches to the end of the reassembly queue, so we check that first. Second we check if it is the missing segment or alternatively attaches to the start of the reassembly queue. Third consecutive segments are merged together (logically) and are skipped over in one jump for linear searches instead of each segment at a time. Further optimizations prototyped merge consecutive segments on the mbuf level instead of only logically. This is expected to give another significant performance gain. The new reassembly queue is tracking all holes in the queue and it may be beneficial to integrate this with the scratch pad of SACK in the future. Andrew Gallatin was able to get 3.7Gb/sec TCP performance on dual-2Gbit Myrinet cards with severe packet reordering (due to a firmware bug) with the new TCP reassembly code. See second link. Open tasks: 1. Need funding, see "Fundraising - TCP & IP Routing Optimization". _________________________________________________________________ The FreeBSD Dutch Documentation Project URL: http://www.freebsd.org/doc/nl/books/handbook URL: http://www.evilcoder.org/content/section/6/39/ URL: http://www.evilcoder.org/freebsd_html/ URL: http://www.evilcoder.org/freebsd/flyer.pdf Contact: Remko Lodder Contact: Siebrand Mazeland Contact: Rene Ladan The FreeBSD Dutch Documentation Project is a ongoing project in translating the english documentation to the Dutch language. Currently we are almost done with the FreeBSD Handbook. Finishing the Handbook is our first priority, and we could use your help. Please contact Siebrand or myself if you want to helpout. After the handbook we will focus on other documents as well, so feel free to help us there as well Open tasks: 1. FreeBSD Handbook translation. Finish the translation from English to Dutch 2. FreeBSD Handbook review. Finish the review of the translated documents 3. FreeBSD Articles. Start translating the articles from English to the Dutch Language 4. FreeBSD www. Start translating the website from English to the Dutch Language 5. The rest of the FreeBSD Documents. Start translating them from English to the Dutch Language. _________________________________________________________________ TODO list for volunteers Contact: Alexander Leidinger Since Google's "Summer of Code" resulted in a lot of interest in open projects, I'm in the process of compiling a list of nice projects for volunteers. Unlike Google's SoC those projects aren't backed with money (but this doesn't means nobody is allowed to sponsor one of those projects), so we can only guarantee the social aspects (some "Thank you!" and "That's great!" messages). So far the list has several entries where the difficulty ranges from "someone just has to sit down and spend some time on it" up to "we need a guru for this". Open tasks: 1. Merging untaken entries from the SoC list as soon as the official participants/tasks in the SoC are announced. 2. Sending the document to some doc people for review. 3. Commit the list. _________________________________________________________________ Transparent support for superpages in the FreeBSD Kernel Contact: Alan L. Cox Contact: Olivier Crameri We are currently working on an updated implementation of Juan Navarro's transparent support for superpages in FreeBSD The idea is to take advantage of the architectural support for big memory pages (superpages) by using a reservation mechanism allowing us to transparently promote groups of base pages into superpages and demote superpages into several smaller superpages or base pages. The advantage of using superpages vs. base pages is to significantly improve the TLB coverage of the physical memory, thus improving the peformance by reducing the number of TLB misses. The modification of the FreeBSD kernel that we are working on involves the replacement of the current list based page allocation mechanism with a system using a buddy allocator to reserve groups of pages for a memory object. The promotion and demotion of the pages occur directly within the pmap module. The former implementation was supporting the alpha and IA64 architectures. We are adding the support for amd64. We currently have an almost complete implementation. Once completed we will make a performance study with a particular emphasis on TLB and cache misses. _________________________________________________________________ TrustedBSD Audit URL: http://www.trustedbsd.org/components.html#audit Contact: Robert Watson Contact: Wayne Salamon Contact: In the past few months, significant work has been done relating to the TrustedBSD audit implementation, including preparatory work to merge audit into the FreeBSD CVS repository for FreeBSD 6.x. In particular: * The user space components, such as libbsm, include files, and command line utilities have been broken out into an OpenBSM distribution in Perforce. Improvements in OpenBSM will be made available separately for use by projects such as Darwin, and imported into the contrib area of FreeBSD. * The system call table format has been updated to include an audit event identifier for each system call across all hardware platforms and ABIs (merged), and all system calls have been assigned event identifiers (not yet merged). * The audit management daemon has been rewritten to run on FreeBSD (originally derived from Darwin) using /dev/audit to track kernel events. * Many system calls now properly audit their arguments. * The TrustedBSD audit3 branch has been updated to a recent 6.x-CURRENT. * Significant work has gone into synchronizing the audit event tables between FreeBSD, Darwin, and OpenSolaris to make sure file formats and events are portable. * OpenBSM has been adapted to consume and generate endian-independent event streams. * OpenBSM documentation has been created. The hope is still to provide audit as "experimental" in 6.0; the primary blocking factor is our awaiting relicensing of the last remaining audit files from Apple's APSL license to BSDL so that they can be included in the FreeBSD kernel. This is anticipated to complete in the near future. Once this is done, the changes can be merged to CVS, and then MFC'd to RELENG_6. If this is not complete by 6.0-RELEASE, the work will be merged shortly after the release, as all ABI-sensitive data structures have been updated as needed. _________________________________________________________________ TrustedBSD SEBSD URL: http://www.TrustedBSD.org/sebsd.html Contact: Robert Watson The TrustedBSD Project has released a new snapshot of "SEBSD", a port of NSA's SELinux FLASK and Type Enforcement implementation to FreeBSD based on a late 2005 FreeBSD 6.x snapshot. The SEBSD distribution has now been updated in Perforce to a recent 6.x snapshot, and a new distribution will be made available in the near future. Work has been performed to merge additional dependencies for SEBSD back into the base FreeBSD tree, including most recently, changes to devfs, and System V and POSIX IPC. Open tasks: 1. Update to new NSA FLASK implementation, which has improved MLS support. 2. Merge remaining kernel changes to support SEBSD back to the base FreeBSD CVS repository, including file descriptor labeling and access control (in contrast to file labeling and access control), and categorization of kernel privileges. _________________________________________________________________ TTCPv2: Transactional TCP version 2 URL: http://people.freebsd.org/~andre/tcpoptimization.html URL: http://lists.freebsd.org/pipermail/cvs-all/2004-November/089939.html Contact: Andre Oppermann The old TTCP according to RFC1644 was insecure, intrusive, complicated and has been removed from FreeBSD >= 5.3. Although the idea and semantics behind it are still sound and valid. The rewrite uses a much easier and more secure system with 24bit long client and server cookies which are transported in the TCP options. Client cookies protect against various kinds of blind injection attacks and can be used as well to generally secure TCP sessions (for BGP for example). Server cookies are only exchanged during the SYN-SYN/ACK phase and allow a server to ensure that it has communicated with this particular client before. The first connection is always performing a 3WHS and assigning a server cookie to a client. Subsequent connections can send the cookie back to the server and short-cut the 3WHS to SYN->OPEN on the server. TTCPv2 is fully configurable per-socket via the setsockopt() system call. Clients and server not capable of TTCPv2 remain fully compatible and just continue using the normal 3WHS without any delay or other complications. Work on implementing TTCPv2 is done to 90% and expected to be available by early February 2005. Writing the implementation specification (RFC Draft) has just started. Open tasks: 1. Need funding, see "Fundraising - TCP & IP Routing Optimization". _________________________________________________________________ UFSJ -- Journaling for UFS Contact: Brian Wilson Contact: Scott Long filesystem. Journaling helps ensure the filesystem's integrity should the system crash. Journaling eliminates the need for fsck'ing a filesystem, as the filesystem is never in an inconsistent state (barring hardware failure). This implementation is inspired by Darwin's HFS+ filesystem and the SGI XFS filesystem. This is a Summer of Code project, with Scott Long as the mentor and Brian Wilson as the developer/mentee. Currently this project is still in the early stages, but will be in a usable state by September 1 (the Google Summer of Code completion date). Open tasks: 1. Finish making the file system log metadata updates. 2. Add facilities to replay the log on dirty file systems. 3. Make snapshots work with journaling. _________________________________________________________________ Update of the Linux userland infrastructure Contact: Alexander Leidinger Contact: Emulation Mailinglist The cleanup/streamlining and the possibility of overriding the default Linux base as reported in the last report happened without major problems. Work on the open tasks hasn't started yet, but is scheduled to start "soon". If a volunteer wants to spend some hours on one of the open tasks, he should tell it on the emulation mailinglist. Open tasks: 1. Refactoring the common RPM code in x11-toolkits/linux-gtk/Makefile into bsd.rpm.mk. 2. Determining which up-to-date Linux distribution to use as the next default Linux base. Important criteria: + RPM based (to be able to use the existing infrastructure) + good track record regarding availability of security fixes + packages available from several mirror sites + available for several hardware architectures (e.g. i386, amd64, sparc64; Note: not all architectures have a working linuxolator for their native bit with, but as long as there are no userland bits available, no motivation regarding writing the kernel bits will arise) 3. Moving the linuxolator userland to an up-to-date version (see above). _________________________________________________________________ VFS SMP Contact: Jeff Roberson FreeBSD's VFS layer has been fine grain locked along with the FFS filesystem for the FreeBSD 6.0 release. The locking has been underway for several years, with the project really picking up over the last 6 months thanks largely to sponsorship provided by Isilon Systems, Inc. a leading vendor of clustered storage systems. The project has entered a stabilization phase, with a few bugs being reported in extreme circumstances while the majority of users have seen no problems. Tests on a 8 and 16 way machines yield reasonable parallelization, however, it will be beneficial to do lock contention analysis once things are fully stable. For those interested in technical details, there have been a few relatively significant changes with vnode life-cycle management. Vnode reference counting and recycling is now no longer an ad-hoc process involving a variety of flags, a use count and the hold count. A single hold count is used to track all vnode references and a destroyed vnode is freed in the context of the caller when the last ref is lost. The old system would never reclaim memory used by vnodes and also had pathlogical behavior with unreferenced vnode caching under pressure. The new system is much simpler than the old one, however, callers are now required to vhold a vnode that they lock directly without going through vget to prevent it from being recycled while they are waiting on a lock. Relying on 'location stable storage', which is a more strict version of 'type stable storage' is no longer a valid approach. Some other side effects include a much simpler and faster nullfs implementation, an improved buf daemon flushing algorithm which eliminated high latency that caused audio skipping, and a lots of minor cleanups and debugging aids. _________________________________________________________________ Wireless Networking Support Contact: Sam Leffler A lot of bugs were fixed in preparation for the 6.0 release. 6.0 will be the first release to include full WPA support (both supplicant and authenticator). A presentation on the forthcoming multi-bss support was given at BSDCan 2005. The slides from the talk are available at http://www.freebsd.org/~sam/BSDCan2005.pdf . The plan is to commit this work to HEAD after 6.0 is released which means the first release that will have it is 7.0. Open tasks: 1. hostapd needs work to support the IAPP and 802.11i preauthentication protocols (these are simple conversions of existing Linux code). _________________________________________________________________ --------------080004040504090205090707-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 19:40:12 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F29B416A41F for ; Fri, 22 Jul 2005 19:40:11 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 310E043D49 for ; Fri, 22 Jul 2005 19:40:10 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6MJe9ED095768 for ; Fri, 22 Jul 2005 14:40:10 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Fri Jul 22 14:40:09 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6MJe90U095766 for freebsd-stable@freebsd.org; Fri, 22 Jul 2005 14:40:09 -0500 (CDT) (envelope-from karl) Date: Fri, 22 Jul 2005 14:40:09 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050722194009.GA95692@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> <20050722004340.H16902@fledge.watson.org> <20050722001253.GA70277@FS.denninger.net> <20050722013605.U16902@fledge.watson.org> <20050722010611.GA72234@FS.denninger.net> <42E0F93E.7000108@commit.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42E0F93E.7000108@commit.it> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: make -j as a stress test (was: Re: Quality of FreeBSD) [WARNING - 6.0-BETA1 still hosed!] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 19:40:12 -0000 It is definitely NOT fixed in 6.0-BETA1 Within SECONDS of starting a buildworld after the provider rebuild completed, I got this... GEOM_MIRROR: Device boot: provider ad4s1 detected. GEOM_MIRROR: Device boot: rebuilding provider ad4s1. GEOM_MIRROR: Device boot: provider ad6s1 detected. GEOM_MIRROR: Device boot: rebuilding provider ad6s1. GEOM_MIRROR: Device boot: rebuilding provider ad4s1 finished. GEOM_MIRROR: Device boot: provider ad4s1 activated. GEOM_MIRROR: Device boot: rebuilding provider ad6s1 finished. GEOM_MIRROR: Device boot: provider ad6s1 activated. subdisk4: detached ad4: detached unknown: FAILURE - SETFEATURES SET TRANSFER MODE timed out unknown: timeout waiting to issue command unknown: error issueing SETFEATURES SET TRANSFER MODE command GEOM_MIRROR: Device boot: provider ad4s1 disconnected. GEOM_MIRROR: Request failed (error=6). ad4s1[READ(offset=35096543232, length=10240)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35463411712, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35467393024, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35501357056, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35501551616, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35501553664, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35502305280, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35502583808, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35502764032, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35648684032, length=16384)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35705600000, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35840983040, length=16384)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35840999424, length=16384)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35848910848, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35854632960, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35866456064, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=36226842624, length=16384)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=36226859008, length=16384)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=36233115648, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=36234352640, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=36234868736, length=2048)] GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=36274173952, length=2048)] unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! DANGER Will Robinson !! This is significantly WORSE than 5.3-RELEASE in that it appears not only to detach the disk, but then to go on to whine mightily about other things (I have no idea whether I've taken a data corruption hit at this point or not.) That didn't take long to verify.... -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind On Fri, Jul 22, 2005 at 03:48:46PM +0200, Angelo Turetta wrote: > Karl Denninger wrote: > >As I pointed out in my PR, "make -j4 buildworld" is more than sufficient > >to demonstrate the problem. > ( ... ) > >I'll pull over 6.0-BETA1, rebuild the array (that is the time-consuming > >part of this test - takes 6-8 hours for the rebuild to run) and see if it > >fails during a buildworld. > > Maybe I'm wrong, but in my tests I had the impression that RELENG_6 > includes the phk's update to make which corrects the -j behaviour. > > In 4.x and 5.x, every submake will spawn up to n tasks (n being the > number provided with -j), and a buildworld -j4 in UP hardware easily > produces a 2 digits system load. > > That's not more the case with 6.x (if I'm not wrong), in my test > buildworld -j4 puts the load right near 4. > > So I hope you have other ways to test the new ATA, as make buildworld > might not more be the monster it used to be. > > Angelo Turetta > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" > > > %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 19:44:44 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9123B16A41F for ; Fri, 22 Jul 2005 19:44:44 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (pop.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 817F043D48 for ; Fri, 22 Jul 2005 19:44:43 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 22 Jul 2005 19:44:42 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp032) with SMTP; 22 Jul 2005 21:44:42 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-stable@freebsd.org Date: Fri, 22 Jul 2005 21:44:22 +0200 User-Agent: KMail/1.8.1 References: <200507212006.j6LK68RO037136@drjekyll.mkbuelow.net> In-Reply-To: <200507212006.j6LK68RO037136@drjekyll.mkbuelow.net> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart10130128.AHysfYeH06"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507222144.30804@harrymail> X-Y-GMX-Trusted: 0 Cc: Matthias Buelow , pcasidy@casidy.com Subject: Re: Quality of FreeBSD X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 19:44:44 -0000 --nextPart10130128.AHysfYeH06 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Donnerstag, 21. Juli 2005 22:06 CEST schrieb Matthias Buelow: > pcasidy@casidy.com writes: > >My main problem, and to others after seeing the question from times to > >times, is to know which is a good (not necessarly the best) hardware to > >run FreeBSD on? > >When I buy a new motherboard, which chipset to choose/avoid, which > > controllers ? > > Maybe some website like it is being done for notebooks (with > Linux/FreeBSD support) would be in order. I'm thinking about something > like http://www.linux-laptop.net/, only for FreeBSD and all kinds of > machines, not just notebooks. (Or, if some collaboration would be ok, > for *BSD in general, with people posting experience from NetBSD, > OpenBSD, Dragonfly, even Darwin aswell. That way one could also compare > support for hardware and see what problems the individual systems have.) > > Make it a Wiki, or something similar, where people can freely post > experiences they have with their hardware. That could be whole machines > (Dell model xxx desktop, IBM yyy laptop, HP zzz server) aswell as > components (Asus blah motherboard, 3Com wlan card model foobar, etc.) > and make the thing searchable, and perhaps allow one to post comments on > entries (easy with a Wiki). That way people can quickly search & review > hardware, awell as test suggested workarounds by the posters, without > having to google for obscured mailing list entries, or problem reports. Well, there are numerous great FreeBSD sites out there which assist in such= =20 question, but I also like the idea of a purely hardware database site. If nobody want's to extend his site I'd offer to start a new one, I have=20 spare capacity in both, my servers (if they go online, in some days I=20 hope) and my leased line, so I'd be glad to contribute something. If anybody with wiki-experience wants to step in, you're welcome, I'm not=20 the big webmaster... Maybe Eric Anderson wants to contribute his bsdhardware.org domain, or we=20 could name it hardware.freebsd.org I'll be back when I have something online. Best regards, =2DHarry --nextPart10130128.AHysfYeH06 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC4UyeBylq0S4AzzwRAmrNAKCGWDUoWCozcOQihTlgoIz793IQFQCdELJw XtFSwhOUgfeMTRQRGWfBMDs= =2x5M -----END PGP SIGNATURE----- --nextPart10130128.AHysfYeH06-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 19:53:58 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B365C16A41F for ; Fri, 22 Jul 2005 19:53:58 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11C3443D46 for ; Fri, 22 Jul 2005 19:53:57 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6MJrvJj096048 for ; Fri, 22 Jul 2005 14:53:57 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Fri Jul 22 14:53:57 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6MJrvsB096046 for freebsd-stable@freebsd.org; Fri, 22 Jul 2005 14:53:57 -0500 (CDT) (envelope-from karl) Date: Fri, 22 Jul 2005 14:53:57 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050722195357.GB95692@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> <20050722004340.H16902@fledge.watson.org> <20050722001253.GA70277@FS.denninger.net> <20050722013605.U16902@fledge.watson.org> <20050722010611.GA72234@FS.denninger.net> <42E0F93E.7000108@commit.it> <20050722194009.GA95692@FS.denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050722194009.GA95692@FS.denninger.net> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: make -j as a stress test (was: Re: Quality of FreeBSD) [WARNING - 6.0-BETA1 still hosed!] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 19:53:58 -0000 On Fri, Jul 22, 2005 at 02:40:09PM -0500, Karl Denninger wrote: > It is definitely NOT fixed in 6.0-BETA1 > > Within SECONDS of starting a buildworld after the provider rebuild > completed, I got this... > > GEOM_MIRROR: Device boot: provider ad4s1 detected. > GEOM_MIRROR: Device boot: rebuilding provider ad4s1. > GEOM_MIRROR: Device boot: provider ad6s1 detected. > GEOM_MIRROR: Device boot: rebuilding provider ad6s1. > GEOM_MIRROR: Device boot: rebuilding provider ad4s1 finished. > GEOM_MIRROR: Device boot: provider ad4s1 activated. > GEOM_MIRROR: Device boot: rebuilding provider ad6s1 finished. > GEOM_MIRROR: Device boot: provider ad6s1 activated. > subdisk4: detached > ad4: detached > unknown: FAILURE - SETFEATURES SET TRANSFER MODE timed out > unknown: timeout waiting to issue command > unknown: error issueing SETFEATURES SET TRANSFER MODE command > GEOM_MIRROR: Device boot: provider ad4s1 disconnected. > GEOM_MIRROR: Request failed (error=6). ad4s1[READ(offset=35096543232, > length=10240)] Note carefully from this that there is NO ERROR INDICATION AS TO WHY THE DISK DETACHED! At least with the 5.x problems you'd SEE an error before it went BOOM. This time around, nope - just death. What's worse, the complaints continue even through a shutdown, making any attempt to shutdown and reboot the machine futile. After waiting over 10 minutes for a shutdown to complete I had to resort to the use of the power switch. This is NOT good, because if you get hosed by this kind of thing you have no way out of it remotely. Thus, my contention is that 6.0-BETA1 is far than 5.x is in this regard. Be careful out there.... -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 20:06:28 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C819C16A41F for ; Fri, 22 Jul 2005 20:06:28 +0000 (GMT) (envelope-from bfoz@bfoz.net) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 48A2843D49 for ; Fri, 22 Jul 2005 20:06:27 +0000 (GMT) (envelope-from bfoz@bfoz.net) Received: from [192.168.0.5] (c-24-6-134-233.hsd1.ca.comcast.net[24.6.134.233]) by comcast.net (sccrmhc11) with ESMTP id <2005072220061701100kloi1e>; Fri, 22 Jul 2005 20:06:18 +0000 Message-ID: <42E151B4.7030500@bfoz.net> Date: Fri, 22 Jul 2005 13:06:12 -0700 From: Brandon Fosdick User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050721) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: SMP support maturity? AMD64x2 or FX-57? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 20:06:28 -0000 SMP support in FreeBSD seems to be a perpetually favorite feature to gripe about, but every release seems to say that its getting better. I'm about to build a new server and am trying to determine if I should go with dual procs or just a single. The AMD64x2 is slightly cheaper than the FX-57 so I'm leaning that way, but it would be a rather pointless savings if SMP isn't well supported. So, is SMP in -STABLE ready for primetime? Can it really make use of two processors? From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 20:27:38 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EE0516A41F for ; Fri, 22 Jul 2005 20:27:38 +0000 (GMT) (envelope-from frank@exit.com) Received: from tinker.exit.com (tinker.exit.com [206.223.0.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B1CA43D45 for ; Fri, 22 Jul 2005 20:27:38 +0000 (GMT) (envelope-from frank@exit.com) Received: from [206.223.0.5] (realtime [206.223.0.5]) by tinker.exit.com (8.13.3/8.13.3) with ESMTP id j6MKRf8H036170; Fri, 22 Jul 2005 13:27:42 -0700 (PDT) (envelope-from frank@exit.com) Message-ID: <42E156B2.1070004@exit.com> Date: Fri, 22 Jul 2005 13:27:30 -0700 From: Frank Mayhar User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050412) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Brandon Fosdick References: <42E151B4.7030500@bfoz.net> In-Reply-To: <42E151B4.7030500@bfoz.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.86.1/988/Fri Jul 22 05:29:55 2005 on tinker.exit.com X-Virus-Status: Clean Cc: freebsd-stable@freebsd.org Subject: Re: SMP support maturity? AMD64x2 or FX-57? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 20:27:38 -0000 Brandon Fosdick wrote: > SMP support in FreeBSD seems to be a perpetually favorite feature to > gripe about, but every release seems to say that its getting better. I'm > about to build a new server and am trying to determine if I should go > with dual procs or just a single. The AMD64x2 is slightly cheaper than > the FX-57 so I'm leaning that way, but it would be a rather pointless > savings if SMP isn't well supported. > So, is SMP in -STABLE ready for primetime? Can it really make use of two > processors? Sigh. You know, I've been running with two processors since 4.1 or thereabouts. Sure, the BGL scheme is inefficient as far as the kernel itself is concerned, but for compute-bound user processes it worked just fine. Naturally I avoided 5.0/1/2 for my production boxen, waiting for the complete overhaul of SMP to stabilize, but when I booted 5.3, everything was fine and I haven't looked back. Personally I don't have the first clue what people have found to gripe about. It has been good, it got a _lot_ better in 5.x, and it's continuing to improve. Ports to new processor families are an entirely different kettle of fish and have their own sets of problems, virtually all of which have to do with the new architecture and not with the general SMP support itself. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 20:43:48 2005 Return-Path: X-Original-To: stable@FreeBSD.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF80816A41F for ; Fri, 22 Jul 2005 20:43:47 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from ameno.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2621243D45 for ; Fri, 22 Jul 2005 20:43:46 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from kasuga.mahoroba.org (IDENT:djnyuIG8s3aTy8NmMy7ZDo2LslD/MXAIWCEVdcmChTdwd2Uj75hSLI4TcRxPohIn@kasuga.mahoroba.org [IPv6:3ffe:501:185b:8010:20b:97ff:fe2e:b521]) (user=ume mech=CRAM-MD5 bits=0) by ameno.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j6MKhhaL008708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 23 Jul 2005 05:43:43 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 23 Jul 2005 05:43:26 +0900 Message-ID: From: Hajimu UMEMOTO To: stable@FreeBSD.org References: <200507222017.j6MKHUId033267@repoman.freebsd.org> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd6.0) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 7.0-CURRENT X-PGP-Key: http://www.imasy.or.jp/~ume/publickey.asc X-PGP-Fingerprint: 1F00 0B9E 2164 70FC 6DC5 BF5F 04E9 F086 BF90 71FE Organization: Internet Mutual Aid Society, YOKOHAMA MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: multipart/mixed; boundary="Multipart_Sat_Jul_23_05:43:26_2005-1" X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sat, 23 Jul 2005 05:43:43 +0900 (JST) X-Virus-Scanned: ClamAV 0.86.1/988/Fri Jul 22 21:29:55 2005 on ameno.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-5.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org Cc: Subject: HEADS-UP: ABI compatibility of getaddrinfo(3) was lost. X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 20:43:48 -0000 --Multipart_Sat_Jul_23_05:43:26_2005-1 Content-Type: text/plain; charset=US-ASCII Hi, I've nuked the padding for ai_addrlen member of struct addrinfo on RELENG_6. It broke ABI compatibility of getaddrinfo(3) on 64 bit architecture. You have to recompile userland programs that use getaddrinfo(3) on 64 bit architecture. Sincerely, --Multipart_Sat_Jul_23_05:43:26_2005-1 Content-Type: message/rfc822 X-Sieve: CMU Sieve 2.2 Delivered-To: ume@freebsd.org X-Original-To: src-committers@FreeBSD.org Delivered-To: src-committers@FreeBSD.org Message-Id: <200507222017.j6MKHUId033267@repoman.freebsd.org> From: Hajimu UMEMOTO Date: Fri, 22 Jul 2005 20:17:30 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/include netdb.h src/lib/libc/net getaddrinfo.c X-FreeBSD-CVS-Branch: RELENG_6 Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-2.0 (ameno.mahoroba.org [218.45.22.175]); Sat, 23 Jul 2005 05:17:47 +0900 (JST) X-Virus-Scanned: ClamAV 0.86.1/988/Fri Jul 22 21:29:55 2005 on ameno.mahoroba.org X-Virus-Status: Clean X-Spam-Status: No, score=-5.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.0.4 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on ameno.mahoroba.org ume 2005-07-22 20:17:30 UTC FreeBSD src repository Modified files: (Branch: RELENG_6) include netdb.h lib/libc/net getaddrinfo.c Log: MFC: Remove padding for ABI compatibility of ai_addrlen member from struct addrinfo. This change break ABI compatibility on 64 bit arch. include/netdb.h: 1.39 lib/libc/net/getaddrinfo.c: 1.70 Approved by: re (kensmith) Revision Changes Path 1.38.2.1 +0 -19 src/include/netdb.h 1.69.2.1 +0 -3 src/lib/libc/net/getaddrinfo.c --Multipart_Sat_Jul_23_05:43:26_2005-1 Content-Type: text/plain; charset=US-ASCII -- Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan ume@mahoroba.org ume@{,jp.}FreeBSD.org http://www.imasy.org/~ume/ --Multipart_Sat_Jul_23_05:43:26_2005-1-- From owner-freebsd-stable@FreeBSD.ORG Fri Jul 22 21:33:16 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0348F16A41F for ; Fri, 22 Jul 2005 21:33:16 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from crumpet.united-ware.com (ddsl-66-42-172-210.fuse.net [66.42.172.210]) by mx1.FreeBSD.org (Postfix) with ESMTP id E6217443F2 for ; Fri, 22 Jul 2005 21:11:44 +0000 (GMT) (envelope-from mistry.7@osu.edu) Received: from [192.168.1.101] (ddsl-66-42-172-210.fuse.net [66.42.172.210]) (authenticated bits=0) by crumpet.united-ware.com (8.12.8p2/8.12.8) with ESMTP id j6ML8Kwj002899 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Fri, 22 Jul 2005 17:08:20 -0400 (EDT) (envelope-from mistry.7@osu.edu) From: Anish Mistry To: freebsd-stable@freebsd.org, Brandon Fosdick Date: Fri, 22 Jul 2005 17:11:04 -0400 User-Agent: KMail/1.8 References: <42E151B4.7030500@bfoz.net> In-Reply-To: <42E151B4.7030500@bfoz.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1492933.Dykjf673B7"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200507221711.12690.mistry.7@osu.edu> X-Spam-Status: No, hits=-1.5 required=5.0 tests=BAYES_99,MYFREEBSD2 autolearn=no version=2.64 X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on crumpet.united-ware.com Cc: Subject: Re: SMP support maturity? AMD64x2 or FX-57? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jul 2005 21:33:16 -0000 --nextPart1492933.Dykjf673B7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Friday 22 July 2005 04:06 pm, Brandon Fosdick wrote: > SMP support in FreeBSD seems to be a perpetually favorite feature > to gripe about, but every release seems to say that its getting > better. I'm about to build a new server and am trying to determine > if I should go with dual procs or just a single. The AMD64x2 is > slightly cheaper than the FX-57 so I'm leaning that way, but it > would be a rather pointless savings if SMP isn't well supported. > > So, is SMP in -STABLE ready for primetime? Can it really make use > of two processors? _______________________________________________ I'm running RELENG_6 on a dual processor Opteron in 64 bit mode and=20 it's working fine as long as I'm using the 4BSD scheduler. =2D-=20 Anish Mistry --nextPart1492933.Dykjf673B7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBC4WDwxqA5ziudZT0RAtEXAJ9Ma05EFPFrmZsSlPZao90goNHHVwCgu6Vn o031UtVuktPhyAoIrM+/zQY= =t0+3 -----END PGP SIGNATURE----- --nextPart1492933.Dykjf673B7-- From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 02:06:32 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 045FE16A41F for ; Sat, 23 Jul 2005 02:06:32 +0000 (GMT) (envelope-from ilbthere@comcast.net) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5B77843D58 for ; Sat, 23 Jul 2005 02:06:31 +0000 (GMT) (envelope-from ilbthere@comcast.net) Received: from pepe (c-24-99-149-73.hsd1.ga.comcast.net[24.99.149.73]) by comcast.net (sccrmhc11) with SMTP id <2005072302062901100kkg9ge>; Sat, 23 Jul 2005 02:06:29 +0000 From: "Ray Rogers" To: Date: Fri, 22 Jul 2005 22:06:27 -0400 Message-ID: <000001c58f2b$2438e000$1900a8c0@pepe> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: ATA issue on 5.4 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 02:06:32 -0000 Greetings all. I would appreciate any incite that you can give me with this problem. =20 I am sure that you have visited this issue in the past, but I have been unable to find a resolution. The symptoms are ad1: TIMEOUT - READ_DMA retrying (2 retries left) = LBA=3D10027551 ad0: WARNING - removed from configuration ad1: WARNING - removed from configuration ata0-slave: FAILURE - READ_DMA timed out =20 After these messages the machine is unusable until it is power cycled. =20 =20 The machine can is described by dmesg below, but here is some history. = The machine has been running FreeBSD 4.8 - 4.10 for the last several years = with two disks on the ATA0 controller. (ad0=3D Maxtor 51024H2 10GB, = ad1=3DWD400BB 40GB) =20 =20 I finally decided it was time to move to 5.x release. I also decided it = was time to upgrade the disks I used a Maxtor 20GB for ad0 and WD2500JB for = ad1. The Maxtor disk has been used before but the WD is brand new. =20 =20 The machine is a 733 MHz Compaq Deskpro EN (Intel 815e chipset with an = ICH 2 ata controller). I have turned off all power management functions in = the CMOS. I am currently running the GENERIC Kernel as taken from the 5.4 = ISO install. I upgraded to p4 but it did not help my situation so I backed = off. I have searched high and low and have found a suggestion of adding a = command to the /boot/loader.conf to no avail. I do not believe that the issue = is the ata controller, however, it could have to do with compatibility with = the 250GB WD drive with FreeBSD. I have not used the WD before but I have tested it with Western Digital's Data Lifeguard Diagnostics as it was installed in the box for both communication and media errors with no = errors found. =20 The issue seems to occur when the system has been idle for some time (an hour or so). =20 Below is my dmesg output. I do not want to reload 4.10 to have a = working system.=20 =20 Thanks for the help. =20 Ray =20 =20 Copyright (c) 1992-2005 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.4-RELEASE #0: Sun May 8 10:21:06 UTC 2005 root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel Pentium III (730.90-MHz 686-class CPU) Origin =3D "GenuineIntel" Id =3D 0x683 Stepping =3D 3 =20 Features=3D0x383fbff real memory =3D 535822336 (511 MB) avail memory =3D 514658304 (490 MB) MPTable: ioapic0: Changing APIC ID to 8 ioapic0: Assuming intbase of 0 ioapic0 irqs 0-23 on motherboard npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard pcib0: pcibus 0 on motherboard pci0: on pcib0 agp0: mem 0x40500000-0x4057ffff,0x44000000-0x47ffffff irq 16 at device 2.0 on pci0 pcib1: at device 30.0 on pci0 pci2: on pcib1 fxp0: port 0x1000-0x103f = mem 0x40100000-0x40100fff irq 20 at device 8.0 on pci2 miibus0: on fxp0 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp0: Ethernet address: 00:50:8b:d8:70:af fxp1: port 0x1040-0x107f mem 0x40000000-0x400fffff,0x40200000-0x40200fff irq 18 at device 9.0 on pci2 miibus1: on fxp1 inphy1: on miibus1 inphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fxp1: Ethernet address: 00:d0:b7:0f:a7:f4 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x2460-0x246f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: port = 0x2440-0x245f irq 23 at device 31.4 on pci0 usb0: on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pcm0: port 0x2400-0x243f,0x2000-0x20ff irq 17 at device 31.5 on pci0 pcm0: orm0: at iomem 0xe0000-0xeffff,0xcb000-0xd87ff,0xca000-0xcafff,0xc0000-0xc9fff on isa0 pmtimer0 on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 fdc0: at port 0x3f0-0x3f5 irq 6 drq 2 on = isa0 fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/13 bytes threshold ppbus0: on ppc0 plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=3D0x300> sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on = isa0 unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (irq) Timecounter "TSC" frequency 730899496 Hz quality 800 Timecounters tick every 10.000 msec ad0: 19092MB [38792/16/63] at ata0-master = UDMA100 ad1: 238475MB [484521/16/63] at = ata0-slave UDMA100 acd0: CDROM at ata1-master PIO4 pcm0: measured ac97 link rate at 55931 Hz Mounting root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /home was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /usr/local was not properly dismounted WARNING: /var was not properly dismounted =20 I=20 =20 From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 02:53:00 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F0F916A41F for ; Sat, 23 Jul 2005 02:53:00 +0000 (GMT) (envelope-from djh@nebcorp.com) Received: from ratchet.nebcorp.com (ratchet.nebcorp.com [205.217.153.72]) by mx1.FreeBSD.org (Postfix) with ESMTP id 502BF43D45 for ; Sat, 23 Jul 2005 02:53:00 +0000 (GMT) (envelope-from djh@nebcorp.com) Received: by ratchet.nebcorp.com (Postfix, from userid 1014) id 1D9E5D9823; Fri, 22 Jul 2005 19:53:00 -0700 (PDT) Date: Fri, 22 Jul 2005 19:53:00 -0700 From: Danny Howard To: freebsd-stable@freebsd.org Message-ID: <20050723025300.GY24353@ratchet.nebcorp.com> References: <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> <20050722004340.H16902@fledge.watson.org> <20050722001253.GA70277@FS.denninger.net> <20050722013605.U16902@fledge.watson.org> <20050722010611.GA72234@FS.denninger.net> <42E0F93E.7000108@commit.it> <20050722194009.GA95692@FS.denninger.net> <20050722195357.GB95692@FS.denninger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050722195357.GB95692@FS.denninger.net> User-Agent: Mutt/1.4.2.1i X-Loop: djhoward@uiuc.edu Subject: Re: make -j as a stress test (was: Re: Quality of FreeBSD) [WARNING - 6.0-BETA1 still hosed!] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 02:53:00 -0000 On Fri, Jul 22, 2005 at 02:53:57PM -0500, Karl Denninger wrote: [...] > Note carefully from this that there is NO ERROR INDICATION AS TO WHY THE > DISK DETACHED! > > At least with the 5.x problems you'd SEE an error before it went BOOM. > > This time around, nope - just death. > > What's worse, the complaints continue even through a shutdown ... While I agree with Karl that introducing instability is a very bad thing, I guess we now have an answer to Karl's vexation yesterday: [ http://lists.freebsd.org/pipermail/freebsd-stable/2005-July/017210.html ] "What I don't understand Robert is why Soren's code is "too sensitive" to commit, but the explosive reduction in stability that the changes made between 4.x and 5.3 caused weren't enough to back THAT out until it could be fixed." The answer would seem to be that when someone actually does test the untested code, it is even worse than the code we are already upset with. :) Love, -danny -- http://dannyman.toldme.com/ From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 02:53:06 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7FC0B16A425 for ; Sat, 23 Jul 2005 02:53:06 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: from mortis.over-yonder.net (adsl-19-148-33.jan.bellsouth.net [68.19.148.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2279243D46 for ; Sat, 23 Jul 2005 02:53:05 +0000 (GMT) (envelope-from fullermd@over-yonder.net) Received: by mortis.over-yonder.net (Postfix, from userid 100) id 52C5420FBA; Fri, 22 Jul 2005 21:53:04 -0500 (CDT) Date: Fri, 22 Jul 2005 21:53:03 -0500 From: "Matthew D. Fuller" To: Frank Mayhar Message-ID: <20050723025303.GE32805@over-yonder.net> References: <42E151B4.7030500@bfoz.net> <42E156B2.1070004@exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42E156B2.1070004@exit.com> X-Editor: vi X-OS: FreeBSD User-Agent: Mutt/1.5.9i-fullermd.2 Cc: Brandon Fosdick , freebsd-stable@freebsd.org Subject: Re: SMP support maturity? AMD64x2 or FX-57? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 02:53:06 -0000 On Fri, Jul 22, 2005 at 01:27:30PM -0700 I heard the voice of Frank Mayhar, and lo! it spake thus: > > Sigh. You know, I've been running with two processors since 4.1 or > thereabouts. Sure, the BGL scheme is inefficient as far as the > kernel itself is concerned, but for compute-bound user processes it > worked just fine. Naturally I avoided 5.0/1/2 for my production > boxen, waiting for the complete overhaul of SMP to stabilize, but > when I booted 5.3, everything was fine and I haven't looked back. This system (this one, right here, that I'm typing on) is dual processor, and I installed it fresh with 4-CURRENT just after RELENG_3 was branched. Except for an excursion on RELENG_5, it's always run -CURRENT. Sometimes I'd go a year without updating, sometimes a week. It's running -CURRENT from a couple weeks ago now. Sometimes it's a bit twitchy, but I think running X has a whole lot to do with that, since MP systems under heavier loads without X would do just peachy with the exact same build that was flaky here. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 04:16:47 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 776F616A41F for ; Sat, 23 Jul 2005 04:16:47 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from FS.denninger.net (wsip-68-15-213-52.at.at.cox.net [68.15.213.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6E18D43D48 for ; Sat, 23 Jul 2005 04:16:46 +0000 (GMT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net (localhost [127.0.0.1]) by FS.denninger.net (8.13.3/8.13.1) with SMTP id j6N4Gjpa002731 for ; Fri, 22 Jul 2005 23:16:45 -0500 (CDT) (envelope-from karl@FS.denninger.net) Received: from fs.denninger.net [127.0.0.1] by Spamblock-sys (LOCAL); Fri Jul 22 23:16:45 2005 Received: (from karl@localhost) by FS.denninger.net (8.13.3/8.13.1/Submit) id j6N4GiKs002729 for freebsd-stable@freebsd.org; Fri, 22 Jul 2005 23:16:44 -0500 (CDT) (envelope-from karl) Date: Fri, 22 Jul 2005 23:16:44 -0500 From: Karl Denninger To: freebsd-stable@freebsd.org Message-ID: <20050723041644.GA2607@FS.denninger.net> Mail-Followup-To: freebsd-stable@freebsd.org References: <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> <20050722004340.H16902@fledge.watson.org> <20050722001253.GA70277@FS.denninger.net> <20050722013605.U16902@fledge.watson.org> <20050722010611.GA72234@FS.denninger.net> <42E0F93E.7000108@commit.it> <20050722194009.GA95692@FS.denninger.net> <20050722195357.GB95692@FS.denninger.net> <20050723025300.GY24353@ratchet.nebcorp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050723025300.GY24353@ratchet.nebcorp.com> User-Agent: Mutt/1.4.2.1i Organization: Karl's Sushi and Packet Smashers X-Die-Spammers: Spammers cheerfully broiled for supper and served with ketchup! Subject: Re: make -j as a stress test (was: Re: Quality of FreeBSD) [WARNING - 6.0-BETA1 still hosed!] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 04:16:47 -0000 On Fri, Jul 22, 2005 at 07:53:00PM -0700, Danny Howard wrote: > On Fri, Jul 22, 2005 at 02:53:57PM -0500, Karl Denninger wrote: > [...] > > Note carefully from this that there is NO ERROR INDICATION AS TO WHY THE > > DISK DETACHED! > > > > At least with the 5.x problems you'd SEE an error before it went BOOM. > > > > This time around, nope - just death. > > > > What's worse, the complaints continue even through a shutdown ... > > While I agree with Karl that introducing instability is a very bad > thing, I guess we now have an answer to Karl's vexation yesterday: > [ http://lists.freebsd.org/pipermail/freebsd-stable/2005-July/017210.html ] > > "What I don't understand Robert is why Soren's code is "too > sensitive" to commit, but the explosive reduction in stability > that the changes made between 4.x and 5.3 caused weren't > enough to back THAT out until it could be fixed." > > The answer would seem to be that when someone actually does test the > untested code, it is even worse than the code we are already upset with. > :) > > Love, > -danny Point taken. Can we get a from the development team that 6.x will go out the door until this problem is identified and FIXED (e.g. the PR I submitted against this early in the year is closed)? The problem is trivially easy to reproduce, as I've pointed out. My hardware is hardly anything special - its a Dell Poweredge 400SC, a rather pedestrian 2.4Ghz P4/HT machine with 512MB of RAM and nothing special in terms of boards in it. Indeed, on the sandbox machine the ONLY cards in the machine are the Adaptec SATA card and a video board! The ICH SATA onboard adapter works fine. No problems, even if you beat the snot out of the disks. Ditto for the onboard PATA channels. ANY PCI SII-chipset SATA card (nothing fancy here, no onboard RAID, just a disk adapter) that I've tried thus far - Bustek or Adaptec - causes trouble in an absolutely reproducable fashion when put under heavy load. If both channels are in use the trouble is immediate and dramatic, although you CAN provoke errors even with only one of the two channels in operation if you can get the I/O load up high enough. Gmirror is great for provoking this as it queues traffic to both channels in a nicely balanced and heavily-utilized fashion, although I'm willing to bet that Gmirror itself is not involved as the actual cause of the problem, since I had trouble once DURING install (before I had put a gmirror'ed config on the disks.) Note that a MIX of read and writes appears to be required - a REBUILD of the disks by Gmirror (which is all writes to those two disks) succeeds. As soon as you have all three subdisks in the array, however, a "make buildworld" produces fireworks. If necessary (or useful) I can give one or more developers a way to log into the sandbox machine here via ssh. I do not have a way to get a serial console on the box, however, so if its blown up in an unrecoverable fashion remotely someone would have to call or IM me to push the big red button. If that's NOT necessary (or desired), then I want to move those two disks back to the production machine as they are how my offsite/offline backups are done - I've no problem with leaving them on the sandbox IF the problem is being actively worked though. -- -- Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist http://www.denninger.net My home on the net - links to everything I do! http://scubaforum.org Your UNCENSORED place to talk about DIVING! http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! http://genesis3.blogspot.com Musings Of A Sentient Mind From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 04:41:18 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E00B516A41F for ; Sat, 23 Jul 2005 04:41:18 +0000 (GMT) (envelope-from vinny@tellurian.com) Received: from mail1.tellurian.net (mail1.tellurian.net [216.182.1.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 684BD43D48 for ; Sat, 23 Jul 2005 04:41:18 +0000 (GMT) (envelope-from vinny@tellurian.com) Received: from leviathon.tellurian.com (leviathon.tellurian.net [216.182.41.250]) by mail1.tellurian.net ([216.182.1.23] Tellurian Networks Mail Server version 3.0d-2) with ESMTP id 247639775 for multiple; Sat, 23 Jul 2005 00:41:17 -0400 Message-Id: <6.2.3.4.2.20050723003957.05d7a938@pop3.tellurian.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.3.4 Date: Sat, 23 Jul 2005 00:42:17 -0400 To: Frank Mayhar From: Vinny Abello In-Reply-To: <42E156B2.1070004@exit.com> References: <42E151B4.7030500@bfoz.net> <42E156B2.1070004@exit.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: vinny@tellurian.com X-Ultimate-Internet-Connection: Tellurian Networks Cc: Brandon Fosdick , freebsd-stable@freebsd.org Subject: Re: SMP support maturity? AMD64x2 or FX-57? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 04:41:19 -0000 At 04:27 PM 7/22/2005, Frank Mayhar wrote: >Brandon Fosdick wrote: >>SMP support in FreeBSD seems to be a perpetually favorite feature >>to gripe about, but every release seems to say that its getting >>better. I'm about to build a new server and am trying to determine >>if I should go with dual procs or just a single. The AMD64x2 is >>slightly cheaper than the FX-57 so I'm leaning that way, but it >>would be a rather pointless savings if SMP isn't well supported. >>So, is SMP in -STABLE ready for primetime? Can it really make use >>of two processors? > >Sigh. You know, I've been running with two processors since 4.1 or >thereabouts. Sure, the BGL scheme is inefficient as far as the >kernel itself is concerned, but for compute-bound user processes it >worked just fine. Naturally I avoided 5.0/1/2 for my production >boxen, waiting for the complete overhaul of SMP to stabilize, but >when I booted 5.3, everything was fine and I haven't looked back. > >Personally I don't have the first clue what people have found to >gripe about. It has been good, it got a _lot_ better in 5.x, and >it's continuing to improve. > >Ports to new processor families are an entirely different kettle of >fish and have their own sets of problems, virtually all of which >have to do with the new architecture and not with the general SMP >support itself. >-- >Frank Mayhar frank@exit.com http://www.exit.com/ >Exit Consulting http://www.gpsclock.com/ > http://www.exit.com/blog/frank/ I agree. I'm not a FreeBSD expert by any means, but I do enjoy using it very much. I've learned a lot about it over the past year or so that I've been running it. I have both a 4.11 and 5.4 box that have dual processors and are running like champs. The 5.4 box is doing a lot more work actually, and it never has a problem. It's been all good for me, but then again, I probably don't delve quite as deeply into some of the complex heavy loaded things other do. Vinny Abello Network Engineer Server Management vinny@tellurian.com (973)300-9211 x 125 (973)940-6125 (Direct) PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A Tellurian Networks - The Ultimate Internet Connection http://www.tellurian.com (888)TELLURIAN "Courage is resistance to fear, mastery of fear - not absence of fear" -- Mark Twain From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 07:43:08 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3DCED16A420 for ; Sat, 23 Jul 2005 07:43:08 +0000 (GMT) (envelope-from rasputnik@hellooperator.net) Received: from mta08-winn.ispmail.ntl.com (mta08-winn.ispmail.ntl.com [81.103.221.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2F6443D53 for ; Sat, 23 Jul 2005 07:43:06 +0000 (GMT) (envelope-from rasputnik@hellooperator.net) Received: from aamta09-winn.ispmail.ntl.com ([81.103.221.35]) by mta08-winn.ispmail.ntl.com with ESMTP id <20050723074305.DIIK889.mta08-winn.ispmail.ntl.com@aamta09-winn.ispmail.ntl.com>; Sat, 23 Jul 2005 08:43:05 +0100 Received: from 9.hellooperator.net ([82.31.78.41]) by aamta09-winn.ispmail.ntl.com with ESMTP id <20050723074305.IDEZ19483.aamta09-winn.ispmail.ntl.com@9.hellooperator.net>; Sat, 23 Jul 2005 08:43:05 +0100 Received: from [10.4.0.5] (helo=eris.tenfour) by 9.hellooperator.net with esmtp (Exim 4.51) id 1DwEez-0003mP-AH; Sat, 23 Jul 2005 08:43:03 +0100 Received: from rasputnik by eris.tenfour with local (Exim 4.51 (FreeBSD)) id 1DwEez-000GbO-2j; Sat, 23 Jul 2005 08:43:01 +0100 Date: Sat, 23 Jul 2005 08:43:00 +0100 From: Dick Davies To: Dan Mack Message-ID: <20050723074300.GA49467@eris.tenfour> References: <42DFF582.1050406@unixforge.net> <20050721150151.R7966@coco.macktronics.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050721150151.R7966@coco.macktronics.com> User-Agent: mutt-ng devel (FreeBSD) Cc: FreeBSD Stable Users Subject: Re: Machine Replication X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Dick Davies List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 07:43:08 -0000 * Dan Mack [0705 21:05]: > Is there a jumpstart (solaris), kickstart (redhat linux), roboinst (irix), > or ignite (hpux) like auto-installer for BSD? > > If there was, then I wouldn't image the disk at all, I'd instead setup up custom network images that I could blast to any > system just by pxebooting it. I'm not sure if it is possible with FreeBSD though, anyone? http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pxe/article.html -- 'Make cheap but effective baby rattles by gluing a lollipop stick to an empty matchbox, then filling it with ten woodlice.' -- Ms. G. M. Dowd, Wigan. Rasputin :: Jack of All Trades - Master of Nuns From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 09:43:41 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E224E16A41F; Sat, 23 Jul 2005 09:43:41 +0000 (GMT) (envelope-from jack@raats.xs4all.nl) Received: from zeus.jarasoft.net (raats.xs4all.nl [80.126.151.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 796E943D46; Sat, 23 Jul 2005 09:43:41 +0000 (GMT) (envelope-from jack@raats.xs4all.nl) Received: from zeus.jarasoft.net (localhost.jarasoft.net [127.0.0.1]) by zeus.jarasoft.net (Postfix) with ESMTP id 7640EABF3; Sat, 23 Jul 2005 11:43:39 +0200 (CEST) Message-ID: <000e01c58f6b$20bc9670$9800000a@jara2> From: "Jack Raats" To: , "FreeBSD Stable" Date: Sat, 23 Jul 2005 11:44:30 +0200 Organization: Jack Raats MIME-Version: 1.0 X-Priority: 1 X-Virus-Scanned: ClamAV using ClamSMTP Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Trouble with PHP4-extensions X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jack Raats List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 09:43:42 -0000 I had installed Apache, PHP4.40 and imap on a FreeBSD 5.4-STABLE server. = It worked OK. I had to recompile IMAP and after this apache refuses to = start. I have to recompile the php4-imap part of php. How to do this? Deinstall php4 completely and then reinstall it or Can i use the extensions to recompile only a part? Met vriendelijke groeten Jack Raats From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 12:17:32 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2D97116A41F for ; Sat, 23 Jul 2005 12:17:32 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from mail.ticketswitch.com (mail.ticketswitch.com [194.200.93.188]) by mx1.FreeBSD.org (Postfix) with ESMTP id D09E443D46 for ; Sat, 23 Jul 2005 12:17:31 +0000 (GMT) (envelope-from petefrench@ticketswitch.com) Received: from [172.16.1.6] (helo=dilbert.firstcallgroup.co.uk) by mail.ticketswitch.com with esmtp (Exim 4.50 (FreeBSD)) id 1DwIwV-0001b3-0g; Sat, 23 Jul 2005 13:17:23 +0100 Received: from petefrench by dilbert.firstcallgroup.co.uk with local (Exim 4.50 (FreeBSD)) id 1DwIwU-0004Io-Su; Sat, 23 Jul 2005 13:17:22 +0100 To: bfoz@bfoz.net, freebsd-stable@freebsd.org In-Reply-To: <42E151B4.7030500@bfoz.net> Message-Id: From: Pete French Date: Sat, 23 Jul 2005 13:17:22 +0100 Cc: Subject: Re: SMP support maturity? AMD64x2 or FX-57? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 12:17:32 -0000 > if I should go with dual procs or just a single. The AMD64x2 is > slightly cheaper than the FX-57 so I'm leaning that way, but it > would be a rather pointless savings if SMP isn't well supported. Well, I've not triied it under amd64, but i386 SMP has been rock stable for me since I upgraded to 5.X, on both nyperthreaded machines and genuine SMP machines. Choosing one or two cores is, however, more a matter of what the box is going to be doing - if you are usually running one big compute job then a single faster core is better than two smaller ones. > So, is SMP in -STABLE ready for primetime? Can it really make use of two processors? Yes and yes. -pcf. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 13:58:17 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2AE5916A420 for ; Sat, 23 Jul 2005 13:58:17 +0000 (GMT) (envelope-from alexjeffburke@gmail.com) Received: from nproxy.gmail.com (nproxy.gmail.com [64.233.182.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF34B43D7F for ; Sat, 23 Jul 2005 13:58:03 +0000 (GMT) (envelope-from alexjeffburke@gmail.com) Received: by nproxy.gmail.com with SMTP id g2so73988nfe for ; Sat, 23 Jul 2005 06:58:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=cE7AoZbKRAMGfc23P1TGcwAWwqP/jPJKkAzIqW+vhP7u7X1ksPDO8/To/hr68XT3yaukqV7jyvknYCT5unmLeB5biT/GN2G3ZR0JbEnli2hZ3kVdV/nknvg3xq475diLKI+rq115wfmL60bI7xLMcL2Fz2Nfm0I24pZBWpB7vOw= Received: by 10.48.249.6 with SMTP id w6mr116550nfh; Sat, 23 Jul 2005 06:58:02 -0700 (PDT) Received: by 10.48.249.8 with HTTP; Sat, 23 Jul 2005 06:58:02 -0700 (PDT) Message-ID: Date: Sat, 23 Jul 2005 06:58:02 -0700 From: Alex Burke To: FreeBSD STABLE Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: FreeBSD 6.0BETA1 - Oddness with install floppies X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Alex Burke List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 13:58:17 -0000 Hi All, I was trying to boot a system from the installation floppies, and after the kernel booted it dropped me out into a mountroot prompt. I am posative its not meant to do this, it should start sysinstall. I am not exactly sure what to do from here on, should i specify ufs:da0s1a...would that be the location of the memory disk? Anyways, just thought I would ask/mention it to see if its me doing something odd or whether the disk needs some attention. Thanks in advance, Alex J Burke. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 14:11:46 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 45C3A16A41F for ; Sat, 23 Jul 2005 14:11:46 +0000 (GMT) (envelope-from mkb@incubus.de) Received: from luzifer.incubus.de (incubus.de [80.237.207.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id CBF2643D45 for ; Sat, 23 Jul 2005 14:11:45 +0000 (GMT) (envelope-from mkb@incubus.de) Received: from drjekyll.mkbuelow.net (p54AA866C.dip0.t-ipconnect.de [84.170.134.108]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by luzifer.incubus.de (Postfix) with ESMTP id 9748830E63; Sat, 23 Jul 2005 16:14:37 +0200 (CEST) Received: from drjekyll.mkbuelow.net (mkb@localhost.mkbuelow.net [127.0.0.1]) by drjekyll.mkbuelow.net (8.13.3/8.13.3) with ESMTP id j6NEBufR000828; Sat, 23 Jul 2005 16:11:56 +0200 (CEST) (envelope-from mkb@drjekyll.mkbuelow.net) Received: (from mkb@localhost) by drjekyll.mkbuelow.net (8.13.3/8.13.3/Submit) id j6NEBtVj000827; Sat, 23 Jul 2005 16:11:55 +0200 (CEST) (envelope-from mkb) Date: Sat, 23 Jul 2005 16:11:55 +0200 From: Matthias Buelow To: Alex Burke Message-ID: <20050723141155.GA706@drjekyll.mkbuelow.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: FreeBSD STABLE Subject: Re: FreeBSD 6.0BETA1 - Oddness with install floppies X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 14:11:46 -0000 Alex Burke wrote: >I was trying to boot a system from the installation floppies, and >after the kernel booted it dropped me out into a mountroot prompt. I >am posative its not meant to do this, it should start sysinstall. >I am not exactly sure what to do from here on, should i specify >ufs:da0s1a...would that be the location of the memory disk? There were no ATA timeout messages? Otherwise, this would indicate that the nasty ATA bugs are on 6.0 still. I have (on 5.4-stable) to try a boot several times until the kernel properly recognizes my drive, and it dumps me in the mount root prompt when it doesn't. mkb. From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 18:29:52 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07BF616A41F; Sat, 23 Jul 2005 18:29:51 +0000 (GMT) (envelope-from news649@powersystemsdirect.com) Received: from sccrmhc11.comcast.net (sccrmhc11.comcast.net [204.127.202.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B0CE43D46; Sat, 23 Jul 2005 18:29:51 +0000 (GMT) (envelope-from news649@powersystemsdirect.com) Received: from [192.168.1.6] (c-24-1-170-82.hsd1.tx.comcast.net[24.1.170.82]) by comcast.net (sccrmhc11) with ESMTP id <2005072318295001100lrsbre>; Sat, 23 Jul 2005 18:29:50 +0000 Message-ID: <42E28C9F.1060204@powersystemsdirect.com> Date: Sat, 23 Jul 2005 13:29:51 -0500 From: Steve User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <42DF2A8F.30202@powersystemsdirect.com> <20050721112230.A97888@fledge.watson.org> In-Reply-To: <20050721112230.A97888@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: READ_DMA, WRITE_DMA errors X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 18:29:52 -0000 Ok, I applied the ata mkiii patches onto my freebsd 5.4 on our least important machine that I was speaking of in my first email here, and, so far, for an hour, no read or write dma errors! Running udma now instead of pio4 which I had to use before. Massive speed difference of course. This is the VT8237 VT6410 SATA Raid Controller (not using raid) found on the asus a7v880 MB. So, count me in as saying the new ata mkiii patch is great! Looking forward to it even going into 5.5 if possible. Steve Robert Watson wrote: > > On Wed, 20 Jul 2005, Steve wrote: > >> I've found tons of emails, news messages, listserv messages, and even >> some bug reports of this seemingly common error. >> >> So, I had been running 5.2 on a server, and, updated to 5.3. Got the >> READ_DMA and WRITE_DMA error and retries. So, figuring it might be a >> bad update, took a new drive. put it in, loaded 5.4 for grins, and, >> same issue, lots of these errors, eventually destroying the FS. >> Played around with various settings, no avail. So, took it back, got >> different box, everything new. Same problem, new install of 5.4 > > > 6.0 contains a significant re-write and update of the ATA driver, and > corrects a number of known problems with timeouts and reliability. > This rewrite is available as patches against 5.x, but has not been > committed because ATA is a very sensitive thing (lots of very diverse > and very broken hardware), and has had insufficient testing. If you > have test hardware available that's not in production, it would be > quite helpful if you could install 6.0-BETA2, once that comes out in > the next week or so, and see if the specific ATA problems you're > experiencing occur there. It's not impossible that the new ATA code > will be merged to 5.x, but I think we cannot do that until it has seen > a lot more exposure. If you search back through the mailing archives, > you should be able to find posts from Soren regarding the new ATA > patches, if you want to give them a try on 5.x. > > Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 19:52:16 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 51F0116A4F3 for ; Sat, 23 Jul 2005 19:52:16 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBBE443D46 for ; Sat, 23 Jul 2005 19:52:15 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 3487D46B04; Sat, 23 Jul 2005 15:52:15 -0400 (EDT) Date: Sat, 23 Jul 2005 20:53:02 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Danny Howard In-Reply-To: <20050723025300.GY24353@ratchet.nebcorp.com> Message-ID: <20050723204434.B61837@fledge.watson.org> References: <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> <20050722004340.H16902@fledge.watson.org> <20050722001253.GA70277@FS.denninger.net> <20050722013605.U16902@fledge.watson.org> <20050722010611.GA72234@FS.denninger.net> <42E0F93E.7000108@commit.it> <20050722194009.GA95692@FS.denninger.net> <20050722195357.GB95692@FS.denninger.net> <20050723025300.GY24353@ratchet.nebcorp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: make -j as a stress test (was: Re: Quality of FreeBSD) [WARNING - 6.0-BETA1 still hosed!] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 19:52:16 -0000 On Fri, 22 Jul 2005, Danny Howard wrote: > While I agree with Karl that introducing instability is a very bad > thing, I guess we now have an answer to Karl's vexation yesterday: [ > http://lists.freebsd.org/pipermail/freebsd-stable/2005-July/017210.html > ] > > "What I don't understand Robert is why Soren's code is "too > sensitive" to commit, but the explosive reduction in stability > that the changes made between 4.x and 5.3 caused weren't > enough to back THAT out until it could be fixed." > > The answer would seem to be that when someone actually does test the > untested code, it is even worse than the code we are already upset with. > :) I think part of the confusion here has to do with the nature of "tested code". Hardware device drivers can be highly tested, but fail to work on specific hardware that isn't in the hands of the people developing or testing with. The 6.x code is presumably running on tens of thousands if not hundreds of thousands of machines quite successfully under very high load, running this same code. So far, since people having problems with the 5.x code were reminded of the patches, we've seen one post of "this works much better!" and one post of "this is even worse!", which should make clear the challenges involved, and how important it is that as many people as possible help in the testing process. And that it doesn't take a whole lot of work to provide at least a little help in the testing -- Karl was able to uncover a problem by simply booting the installed system, which was presumably an investment of less then twenty minutes of his time. I'm sure Soren would love a donation of some nice new server hardware if you happen to have it to spare, but getting involved in testing code is the next best thing :-). Robert N M Watson From owner-freebsd-stable@FreeBSD.ORG Sat Jul 23 20:46:12 2005 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F31A816A41F for ; Sat, 23 Jul 2005 20:46:11 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7367E43D46 for ; Sat, 23 Jul 2005 20:46:11 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 0589046B43; Sat, 23 Jul 2005 16:46:11 -0400 (EDT) Date: Sat, 23 Jul 2005 21:46:58 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Karl Denninger In-Reply-To: <20050722194009.GA95692@FS.denninger.net> Message-ID: <20050723214450.A61837@fledge.watson.org> References: <200507211803.j6LI34dV005050@ferens.net> <20050721194500.W9208@fledge.watson.org> <20050721192613.GA61902@FS.denninger.net> <6.2.1.2.0.20050721153750.0851fab0@64.7.153.2> <20050721202234.GA62615@FS.denninger.net> <20050722004340.H16902@fledge.watson.org> <20050722001253.GA70277@FS.denninger.net> <20050722013605.U16902@fledge.watson.org> <20050722010611.GA72234@FS.denninger.net> <42E0F93E.7000108@commit.it> <20050722194009.GA95692@FS.denninger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-stable@freebsd.org Subject: Re: make -j as a stress test (was: Re: Quality of FreeBSD) [WARNING - 6.0-BETA1 still hosed!] X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jul 2005 20:46:12 -0000 On Fri, 22 Jul 2005, Karl Denninger wrote: > It is definitely NOT fixed in 6.0-BETA1 > > Within SECONDS of starting a buildworld after the provider rebuild > completed, I got this... Could you file a PR based on this report? Specifically, if you could include: - The error output below. - If possible, the dmesg -v output. - Any other hardware information that's relevant (the full product name(s) of the box and card if bought separately, as that likely doesn't appear in dmesg). Thanks, Robert N M Watson > > GEOM_MIRROR: Device boot: provider ad4s1 detected. > GEOM_MIRROR: Device boot: rebuilding provider ad4s1. > GEOM_MIRROR: Device boot: provider ad6s1 detected. > GEOM_MIRROR: Device boot: rebuilding provider ad6s1. > GEOM_MIRROR: Device boot: rebuilding provider ad4s1 finished. > GEOM_MIRROR: Device boot: provider ad4s1 activated. > GEOM_MIRROR: Device boot: rebuilding provider ad6s1 finished. > GEOM_MIRROR: Device boot: provider ad6s1 activated. > subdisk4: detached > ad4: detached > unknown: FAILURE - SETFEATURES SET TRANSFER MODE timed out > unknown: timeout waiting to issue command > unknown: error issueing SETFEATURES SET TRANSFER MODE command > GEOM_MIRROR: Device boot: provider ad4s1 disconnected. > GEOM_MIRROR: Request failed (error=6). ad4s1[READ(offset=35096543232, > length=10240)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35463411712, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35467393024, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35501357056, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35501551616, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35501553664, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35502305280, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35502583808, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35502764032, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35648684032, > length=16384)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35705600000, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35840983040, > length=16384)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35840999424, > length=16384)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35848910848, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35854632960, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=35866456064, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=36226842624, > length=16384)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=36226859008, > length=16384)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=36233115648, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=36234352640, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=36234868736, > length=2048)] > GEOM_MIRROR: Request failed (error=6). ad4s1[WRITE(offset=36274173952, > length=2048)] > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > unknown: req=0xc1e2e320 SETFEATURES SET TRANSFER MODE semaphore timeout !! > DANGER Will Robinson !! > > > This is significantly WORSE than 5.3-RELEASE in that it appears not only > to detach the disk, but then to go on to whine mightily about other things > (I have no idea whether I've taken a data corruption hit at this point or > not.) > > That didn't take long to verify.... > > -- > -- > Karl Denninger (karl@denninger.net) Internet Consultant & Kids Rights Activist > http://www.denninger.net My home on the net - links to everything I do! > http://scubaforum.org Your UNCENSORED place to talk about DIVING! > http://homecuda.com Emerald Coast: Buy / sell homes, cars, boats! > http://genesis3.blogspot.com Musings Of A Sentient Mind > > > On Fri, Jul 22, 2005 at 03:48:46PM +0200, Angelo Turetta wrote: >> Karl Denninger wrote: >>> As I pointed out in my PR, "make -j4 buildworld" is more than sufficient >>> to demonstrate the problem. >> ( ... ) >>> I'll pull over 6.0-BETA1, rebuild the array (that is the time-consuming >>> part of this test - takes 6-8 hours for the rebuild to run) and see if it >>> fails during a buildworld. >> >> Maybe I'm wrong, but in my tests I had the impression that RELENG_6 >> includes the phk's update to make which corrects the -j behaviour. >> >> In 4.x and 5.x, every submake will spawn up to n tasks (n being the >> number provided with -j), and a buildworld -j4 in UP hardware easily >> produces a 2 digits system load. >> >> That's not more the case with 6.x (if I'm not wrong), in my test >> buildworld -j4 puts the load right near 4. >> >> So I hope you have other ways to test the new ATA, as make buildworld >> might not more be the monster it used to be. >> >> Angelo Turetta >> _______________________________________________ >> freebsd-stable@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-stable >> To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >> >> >> %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok > > > _______________________________________________ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org" >