From owner-freebsd-current@FreeBSD.ORG Sun May 22 00:21:51 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13B6416A41C; Sun, 22 May 2005 00:21:51 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD9FB43D1F; Sun, 22 May 2005 00:21:50 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from [192.168.1.6] (211.27.165.224) by smtp02.syd.iprimus.net.au (7.0.036) id 426404FF00CA1C61; Sun, 22 May 2005 10:21:48 +1000 From: Brett Wildermoth Organization: Griffith University To: freebsd-current@freebsd.org Date: Sun, 22 May 2005 10:19:18 +1000 User-Agent: KMail/1.8 References: <20050516203932.0A38316A4D0@hub.freebsd.org> <264865265.20050520150242@takeda.tk> <1313.172.16.0.199.1116680601.squirrel@172.16.0.1> In-Reply-To: <1313.172.16.0.199.1116680601.squirrel@172.16.0.1> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1764883.PTsLnchqh5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505221019.27154.B.Wildermoth@griffith.edu.au> cc: Dariusz Kulinski cc: current@freebsd.org cc: owner-freebsd-current@freebsd.org Subject: Re: Alright you primitive screwheads, LISTEN UP!! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: B.WIldermoth@griffith.edu.au List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 00:21:51 -0000 --nextPart1764883.PTsLnchqh5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Couldn't have said it better myself.... Let this be the end of off-topic=20 messages..... On Sat, 21 May 2005 11:03 pm, owner-freebsd-current@freebsd.org wrote: > On Fri, May 20, 2005 6:02 pm, Dariusz Kulinski said: > > Yeah, It's SO HARD to set rule to delete posts by the subject or > > references. > > You dont get it, do you? This is a mailing list, not a chat board. No one > should have to setup filters to delete offtopic posts. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" =2D-=20 =2D------------------------------------------------------------------ =3D, (\_/) ,=3D Brett Wildermoth BEng(ME) MPhil /`-'--(")--'-'\ Lecturer / PhD Student / (___) \ School of Microelectronic Engineering /.-.-./ " " \.-.-.\ Faculty of Engineering and Info. Tech. Ph. +61 7 3875 5063, Fax. +61 7 3875 5384 Email. B.Wildermoth@grifith.edu.au =2D------------------------------------------------------------------ --nextPart1764883.PTsLnchqh5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCj9AObSsZm/bQWSwRAj//AJ0SFuP0HgRBcZQs+m8jH0FmqTXQigCeK+Si 716XJYPKJJruj2HYbuFbxfM= =UQ1R -----END PGP SIGNATURE----- --nextPart1764883.PTsLnchqh5-- From owner-freebsd-current@FreeBSD.ORG Sun May 22 00:21:51 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13B6416A41C; Sun, 22 May 2005 00:21:51 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD9FB43D1F; Sun, 22 May 2005 00:21:50 +0000 (GMT) (envelope-from B.Wildermoth@griffith.edu.au) Received: from [192.168.1.6] (211.27.165.224) by smtp02.syd.iprimus.net.au (7.0.036) id 426404FF00CA1C61; Sun, 22 May 2005 10:21:48 +1000 From: Brett Wildermoth Organization: Griffith University To: freebsd-current@freebsd.org Date: Sun, 22 May 2005 10:19:18 +1000 User-Agent: KMail/1.8 References: <20050516203932.0A38316A4D0@hub.freebsd.org> <264865265.20050520150242@takeda.tk> <1313.172.16.0.199.1116680601.squirrel@172.16.0.1> In-Reply-To: <1313.172.16.0.199.1116680601.squirrel@172.16.0.1> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1764883.PTsLnchqh5"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505221019.27154.B.Wildermoth@griffith.edu.au> cc: Dariusz Kulinski cc: current@freebsd.org cc: owner-freebsd-current@freebsd.org Subject: Re: Alright you primitive screwheads, LISTEN UP!! X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: B.WIldermoth@griffith.edu.au List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 00:21:51 -0000 --nextPart1764883.PTsLnchqh5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Couldn't have said it better myself.... Let this be the end of off-topic=20 messages..... On Sat, 21 May 2005 11:03 pm, owner-freebsd-current@freebsd.org wrote: > On Fri, May 20, 2005 6:02 pm, Dariusz Kulinski said: > > Yeah, It's SO HARD to set rule to delete posts by the subject or > > references. > > You dont get it, do you? This is a mailing list, not a chat board. No one > should have to setup filters to delete offtopic posts. > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" =2D-=20 =2D------------------------------------------------------------------ =3D, (\_/) ,=3D Brett Wildermoth BEng(ME) MPhil /`-'--(")--'-'\ Lecturer / PhD Student / (___) \ School of Microelectronic Engineering /.-.-./ " " \.-.-.\ Faculty of Engineering and Info. Tech. Ph. +61 7 3875 5063, Fax. +61 7 3875 5384 Email. B.Wildermoth@grifith.edu.au =2D------------------------------------------------------------------ --nextPart1764883.PTsLnchqh5 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCj9AObSsZm/bQWSwRAj//AJ0SFuP0HgRBcZQs+m8jH0FmqTXQigCeK+Si 716XJYPKJJruj2HYbuFbxfM= =UQ1R -----END PGP SIGNATURE----- --nextPart1764883.PTsLnchqh5-- From owner-freebsd-current@FreeBSD.ORG Sun May 22 06:04:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D40216A41C for ; Sun, 22 May 2005 06:04:26 +0000 (GMT) (envelope-from freebsd@leanox.com) Received: from vax.hanford.org (vax.hanford.org [216.218.218.27]) by mx1.FreeBSD.org (Postfix) with SMTP id 5D89743D73 for ; Sun, 22 May 2005 06:04:24 +0000 (GMT) (envelope-from freebsd@leanox.com) Received: (qmail 1021 invoked from network); 22 May 2005 06:04:23 -0000 Received: from unknown (HELO localhost) (216.218.218.27) by vax.hanford.org with SMTP; 22 May 2005 06:04:23 -0000 Date: Sat, 21 May 2005 23:04:23 -0700 (PDT) Message-Id: <20050521.230423.68528638.gwl@area.com> To: freebsd-current@freebsd.org From: Gerry Lawrence In-Reply-To: <200505221019.27154.B.Wildermoth@griffith.edu.au> References: <264865265.20050520150242@takeda.tk> <1313.172.16.0.199.1116680601.squirrel@172.16.0.1> <200505221019.27154.B.Wildermoth@griffith.edu.au> X-Mailer: Mew version 1.95b112 on Emacs 20.7 / Mule 4.0 (HANANOEN) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: Can't make a kernel in 5.4 release -- cc dumps core. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 06:04:26 -0000 Just wondering if anyone's see this: (from a make depend, totally clean install of 5.4 release) make _kernel-depend cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I../../.. -I../../../contrib/dev/acpica -I../../../contrib/altq -I../../../contrib/ipfilter -I../../../contrib/pf -I../../../contrib/dev/ath -I../../../contrib/dev/ath/freebsd -I../../../contrib/ngatm -D_KERNEL -include opt_global.h -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding ../../../i386/i386/genassym.c :1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See for instructions. *** Error code 1 Stop in /usr/src/sys/i386/compile/GENERIC. *** Error code 1 Stop in /usr/src/sys/i386/compile/GENERIC. From owner-freebsd-current@FreeBSD.ORG Sun May 22 06:37:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9EB2316A41C for ; Sun, 22 May 2005 06:37:10 +0000 (GMT) (envelope-from dmschei@attglobal.net) Received: from rockridge.uits.indiana.edu (rockridge.uits.indiana.edu [129.79.1.74]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F63D43D58 for ; Sun, 22 May 2005 06:37:07 +0000 (GMT) (envelope-from dmschei@attglobal.net) Received: from mail-relay.iu.edu (logchain.uits.indiana.edu [129.79.1.77]) by rockridge.uits.indiana.edu (8.12.10/8.12.10/IUPO) with ESMTP id j4M6b6RY013092; Sun, 22 May 2005 01:37:06 -0500 (EST) Received: from [10.0.1.4] (scheidt-rout.canopy.nd.edu [129.74.98.169] (may be forged)) (authenticated bits=0) by mail-relay.iu.edu (8.12.10/8.12.10/IUPO) with ESMTP id j4M6b2sY028890; Sun, 22 May 2005 01:37:05 -0500 (EST) Message-ID: <42902890.20408@attglobal.net> Date: Sun, 22 May 2005 01:37:04 -0500 From: David Scheidt User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050426) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerry Lawrence , freebsd-current@freebsd.org References: <264865265.20050520150242@takeda.tk> <1313.172.16.0.199.1116680601.squirrel@172.16.0.1> <200505221019.27154.B.Wildermoth@griffith.edu.au> <20050521.230423.68528638.gwl@area.com> In-Reply-To: <20050521.230423.68528638.gwl@area.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Subject: Re: Can't make a kernel in 5.4 release -- cc dumps core. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 06:37:10 -0000 Gerry Lawrence wrote: > Just wondering if anyone's see this: > > > (from a make depend, totally clean install of 5.4 release) > > > :1: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > *** Error code 1 > > Stop in /usr/src/sys/i386/compile/GENERIC. > *** Error code 1 > > Stop in /usr/src/sys/i386/compile/GENERIC. > Usual cause is bad hardware. See http://www.bitwizard.nl/sig11/ Regards, David From owner-freebsd-current@FreeBSD.ORG Sun May 22 07:13:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 07F3A16A41F for ; Sun, 22 May 2005 07:13:37 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: from sarajevo.pacific.net.sg (sarajevo.pacific.net.sg [203.120.90.134]) by mx1.FreeBSD.org (Postfix) with SMTP id 0310143D1F for ; Sun, 22 May 2005 07:13:35 +0000 (GMT) (envelope-from oceanare@pacific.net.sg) Received: (qmail 20720 invoked from network); 22 May 2005 07:13:33 -0000 Received: from unknown (HELO maxwell2.pacific.net.sg) (203.120.90.192) by sarajevo with SMTP; 22 May 2005 07:13:33 -0000 Received: from [192.168.0.107] ([210.24.246.101]) by maxwell2.pacific.net.sg with ESMTP id <20050522071333.OPDQ1130.maxwell2.pacific.net.sg@[192.168.0.107]>; Sun, 22 May 2005 15:13:33 +0800 Message-ID: <4290311A.1010305@pacific.net.sg> Date: Sun, 22 May 2005 15:13:30 +0800 From: Erich Dollansky Organization: oceanare pte ltd User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050514) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gerry Lawrence References: <264865265.20050520150242@takeda.tk> <1313.172.16.0.199.1116680601.squirrel@172.16.0.1> <200505221019.27154.B.Wildermoth@griffith.edu.au> <20050521.230423.68528638.gwl@area.com> In-Reply-To: <20050521.230423.68528638.gwl@area.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Can't make a kernel in 5.4 release -- cc dumps core. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 07:13:37 -0000 Hi, Gerry Lawrence wrote: > Just wondering if anyone's see this: > > > (from a make depend, totally clean install of 5.4 release) > > :1: internal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. > *** Error code 1 > I have had similar problems after a binary upgrade. I was able to overcome them only after I downloaded the sources via CVSup. I have had to rebuild the kernel and world to get the system running again. I runs now since more than a week without any glicht. If this still does not help, try to install an older version (5.2 ...) and check if your system works with it. Erich From owner-freebsd-current@FreeBSD.ORG Sun May 22 11:26:23 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 875B716A41C; Sun, 22 May 2005 11:26:23 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CDB043D49; Sun, 22 May 2005 11:26:22 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 752C7EB38EC; Sun, 22 May 2005 19:26:20 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 59C32132DE1; Sun, 22 May 2005 19:26:18 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 37811-02; Sun, 22 May 2005 19:26:12 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 4A3FB1317C4; Sun, 22 May 2005 19:26:12 +0800 (CST) Date: Sun, 22 May 2005 19:26:12 +0800 From: Xin LI To: freebsd-current@FreeBSD.org, delphij@FreeBSD.org Message-ID: <20050522112612.GA37841@frontfree.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="EeQfGwPcQSOJBaQU" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #15: Wed Dec 15 10:43:16 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net Cc: Subject: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 11:26:23 -0000 --EeQfGwPcQSOJBaQU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear -CURRENT users, I would like to solicit a test of the following patchset which is based on DragonFly's changes, against -CURRENT, to bring high resolution console support to FreeBSD. The current patchset can be considered as "BETA" and I would commit it if there is no complain about this patchset in the next week. The patchset can be found at: http://people.freebsd.org/~delphij/vesa/patchset-highres.20050522 To use it, you will need latest -CURRENT code, and apply the patchset at toplevel source tree, i.e. /usr/src for usual cases. Then you need to build and reinstall your kernel, with 'options SC_PIXEL_MODE' compiled in, and optionally options VESA if you don't want to manually load VESA support module. A make buildworld/installworld is recommended, but I believe that just rebuild/reinstall usr.sbin/vidcontrol is enough to get your hands on the support for using something like 'vidcontrol MODE_239' or so, which will switch the current console to that mode. Some mode may not work on certain cards, though. Please let me know if anything strange happens; While I have been running with the patch for a while, I would still be happy if you will report that it works :-) Thanks in advance! Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --EeQfGwPcQSOJBaQU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCkGxU/cVsHxFZiIoRAuafAJ9dW49OGBTk1tNASuavzS/w4/JkvQCfc4Mo V7Ki38uy2BeWHFkVBcTDL5c= =vftH -----END PGP SIGNATURE----- --EeQfGwPcQSOJBaQU-- From owner-freebsd-current@FreeBSD.ORG Sat May 21 20:55:50 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23FC316A4CE; Sat, 21 May 2005 20:55:50 +0000 (GMT) Received: from viefep14-int.chello.at (viefep14-int.chello.at [213.46.255.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 210FE43D1D; Sat, 21 May 2005 20:55:48 +0000 (GMT) (envelope-from gabor.kovesdan@t-hosting.hu) Received: from [80.98.207.149] by viefep14-int.chello.at (InterMail vM.6.01.04.04 201-2131-118-104-20050224) with ESMTP id <20050521205546.ZKAO7053.viefep14-int.chello.at@[80.98.207.149]>; Sat, 21 May 2005 22:55:46 +0200 Message-ID: <428FA04F.7060708@t-hosting.hu> Date: Sat, 21 May 2005 22:55:43 +0200 From: =?ISO-8859-1?Q?K=F6vesd=E1n_G=E1bor?= User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-bugs@t-hosting.hu, freebsd-current@freebsd.org, freebsd-stable@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 22 May 2005 11:56:36 +0000 Cc: Subject: FreeBSD 5.3 forgets some of my users X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 May 2005 20:55:50 -0000 Hello there, there is a strange thing.... FreeBSD 5.3 randomly frogets some of my users. Sometimes I see in the first column of the ps aux output the uid number instead of the login name, but next when I run it, there is the login name. Besides, I tried to chown a directory to an existing user, but the I get an error message, that there wasn't such user. I immediately checked passwd, group and master.passwd files in /etc but the entry for that user was present there. The pw userdel was unable to delete that user, so I had to manually remove it from those three files and create it again. It worked then, but a bit later there was the same result. I'm quite annoyed now. This state isn't safe enough, I have to do something to get around with this. Do You have similar experiences? Or do You now some kinda workaround? Cheers, Gábor Kövesdán From owner-freebsd-current@FreeBSD.ORG Sun May 22 11:06:30 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6AE416A41C for ; Sun, 22 May 2005 11:06:29 +0000 (GMT) (envelope-from emil@cs.rmit.edu.au) Received: from ppp162-47.static.internode.on.net (ppp162-47.static.internode.on.net [150.101.162.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3C82543D4C for ; Sun, 22 May 2005 11:06:29 +0000 (GMT) (envelope-from emil@cs.rmit.edu.au) Received: by ppp162-47.static.internode.on.net (Poofix, from userid 1001) id DF45B6218; Sun, 22 May 2005 21:06:27 +1000 (EST) Date: Sun, 22 May 2005 21:06:27 +1000 From: Emil Mikulic To: freebsd-current@FreeBSD.org Message-ID: <20050522110627.GA48162@dmr.ath.cx> Mail-Followup-To: Emil Mikulic , freebsd-current@FreeBSD.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-PGP-ID: 1024D/344A699F X-PGP-Fingerprint: EE97 2C84 6D07 E76C F075 C0BA ED2A 9319 344A 699F X-Written-On: dmr.ath.cx (FreeBSD 6.0-CURRENT i386) User-Agent: Mutt/1.5.9i X-Mailman-Approved-At: Sun, 22 May 2005 11:56:36 +0000 Cc: Subject: ath0 goes down periodically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 11:06:30 -0000 At home I have a FreeBSD 6-CURRENT machine with an ath card acting as an access point. Every once in a while, wireless traffic stops and I have to log in to this machine and manually bounce the interface to get it going again. I noticed that when this sort of outage occurs I can't ping from the hostap machine on the wifi interface. It looks like the interface queue is full. (?) It just happened now so here are the diagnostics I can think of: # ifconfig -v ath0 ath0: flags=8c43 mtu 1500 inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 inet6 fe80::209:5bff:fec8:6919%ath0 prefixlen 64 scopeid 0x3 ether 00:09:5b:c8:69:19 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b status: associated ssid ***** channel 6 (2437) bssid 00:09:5b:c8:69:19 authmode SHARED privacy ON deftxkey 1 wepkey 1:40-bit <**********> tx+rx+def powersavemode OFF powersavesleep 100 txpowmax 0 txpower 60 rtsthreshold 2312 protmode CTS wme ssid SHOW apbridge dtimperiod 1 bintval 100 AC_BE cwmin 5 cwmax 7 aifs 3 txopLimit 0 -acm ack cwmin 5 cwmax 10 aifs 3 txopLimit 0 -acm AC_BK cwmin 5 cwmax 10 aifs 7 txopLimit 0 -acm ack cwmin 5 cwmax 10 aifs 7 txopLimit 0 -acm AC_VI cwmin 4 cwmax 5 aifs 1 txopLimit 188 -acm ack cwmin 4 cwmax 5 aifs 2 txopLimit 188 -acm AC_VO cwmin 3 cwmax 4 aifs 1 txopLimit 102 -acm ack cwmin 3 cwmax 4 aifs 2 txopLimit 102 -acm # ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1): 56 data bytes 64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=0.191 ms 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.149 ms # ping 192.168.2.2 PING 192.168.2.2 (192.168.2.2): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available /var/log/messages has a couple of recent lines saying "kernel: ath0: device timeout" The fix: # ifconfig ath0 down # ifconfig ath0 up # ping 192.168.2.2 PING 192.168.2.2 (192.168.2.2): 56 data bytes 64 bytes from 192.168.2.2: icmp_seq=0 ttl=128 time=3.392 ms 64 bytes from 192.168.2.2: icmp_seq=1 ttl=128 time=0.886 ms The card is a Netgear WG311T: ath0: mem 0xe8120000-0xe812ffff irq 11 at device 12.0 on pci0 ath0: Ethernet address: 00:09:5b:c8:69:19 ath0: mac 5.6 phy 4.1 radio 1.7 The kernel is a little old: FreeBSD 6.0-CURRENT #4: Tue Apr 5 18:07:56 EST 2005 But all the relevant source files seem up to date: # ident /boot/kernel/kernel | grep ath $FreeBSD: src/sys/dev/ath/ath_rate/sample/sample.c,v 1.8 2005/04/02 18:56:50 sam Exp $ $FreeBSD: src/sys/dev/ath/if_ath.c,v 1.87 2005/04/04 02:34:14 sam Exp $ $FreeBSD: src/sys/dev/ath/if_ath_pci.c,v 1.12 2005/03/05 19:06:12 imp Exp $ (Latest if_ath.c is 1.88, the changelog says "honor new IEEE80211_KEY_GROUP key flag") This happens periodically. I can't reproduce it at will, but it will happen again eventually. Is there anything further I can do to help diagnose (and hopefully fix) this problem? --Emil From owner-freebsd-current@FreeBSD.ORG Sun May 22 11:59:26 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 246C816A41C for ; Sun, 22 May 2005 11:59:26 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB87743D48 for ; Sun, 22 May 2005 11:59:25 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd25.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1DZp75-0000JO-00; Sun, 22 May 2005 13:59:23 +0200 Received: from Andro-Beta.Leidinger.net (bpuAQmZEwejH2QseWJO1Xfnkuw20ZAEBmi5UD5ohKxjf-99mArBKZy@[217.81.85.119]) by fwd25.sul.t-online.de with esmtp id 1DZp6r-1WXWVc0; Sun, 22 May 2005 13:59:09 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.1/8.13.1) with ESMTP id j4MBx7eE082611 for ; Sun, 22 May 2005 13:59:08 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 22 May 2005 13:59:15 +0200 From: Alexander Leidinger To: current@freebsd.org Message-ID: <20050522135915.6117ef26@Magellan.Leidinger.net> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: bpuAQmZEwejH2QseWJO1Xfnkuw20ZAEBmi5UD5ohKxjf-99mArBKZy@t-dialin.net X-TOI-MSGID: f773c07c-b6bb-42e4-b54e-e31320ac9ec7 Cc: Subject: wrong link state change message from vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 11:59:26 -0000 Hi, I get a "vr0: link state changed to DOWN" when it should be a UP-message (kernel as of May 2). I want to fix this, but don't know what part of the source is responsible and how it should look like. Can someone please give me a hint? Bye, Alexander. -- There's no place like ~ http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Sun May 22 14:02:47 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC40616A41C for ; Sun, 22 May 2005 14:02:47 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99FB243D53 for ; Sun, 22 May 2005 14:02:47 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.190.81]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGW009OI9OI1VCE@vms042.mailsrvcs.net> for freebsd-current@FreeBSD.org; Sun, 22 May 2005 09:02:43 -0500 (CDT) Date: Sun, 22 May 2005 10:00:31 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <20050522110627.GA48162@dmr.ath.cx> To: Emil Mikulic Message-id: <1116770431.58707.6.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-type: text/plain; charset=iso-8859-5 Content-transfer-encoding: 8BIT References: <20050522110627.GA48162@dmr.ath.cx> Cc: freebsd-current@FreeBSD.org Subject: Re: ath0 goes down periodically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 14:02:47 -0000 On Sun, 2005-05-22 at 21:06 +1000, Emil Mikulic wrote: > At home I have a FreeBSD 6-CURRENT machine with an ath card acting as an > access point. Every once in a while, wireless traffic stops and I have > to log in to this machine and manually bounce the interface to get it > going again. > > I noticed that when this sort of outage occurs I can't ping from the > hostap machine on the wifi interface. It looks like the interface queue > is full. (?) > > It just happened now so here are the diagnostics I can think of: > > This happens periodically. I can't reproduce it at will, but it will > happen again eventually. Is there anything further I can do to help > diagnose (and hopefully fix) this problem? > > --Emil > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" Unfortunately, I could not offer you a solution, however, you can get additional information on what driver thinks card is doing by using 80211debug utility (it lives in /usr/src/tools/tools/ath). As the side note -- I have been observing similar behavior with my Atheros card when I have neighboring station with the stronger signal then one from my own. In my case, 80211debug shows that card goes into the loop, scanning all channels, it can think of. Bouncing the card cures it for a while and then it will go back into that mode. HTH, -- Alexandre "Sunny" Kovalenko (¾ÛÕÚáÐÝÔà ºÞÒÐÛÕÝÚÞ) From owner-freebsd-current@FreeBSD.ORG Sun May 22 14:38:10 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 011CA16A41C; Sun, 22 May 2005 14:38:10 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1C4943D1F; Sun, 22 May 2005 14:38:09 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.190.81]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGW009AUBBK1T0E@vms042.mailsrvcs.net>; Sun, 22 May 2005 09:38:09 -0500 (CDT) Date: Sun, 22 May 2005 10:36:03 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <20050522112612.GA37841@frontfree.net> To: Xin LI Message-id: <1116772563.742.5.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-type: text/plain; charset=iso-8859-5 Content-transfer-encoding: 8BIT References: <20050522112612.GA37841@frontfree.net> Cc: freebsd-current@FreeBSD.org, delphij@FreeBSD.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 14:38:10 -0000 On Sun, 2005-05-22 at 19:26 +0800, Xin LI wrote: > Dear -CURRENT users, > > I would like to solicit a test of the following patchset which is based > on DragonFly's changes, against -CURRENT, to bring high resolution console > support to FreeBSD. The current patchset can be considered as "BETA" and > I would commit it if there is no complain about this patchset in the next > week. > > The patchset can be found at: > http://people.freebsd.org/~delphij/vesa/patchset-highres.20050522 > > To use it, you will need latest -CURRENT code, and apply the patchset at > toplevel source tree, i.e. /usr/src for usual cases. Then you need to build > and reinstall your kernel, with 'options SC_PIXEL_MODE' compiled in, and > optionally options VESA if you don't want to manually load VESA support > module. A make buildworld/installworld is recommended, but I believe that > just rebuild/reinstall usr.sbin/vidcontrol is enough to get your hands on > the support for using something like 'vidcontrol MODE_239' or so, which will > switch the current console to that mode. Some mode may not work on certain > cards, though. > > Please let me know if anything strange happens; While I have been running > with the patch for a while, I would still be happy if you will report that > it works :-) > > Thanks in advance! > > Cheers, Works very well here (Averatec 3150H notebook with S3 ProSavage video chipset). Current sources are from May 14. I was able to switch console into 1024x768x32 (mode 280). Mouse cursor displays and moves around, but since I am not using mouse on the console I could not report much on that. Thank you very much, -- Alexandre "Sunny" Kovalenko (¾ÛÕÚáÐÝÔà ºÞÒÐÛÕÝÚÞ) From owner-freebsd-current@FreeBSD.ORG Sun May 22 16:51:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0C37B16A41C for ; Sun, 22 May 2005 16:51:49 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id B65C343D1F for ; Sun, 22 May 2005 16:51:48 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.90] ([66.127.85.90]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j4MGpems035324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 May 2005 09:51:40 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4290B89E.1040107@errno.com> Date: Sun, 22 May 2005 09:51:42 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Emil Mikulic References: <20050522110627.GA48162@dmr.ath.cx> In-Reply-To: <20050522110627.GA48162@dmr.ath.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ath0 goes down periodically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 16:51:49 -0000 Emil Mikulic wrote: > At home I have a FreeBSD 6-CURRENT machine with an ath card acting as an > access point. Every once in a while, wireless traffic stops and I have > to log in to this machine and manually bounce the interface to get it > going again. > > I noticed that when this sort of outage occurs I can't ping from the > hostap machine on the wifi interface. It looks like the interface queue > is full. (?) When this happens can you see beacons being xmit'd by the ap? Also the output of athstats (src/tools/tools/ath) may be useful. Sam From owner-freebsd-current@FreeBSD.ORG Sun May 22 18:19:07 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D746C16A41C for ; Sun, 22 May 2005 18:19:07 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (pipa.profix.cz [213.151.89.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 393FE43D53 for ; Sun, 22 May 2005 18:19:04 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id E077C4E733; Sun, 22 May 2005 20:19:04 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14804-03; Sun, 22 May 2005 20:19:04 +0200 (CEST) Received: from gandalf (105.121.95.80.ip.b26.cz [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id 7202B4E70E; Sun, 22 May 2005 20:19:04 +0200 (CEST) From: =?us-ascii?Q?Daniel_Dvorak?= To: "'Emil Mikulic'" Date: Sun, 22 May 2005 20:18:36 +0200 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: <20050522110627.GA48162@dmr.ath.cx> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Thread-Index: AcVexW2Vct5/9OjvRJe1fadCjBsSDgAMF/MA Message-Id: <20050522181904.7202B4E70E@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com Cc: freebsd-current@FreeBSD.org Subject: RE: ath0 goes down periodically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 18:19:08 -0000 On Thursday I reported my problem with atheros and no response. Now we see it is common problem. I used ath_rate_onoe, ath_rate_amrr and now last I am testing ath_rate_sample, and yet no "kernel: ath0: device timeout" message turns up in /var/log/messages since last reboot after recompilation kornel with sample rate. But U use sample rate and have the same messages. So choise of ath_rate does not have a influence on timeout. Last panic was connection to mbuf. My box went to panic state due to Atheros for many times, my friend advised me to use this: lsd# sysctl kern.ipc.maxsockbuf kern.ipc.maxsockbuf: 2097152 For the present no panic, We will see. :( U use hostap mode, I use client mode. U use 802.11b, I use 802.11a. My athstats: lsd# athstats 3 tx management frames 17 tx frames discarded prior to association 78 tx stopped 'cuz no xmit buffer 36876 tx failed 'cuz too many retries 4224534 long on-chip tx retries 1 tx frames with no ack marked 777988 tx frames with an alternate rate 7419 rx failed 'cuz of bad CRC 1052759 rx failed 'cuz frame too short 10361501 rx failed 'cuz of PHY err 10360958 OFDM timing 541 OFDM illegal service 2 OFDM restart 4677 periodic calibrations 1 rfgain value change rssi of last ack: 26 avg recv rssi: 26 15 switched default/rx antenna Antenna profile: [1] tx 32354058 rx 45291855 [2] tx 72289 rx 3319 My RSSI is about 26, so -95, signal from AP is about -69 dBm, strong enough. Media selection is autoselect. Generally OFDM/18Mbps. Daniel -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Emil Mikulic Sent: Sunday, May 22, 2005 1:06 PM To: freebsd-current@FreeBSD.org Subject: ath0 goes down periodically At home I have a FreeBSD 6-CURRENT machine with an ath card acting as an access point. Every once in a while, wireless traffic stops and I have to log in to this machine and manually bounce the interface to get it going again. I noticed that when this sort of outage occurs I can't ping from the hostap machine on the wifi interface. It looks like the interface queue is full. (?) It just happened now so here are the diagnostics I can think of: # ifconfig -v ath0 ath0: flags=8c43 mtu 1500 inet 192.168.2.1 netmask 0xffffff00 broadcast 192.168.2.255 inet6 fe80::209:5bff:fec8:6919%ath0 prefixlen 64 scopeid 0x3 ether 00:09:5b:c8:69:19 media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b status: associated ssid ***** channel 6 (2437) bssid 00:09:5b:c8:69:19 authmode SHARED privacy ON deftxkey 1 wepkey 1:40-bit <**********> tx+rx+def powersavemode OFF powersavesleep 100 txpowmax 0 txpower 60 rtsthreshold 2312 protmode CTS wme ssid SHOW apbridge dtimperiod 1 bintval 100 AC_BE cwmin 5 cwmax 7 aifs 3 txopLimit 0 -acm ack cwmin 5 cwmax 10 aifs 3 txopLimit 0 -acm AC_BK cwmin 5 cwmax 10 aifs 7 txopLimit 0 -acm ack cwmin 5 cwmax 10 aifs 7 txopLimit 0 -acm AC_VI cwmin 4 cwmax 5 aifs 1 txopLimit 188 -acm ack cwmin 4 cwmax 5 aifs 2 txopLimit 188 -acm AC_VO cwmin 3 cwmax 4 aifs 1 txopLimit 102 -acm ack cwmin 3 cwmax 4 aifs 2 txopLimit 102 -acm # ping 192.168.2.1 PING 192.168.2.1 (192.168.2.1): 56 data bytes 64 bytes from 192.168.2.1: icmp_seq=0 ttl=64 time=0.191 ms 64 bytes from 192.168.2.1: icmp_seq=1 ttl=64 time=0.149 ms # ping 192.168.2.2 PING 192.168.2.2 (192.168.2.2): 56 data bytes ping: sendto: No buffer space available ping: sendto: No buffer space available /var/log/messages has a couple of recent lines saying "kernel: ath0: device timeout" The fix: # ifconfig ath0 down # ifconfig ath0 up # ping 192.168.2.2 PING 192.168.2.2 (192.168.2.2): 56 data bytes 64 bytes from 192.168.2.2: icmp_seq=0 ttl=128 time=3.392 ms 64 bytes from 192.168.2.2: icmp_seq=1 ttl=128 time=0.886 ms The card is a Netgear WG311T: ath0: mem 0xe8120000-0xe812ffff irq 11 at device 12.0 on pci0 ath0: Ethernet address: 00:09:5b:c8:69:19 ath0: mac 5.6 phy 4.1 radio 1.7 The kernel is a little old: FreeBSD 6.0-CURRENT #4: Tue Apr 5 18:07:56 EST 2005 But all the relevant source files seem up to date: # ident /boot/kernel/kernel | grep ath $FreeBSD: src/sys/dev/ath/ath_rate/sample/sample.c,v 1.8 2005/04/02 18:56:50 sam Exp $ $FreeBSD: src/sys/dev/ath/if_ath.c,v 1.87 2005/04/04 02:34:14 sam Exp $ $FreeBSD: src/sys/dev/ath/if_ath_pci.c,v 1.12 2005/03/05 19:06:12 imp Exp $ (Latest if_ath.c is 1.88, the changelog says "honor new IEEE80211_KEY_GROUP key flag") This happens periodically. I can't reproduce it at will, but it will happen again eventually. Is there anything further I can do to help diagnose (and hopefully fix) this problem? --Emil _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Sun May 22 18:34:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58B1A16A41C for ; Sun, 22 May 2005 18:34:45 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A63D43D49 for ; Sun, 22 May 2005 18:34:45 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id D304372DD9; Sun, 22 May 2005 11:34:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id D0ACE72DD4; Sun, 22 May 2005 11:34:44 -0700 (PDT) Date: Sun, 22 May 2005 11:34:44 -0700 (PDT) From: Doug White To: Jens Schweikhardt In-Reply-To: <20050521092857.GA847@schweikhardt.net> Message-ID: <20050522112845.S27009@carver.gumbysoft.com> References: <20050516113420.GA786@schweikhardt.net> <20050518150346.S87264@carver.gumbysoft.com> <20050519190129.GA1048@schweikhardt.net> <20050520122944.B8229@carver.gumbysoft.com> <20050521092857.GA847@schweikhardt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: Timekeeping hosed by factor 3, high lapic[01] interrupt rates X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 18:34:45 -0000 On Sat, 21 May 2005, Jens Schweikhardt wrote: > On Fri, May 20, 2005 at 12:44:50PM -0700, Doug White wrote: > ... > # > Note that there's no > # > irq0: clk 745029 1000 > # > appearing. I'm not an expert, but that's unexpected to my eyes. > # > # Not totally (I don't have irq0 on any of my -current machines after the > # lapic change), but it being there before and then going away implies the > # kernel is choosing a different timecounter than before, and the new one > # may be bogus. > # > # Can you get the output of 'sysctl kern.timecounter' for both working and > # broken kernels? > > > broken: > kern.timecounter.hardware: i8254 > kern.timecounter.choice: TSC(-100) i8254(0) dummy(-1000000) > > working: > kern.timecounter.hardware: i8254 > kern.timecounter.choice: TSC(-100) i8254(0) dummy(-1000000) Okay, no change there. > # When did you pull sources for the original working kernel and the new > # broken kernel? > > Working: around March 5 (I always cvsup before compiling a system) > Broken: May 17 (after the ATA hangs at boot were fixed) Lets try this: 0. If you're overclocking your CPU, don't. 1. Boot with ACPI enabled and print the two kern.timecount sysctls above. I'm curious if its picking up the ACPI timecounter. 2. Shutdown and unplug the machine for about 20 minutes or overnight if convenient. Plug it back in, go into BIOS Setup and check the clock. If its off or dead then the CMOS battery is dead. 3. Backout rev 1.218 of src/sys/i386/isa/clock.c so the irq0 interrupt handler is reactivated and the RTC fiddled. > Some time in the past, the system would hang at boot with acpi enabled. > So I kept a hint.acpi.0.disabled="1" in /boot/device.hints. But even > without that hint, the time dilation effect (hey, it's the Einstein > Year!) is the same... This would imply the source of the problem is not in the timecounter, which doesn't make sense. Are you running ntpd? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun May 22 18:45:51 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8194816A41C; Sun, 22 May 2005 18:45:51 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B8BD43D53; Sun, 22 May 2005 18:45:51 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.190.81]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGW00A9DMSDS1H9@vms042.mailsrvcs.net>; Sun, 22 May 2005 13:45:49 -0500 (CDT) Date: Sun, 22 May 2005 14:43:43 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <20050522112612.GA37841@frontfree.net> To: Xin LI Message-id: <1116787423.786.10.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-type: text/plain; charset=iso-8859-5 Content-transfer-encoding: 8BIT References: <20050522112612.GA37841@frontfree.net> Cc: freebsd-current@FreeBSD.org, delphij@FreeBSD.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 18:45:51 -0000 On Sun, 2005-05-22 at 19:26 +0800, Xin LI wrote: > Dear -CURRENT users, > > I would like to solicit a test of the following patchset which is based > on DragonFly's changes, against -CURRENT, to bring high resolution console > support to FreeBSD. The current patchset can be considered as "BETA" and > I would commit it if there is no complain about this patchset in the next > week. > > The patchset can be found at: > http://people.freebsd.org/~delphij/vesa/patchset-highres.20050522 > > To use it, you will need latest -CURRENT code, and apply the patchset at > toplevel source tree, i.e. /usr/src for usual cases. Then you need to build > and reinstall your kernel, with 'options SC_PIXEL_MODE' compiled in, and > optionally options VESA if you don't want to manually load VESA support > module. A make buildworld/installworld is recommended, but I believe that > just rebuild/reinstall usr.sbin/vidcontrol is enough to get your hands on > the support for using something like 'vidcontrol MODE_239' or so, which will > switch the current console to that mode. Some mode may not work on certain > cards, though. > > Please let me know if anything strange happens; While I have been running > with the patch for a while, I would still be happy if you will report that > it works :-) > > Thanks in advance! > > Cheers, I have observed some odd behavior when X display becomes garbled if USB stack is loaded and USB keyboard is attached after user has logged into X desktop (Gnome in my case). I am setting MODE_280 (1024x768x32) in rc.conf using 'allscreens_flags'. I have been playing with it a bit and found out that I can achieve the same result by doing 'vidcontrol MODE_280 < /dev/ttyv8 > /dev/ttyv8' after logging into Gnome. And ttyv8 is the terminal, occupied by X display. Restarting X server cures the problem. Neither original scenario, nor the second one are very likely, so I do not know whether it is much of a problem. I am running -CURRENT from May 14th, video chipset is S3 ProSavage. Please, let me know if there is any additional information that I can provide. -- Alexandre "Sunny" Kovalenko (¾ÛÕÚáÐÝÔà ºÞÒÐÛÕÝÚÞ) From owner-freebsd-current@FreeBSD.ORG Sun May 22 18:45:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2840D16A42B for ; Sun, 22 May 2005 18:45:57 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DB05C43D54 for ; Sun, 22 May 2005 18:45:54 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 9ABD772DD4; Sun, 22 May 2005 11:45:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 956BF72DCB; Sun, 22 May 2005 11:45:54 -0700 (PDT) Date: Sun, 22 May 2005 11:45:54 -0700 (PDT) From: Doug White To: David Gurvich In-Reply-To: <200505210727.23320.david.freebsd@verizon.net> Message-ID: <20050522114524.B27009@carver.gumbysoft.com> References: <20050518051111.GA33262@Athena.infor.org> <428CFD0F.4030800@samsco.org> <200505192249.31200.david.freebsd@verizon.net> <200505210727.23320.david.freebsd@verizon.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 18:45:57 -0000 On Sat, 21 May 2005, David Gurvich wrote: > New cvsup cycle has not fixed the problem. Might it have anything to do with > the fact my freebsd partition is not the first partition? Unlikely ... are you _sure_ you updated your sources correctly and you're booting the fixed loader? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun May 22 18:55:48 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1812E16A41C for ; Sun, 22 May 2005 18:55:48 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DDEAE43D4C for ; Sun, 22 May 2005 18:55:47 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id A12FC72DD9; Sun, 22 May 2005 11:55:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 9F0F772DD4; Sun, 22 May 2005 11:55:47 -0700 (PDT) Date: Sun, 22 May 2005 11:55:47 -0700 (PDT) From: Doug White To: Alexander Leidinger In-Reply-To: <20050522135915.6117ef26@Magellan.Leidinger.net> Message-ID: <20050522115014.O27009@carver.gumbysoft.com> References: <20050522135915.6117ef26@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: current@freebsd.org Subject: Re: wrong link state change message from vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 18:55:48 -0000 On Sun, 22 May 2005, Alexander Leidinger wrote: > Hi, > > I get a "vr0: link state changed to DOWN" when it should be a UP-message > (kernel as of May 2). I want to fix this, but don't know what part of > the source is responsible and how it should look like. Can someone > please give me a hint? Are you saying the messages are reversed, i.e. when the link goes down it says UP and when the cable is plugged in it says DOWN? I can't reproduce this on my vr on a KT400 board from a late April kernel. Note that the message may be delayed due to the way syslog works. Is the media status correct in 'ifconfig vr0'? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun May 22 19:09:19 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E53A16A41C for ; Sun, 22 May 2005 19:09:19 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9B4443D49 for ; Sun, 22 May 2005 19:09:18 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 82944 invoked by uid 89); 22 May 2005 19:08:33 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 22 May 2005 19:08:33 -0000 Date: Sun, 22 May 2005 21:09:12 +0200 From: Oliver Lehmann To: Alexander Leidinger Message-Id: <20050522210912.34f8e11d.lehmann@ans-netz.de> In-Reply-To: <20050522135915.6117ef26@Magellan.Leidinger.net> References: <20050522135915.6117ef26@Magellan.Leidinger.net> X-Mailer: Sylpheed version 1.9.11 (GTK+ 2.6.7; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: wrong link state change message from vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 19:09:19 -0000 Alexander Leidinger wrote: > Hi, > > I get a "vr0: link state changed to DOWN" I've the same here. dmesg(8), /var/run/dmesg.boot and /var/log/messages are saying: Trying to mount root from ufs:/dev/ad0s2a re0: link state changed to UP But my screen shows: Trying to mount root from ufs:/dev/ad0s2a re0: link state changed to DOWN FreeBSD kartoffel.salatschuessel.net 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Sat May 21 09:29:57 CEST 2005 olivleh1@kartoffel.salatschuessel.net:/ usr/obj/usr/src/sys/KARTOFFEL amd64 -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Sun May 22 19:10:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E811B16A41C for ; Sun, 22 May 2005 19:10:35 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF50C43D49 for ; Sun, 22 May 2005 19:10:35 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.190.81]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGW00AKDNXMS1J9@vms042.mailsrvcs.net> for freebsd-current@freebsd.org; Sun, 22 May 2005 14:10:35 -0500 (CDT) Date: Sun, 22 May 2005 15:08:28 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <428E7BAF.200@savvis.net> To: Maksim Yevmenkin Message-id: <1116788908.824.23.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-type: text/plain; charset=iso-8859-5 Content-transfer-encoding: 8BIT References: <4288EBEA.5030701@savvis.net> <428A5A58.6010601@savvis.net> <428B7B99.7080206@savvis.net> <428E7BAF.200@savvis.net> Cc: freebsd-current@freebsd.org Subject: Re: keyboard mux driver (straw man proposal & code) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 19:10:36 -0000 On Fri, 2005-05-20 at 17:07 -0700, Maksim Yevmenkin wrote: > dear hackers, > > next version of experimental keyboard mux can be downloaded from > > http://www.geocities.com/m_evmenkin/kbdmux-2.tar.gz (~8K) > > also on freefall in my home directory (freefall:~emax/kbdmux-2.tar.gz). > > i gave up idea of using slave keyboards in K_XLATE mode. for whatever > reason i could not get it to work in console (it did work just fine in X). > > so, i re-shaped the code and now kbdmux treats slave keyboards just as > suppliers of raw at scan codes. when keyboard is added to the mux it > will set be switched into K_RAW mode. > > i also decided to not add auxiliary device interface. i think its better > to pass keyboard mux ioctl's through /dev/console. > > i tried the code with one ps/2 keyboard connected to the mux > (pass-through) and it worked for me in both X and console. > > any feedback is welcome! > > thanks, > max > I did jump up and down couple of times ;) and set out to add separate USB numeric keypad to my laptop's keyboard. Here are some observations from that undertaking: I was not able to disconnect original keyboard from the console to add it to the multiplexer: kbdcontrol -K < /dev/console kbdcontrol: unable to obtain keyboard information: Inappropriate ioctl for device I have managed to work around this by using yet another USB keyboard and attaching it to the console using 'kbdcontrol -k /dev/kbd1 < /dev/ttyv0'. After that I was able to add both original keyboard and USB keypad to the multiplexer and attached that to the console. At this point both keyboards provided input to console and X with following side effects: -- keyboard lights (caps lock and num lock) on the main keyboard would not turn on. -- keypad would work in the "arrows" ("up"/"down"/"left"/"right") mode on startup. -- "Caps lock" would capitalize main keyboard (there are no letters on the keypad). -- "Num lock" would switch keypad into numeric mode, but leave main keyboard alone (as it is the case with laptop keyboards it has sprinkling of numerals on the right side overlapping letters). -- Key "5" on the keypad will not produce number "5" in any mode, the rest of the keys ('-', '+', '*', '/', and ) seem to work properly. I am running -CURRENT as of May 14th with console high resolution patch. Machine is Averatec 3150H, keypad is manufactured by iConcepts, but represents itself as CHESEN USB keyboard. If there is any additional information that I can provide or there is something you want me to experiment with, please, let me know. -- Alexandre "Sunny" Kovalenko (¾ÛÕÚáÐÝÔà ºÞÒÐÛÕÝÚÞ) From owner-freebsd-current@FreeBSD.ORG Sun May 22 19:11:36 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E542B16A41C for ; Sun, 22 May 2005 19:11:36 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC7EB43D49 for ; Sun, 22 May 2005 19:11:36 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 1959EFE80; Sun, 22 May 2005 15:11:36 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id 371441A08E7; Sun, 22 May 2005 15:11:33 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17040.55652.807936.640806@canoe.dclg.ca> Date: Sun, 22 May 2005 15:11:32 -0400 To: freebsd-current@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Subject: GEOm label inconsistency. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 19:11:37 -0000 I have two USB drives... so I decided that using geom_label.ko would be handy to make scripts work for mounting and unmounting the drives (as I could never ensure that they came up in the same order). I was pleased to find that my various pieces of MSDOS flash seemed to work just fine. /dev/msdosfs/ However, of my two USB drives (actual hard disks) ... both formatted with a UFS filesystem covering the whole drive, one puts a label in /dev/ufs and the other does not. The one that works is a 30 gig laptop drive in a USB2 bus powered (two plugs) carrier. It has an "fdisk -I" MBR and I formatted the da0s1c partition. Now... geom_label recognises da0s1 as the labelled partition ... but that really doesn't matter to me ... it works. The one that doesn't work is a 120G drive in a USB2 enclosure from iomega. Again, it has an "fdisk -I" MBR and a whole disk ufs filesystem. geom_label does not recognise it for some reason. Turning on the debug for geom_label, I find: da1 at umass-sim1 bus 1 target 0 lun 0 da1: Fixed Direct Access SCSI-0 device da1: 40.000MB/s transfers da1: 117800MB (241254720 512 byte sectors: 255H 63S/T 15017C) GEOM_LABEL[1]: UFS1 file system detected on da1s1. GEOM_LABEL[1]: MSDOS (FAT32) file system detected on da1s1. GEOM_LABEL[1]: UFS1 file system detected on da1s1c. GEOM_LABEL[1]: MSDOS (FAT32) file system detected on da1s1c. GEOM_LABEL[1]: UFS1 file system detected on da1s1g. GEOM_LABEL[1]: MSDOS (FAT32) file system detected on da1s1g. Now... the drive _used_ to have a MSDOS filesytem on it... but it has since been: a) fdisk'd to type 165 b) bsdlabeled c) formatted and used for most of 2 years as a UFS filesystem Does this mean that geom_label's testing of filesysem type is weak? Is there a workaround whereby I blank a sector not used by UFS? Should geom_label take hints from the mbr type? Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-current@FreeBSD.ORG Sun May 22 21:53:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8157C16A41F; Sun, 22 May 2005 21:53:49 +0000 (GMT) (envelope-from peter@wemm.org) Received: from canning.wemm.org (canning.wemm.org [192.203.228.65]) by mx1.FreeBSD.org (Postfix) with ESMTP id 25DFE43D1F; Sun, 22 May 2005 21:53:49 +0000 (GMT) (envelope-from peter@wemm.org) Received: from fw.wemm.org (canning.wemm.org [192.203.228.65]) by canning.wemm.org (Postfix) with ESMTP id 095742A8DA; Sun, 22 May 2005 14:53:49 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (overcee.wemm.org [10.0.0.3]) by fw.wemm.org (Postfix) with ESMTP id ABE70E2B3; Sun, 22 May 2005 14:53:48 -0700 (PDT) (envelope-from peter@wemm.org) Received: from overcee.wemm.org (localhost [127.0.0.1]) by overcee.wemm.org (8.13.3/8.13.1) with ESMTP id j4MLrlbu082855; Sun, 22 May 2005 14:53:47 -0700 (PDT) (envelope-from peter@wemm.org) Received: from localhost (localhost [[UNIX: localhost]]) by overcee.wemm.org (8.13.3/8.13.1/Submit) id j4MLriWX082854; Sun, 22 May 2005 14:53:44 -0700 (PDT) (envelope-from peter@wemm.org) X-Authentication-Warning: overcee.wemm.org: peter set sender to peter@wemm.org using -f From: Peter Wemm To: freebsd-current@freebsd.org Date: Sun, 22 May 2005 14:53:43 -0700 User-Agent: KMail/1.8 References: <20050518051111.GA33262@Athena.infor.org> <20050520164349.GD6982@dragon.NUXI.org> <428E1815.8080500@samsco.org> In-Reply-To: <428E1815.8080500@samsco.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200505221453.44007.peter@wemm.org> Cc: David Gurvich Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 21:53:49 -0000 On Friday 20 May 2005 10:02 am, Scott Long wrote: > David O'Brien wrote: > > On Thu, May 19, 2005 at 02:54:39PM -0600, Scott Long wrote: > >>David Gurvich wrote: > >>>Yes that can be done. The problem can be worked around. Should > >>> not need to be. I can use the loader from 5.3-RELEASE iso, but > >>> cannot use any from cvsup. The point here is how to fix the > >>> problem so that when building the loader works. > >> > >>Yes, something has changed that is causing problems. Would you be > >>willing to rewind your source tree incrementally until you find the > >>point where the loader works again? Once we know where that point > >> is, it'll be a whole lot easier to fix it. > > > > dwhite is experiencing the problem. He and I started unwinding > > parts of newer commits to see what broke it for him. > > Apparently it's been fixed as of about 14 hours ago. What I fixed was an amd64 build problem. The thread starter here was talking about pentium-m builds, so I assume its i386 in this case. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com "All of this is for nothing if we don't go to the stars" - JMS/B5 From owner-freebsd-current@FreeBSD.ORG Sun May 22 22:22:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0B2C916A41C; Sun, 22 May 2005 22:22:31 +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 9E12A43D5E; Sun, 22 May 2005 22:22:28 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4MMP7GZ014677; Sun, 22 May 2005 16:25:07 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <429105D8.6000106@samsco.org> Date: Sun, 22 May 2005 16:21:12 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Wemm References: <20050518051111.GA33262@Athena.infor.org> <20050520164349.GD6982@dragon.NUXI.org> <428E1815.8080500@samsco.org> <200505221453.44007.peter@wemm.org> In-Reply-To: <200505221453.44007.peter@wemm.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-current@freebsd.org, David Gurvich Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 22:22:31 -0000 Peter Wemm wrote: > On Friday 20 May 2005 10:02 am, Scott Long wrote: > >>David O'Brien wrote: >> >>>On Thu, May 19, 2005 at 02:54:39PM -0600, Scott Long wrote: >>> >>>>David Gurvich wrote: >>>> >>>>>Yes that can be done. The problem can be worked around. Should >>>>>not need to be. I can use the loader from 5.3-RELEASE iso, but >>>>>cannot use any from cvsup. The point here is how to fix the >>>>>problem so that when building the loader works. >>>> >>>>Yes, something has changed that is causing problems. Would you be >>>>willing to rewind your source tree incrementally until you find the >>>>point where the loader works again? Once we know where that point >>>>is, it'll be a whole lot easier to fix it. >>> >>>dwhite is experiencing the problem. He and I started unwinding >>>parts of newer commits to see what broke it for him. >> >>Apparently it's been fixed as of about 14 hours ago. > > > What I fixed was an amd64 build problem. The thread starter here was > talking about pentium-m builds, so I assume its i386 in this case. > Yes, the threads jumped back and forth between people experiencing problems with non-default CFLAGS and people experiencing problems with amd64. Thanks for fixing the latter. Scott From owner-freebsd-current@FreeBSD.ORG Sun May 22 23:53:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B8CA16A41C for ; Sun, 22 May 2005 23:53:35 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5343A43D49 for ; Sun, 22 May 2005 23:53:35 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.90] ([66.127.85.90]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j4MNrNms037023 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 22 May 2005 16:53:23 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42911B78.8080301@errno.com> Date: Sun, 22 May 2005 16:53:28 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dandee@volny.cz References: <20050522181904.7202B4E70E@pipa.profix.cz> In-Reply-To: <20050522181904.7202B4E70E@pipa.profix.cz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, 'Emil Mikulic' Subject: Re: ath0 goes down periodically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2005 23:53:35 -0000 Daniel Dvorak wrote: > On Thursday I reported my problem with atheros and no response. > Now we see it is common problem. Not sure why you think your problem is related to this one. > > I used ath_rate_onoe, ath_rate_amrr and now last I am testing > ath_rate_sample, and yet no "kernel: ath0: device timeout" message turns up > in /var/log/messages since last reboot after recompilation kornel with > sample rate. > > But U use sample rate and have the same messages. > So choise of ath_rate does not have a influence on timeout. > Last panic was connection to mbuf. > > My box went to panic state due to Atheros for many times, my friend advised > me to use this: > lsd# sysctl kern.ipc.maxsockbuf > kern.ipc.maxsockbuf: 2097152 Don't recall you had a panic; if so please post the strack trace. Sam From owner-freebsd-current@FreeBSD.ORG Mon May 23 00:38:43 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 589F516A41C; Mon, 23 May 2005 00:38:43 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id D653443D1D; Mon, 23 May 2005 00:38:42 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id 25E21C002; Mon, 23 May 2005 02:38:40 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id AE83E407E; Mon, 23 May 2005 02:38:43 +0200 (CEST) Date: Mon, 23 May 2005 02:38:43 +0200 From: Jeremie Le Hen To: Xin LI Message-ID: <20050523003843.GO850@obiwan.tataz.chchile.org> References: <20050522112612.GA37841@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050522112612.GA37841@frontfree.net> User-Agent: Mutt/1.5.9i Cc: freebsd-current@FreeBSD.org, delphij@FreeBSD.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 00:38:43 -0000 Hi Xin, > Dear -CURRENT users, > > I would like to solicit a test of the following patchset which is based > on DragonFly's changes, against -CURRENT, to bring high resolution console > support to FreeBSD. The current patchset can be considered as "BETA" and > I would commit it if there is no complain about this patchset in the next > week. > > The patchset can be found at: > http://people.freebsd.org/~delphij/vesa/patchset-highres.20050522 > > To use it, you will need latest -CURRENT code, and apply the patchset at > toplevel source tree, i.e. /usr/src for usual cases. Then you need to build > and reinstall your kernel, with 'options SC_PIXEL_MODE' compiled in, and > optionally options VESA if you don't want to manually load VESA support > module. A make buildworld/installworld is recommended, but I believe that > just rebuild/reinstall usr.sbin/vidcontrol is enough to get your hands on > the support for using something like 'vidcontrol MODE_239' or so, which will > switch the current console to that mode. Some mode may not work on certain > cards, though. > > Please let me know if anything strange happens; While I have been running > with the patch for a while, I would still be happy if you will report that > it works :-) > > Thanks in advance! Thanks for your work. I have used the patch for five minutes now and it seems to work well. I can switch to multiple resolutions (640x480, 800x600, 1024x768), switch console. When I set a non-supported resolution, the screen stay blanked a few seconds and then goes back to the last resolution telling this operation is not supported by device. Perfect. The mouse cursor is BEAUTIFUL !! It's far more better than the standard one in classic console mode. Note that I don't use either X or an USB mouse on this laptop. The video card is an ATI Radeon X700. One question however : is it supposed to consume more CPU than classical non-VESA text mode ? Thanks again for your work and Sacha Wildner's. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Mon May 23 01:39:12 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCC3716A41C; Mon, 23 May 2005 01:39:12 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1B3943D1F; Mon, 23 May 2005 01:39:12 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Sun, 22 May 2005 18:39:12 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 0D9835D07; Sun, 22 May 2005 18:39:12 -0700 (PDT) To: Xin LI In-reply-to: Your message of "Sun, 22 May 2005 19:26:12 +0800." <20050522112612.GA37841@frontfree.net> Date: Sun, 22 May 2005 18:39:12 -0700 From: "Kevin Oberman" Message-Id: <20050523013912.0D9835D07@ptavv.es.net> Cc: freebsd-current@FreeBSD.org, delphij@FreeBSD.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 01:39:13 -0000 > Date: Sun, 22 May 2005 19:26:12 +0800 > From: Xin LI > Sender: owner-freebsd-current@freebsd.org > > Dear -CURRENT users, > > I would like to solicit a test of the following patchset which is based > on DragonFly's changes, against -CURRENT, to bring high resolution console > support to FreeBSD. The current patchset can be considered as "BETA" and > I would commit it if there is no complain about this patchset in the next > week. > > The patchset can be found at: > http://people.freebsd.org/~delphij/vesa/patchset-highres.20050522 > > To use it, you will need latest -CURRENT code, and apply the patchset at > toplevel source tree, i.e. /usr/src for usual cases. Then you need to build > and reinstall your kernel, with 'options SC_PIXEL_MODE' compiled in, and > optionally options VESA if you don't want to manually load VESA support > module. A make buildworld/installworld is recommended, but I believe that > just rebuild/reinstall usr.sbin/vidcontrol is enough to get your hands on > the support for using something like 'vidcontrol MODE_239' or so, which will > switch the current console to that mode. Some mode may not work on certain > cards, though. > > Please let me know if anything strange happens; While I have been running > with the patch for a while, I would still be happy if you will report that > it works :-) > > Thanks in advance! > > Cheers, > -- > Xin LI http://www.delphij.net/ > See complete headers for GPG key and other information. I rebuilt my kernel and vidcontrol and tried it out. First, the good news is that 'vidcontrol -i mode' showed all of the graphics modes; about 60 of them! Now, the bad news: Setting the mode does not work. # vidcontrol MODE_387 vidcontrol: Setting video mode: Inappropriate ioctl for device or # vidcontrol MODE_281 vidcontrol: cannot activate raster mode: Inappropriate ioctl for device I'm running on an IBM T30 with Radeon M7 video and current as of Friday. Was there something other than te kernel and vidcontrol that I should have rebuilt? I did not rebuild my modules. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Mon May 23 02:15:33 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6435916A41C for ; Mon, 23 May 2005 02:15:33 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 22A5843D1D for ; Mon, 23 May 2005 02:15:33 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4N2FV2D062739; Sun, 22 May 2005 19:15:31 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4N2FRfF062734; Sun, 22 May 2005 19:15:27 -0700 (PDT) (envelope-from obrien) Date: Sun, 22 May 2005 19:15:27 -0700 From: "David O'Brien" To: Scott Long Message-ID: <20050523021527.GA62693@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Scott Long , Peter Wemm , freebsd-current@freebsd.org, David Gurvich References: <20050518051111.GA33262@Athena.infor.org> <20050520164349.GD6982@dragon.NUXI.org> <428E1815.8080500@samsco.org> <200505221453.44007.peter@wemm.org> <429105D8.6000106@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <429105D8.6000106@samsco.org> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, David Gurvich Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 02:15:33 -0000 On Sun, May 22, 2005 at 04:21:12PM -0600, Scott Long wrote: > >What I fixed was an amd64 build problem. The thread starter here was > >talking about pentium-m builds, so I assume its i386 in this case. > > Yes, the threads jumped back and forth between people experiencing > problems with non-default CFLAGS <..snip..> I've heard those problems on and off for a year now - with no one experiencing the problem spending sufficient effort to provide a decent analysis of the issue. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon May 23 02:22:24 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B05EE16A41C; Mon, 23 May 2005 02:22:24 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 00AED43D1D; Mon, 23 May 2005 02:22:23 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from kane.otenet.gr (kane.otenet.gr [195.170.0.27]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with ESMTP id j4N2ML5q031078; Mon, 23 May 2005 05:22:21 +0300 Received: from gothmog.gr (patr530-a042.otenet.gr [212.205.215.42]) by kane.otenet.gr (8.13.4/8.13.4/Debian-1) with ESMTP id j4N2KQP3031233; Mon, 23 May 2005 05:20:27 +0300 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.3/8.13.3) with ESMTP id j4N2M8eu001832; Mon, 23 May 2005 05:22:08 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.3/8.13.3/Submit) id j4N2JLIR001218; Mon, 23 May 2005 05:19:21 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Mon, 23 May 2005 05:19:21 +0300 From: Giorgos Keramidas To: Xin LI Message-ID: <20050523021921.GA1188@gothmog.gr> References: <20050522112612.GA37841@frontfree.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050522112612.GA37841@frontfree.net> Cc: freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 02:22:24 -0000 On 2005-05-22 19:26, Xin LI wrote: > Dear -CURRENT users, > I would like to solicit a test of the following patchset which is based > on DragonFly's changes, against -CURRENT, to bring high resolution console > support to FreeBSD. The current patchset can be considered as "BETA" and > I would commit it if there is no complain about this patchset in the next > week. > > The patchset can be found at: > http://people.freebsd.org/~delphij/vesa/patchset-highres.20050522 First of all, a big *thanks* for your work :-) I just rebuilt my kernel+world from today's sources, installed, then patched and reinstalled kernel+vidcontrol. All seems to work fine, and I can use a console of 1024x768, switch between consoles with different modes, start X11 and then stop it again and have the console return to its previous mode, etc. Almost everything seems to work absolutely great. Except for one minor detail: When I double click on a word, to select this word in a console window, the characters under the cursor and 1-2 characters after it get messed up a bit (i.e. foreground and background colors getting a bit mixed up where the cursor "covers" parts of the characters). - Giorgos From owner-freebsd-current@FreeBSD.ORG Mon May 23 02:23:47 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48E4C16A41C; Mon, 23 May 2005 02:23:47 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7F8043D49; Mon, 23 May 2005 02:23:46 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id D8D5BEB3998; Mon, 23 May 2005 10:23:44 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 97613132CB5; Mon, 23 May 2005 10:23:39 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 44847-20; Mon, 23 May 2005 10:23:33 +0800 (CST) Received: from [10.217.12.87] (unknown [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id A8E8A131B4D; Mon, 23 May 2005 10:23:29 +0800 (CST) From: Xin LI To: Jeremie Le Hen In-Reply-To: <20050523003843.GO850@obiwan.tataz.chchile.org> References: <20050522112612.GA37841@frontfree.net> <20050523003843.GO850@obiwan.tataz.chchile.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-TchTgTtdfKZV1x6KRlTK" Organization: The FreeBSD Simplified Chinese Project Date: Mon, 23 May 2005 10:23:25 +0800 Message-Id: <1116815005.838.3.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at frontfree.net Cc: freebsd-current@FreeBSD.org, delphij@FreeBSD.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 02:23:47 -0000 --=-TchTgTtdfKZV1x6KRlTK Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Jeremie, =E5=9C=A8 2005-05-23=E4=B8=80=E7=9A=84 02:38 +0200=EF=BC=8CJeremie Le Hen= =E5=86=99=E9=81=93=EF=BC=9A [snip] > One question however : is it supposed to consume more CPU than classical > non-VESA text mode ? I think so, it should consume more CPU than classical text mode console since it draws characters, rather than giving the responsibility to the video card. A possible optimization would be to map the video card memory into the space. Cheers, --=20 Xin LI http://www.delphij.net/ --=-TchTgTtdfKZV1x6KRlTK Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCkT6d/cVsHxFZiIoRAnwRAJ9EL+cFmkCkpbEPUz72WdOlwQMYpQCgi+qR O6jz0cIz/+0qGJWkG/Dn7yI= =KKFb -----END PGP SIGNATURE----- --=-TchTgTtdfKZV1x6KRlTK-- From owner-freebsd-current@FreeBSD.ORG Mon May 23 02:37:43 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 98ABF16A41C; Mon, 23 May 2005 02:37:43 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 068B643D53; Mon, 23 May 2005 02:37:43 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 00377EB39BD; Mon, 23 May 2005 10:37:40 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 00B1B13395F; Mon, 23 May 2005 10:37:37 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45973-02; Mon, 23 May 2005 10:37:31 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id E89A91327BF; Mon, 23 May 2005 10:37:30 +0800 (CST) Date: Mon, 23 May 2005 10:37:30 +0800 From: Xin LI To: Alexandre Sunny Kovalenko Message-ID: <20050523023730.GA46012@frontfree.net> References: <20050522112612.GA37841@frontfree.net> <1116787423.786.10.camel@RabbitsDen> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline In-Reply-To: <1116787423.786.10.camel@RabbitsDen> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.3-RELEASE-p2 FreeBSD 5.3-RELEASE-p2 #15: Wed Dec 15 10:43:16 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net Cc: freebsd-current@FreeBSD.org, delphij@FreeBSD.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 02:37:43 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, Alexandre, On Sun, May 22, 2005 at 02:43:43PM -0400, Alexandre Sunny Kovalenko wrote: > On Sun, 2005-05-22 at 19:26 +0800, Xin LI wrote: [snip] > I have observed some odd behavior when X display becomes garbled if USB > stack is loaded and USB keyboard is attached after user has logged into > X desktop (Gnome in my case). I am setting MODE_280 (1024x768x32) in > rc.conf using 'allscreens_flags'. > > I have been playing with it a bit and found out that I can achieve the > same result by doing 'vidcontrol MODE_280 < /dev/ttyv8 > /dev/ttyv8' > after logging into Gnome. And ttyv8 is the terminal, occupied by X > display. Restarting X server cures the problem. Thanks for the feedback. I don't have an USB keyboard at hand but I will try if I would be able to track it down. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --OgqxwSJOaUobr8KG Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCkUHq/cVsHxFZiIoRAu64AJ9OW2j8UYu1O//VpilcsRIkih5Q6ACbB0eA drgx78k6StC0j1WvFcPqvaA= =mihm -----END PGP SIGNATURE----- --OgqxwSJOaUobr8KG-- From owner-freebsd-current@FreeBSD.ORG Mon May 23 02:47:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ECE4F16A41C for ; Mon, 23 May 2005 02:47:41 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B3F443D53 for ; Mon, 23 May 2005 02:47:41 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by wproxy.gmail.com with SMTP id 37so1512225wra for ; Sun, 22 May 2005 19:47:40 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=i2yGj4lUL5sfxV02SD91Tc6IJd7RzqPuhKeduyaZq13ytOQSo6K/CwfyjuR1Q5z+RBx9vn4OvgDIjhHy6Aq+BpYsyAIWvooRBUK8E6vDcczoJNP2nKZsvW0+owRfs6jZ02KeqIdPY4hSTYIpzBb9Hbh9aGe9vsyGznklVwtxnCQ= Received: by 10.54.44.51 with SMTP id r51mr3669263wrr; Sun, 22 May 2005 19:47:40 -0700 (PDT) Received: from ?192.168.1.200? ([213.64.231.30]) by mx.gmail.com with ESMTP id 34sm595102wra.2005.05.22.19.47.39; Sun, 22 May 2005 19:47:40 -0700 (PDT) Message-ID: <42914446.4000203@gmail.com> Date: Mon, 23 May 2005 04:47:34 +0200 From: Pawel Worach User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050521) X-Accept-Language: en-us, en MIME-Version: 1.0 To: obrien@freebsd.org References: <20050518051111.GA33262@Athena.infor.org> <20050520164349.GD6982@dragon.NUXI.org> <428E1815.8080500@samsco.org> <200505221453.44007.peter@wemm.org> <429105D8.6000106@samsco.org> <20050523021527.GA62693@dragon.NUXI.org> In-Reply-To: <20050523021527.GA62693@dragon.NUXI.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, David Gurvich Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 02:47:42 -0000 David O'Brien wrote: > On Sun, May 22, 2005 at 04:21:12PM -0600, Scott Long wrote: > >>>What I fixed was an amd64 build problem. The thread starter here was >>>talking about pentium-m builds, so I assume its i386 in this case. >> >>Yes, the threads jumped back and forth between people experiencing >>problems with non-default CFLAGS <..snip..> > > > I've heard those problems on and off for a year now - with no one > experiencing the problem spending sufficient effort to provide a decent > analysis of the issue. > I'm seeing the same thing if CPUTYPE is set to "pentium-m" while "pentium2" works fine. Loader crashes on start, is there a way to make it freeze instead of reset to capture the register dump? Kernel/world works fine with the pentium-m CPUTYPE if booted with loader.old. This in on a IBM T41 with a cpu as detected below. CPU: Intel(R) Pentium(R) M processor 1700MHz (1698.56-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x695 Stepping = 5 Features=0xa7e9f9bf Features2=0x180 -- Pawel From owner-freebsd-current@FreeBSD.ORG Mon May 23 02:48:29 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4460116A41C; Mon, 23 May 2005 02:48:29 +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 748DF43D55; Mon, 23 May 2005 02:48:23 +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 j4N2owJ0015754; Sun, 22 May 2005 20:50:58 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42914448.5020505@samsco.org> Date: Sun, 22 May 2005 20:47:36 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.5) Gecko/20050218 X-Accept-Language: en-us, en MIME-Version: 1.0 To: obrien@freebsd.org References: <20050518051111.GA33262@Athena.infor.org> <20050520164349.GD6982@dragon.NUXI.org> <428E1815.8080500@samsco.org> <200505221453.44007.peter@wemm.org> <429105D8.6000106@samsco.org> <20050523021527.GA62693@dragon.NUXI.org> In-Reply-To: <20050523021527.GA62693@dragon.NUXI.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: freebsd-current@freebsd.org, David Gurvich Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 02:48:29 -0000 David O'Brien wrote: > On Sun, May 22, 2005 at 04:21:12PM -0600, Scott Long wrote: > >>>What I fixed was an amd64 build problem. The thread starter here was >>>talking about pentium-m builds, so I assume its i386 in this case. >> >>Yes, the threads jumped back and forth between people experiencing >>problems with non-default CFLAGS <..snip..> > > > I've heard those problems on and off for a year now - with no one > experiencing the problem spending sufficient effort to provide a decent > analysis of the issue. > Re-read the threads. There is a lot of good analysis on how gcc was emitting SSE instructions. Scott From owner-freebsd-current@FreeBSD.ORG Mon May 23 04:37:00 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E26DB16A41C for ; Mon, 23 May 2005 04:37:00 +0000 (GMT) (envelope-from david.freebsd@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id AF8FF43D48 for ; Mon, 23 May 2005 04:37:00 +0000 (GMT) (envelope-from david.freebsd@verizon.net) Received: from OSTest ([68.161.118.114]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGX006G9E5NQT19@vms042.mailsrvcs.net> for freebsd-current@freebsd.org; Sun, 22 May 2005 23:36:59 -0500 (CDT) Date: Sun, 22 May 2005 23:40:27 -0400 From: David Gurvich In-reply-to: <20050522114524.B27009@carver.gumbysoft.com> To: freebsd-current@freebsd.org Message-id: <200505222340.27785.david.freebsd@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Content-disposition: inline References: <20050518051111.GA33262@Athena.infor.org> <200505210727.23320.david.freebsd@verizon.net> <20050522114524.B27009@carver.gumbysoft.com> User-Agent: KMail/1.8 Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 04:37:01 -0000 On Sunday 22 May 2005 14:45, Doug White wrote: > On Sat, 21 May 2005, David Gurvich wrote: > > New cvsup cycle has not fixed the problem. Might it have anything to do > > with the fact my freebsd partition is not the first partition? > > Unlikely ... are you _sure_ you updated your sources correctly and you're > booting the fixed loader? I am sure. I had previously copied the old loader to a backup location and then copied that to /boot/loader. Then the cvsup, buildworld kernel and install cycle. The new loader does what all the previous loaders did that failed to work correctly. It would get to a point where I could either escape to the #boot prompt and have it use the older loader or go into a reboot cycle. I am currently using the older loader. Using the older loader I have had no problems with the system other than KWrite crashing when doing a search. From owner-freebsd-current@FreeBSD.ORG Mon May 23 05:57:00 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2020916A41C for ; Mon, 23 May 2005 05:57:00 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id DEBF543D1D for ; Mon, 23 May 2005 05:56:59 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from SMILEY (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id AB2B119F52 for ; Sun, 22 May 2005 22:57:49 -0700 (PDT) From: "Darren Pilgrim" To: Date: Sun, 22 May 2005 22:56:47 -0700 Message-ID: <002a01c55f5c$38218d00$0a2a15ac@SMILEY> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <200505222340.27785.david.freebsd@verizon.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal Subject: RE: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 05:57:00 -0000 I'm running -CURRENT compiled with CPUTYPE?=3Dpentium-m on a = Sonoma-platform notebook. Sources fresh this afternoon work fine, as did sources = cvsup'd on 5/13. 5.3-R and 5.4-R worked fine as well. I dual-boot and let Windows XP's boot manager run the show, so I'm may be skipping the part of the loader with the problem. FreeBSD is flawless on this machine, so I'm all for helping nail this = bug down. Anything I can dump, post, rebuild, etc.? From owner-freebsd-current@FreeBSD.ORG Mon May 23 06:21:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B96BA16A41C for ; Mon, 23 May 2005 06:21:15 +0000 (GMT) (envelope-from roger@gwch.net) Received: from mail.gwch.net (80-219-201-207.dclient.hispeed.ch [80.219.201.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 58A7B43D1F for ; Mon, 23 May 2005 06:21:15 +0000 (GMT) (envelope-from roger@gwch.net) Received: from localhost (link [127.0.0.1]) by mail.gwch.net (Postfix) with ESMTP id 6F29D4086B for ; Mon, 23 May 2005 08:23:40 +0200 (CEST) Received: from mail.gwch.net ([127.0.0.1]) by localhost (mail.gwch.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03092-07 for ; Mon, 23 May 2005 08:23:37 +0200 (CEST) Received: from www.gwch.net (mordor.gwch.net [192.168.2.102]) by mail.gwch.net (Postfix) with ESMTP id 9EA1A4086A for ; Mon, 23 May 2005 08:23:37 +0200 (CEST) Received: from 62.2.21.164 (SquirrelMail authenticated user rogerg) by www.gwch.net with HTTP; Mon, 23 May 2005 08:21:10 +0200 (CEST) Message-ID: <53594.62.2.21.164.1116829270.squirrel@www.gwch.net> Date: Mon, 23 May 2005 08:21:10 +0200 (CEST) From: "Roger Grosswiler" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.4-2 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 gwch.net Subject: openoffice-setup not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: roger@gwch.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 06:21:15 -0000 Hi, after having installed the packages from openoffice, i tried to install openoffice via openoffice-setup as explained in the manual. I only got the message "openoffice-setup not found" Is there a hint for openoffice? I even did not find oowriter.. Roger From owner-freebsd-current@FreeBSD.ORG Mon May 23 07:51:28 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 23CD016A41C; Mon, 23 May 2005 07:51:28 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id C767543D1F; Mon, 23 May 2005 07:51:27 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id D8BBFC091; Mon, 23 May 2005 09:51:26 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 46D0E407E; Mon, 23 May 2005 09:51:28 +0200 (CEST) Date: Mon, 23 May 2005 09:51:28 +0200 From: Jeremie Le Hen To: Xin LI Message-ID: <20050523075128.GP850@obiwan.tataz.chchile.org> References: <20050522112612.GA37841@frontfree.net> <20050523003843.GO850@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523003843.GO850@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.9i Cc: freebsd-current@FreeBSD.org, delphij@FreeBSD.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 07:51:28 -0000 Xin, > I have used the patch for five minutes now and it seems to work well. > I can switch to multiple resolutions (640x480, 800x600, 1024x768), switch > console. When I set a non-supported resolution, the screen stay blanked > a few seconds and then goes back to the last resolution telling this > operation is not supported by device. Perfect. Nearly perfect :-). I use the fade saver and when I woke up this morning, going back from the screen saver turned the VESA console text into blue. Not the whole text, just the non-brilliant one. This is not the case on non-VESA consoles. Switching to another console suffices to get back the orignal text color. I didn't tested whether the blue turns into another color if I change the default text color, but displaying various colors with vim (blue, red, yellow), it appears that all colors are, at least, darkened. Note that as far as I tested, this is not specific to any screensaver, it seems to be ensued by a generic piece of code. I tried changing the resolution and I managed to get another color : instead of blue, I got red :-). Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Mon May 23 08:08:23 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D5C216A41C; Mon, 23 May 2005 08:08:23 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-2.free.fr (postfix4-2.free.fr [213.228.0.176]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EB0B43D1D; Mon, 23 May 2005 08:08:23 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix4-2.free.fr (Postfix) with ESMTP id 0E8B831D9C4; Mon, 23 May 2005 10:08:22 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 264214080; Mon, 23 May 2005 10:08:25 +0200 (CEST) Date: Mon, 23 May 2005 10:08:25 +0200 From: Jeremie Le Hen To: Giorgos Keramidas Message-ID: <20050523080825.GQ850@obiwan.tataz.chchile.org> References: <20050522112612.GA37841@frontfree.net> <20050523021921.GA1188@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523021921.GA1188@gothmog.gr> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 08:08:23 -0000 > Almost everything seems to work absolutely great. Except for one minor > detail: > > When I double click on a word, to select this word in a console window, > the characters under the cursor and 1-2 characters after it get messed > up a bit (i.e. foreground and background colors getting a bit mixed up > where the cursor "covers" parts of the characters). Confirmed. Another question : many notebook screens now support what I would call bastard resolution (something like 1280x800 IIRC). Is there any way to get these kind of modes ? Currently it seems not, but I wonder if it would be easily possible. Thanks. -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Mon May 23 09:04:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8511416A41C for ; Mon, 23 May 2005 09:04:30 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3A2E143D49 for ; Mon, 23 May 2005 09:04:30 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1Da8rJ-0004dM-00; Mon, 23 May 2005 11:04:25 +0200 Date: Mon, 23 May 2005 11:04:25 +0200 To: Jeremie Le Hen Message-ID: <20050523090425.GW21800@poupinou.org> References: <20050517163212.GG14297@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050517163212.GG14297@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot Cc: freebsd-current@FreeBSD.org Subject: Re: ACPI errors with recent laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 09:04:30 -0000 On Tue, May 17, 2005 at 06:32:12PM +0200, Jeremie Le Hen wrote: > I run a -CURRENT kernel from yesterday on my very recent laptop (Acer > Extensa 4100), but it has a few problems with ACPI. In particular, > I have some weird error at boot time or when I run "sysctl hw.acpi" > and I can't get the screen back from S3 state. > > I attached the boot -v output with this mail. Please feel free to > contact me to have more informations. > I think I have already seen that error. The only way to go is to dump the asl, and replace some names (Z00?) with Zero, then override the dsdt with the corrected one. You can post to me a dump to the asl and I will correct this one. -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-current@FreeBSD.ORG Mon May 23 09:06:29 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E292E16A48C for ; Mon, 23 May 2005 09:06:28 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id B223343D55 for ; Mon, 23 May 2005 09:06:27 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 23 May 2005 09:06:25 -0000 Received: from h081217095201.dyn.cm.kabsi.at (EHLO localhost.localdomain) [81.217.95.201] by mail.gmx.net (mp009) with SMTP; 23 May 2005 11:06:25 +0200 X-Authenticated: #16703784 From: Stefan Ehmann To: Jeremie Le Hen In-Reply-To: <20050523080825.GQ850@obiwan.tataz.chchile.org> References: <20050522112612.GA37841@frontfree.net> <20050523021921.GA1188@gothmog.gr> <20050523080825.GQ850@obiwan.tataz.chchile.org> Content-Type: text/plain Date: Mon, 23 May 2005 11:06:24 +0200 Message-Id: <1116839184.1441.4.camel@taxman.pepperland> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-current@freebsd.org, delphij@freebsd.org, Giorgos Keramidas Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 09:06:30 -0000 On Mon, 2005-05-23 at 10:08 +0200, Jeremie Le Hen wrote: > > Almost everything seems to work absolutely great. Except for one minor > > detail: > > > > When I double click on a word, to select this word in a console window, > > the characters under the cursor and 1-2 characters after it get messed > > up a bit (i.e. foreground and background colors getting a bit mixed up > > where the cursor "covers" parts of the characters). > > Confirmed. > > Another question : many notebook screens now support what I would call > bastard resolution (something like 1280x800 IIRC). Is there any way to > get these kind of modes ? Currently it seems not, but I wonder if it > would be easily possible. I got following modes listed that just work fine: 380 (0x17c) 0x0000000f G 1280x800x8 1 8x16 0xa0000 64k 64k 0xe8000000 32576k 381 (0x17d) 0x0000000f G 1280x800x16 1 8x16 0xa0000 64k 64k 0xe8000000 32576k 382 (0x17e) 0x0000000f G 1280x800x32 1 8x16 0xa0000 64k 64k 0xe8000000 32576k -- Stefan Ehmann From owner-freebsd-current@FreeBSD.ORG Mon May 23 10:22:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACB5716A41C for ; Mon, 23 May 2005 10:22:18 +0000 (GMT) (envelope-from mjsaarin@cc.helsinki.fi) Received: from sender-02.it.helsinki.fi (sender-02.it.helsinki.fi [128.214.205.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id 221FA43D1F for ; Mon, 23 May 2005 10:22:17 +0000 (GMT) (envelope-from mjsaarin@cc.helsinki.fi) Received: from lagavulin.it.helsinki.fi (lagavulin.it.helsinki.fi [128.214.38.143]) by sender-02.it.helsinki.fi (8.13.3/8.13.3) with ESMTP id j4NAMFU3015410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 23 May 2005 13:22:15 +0300 Received: (from mjs@localhost) by lagavulin.it.helsinki.fi (8.13.3/8.13.1/Submit) id j4NAMEdJ058340; Mon, 23 May 2005 13:22:14 +0300 (EEST) (envelope-from mjsaarin@cc.helsinki.fi) X-Authentication-Warning: lagavulin.it.helsinki.fi: mjs set sender to mjsaarin@cc.helsinki.fi using -f From: Matti Saarinen To: freebsd-current@freebsd.org Organization: University of Helsinki References: <20050521105919.63c09ff4@localhost> Date: Mon, 23 May 2005 13:22:14 +0300 In-Reply-To: <20050521105919.63c09ff4@localhost> (Fabian Keil's message of "Sat, 21 May 2005 10:59:19 +0200") Message-ID: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Re: if_ipw not working on T41 with 2005-05-20's CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 10:22:18 -0000 Fabian Keil writes: > Matti Saarinen wrote: > >> For some reason the ipw driver has stopped working on my laptop (IBM >> T41). It used to work when the laptop ran CURRENT from 2005-04-11. >> Now, when I upgraded at the beginnig of May the wireless connection >> just stops and loses connectivity. The system logs >> >> ipw0: fatal error >> >> and the interface goes down. > > Did you rebuild if_ipw.ko after you updated the system? I wish my problem was so easy, but unfortunately it does not seem to be. Nowadays, if_ipw is part on the system. I also checked that the if_ipw.ko is the one that was built when I did make buildkernel Cheers, -- - Matti - From owner-freebsd-current@FreeBSD.ORG Mon May 23 10:29:24 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B15CC16A41C for ; Mon, 23 May 2005 10:29:24 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from mail.rdu.kirov.ru (ns.rdu.kirov.ru [217.9.151.217]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0FC4643D48 for ; Mon, 23 May 2005 10:29:23 +0000 (GMT) (envelope-from bu7cher@yandex.ru) Received: from kirov.so-cdu.ru (kirov [172.21.81.1]) by mail.rdu.kirov.ru (Postfix) with ESMTP id 805A7FE3F for ; Mon, 23 May 2005 14:29:21 +0400 (MSD) Received: from kirov.so-cdu.ru (localhost [127.0.0.1]) by rdu.kirov.ru (Postfix) with SMTP id 5E0921560D for ; Mon, 23 May 2005 14:29:21 +0400 (MSD) Received: from [172.21.81.52] (elsukov.kirov.so-cdu.ru [172.21.81.52]) by rdu.kirov.ru (Postfix) with ESMTP id 3858B155D8 for ; Mon, 23 May 2005 14:29:21 +0400 (MSD) Message-ID: <4291B081.4000308@yandex.ru> Date: Mon, 23 May 2005 14:29:21 +0400 From: "Andrey V. Elsukov" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: IPFW2 patch X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: bu7cher@yandex.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 10:29:24 -0000 Hello, Developers! Sorry, my english is bad. :( Patch to IPFW2 for adding restrictions of the traffic with use IPFW bytes counters. It include two parts: * First part is ipfw_bound.patch, this part add ipfw rule options "bound VALUE" and "check-bound NUM". Example: # ipfw add 100 allow ip from any to any bound 10K # ipfw add 200 deny ip from any to any While bytes counter of rule 100 below 10 KBytes, it work. Example: # ipfw add 100 allow ip from A.B.C.D to any out xmit internet check-bound 200 # ipfw add 200 allow ip from any to A.B.C.D in recv internet bound 100M # ipfw add 300 deny ip from any to any via internet While bytes counter of rule 200 below 100 MBytes, rules 100 and 200 work. NOTE: Check-bound option search rule NUM like "ipfw skipto", but if rule NUM not contain bound option, then match fail. Second part is bound_change.patch, this part add control call to ipfw for boundary value change without bytes counter reset. Syntax: # ipfw bound NUM [set N] change VALUE. Files: For CURRENT: http://butcher.heavennet.ru/ipfw_bound/CURRENT/ipfw_bound.patch http://butcher.heavennet.ru/ipfw_bound/CURRENT/bound_change.patch For RELENG_5: http://butcher.heavennet.ru/ipfw_bound/RELENG_5/ipfw_bound.patch http://butcher.heavennet.ru/ipfw_bound/RELENG_5/bound_change.patch For RELENG_5_4: http://butcher.heavennet.ru/ipfw_bound/RELENG_5_4/ipfw_bound.patch http://butcher.heavennet.ru/ipfw_bound/RELENG_5_4/bound_change.patch -- WBR, Andrey V. Elsukov From owner-freebsd-current@FreeBSD.ORG Mon May 23 10:35:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BF58316A41C for ; Mon, 23 May 2005 10:35:18 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id F226443D1D for ; Mon, 23 May 2005 10:35:15 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 23 May 2005 10:35:13 -0000 Received: from h081217095201.dyn.cm.kabsi.at (EHLO localhost.localdomain) [81.217.95.201] by mail.gmx.net (mp021) with SMTP; 23 May 2005 12:35:13 +0200 X-Authenticated: #16703784 From: Stefan Ehmann To: David Gurvich In-Reply-To: <200505222340.27785.david.freebsd@verizon.net> References: <20050518051111.GA33262@Athena.infor.org> <200505210727.23320.david.freebsd@verizon.net> <20050522114524.B27009@carver.gumbysoft.com> <200505222340.27785.david.freebsd@verizon.net> Content-Type: text/plain Date: Mon, 23 May 2005 12:35:13 +0200 Message-Id: <1116844513.1441.19.camel@taxman.pepperland> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-current@freebsd.org Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 10:35:18 -0000 On Sun, 2005-05-22 at 23:40 -0400, David Gurvich wrote: > On Sunday 22 May 2005 14:45, Doug White wrote: > > On Sat, 21 May 2005, David Gurvich wrote: > > > New cvsup cycle has not fixed the problem. Might it have anything to do > > > with the fact my freebsd partition is not the first partition? > > > > Unlikely ... are you _sure_ you updated your sources correctly and you're > > booting the fixed loader? > I am sure. I had previously copied the old loader to a backup location and > then copied that to /boot/loader. Then the cvsup, buildworld kernel and > install cycle. The new loader does what all the previous loaders did that > failed to work correctly. It would get to a point where I could either > escape to the #boot prompt and have it use the older loader or go into a > reboot cycle. I am currently using the older loader. Using the older loader > I have had no problems with the system other than KWrite crashing when doing > a search. Same thing here with CPUTYPE=pentium-m on my notebook. I'm using grub as boot loader. As soon as /boot/loader is booted, the machine resets. I've also seen the kwrite search crash - but don't know if this is related. Also, I had a similar problem with grub when I installed some months ago from the ports. I downloaded a newer version from the homepage and installed it manually which just worked fine (I suppose because no cputype/optimization was set when compiling by hand). -- Stefan Ehmann From owner-freebsd-current@FreeBSD.ORG Mon May 23 12:19:47 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A565816A41C for ; Mon, 23 May 2005 12:19:47 +0000 (GMT) (envelope-from svein-freebsd-current@theloosingend.net) Received: from royk.itea.ntnu.no (royk.itea.ntnu.no [129.241.190.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A94043D1D for ; Mon, 23 May 2005 12:19:45 +0000 (GMT) (envelope-from svein-freebsd-current@theloosingend.net) Received: from localhost (localhost [127.0.0.1]) by royk.itea.ntnu.no (Postfix) with ESMTP id D112D66D7C for ; Mon, 23 May 2005 14:19:43 +0200 (CEST) Received: from maren.thelosingend.net (maren.math.ntnu.no [129.241.211.48]) by royk.itea.ntnu.no (Postfix) with SMTP for ; Mon, 23 May 2005 14:19:43 +0200 (CEST) Received: (qmail 47337 invoked by uid 1001); 23 May 2005 14:19:42 +0200 Received: from localhost (sendmail-bs@127.0.0.1) by localhost with SMTP; 23 May 2005 14:19:42 +0200 Date: Mon, 23 May 2005 14:19:42 +0200 (CEST) From: Svein Halvor Halvorsen X-X-Sender: sveinhal@maren.thelosingend.net To: Roger Grosswiler In-Reply-To: <53594.62.2.21.164.1116829270.squirrel@www.gwch.net> Message-ID: <20050523141411.S47305@maren.thelosingend.net> References: <53594.62.2.21.164.1116829270.squirrel@www.gwch.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Content-Scanned: with sophos and spamassassin at mailgw.ntnu.no. Cc: freebsd-current@freebsd.org Subject: Re: openoffice-setup not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 12:19:47 -0000 * Roger Grosswiler [2005-05-23 08:21 +0200] > after having installed the packages from openoffice, i tried to install > openoffice via openoffice-setup as explained in the manual. I only got > the message "openoffice-setup not found" > > Is there a hint for openoffice? I even did not find oowriter.. I'm nut sure what kind of manual you are talking about, but on my system these applications are installed as openoffice.org-1.1.4-setup openoffice.org-1.1.4-writer &c. These are just wrappers (or rather a wrapper) for /usr/local/OpenOffice.org1.1.4/program/setup /usr/local/OpenOffice.org1.1.4/program/writer &c. From owner-freebsd-current@FreeBSD.ORG Mon May 23 12:34:19 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D90D16A41C for ; Mon, 23 May 2005 12:34:19 +0000 (GMT) (envelope-from roger@gwch.net) Received: from mail.gwch.net (80-219-201-207.dclient.hispeed.ch [80.219.201.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 35FD643D1D for ; Mon, 23 May 2005 12:34:19 +0000 (GMT) (envelope-from roger@gwch.net) Received: from localhost (link [127.0.0.1]) by mail.gwch.net (Postfix) with ESMTP id 18B2E40854 for ; Mon, 23 May 2005 14:36:46 +0200 (CEST) Received: from mail.gwch.net ([127.0.0.1]) by localhost (mail.gwch.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04902-04 for ; Mon, 23 May 2005 14:36:42 +0200 (CEST) Received: from www.gwch.net (mordor.gwch.net [192.168.2.102]) by mail.gwch.net (Postfix) with ESMTP id C6DD44084E for ; Mon, 23 May 2005 14:36:42 +0200 (CEST) Received: from 62.2.21.164 (SquirrelMail authenticated user rogerg) by www.gwch.net with HTTP; Mon, 23 May 2005 14:34:14 +0200 (CEST) Message-ID: <51554.62.2.21.164.1116851654.squirrel@www.gwch.net> In-Reply-To: <20050523141411.S47305@maren.thelosingend.net> References: <53594.62.2.21.164.1116829270.squirrel@www.gwch.net> <20050523141411.S47305@maren.thelosingend.net> Date: Mon, 23 May 2005 14:34:14 +0200 (CEST) From: "Roger Grosswiler" To: current@freebsd.org User-Agent: SquirrelMail/1.4.4-2 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 gwch.net Cc: Subject: Re: openoffice-setup not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: roger@gwch.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 12:34:19 -0000 > > * Roger Grosswiler [2005-05-23 08:21 +0200] >> after having installed the packages from openoffice, i tried to install >> openoffice via openoffice-setup as explained in the manual. I only got >> the message "openoffice-setup not found" >> >> Is there a hint for openoffice? I even did not find oowriter.. > > > I'm nut sure what kind of manual you are talking about, but on my system > these applications are installed as > > openoffice.org-1.1.4-setup > openoffice.org-1.1.4-writer > &c. > > > These are just wrappers (or rather a wrapper) for > > /usr/local/OpenOffice.org1.1.4/program/setup > /usr/local/OpenOffice.org1.1.4/program/writer > &c. > > > Hey, thanks for the info. I was talking about the freebsd-manual from the freebsd-homepage. Roger From owner-freebsd-current@FreeBSD.ORG Mon May 23 12:44:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E3E4F16A41C for ; Mon, 23 May 2005 12:44:52 +0000 (GMT) (envelope-from cpghost@cordula.ws) Received: from fw.farid-hajji.net (fw.farid-hajji.net [213.146.115.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5389143D1D for ; Mon, 23 May 2005 12:44:51 +0000 (GMT) (envelope-from cpghost@cordula.ws) Received: from [192.168.254.11] (epia-2 [192.168.254.11]) by fw.farid-hajji.net (Postfix) with ESMTP id 97BDB4BF6B; Mon, 23 May 2005 14:42:07 +0200 (CEST) Message-ID: <4291D0CA.9090706@cordula.ws> Date: Mon, 23 May 2005 14:47:06 +0200 From: cpghost User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050428) X-Accept-Language: en-us, en MIME-Version: 1.0 To: yongari@rndsoft.co.kr References: <4286AB34.6050101@elischer.org> <20050515093422.GA18361@fw.farid-hajji.net> <42871944.4030506@elischer.org> <20050516022100.GB1020@rndsoft.co.kr> In-Reply-To: <20050516022100.GB1020@rndsoft.co.kr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Current , Julian Elischer Subject: Re: skype on current/5.x and maestro-2E sound X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 12:44:53 -0000 Pyun YongHyeon wrote: >On Sun, May 15, 2005 at 02:41:24AM -0700, Julian Elischer wrote: > > cpghost@cordula.ws wrote: > > >On Sat, May 14, 2005 at 06:51:48PM -0700, Julian Elischer wrote: > > > > > >>Has anyone run skype successfully on these versions (5 or 6) of freeBSD? > > >>I can run it successfully on 4.x but on my 5.x machine the audio is > > >>completely > > >>broken up. like someone is chopping the audio stream. > > > > > > > > >I'm running Skype on 5.4 (via82c686). On an AMD Duron 1200 MHz, the > > >sound quality is all right; on an EPIA 5000 Eden 500 MHz (also via82c686), > > >the sound is totally chopped and it is impossible to follow. > > > > hmm so maybe its the fact that my machine is too slow.. it's also 500MHz > > my 1GHz 4.11 machine seems to run it fine. > > > >I don't think 500MHz is too slow. Check if kernel converters >are active when you play audio samples.(cat /dev/sndstat after >setting hw.snd.verbose=2). > > This is what I get while skype plays the chopped sound of the echo service: epia2# cat /dev/sndstat FreeBSD Audio Driver (newpcm) Installed devices: pcm0: at io 0xdc00 irq 10 kld snd_via82c686 (1p/1r/0v channels duplex default) [pcm0:play:0]: spd 48000, fmt 0x00000010, flags 0x00003030, 0x00000000, pid 78793 interrupts 18062, underruns 4824, ready 3580 {userland} -> feeder_root(0x00000010) -> {hardware} [pcm0:record:0]: spd 48000, fmt 0x00000010, flags 0x00003030, 0x00000000, pid 78793 interrupts 16968, overruns 4808, hfree 512, sfree 3584 {hardware} -> feeder_root(0x00000010) -> {userland} No idea how to interpret this. >Since the driver also needs Giant lock it may suffer from interrupt >latencies with other devices. In addition if it share IRQ with >other devices(e.g. USB) the issue would be noticable. > > None that I know of: epia2# vmstat -i interrupt total rate irq0: clk 30624081 99 irq1: atkbd0 416592 1 irq8: rtc 39199914 128 irq10: pcm0 1210380 3 irq11: vr0 531082 1 irq12: psm0 1354640 4 irq13: npx0 1 0 irq14: ata0 3681643 12 Total 77018333 251 irc10 is not shared by any other likely interrupt source, or so it seems. Regards, -cpghost. -- Cordula's Web. http://www.cordula.ws/ From owner-freebsd-current@FreeBSD.ORG Mon May 23 13:22:04 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4470216A41C for ; Mon, 23 May 2005 13:22:04 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1B8B43D1F for ; Mon, 23 May 2005 13:22:03 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-1.free.fr (Postfix) with ESMTP id 139CC17348A; Mon, 23 May 2005 15:22:02 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 36F1D407E; Mon, 23 May 2005 15:22:04 +0200 (CEST) Date: Mon, 23 May 2005 15:22:04 +0200 From: Jeremie Le Hen To: Bruno Ducrot Message-ID: <20050523132204.GZ850@obiwan.tataz.chchile.org> References: <20050517163212.GG14297@obiwan.tataz.chchile.org> <20050523090425.GW21800@poupinou.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523090425.GW21800@poupinou.org> User-Agent: Mutt/1.5.9i Cc: freebsd-current@FreeBSD.org, Jeremie Le Hen Subject: Re: ACPI errors with recent laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 13:22:04 -0000 Hi Bruno, > I think I have already seen that error. The only way to go is to dump > the asl, and replace some names (Z00?) with Zero, then override the dsdt > with the corrected one. > You can post to me a dump to the asl and I will correct this one. Here it is, thanks. http://jeremie.le-hen.org/~tataz/acpidump.gz Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Mon May 23 14:43:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3846B16A41C for ; Mon, 23 May 2005 14:43:58 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1203F43D1D for ; Mon, 23 May 2005 14:43:58 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DaE9r-000Dbb-MO for freebsd-current@freebsd.org; Mon, 23 May 2005 14:43:55 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DaE9c-0000Mb-59 for freebsd-current@freebsd.org; Mon, 23 May 2005 10:43:40 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17041.60442.522858.744833@roam.psg.com> Date: Mon, 23 May 2005 10:43:38 -0400 To: FreeBSD Current References: <200504191530.j3JFUvWD030545@energistic.com> <20050419165227.GA86651@energistic.com> <20050420005744.Y64858@lexi.siliconlandmark.com> <200504271404.10021.jhb@FreeBSD.org> Subject: Re: kernel.old not used any longer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 14:43:58 -0000 > On Wednesday 20 April 2005 01:02 am, Andre Guibert de Bruet wrote: >> On Tue, 19 Apr 2005, Steve Ames wrote: >>> Hrm. Almost the same as you. On mine that first comparison is actually >>> "!= //boot/kernel". Likely because I have "DESTDIR?=/" in /etc/make.conf. >>> >>> Hrm. Suddenly all makes sense. I defined DESTDIR so that 'make world' >>> would continue to work normally (instead of doing >>> buildworld/installworld) and that probably happened around August '04. >>> >>> So I guess if I get rid of DESTDIR and start doing >>> buildworld/installworld then I get kernel.old functionality again... >>> however this tastes like a bug to me. Perhaps that comparison should be: >>> >>> "!= ${DESTIR}/boot/kernel" ?? >> >> This is not a bug. You are looking for the functionality that is offered >> by HISTORICAL_MAKE_WORLD. > > This isn't part of make world. I do think he has found a bug. ru@ is the > person to ask. sorry to be slow (marriage and honeymoon (aborted due to medical emergency in wife's family)), but what happened to this thread? i just cvsupped and did a make kernel with /etc/make.conf having KERNCONF=MYKERNEL, and did not get kernel.old. randy From owner-freebsd-current@FreeBSD.ORG Mon May 23 14:58:13 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B212A16A41C for ; Mon, 23 May 2005 14:58:13 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6C8F943D48 for ; Mon, 23 May 2005 14:58:13 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1DaENe-0004rG-00; Mon, 23 May 2005 16:58:10 +0200 Date: Mon, 23 May 2005 16:58:10 +0200 To: Jeremie Le Hen Message-ID: <20050523145810.GY21800@poupinou.org> References: <20050517163212.GG14297@obiwan.tataz.chchile.org> <20050523090425.GW21800@poupinou.org> <20050523132204.GZ850@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523132204.GZ850@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot Cc: freebsd-current@FreeBSD.org Subject: Re: ACPI errors with recent laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 14:58:13 -0000 On Mon, May 23, 2005 at 03:22:04PM +0200, Jeremie Le Hen wrote: > Hi Bruno, > > > I think I have already seen that error. The only way to go is to dump > > the asl, and replace some names (Z00?) with Zero, then override the dsdt > > with the corrected one. > > You can post to me a dump to the asl and I will correct this one. > > Here it is, thanks. > http://jeremie.le-hen.org/~tataz/acpidump.gz > The patch attached allow to compile at least and will correct the problem you encounter. There is 3 warnings still but there should be harmless (one is related to video switching, the others to a docking station apparently, so if you have trouble with those, please report). I'm not sure yet we can write a workaround to fix this without having to override the DSDT (maybe Nate have some thought about this?) --- acpidump 2005/05/23 14:46:06 1.1 +++ acpidump 2005/05/23 14:46:50 @@ -6342,8 +6342,8 @@ Name (PBST, Package (0x04) { 0x00, - Z00C, - Z00C, + Zero, + Zero, 0x2710 }) Name (ERRC, 0x00) @@ -6599,8 +6599,8 @@ Name (PBST, Package (0x04) { 0x00, - Z00C, - Z00C, + Zero, + Zero, 0x2710 }) Name (ERRC, 0x00) Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-current@FreeBSD.ORG Mon May 23 15:11:00 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADFD716A41C; Mon, 23 May 2005 15:11:00 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A05343D48; Mon, 23 May 2005 15:10:58 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd33.aul.t-online.de by mailout07.sul.t-online.com with smtp id 1DaEZx-0006NQ-02; Mon, 23 May 2005 17:10:53 +0200 Received: from Andro-Beta.Leidinger.net (T585aoZSreGVZLz4ihe8SpgJoOv4SnBZwyHWqwAWJAqBC1eLivrfcl@[217.229.208.159]) by fwd33.sul.t-online.de with esmtp id 1DaEZo-1qQorI0; Mon, 23 May 2005 17:10:44 +0200 Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.1/8.13.1) with ESMTP id j4NFAiGi080242; Mon, 23 May 2005 17:10:44 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Mon, 23 May 2005 17:10:43 +0200 Message-ID: <20050523171043.f37o5adfmsw04kcs@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 23 May 2005 17:10:43 +0200 From: Alexander Leidinger To: Pawel Worach References: <20050518051111.GA33262@Athena.infor.org> <20050520164349.GD6982@dragon.NUXI.org> <428E1815.8080500@samsco.org> <200505221453.44007.peter@wemm.org> <429105D8.6000106@samsco.org> <20050523021527.GA62693@dragon.NUXI.org> <42914446.4000203@gmail.com> In-Reply-To: <42914446.4000203@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-ID: T585aoZSreGVZLz4ihe8SpgJoOv4SnBZwyHWqwAWJAqBC1eLivrfcl@t-dialin.net X-TOI-MSGID: a71a10c8-f250-492c-afc3-eaf550ec50b1 Cc: freebsd-current@freebsd.org, David Gurvich Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 15:11:00 -0000 Pawel Worach wrote: > I'm seeing the same thing if CPUTYPE is set to "pentium-m" while > "pentium2" works fine. Loader crashes on start, is there a way to > make it freeze instead of reset to capture the register dump? Do you use CPUTYPE=xxx or CPUTYPE?=xxx and if you use the former, can you please try with the later? Background (as already posted here): I have two AMD systems, one with a Mobile Athlon XP (Laptop) and one with an Athlon XP (desktop). I hadn't time to test it yet, put in one of the systems the loader works and in the other one the loader doesn't work. The system with the broken loader (desktop) uses '=', the other system uses '?='. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 She was only a moonshiner's daughter, but I love her still. From owner-freebsd-current@FreeBSD.ORG Mon May 23 15:15:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B67716A41C for ; Mon, 23 May 2005 15:15:15 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 307B343D48 for ; Mon, 23 May 2005 15:15:15 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd18.aul.t-online.de by mailout07.sul.t-online.com with smtp id 1DaEe6-0000iw-03; Mon, 23 May 2005 17:15:10 +0200 Received: from Andro-Beta.Leidinger.net (VmKhluZJoe3c3qq2p-laJf-444fRyhBIuRF1ZAAhRsPT6fWR0H-6Qc@[217.229.208.159]) by fwd18.sul.t-online.de with esmtp id 1DaEdw-03vdKa0; Mon, 23 May 2005 17:15:00 +0200 Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.1/8.13.1) with ESMTP id j4NFExlT081054; Mon, 23 May 2005 17:14:59 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Mon, 23 May 2005 17:14:59 +0200 Message-ID: <20050523171459.taajh3b3ms0k40sw@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 23 May 2005 17:14:59 +0200 From: Alexander Leidinger To: Darren Pilgrim References: <002a01c55f5c$38218d00$0a2a15ac@SMILEY> In-Reply-To: <002a01c55f5c$38218d00$0a2a15ac@SMILEY> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-ID: VmKhluZJoe3c3qq2p-laJf-444fRyhBIuRF1ZAAhRsPT6fWR0H-6Qc@t-dialin.net X-TOI-MSGID: e0b3a4f5-90d8-415b-a0d7-43b70599d5f8 Cc: freebsd-current@freebsd.org Subject: RE: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 15:15:15 -0000 Darren Pilgrim wrote: > I'm running -CURRENT compiled with CPUTYPE?=pentium-m on a Sonoma-platform > notebook. Sources fresh this afternoon work fine, as did sources cvsup'd on > 5/13. 5.3-R and 5.4-R worked fine as well. I dual-boot and let Windows > XP's boot manager run the show, so I'm may be skipping the part of the > loader with the problem. When you see the menu where you can chose between different ways to boot, you use the loader. Can you please try if you get a broken loader when you remove the question mark from the CPUTYPE line? Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 When in trouble, obfuscate. From owner-freebsd-current@FreeBSD.ORG Mon May 23 15:18:46 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F2E6B16A41C for ; Mon, 23 May 2005 15:18:45 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout02.sul.t-online.com (mailout02.sul.t-online.com [194.25.134.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D3A243D55 for ; Mon, 23 May 2005 15:18:45 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd21.aul.t-online.de by mailout02.sul.t-online.com with smtp id 1DaEhX-0006cs-02; Mon, 23 May 2005 17:18:44 +0200 Received: from Andro-Beta.Leidinger.net (Xd4MfGZ-QeOL4zvn801I394vCT+BJHZ5iZ+X85RfbLrPTO+ZkebZkC@[217.229.208.159]) by fwd21.sul.t-online.de with esmtp id 1DaEhI-0QvPuq0; Mon, 23 May 2005 17:18:28 +0200 Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.1/8.13.1) with ESMTP id j4NFINWA081651; Mon, 23 May 2005 17:18:23 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Mon, 23 May 2005 17:18:23 +0200 Message-ID: <20050523171823.dxh5xkei0go0s4wk@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 23 May 2005 17:18:23 +0200 From: Alexander Leidinger To: Stefan Ehmann References: <20050518051111.GA33262@Athena.infor.org> <200505210727.23320.david.freebsd@verizon.net> <20050522114524.B27009@carver.gumbysoft.com> <200505222340.27785.david.freebsd@verizon.net> <1116844513.1441.19.camel@taxman.pepperland> In-Reply-To: <1116844513.1441.19.camel@taxman.pepperland> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-ID: Xd4MfGZ-QeOL4zvn801I394vCT+BJHZ5iZ+X85RfbLrPTO+ZkebZkC@t-dialin.net X-TOI-MSGID: 59d20ea3-8aa1-42e7-a124-8e0726bdecc2 Cc: freebsd-current@freebsd.org, David Gurvich Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 15:18:46 -0000 Stefan Ehmann wrote: > Same thing here with CPUTYPE=pentium-m on my notebook. Can you please try with CPUTYPE?=pentium-m instead of CPUTYPE=pentium-m and report back if this helps? What do you use for CFLAGS? Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 We can defeat gravity. The problem is the paperwork involved. From owner-freebsd-current@FreeBSD.ORG Mon May 23 15:25:14 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8DB0016A41C; Mon, 23 May 2005 15:25:14 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4ACCE43D55; Mon, 23 May 2005 15:25:13 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j4NFP8Ir040737; Mon, 23 May 2005 10:25:08 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4291F5C9.8020208@centtech.com> Date: Mon, 23 May 2005 10:24:57 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050504 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Xin LI References: <20050522112612.GA37841@frontfree.net> In-Reply-To: <20050522112612.GA37841@frontfree.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/890/Mon May 23 06:34:44 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 15:25:14 -0000 Xin LI wrote: > Dear -CURRENT users, > > I would like to solicit a test of the following patchset which is based > on DragonFly's changes, against -CURRENT, to bring high resolution console > support to FreeBSD. The current patchset can be considered as "BETA" and > I would commit it if there is no complain about this patchset in the next > week. > > The patchset can be found at: > http://people.freebsd.org/~delphij/vesa/patchset-highres.20050522 > > To use it, you will need latest -CURRENT code, and apply the patchset at > toplevel source tree, i.e. /usr/src for usual cases. Then you need to build > and reinstall your kernel, with 'options SC_PIXEL_MODE' compiled in, and > optionally options VESA if you don't want to manually load VESA support > module. A make buildworld/installworld is recommended, but I believe that > just rebuild/reinstall usr.sbin/vidcontrol is enough to get your hands on > the support for using something like 'vidcontrol MODE_239' or so, which will > switch the current console to that mode. Some mode may not work on certain > cards, though. > > Please let me know if anything strange happens; While I have been running > with the patch for a while, I would still be happy if you will report that > it works :-) This seems to work nicely for me (Dell Latitude D610, Radeon X300, 1400x1050x16,24,or 32). Only thing I saw was my machine locked up once after leaving X, but I could not reproduce it. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Mon May 23 15:34:48 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A9B7116A41C for ; Mon, 23 May 2005 15:34:48 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout07.sul.t-online.com (mailout07.sul.t-online.com [194.25.134.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 496F743D54 for ; Mon, 23 May 2005 15:34:48 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd25.aul.t-online.de by mailout07.sul.t-online.com with smtp id 1DaEx4-0007PD-00; Mon, 23 May 2005 17:34:46 +0200 Received: from Andro-Beta.Leidinger.net (ZqNn7kZereWD9-vupC22qmZ6W0oV8KFZnjVqzfzkkPTtho-Qk-rgsZ@[217.229.208.159]) by fwd25.sul.t-online.de with esmtp id 1DaEwt-1bJgBM0; Mon, 23 May 2005 17:34:35 +0200 Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.1/8.13.1) with ESMTP id j4NFYW1Y084769; Mon, 23 May 2005 17:34:32 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from 141.113.101.32 ([141.113.101.32]) by netchild.homeip.net (Horde MIME library) with HTTP for ; Mon, 23 May 2005 17:34:31 +0200 Message-ID: <20050523173431.n35nvghwrkg8kgc8@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 23 May 2005 17:34:31 +0200 From: Alexander Leidinger To: Doug White References: <20050522135915.6117ef26@Magellan.Leidinger.net> <20050522115014.O27009@carver.gumbysoft.com> In-Reply-To: <20050522115014.O27009@carver.gumbysoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.3) / FreeBSD-4.11 X-ID: ZqNn7kZereWD9-vupC22qmZ6W0oV8KFZnjVqzfzkkPTtho-Qk-rgsZ@t-dialin.net X-TOI-MSGID: 5d607af6-45ee-45fd-8e78-a7823d9d1d97 Cc: current@freebsd.org Subject: Re: wrong link state change message from vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 15:34:48 -0000 Doug White wrote: > On Sun, 22 May 2005, Alexander Leidinger wrote: > >> Hi, >> >> I get a "vr0: link state changed to DOWN" when it should be a UP-message >> (kernel as of May 2). I want to fix this, but don't know what part of >> the source is responsible and how it should look like. Can someone >> please give me a hint? > > Are you saying the messages are reversed, i.e. when the link goes down it > says UP and when the cable is plugged in it says DOWN? I've noticed that the connector is broken. Depending on the direction the cable is coming in I have network access or not. I will get back to this topic when I've disassembled my laptop and successfully soldered in a replacement connector. Until then I can't make any reliable measurement. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 The first rule of intelligent tinkering is to save all the parts. -- Paul Erlich From owner-freebsd-current@FreeBSD.ORG Mon May 23 15:53:29 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C53B16A41C for ; Mon, 23 May 2005 15:53:29 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout1-sn2.hy.skanova.net (pne-smtpout1-sn2.hy.skanova.net [81.228.8.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0B4243D1D for ; Mon, 23 May 2005 15:53:28 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from sentinel (195.198.193.104) by pne-smtpout1-sn2.hy.skanova.net (7.1.026.7) id 41E32167016CB878; Mon, 23 May 2005 17:53:27 +0200 From: "Daniel Eriksson" To: Date: Mon, 23 May 2005 17:53:20 +0200 Organization: Home Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVfr4rVZtcW7GWtS4SRjtXyBU58ww== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Cc: martines@frontiernet.net, =?iso-8859-1?Q?'S=F8ren_Schmidt'?= Subject: smartmontools no longer work in 6-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 15:53:29 -0000 After the change to ioctl handling in ATA (sos 2005-05-16 13:07:27 UTC), smartmontools no longer work under 6-CURRENT. Is anyone working on this problem? /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Mon May 23 15:57:33 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AAB6916A41F for ; Mon, 23 May 2005 15:57:33 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id 066ED43D54 for ; Mon, 23 May 2005 15:57:32 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so873131rng for ; Mon, 23 May 2005 08:57:32 -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=O3zhKKf38now+WqFhoTpOa1iQgwFVCGLSsVFbi6TZRamJ2WirWWl/AxOrL9BeI053BELnwo1so1f3A8WjvRJEVlg049/+PrR4MNzFb8MPUQAdQH5pucOcT60zN/xsnPmfEjegolPBzORTT6kOCKqWiQEbvmOh0uFORL39/6ktA0= Received: by 10.38.149.23 with SMTP id w23mr3180137rnd; Mon, 23 May 2005 08:57:32 -0700 (PDT) Received: by 10.38.149.38 with HTTP; Mon, 23 May 2005 08:57:32 -0700 (PDT) Message-ID: Date: Mon, 23 May 2005 17:57:32 +0200 From: Pawel Worach To: Alexander Leidinger In-Reply-To: <20050523171043.f37o5adfmsw04kcs@netchild.homeip.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050518051111.GA33262@Athena.infor.org> <20050520164349.GD6982@dragon.NUXI.org> <428E1815.8080500@samsco.org> <200505221453.44007.peter@wemm.org> <429105D8.6000106@samsco.org> <20050523021527.GA62693@dragon.NUXI.org> <42914446.4000203@gmail.com> <20050523171043.f37o5adfmsw04kcs@netchild.homeip.net> Cc: freebsd-current@freebsd.org, David Gurvich Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pawel Worach List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 15:57:33 -0000 On 5/23/05, Alexander Leidinger wrote: > Pawel Worach wrote: >=20 > > I'm seeing the same thing if CPUTYPE is set to "pentium-m" while > > "pentium2" works fine. Loader crashes on start, is there a way to > > make it freeze instead of reset to capture the register dump? >=20 > Do you use > CPUTYPE=3Dxxx > or > CPUTYPE?=3Dxxx > and if you use the former, can you please try with the later? >=20 Right now I have, it was still "?=3D" when i tried with pentium-m # grep "^CPUTYPE" /etc/make.conf CPUTYPE?=3Dpentium2 --=20 Pawel From owner-freebsd-current@FreeBSD.ORG Mon May 23 15:58:02 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D5D816A462 for ; Mon, 23 May 2005 15:58:02 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3517443D5D for ; Mon, 23 May 2005 15:58:01 +0000 (GMT) (envelope-from sos@DeepCore.dk) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j4NFpYWN045217; Mon, 23 May 2005 17:51:34 +0200 (CEST) (envelope-from sos@DeepCore.dk) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Mon, 23 May 2005 17:57:56 +0200 To: "Daniel Eriksson" X-Mailer: Apple Mail (2.730) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: martines@frontiernet.net, freebsd-current@FreeBSD.org Subject: Re: smartmontools no longer work in 6-CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 15:58:02 -0000 On 23/05/2005, at 17:53, Daniel Eriksson wrote: > > After the change to ioctl handling in ATA (sos 2005-05-16 13:07:27 =20 > UTC), > smartmontools no longer work under 6-CURRENT. > > Is anyone working on this problem? I've mailed the maintainer with patches, and they are in the PR =20 database as well under ports/81403. - S=F8ren From owner-freebsd-current@FreeBSD.ORG Mon May 23 16:01:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 637CC16A41C for ; Mon, 23 May 2005 16:01:10 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E2EB43D4C for ; Mon, 23 May 2005 16:01:10 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([66.130.198.54]) by VL-MO-MR011.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0IGY007379TS8Y@VL-MO-MR011.ip.videotron.ca> for freebsd-current@freebsd.org; Mon, 23 May 2005 12:01:04 -0400 (EDT) Date: Mon, 23 May 2005 12:00:43 -0400 From: Nicolas Blais To: freebsd-current@freebsd.org Message-id: <200505231201.04102.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=nextPart1980935.A7Z10THgfx Content-transfer-encoding: 7bit User-Agent: KMail/1.8 Subject: Enabling blackhole causes problems X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 16:01:10 -0000 --nextPart1980935.A7Z10THgfx Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline When I add the following lines to /etc/sysctl.conf: net.inet.tcp.blackhole=3D2 net.inet.udp.blackhole=3D1 And I reboot, it will hang right before the login manager. At that point, I= =20 need to press Ctrl-C (closes /etc/rc.d/localpkg) and I can boot normaly=20 except that kmail will freeze when I try to read a message. I can't find th= e=20 logic in that, but when I reboot without the 2 lines, it will boot and work= =20 fine. I don't really need blackhole but I was curious to see if I could benefit f= rom=20 it. Here's rc.conf: ifconfig_sk0=3D"inet 192.168.1.100 media 100baseTX mediaopt full-duplex net= mask=20 255.255.255.0" hostname=3D"clk01a" defaultrouter=3D"192.168.1.1" linux_enable=3D"YES" ntpdate_flags=3D"ntp1.cmc.ec.gc.ca" ntpdate_enable=3D"YES" sendmail_enable=3D"NONE" samba_enable=3D"YES" lisa_enable=3D"YES" sshd_enable=3D"YES" usbd_enable=3D"YES" apache2_enable=3D"YES" and the ending of my bootlog: Additional routing options:. Starting devd. Mounting NFS file systems:. Creating and/or trimming log files:. Starting syslogd. Setting date via ntp. 23 May 11:50:50 ntpdate[282]: adjust time server 199.212.17.15 offset=20 =2D0.066166 sec ELF ldconfig=20 path: /lib /usr/lib /usr/lib/compat /usr/X11R6/lib /usr/local/lib / usr/local/lib/compat/pkg a.out ldconfig path: /usr/lib/aout /usr/lib/compat/aout /usr/X11R6/lib/aout Starting usbd. Starting local daemons:. Updating motd. Configuring syscons: blanktime. Starting sshd. Initial i386 initialization:. Additional ABI support: linux. Starting cron. Local package initialization:Starting apache2. Starting lisa. rtcStarting SAMBA: removing stale tdbs : /var/db/samba/messages.tdb Starting nmbd. Starting smbd. Is blackhole dependant of an option in the kernel? Do I have to have ipfw=20 running? Thanks, Nicolas =2D-=20 =46reeBSD 6.0-CURRENT #2: Sun May 22 11:29:47 EDT 2005 =20 nicblais@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://66.130.198.54:8081/security/nb_root.asc --nextPart1980935.A7Z10THgfx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCkf5Az38ton5LGeIRAq83AKCH7xuYybnrrF4L6uTpGvnG/wziYwCdFceB TLn5qRVlL6ND+fFo+t4KQic= =wGMt -----END PGP SIGNATURE----- --nextPart1980935.A7Z10THgfx-- From owner-freebsd-current@FreeBSD.ORG Mon May 23 16:37:20 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 749E216A41C; Mon, 23 May 2005 16:37:20 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6246943D48; Mon, 23 May 2005 16:37:18 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA25432; Mon, 23 May 2005 19:37:15 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <429206BB.2050409@icyb.net.ua> Date: Mon, 23 May 2005 19:37:15 +0300 From: Andriy Gapon User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050328) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org References: <428C6489.3040609@icyb.net.ua> In-Reply-To: <428C6489.3040609@icyb.net.ua> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Subject: Re: acd lacks devstat [Was: systat -vmstat vs. acd] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 16:37:20 -0000 on 19.05.2005 13:03 Andriy Gapon said the following: > With 4.X on ATA(PI)-only machine systat -vmstat used to show disks > statistics for both ad and acd devices. Now, in 5.4-RELEASE, it shows > statistics only for ad devices. If atapicam is added then statistics for > cd and pass devices is shown as well. I've done some investigation on this and it seems that this behavior exists since circa introduction of geom and is present in current too. A root cause of this behavior seems to be that acd is not treated as a geom disk and doesn't have any devstat calls of itw own (unlike 4.X). Btw, the same problem exists in current too. I've found a short converstion on a close topic that happened a long while ago: http://www.mail-archive.com/freebsd-current@freebsd.org/msg33834.html I would like to comment on two things: 1. the following part of that converion doesn't seem to be valid to me, because cd device essentially has the same basic properties as acd and that doesn't prevent it from being a geom disk: > At any rate I wouldn't expect a CDROM to show up as a disk, unless > it has a R/W medium formatted for random R/W inserted (which we at > this time doesn't support). 2. even if acd can not be a geom disk (and maybe it can not be indeed), shouldn't it have devstat bookkeeping of its own then ? And the following question still remains: > Should I file a PR ? -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Mon May 23 17:05:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B42316A41C for ; Mon, 23 May 2005 17:05:22 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id A494243D1D for ; Mon, 23 May 2005 17:05:21 +0000 (GMT) (envelope-from shoesoft@gmx.net) Received: (qmail invoked by alias); 23 May 2005 17:05:20 -0000 Received: from h081217094227.dyn.cm.kabsi.at (EHLO localhost.localdomain) [81.217.94.227] by mail.gmx.net (mp005) with SMTP; 23 May 2005 19:05:20 +0200 X-Authenticated: #16703784 From: Stefan Ehmann To: Alexander Leidinger In-Reply-To: <20050523171823.dxh5xkei0go0s4wk@netchild.homeip.net> References: <20050518051111.GA33262@Athena.infor.org> <200505210727.23320.david.freebsd@verizon.net> <20050522114524.B27009@carver.gumbysoft.com> <200505222340.27785.david.freebsd@verizon.net> <1116844513.1441.19.camel@taxman.pepperland> <20050523171823.dxh5xkei0go0s4wk@netchild.homeip.net> Content-Type: text/plain Date: Mon, 23 May 2005 19:05:21 +0200 Message-Id: <1116867921.1441.23.camel@taxman.pepperland> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-current@freebsd.org, David Gurvich Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 17:05:22 -0000 On Mon, 2005-05-23 at 17:18 +0200, Alexander Leidinger wrote: > Stefan Ehmann wrote: > > > Same thing here with CPUTYPE=pentium-m on my notebook. > > Can you please try with > CPUTYPE?=pentium-m > instead of > CPUTYPE=pentium-m > and report back if this helps? > > What do you use for CFLAGS? Did a full build/installworld cycle but didn't help. I do not override CFLAGS. -- Stefan Ehmann From owner-freebsd-current@FreeBSD.ORG Mon May 23 17:24:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 15BBD16A41C for ; Mon, 23 May 2005 17:24:57 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id ACDBE43D1D for ; Mon, 23 May 2005 17:24:56 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id F1C883BE9D; Mon, 23 May 2005 12:24:53 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01742-01-34; Mon, 23 May 2005 12:24:53 -0500 (CDT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (Postfix) with ESMTP id 9E4D43BF5E; Mon, 23 May 2005 12:24:53 -0500 (CDT) Received: from s228130hz1ew031.apptix-01.savvis.net ([10.146.4.28]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 12:24:40 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew031.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 12:24:29 -0500 Message-ID: <429211C9.4000903@savvis.net> Date: Mon, 23 May 2005 10:24:25 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <4288EBEA.5030701@savvis.net> <428A5A58.6010601@savvis.net> <428B7B99.7080206@savvis.net> <428E7BAF.200@savvis.net> <1116788908.824.23.camel@RabbitsDen> In-Reply-To: <1116788908.824.23.camel@RabbitsDen> Content-Type: text/plain; charset=ISO-8859-5; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 May 2005 17:24:29.0930 (UTC) FILETIME=[46FB6CA0:01C55FBC] X-Virus-Scanned: amavisd-new at savvis.net Cc: freebsd-current@freebsd.org Subject: Re: keyboard mux driver (straw man proposal & code) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 17:24:57 -0000 Alexandre, thanks for trying the code. please read my answers below. >> next version of experimental keyboard mux can be downloaded from >> >> http://www.geocities.com/m_evmenkin/kbdmux-2.tar.gz (~8K) >> >> also on freefall in my home directory >> (freefall:~emax/kbdmux-2.tar.gz). >> >> i gave up idea of using slave keyboards in K_XLATE mode. for >> whatever reason i could not get it to work in console (it did work >> just fine in X). >> >> so, i re-shaped the code and now kbdmux treats slave keyboards just >> as suppliers of raw at scan codes. when keyboard is added to the >> mux it will set be switched into K_RAW mode. >> >> i also decided to not add auxiliary device interface. i think its >> better to pass keyboard mux ioctl's through /dev/console. >> >> i tried the code with one ps/2 keyboard connected to the mux >> (pass-through) and it worked for me in both X and console. >> >> any feedback is welcome! > > I did jump up and down couple of times ;) and set out to add separate > USB numeric keypad to my laptop's keyboard. Here are some observations > from that undertaking: > > I was not able to disconnect original keyboard from the console to add > it to the multiplexer: > > kbdcontrol -K < /dev/console > kbdcontrol: unable to obtain keyboard information: Inappropriate ioctl > for device hmm... this is strange. i usually get this when my console does not have any keyboard attached. > I have managed to work around this by using yet another USB keyboard and > attaching it to the console using 'kbdcontrol -k /dev/kbd1 > < /dev/ttyv0'. yes. this is awkward right now. basically kbdmux needs ioctl to add/remove keyboard to/from mux. however it is not possible to open /dev/kbdX (or /dev/atkbdX for example) once keyboard was "kbd_allocate"ed. this part needs more work on mux/syscons/kbd side, but because its still experimental it is not done yet. > After that I was able to add both original keyboard and USB keypad to > the multiplexer and attached that to the console. At this point both > keyboards provided input to console and X with following side effects: excellent! > -- keyboard lights (caps lock and num lock) on the main keyboard would > not turn on. yes. i think i know why this might be. kbdmux does not do anything on SETLED ioctl (except updating its internal state). because there might be more then one keyboard in the mux i was not sure which keyboard (or all of them?) should get lights turned on. > -- keypad would work in the "arrows" ("up"/"down"/"left"/"right") mode > on startup. ok > -- "Caps lock" would capitalize main keyboard (there are no letters on > the keypad). "caps lock" on keypad or main keyboard? i'm not sure i understand the problem. > -- "Num lock" would switch keypad into numeric mode, but leave main > keyboard alone (as it is the case with laptop keyboards it has > sprinkling of numerals on the right side overlapping letters). again "num lock" on keypad or main keyboard? > -- Key "5" on the keypad will not produce number "5" in any mode, the > rest of the keys ('-', '+', '*', '/', and ) seem to > work properly. ok, probably scancode translation problem. > I am running -CURRENT as of May 14th with console high resolution patch. > Machine is Averatec 3150H, keypad is manufactured by iConcepts, but > represents itself as CHESEN USB keyboard. > > If there is any additional information that I can provide or there is > something you want me to experiment with, please, let me know. thanks again for trying this and reporting the problems. i will try to get myself a couple of usb keyboards and reproduce/fix the problems. thanks, max From owner-freebsd-current@FreeBSD.ORG Mon May 23 17:56:33 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26CB416A41C for ; Mon, 23 May 2005 17:56:33 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id C166443D49 for ; Mon, 23 May 2005 17:56:31 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id B3EFD3B921; Mon, 23 May 2005 19:56:29 +0200 (CEST) Received: from hal9000.schweikhardt.net (localhost [127.0.0.1]) by hal9000.schweikhardt.net (8.13.3/8.13.3) with ESMTP id j4NHu9gw001141; Mon, 23 May 2005 19:56:09 +0200 (CEST) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.13.3/8.13.3/Submit) id j4NHu93f001140; Mon, 23 May 2005 19:56:09 +0200 (CEST) (envelope-from schweikh) Date: Mon, 23 May 2005 19:56:09 +0200 From: Jens Schweikhardt To: Doug White Message-ID: <20050523175609.GA779@schweikhardt.net> References: <20050516113420.GA786@schweikhardt.net> <20050518150346.S87264@carver.gumbysoft.com> <20050519190129.GA1048@schweikhardt.net> <20050520122944.B8229@carver.gumbysoft.com> <20050521092857.GA847@schweikhardt.net> <20050522112845.S27009@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050522112845.S27009@carver.gumbysoft.com> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: Timekeeping hosed by factor 3, high lapic[01] interrupt rates X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 17:56:33 -0000 ... # Lets try this: # 0. If you're overclocking your CPU, don't. Never did. # 1. Boot with ACPI enabled and print the two kern.timecount sysctls above. # I'm curious if its picking up the ACPI timecounter. Isn't APIC enabled unless I disable it with hint.acpi.0.disabled="1"? # 2. Shutdown and unplug the machine for about 20 minutes or overnight if # convenient. Plug it back in, go into BIOS Setup and check the clock. If its # off or dead then the CMOS battery is dead. This is my home machine, which I turn off at night. The BIOS clock looks good. And this would not explain why it's the same system that works with a different kernel. # 3. Backout rev 1.218 of src/sys/i386/isa/clock.c so the irq0 interrupt # handler is reactivated and the RTC fiddled. Will do so next. I've nailed the change between March 6 and March 30. 1.218 is from 2005/03/24 21:34:16, which would fit. # > Some time in the past, the system would hang at boot with acpi enabled. # > So I kept a hint.acpi.0.disabled="1" in /boot/device.hints. But even # > without that hint, the time dilation effect (hey, it's the Einstein # > Year!) is the same... # # This would imply the source of the problem is not in the timecounter, # which doesn't make sense. It's puzzling, but dammit, these are deterministic machines :-) I'm sure in the end we'll find the cause. Thanks for your patience. # Are you running ntpd? Yes. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-current@FreeBSD.ORG Mon May 23 19:29:14 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7883816A41C for ; Mon, 23 May 2005 19:29:14 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 40CA843D1F for ; Mon, 23 May 2005 19:29:12 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from SMILEY (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 5A09B19F3B; Mon, 23 May 2005 12:30:02 -0700 (PDT) From: "Darren Pilgrim" To: "'Alexander Leidinger'" Date: Mon, 23 May 2005 12:29:02 -0700 Message-ID: <002001c55fcd$b0d87f80$0a2a15ac@SMILEY> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <20050523171459.taajh3b3ms0k40sw@netchild.homeip.net> Importance: Normal Cc: freebsd-current@freebsd.org Subject: RE: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 19:29:14 -0000 From: Alexander Leidinger [mailto:Alexander@Leidinger.net]=20 > Darren Pilgrim wrote: >=20 > > I'm running -CURRENT compiled with CPUTYPE?=3Dpentium-m on a Sonoma-platform > > notebook. Sources fresh this afternoon work fine, as did sources cvsup'd on > > 5/13. 5.3-R and 5.4-R worked fine as well. I dual-boot and let = Windows > > XP's boot manager run the show, so I'm may be skipping the part of = the > > loader with the problem. >=20 > When you see the menu where you can chose between different ways to = boot, you > use the loader. >=20 > Can you please try if you get a broken loader when you remove the = question > mark from the CPUTYPE line? That's not correct usage of the define, though. The question mark is = there so that the value in make.conf is used only if it isn't already set, presumably on the command line or in another makefile. Just the same, I'll rebuild the loader without the ? and see if it = breaks. From owner-freebsd-current@FreeBSD.ORG Mon May 23 20:55:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3695016A41C for ; Mon, 23 May 2005 20:55:35 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp104.rog.mail.re2.yahoo.com (smtp104.rog.mail.re2.yahoo.com [206.190.36.82]) by mx1.FreeBSD.org (Postfix) with SMTP id E143543D48 for ; Mon, 23 May 2005 20:55:34 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO 172.16.0.1) (mikej@69.193.222.195 with login) by smtp104.rog.mail.re2.yahoo.com with SMTP; 23 May 2005 20:55:34 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Mon, 23 May 2005 16:55:34 -0400 (EDT) Message-ID: <3475.172.16.0.199.1116881734.squirrel@172.16.0.1> Date: Mon, 23 May 2005 16:55:34 -0400 (EDT) From: "Mike Jakubik" To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: non-sleepable locks held (xl0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 20:55:35 -0000 Not sure if this is reported already, but i got this on a recently cvsuped -current system while booting. FreeBSD 6.0-CURRENT #1: Mon May 23 16:17:04 EDT 2005 root@fbsd.wettoast.net:/usr/obj/usr/src/sys/DP WARNING: WITNESS option enabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) Processor (1410.21-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x644 Stepping = 4 Features=0x183f9ff AMD Features=0xc0440000 real memory = 536788992 (511 MB) xl0: <3Com 3c905C-TX Fast Etherlink XL> port 0x9400-0x947f mem 0xe3800000-0xe380007f irq 5 at device 9.0 on pci0 --- Starting dhclient. taskqueue_drain with the following non-sleepable locks held: exclusive sleep mutex xl0 (network driver) r = 0 (0xc16512fc) locked @ /usr/src/sys/pci/if_xl.c:3148 KDB: stack backtrace: kdb_backtrace(c06e334c,d54c3b6c,1,1,1) at kdb_backtrace+0x2e witness_warn(5,0,c064a857,c159caf8,c0517b6b) at witness_warn+0x1b3 taskqueue_drain(c1552d00,c1651320,c06544df,cc2,c164f000) at taskqueue_drain+0x2b xl_stop(c164f000,1,c06544df,af4,0) at xl_stop+0x58 xl_init_locked(c164f000,0,c06544df,c4c,0) at xl_init_locked+0x43 xl_ioctl(c164f000,80206910,c1867560,1,c0646d61) at xl_ioctl+0x1c1 ifhwioctl(80206910,c164f000,c1867560,c159ca80,c04e1ac7) at ifhwioctl+0x368 ifioctl(c1869530,80206910,c1867560,c159ca80,1) at ifioctl+0xe6 soo_ioctl(c17df990,80206910,c1867560,c1551c80,c159ca80) at soo_ioctl+0x3bf ioctl(c159ca80,d54c3d04,c,407,3) at ioctl+0x462 syscall(3b,3b,3b,4,1) at syscall+0x265 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280cb8bf, esp = 0xbfbfe57c, ebp = 0xbfbfe5c8 --- xl0: link state changed to UP taskqueue_drain with the following non-sleepable locks held: exclusive sleep mutex xl0 (network driver) r = 0 (0xc16512fc) locked @ /usr/src/sys/pci/if_xl.c:2791 KDB: stack backtrace: kdb_backtrace(c06e334c,d54c3af0,1,1,1) at kdb_backtrace+0x2e witness_warn(5,0,c064a857,c159caf8,c0517b6b) at witness_warn+0x1b3 taskqueue_drain(c1552d00,c1651320,c06544df,cc2,c164f000) at taskqueue_drain+0x2b xl_stop(c164f000,1,c06544df,af4,0) at xl_stop+0x58 xl_init_locked(c164f000,0,c06544df,ae7,c164f000) at xl_init_locked+0x43 xl_init(c164f000,c0646d61,18a,8020690c,c17c9500) at xl_init+0x3d ether_ioctl(c164f000,8020690c,c17c9500,c06726a8,0) at ether_ioctl+0x69 xl_ioctl(c164f000,8020690c,c17c9500,1,c04e4384) at xl_ioctl+0x363 in_ifinit(c164f000,c17c9500,c16cd3d0,0,1) at in_ifinit+0x1b5 in_control(c1869530,8040691a,c16cd3c0,c164f000,c159ca80) at in_control+0x905 ifioctl(c1869530,8040691a,c16cd3c0,c159ca80,2) at ifioctl+0x1e1 soo_ioctl(c17df990,8040691a,c16cd3c0,c1551c80,c159ca80) at soo_ioctl+0x3bf ioctl(c159ca80,d54c3d04,c,407,3) at ioctl+0x462 syscall(3b,3b,3b,80563a0,0) at syscall+0x265 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280cb8bf, esp = 0xbfbfe5cc, ebp = 0xbfbfee38 --- em0: link state changed to UP taskqueue_drain with the following non-sleepable locks held: exclusive sleep mutex xl0 (network driver) r = 0 (0xc16512fc) locked @ /usr/src/sys/pci/if_xl.c:2791 KDB: stack backtrace: kdb_backtrace(c06e3314,d54d5af0,1,1,1) at kdb_backtrace+0x2e witness_warn(5,0,c064a857,c16064f8,c0517b6b) at witness_warn+0x1b3 taskqueue_drain(c1552d00,c1651320,c06544df,cc2,c164f000) at taskqueue_drain+0x2b xl_stop(c164f000,1,c06544df,af4,0) at xl_stop+0x58 xl_init_locked(c164f000,0,c06544df,ae7,c164f000) at xl_init_locked+0x43 xl_init(c164f000,c0646d61,18a,8020690c,c17c9100) at xl_init+0x3d ether_ioctl(c164f000,8020690c,c17c9100,c06726a8,0) at ether_ioctl+0x69 xl_ioctl(c164f000,8020690c,c17c9100,1,c04e4384) at xl_ioctl+0x363 in_ifinit(c164f000,c17c9100,c17ba050,0,1) at in_ifinit+0x1b5 in_control(c1869298,8040691a,c17ba040,c164f000,c1606480) at in_control+0x905 ifioctl(c1869298,8040691a,c17ba040,c1606480,2) at ifioctl+0x1e1 soo_ioctl(c17df1b0,8040691a,c17ba040,c1551c80,c1606480) at soo_ioctl+0x3bf ioctl(c1606480,d54d5d04,c,407,3) at ioctl+0x462 syscall(3b,3b,3b,80563a0,bfbfebaf) at syscall+0x265 Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x280cb8bf, esp = 0xbfbfe1bc, ebp = 0xbfbfea28 --- xl0: flags=8843 mtu 1500 options=9 inet x.x.x.195 netmask 0xfffffe00 broadcast x.x.x.255 ether 00:01:03:d4:4c:07 media: Ethernet autoselect (100baseTX ) status: active From owner-freebsd-current@FreeBSD.ORG Mon May 23 21:01:55 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B755616A41C for ; Mon, 23 May 2005 21:01:55 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id 59DF943D1F for ; Mon, 23 May 2005 21:01:54 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id D6B323B8C4; Mon, 23 May 2005 23:01:53 +0200 (CEST) Received: from hal9000.schweikhardt.net (localhost [127.0.0.1]) by hal9000.schweikhardt.net (8.13.3/8.13.3) with ESMTP id j4NL1gii001103; Mon, 23 May 2005 23:01:42 +0200 (CEST) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.13.3/8.13.3/Submit) id j4NL1fSX001102; Mon, 23 May 2005 23:01:41 +0200 (CEST) (envelope-from schweikh) Date: Mon, 23 May 2005 23:01:41 +0200 From: Jens Schweikhardt To: Doug White Message-ID: <20050523210141.GA779@schweikhardt.net> References: <20050516113420.GA786@schweikhardt.net> <20050518150346.S87264@carver.gumbysoft.com> <20050519190129.GA1048@schweikhardt.net> <20050520122944.B8229@carver.gumbysoft.com> <20050521092857.GA847@schweikhardt.net> <20050522112845.S27009@carver.gumbysoft.com> <20050523175609.GA779@schweikhardt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523175609.GA779@schweikhardt.net> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: Timekeeping hosed by factor 3, high lapic[01] interrupt rates X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 21:01:55 -0000 ... # # 3. Backout rev 1.218 of src/sys/i386/isa/clock.c so the irq0 interrupt # # handler is reactivated and the RTC fiddled. # # Will do so next. I've nailed the change between March 6 and March 30. # 1.218 is from 2005/03/24 21:34:16, which would fit. We have a winner. Backing out 1.218 from a 2005/03/24 system does the trick, as well as a CURRENT without 1.218 (but 1.219-220 in there) bring back irq0 and time dilation is gone. All clocks work correctly. Now the question is: what is so special in my system so that I appear to be the only one to notice the problem? Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-current@FreeBSD.ORG Mon May 23 21:33:04 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48A7C16A41C for ; Mon, 23 May 2005 21:33:04 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5FB743D1D for ; Mon, 23 May 2005 21:33:03 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so2131133wra for ; Mon, 23 May 2005 14:33:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:x-accept-language:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=Qg4OgZK0782EZUAmerUTzRuFTdstz6UnPoSxu4pNaK5YhF1EylX+T1H4dlmPBqH9U7SC6U24Uh9C3Ud/eCPugdZtc+6RGIPnEzTHAXYc/C+JHb3yGqN47OFdX5IXp9PAkSxt+A3M2PHgwaVljpe+kOPQRUnzfFVMKx4hEeWNZI8= Received: by 10.54.79.8 with SMTP id c8mr3104200wrb; Mon, 23 May 2005 14:33:03 -0700 (PDT) Received: from ?192.168.1.200? ([213.64.231.30]) by mx.gmail.com with ESMTP id 66sm817136wra.2005.05.23.14.33.02; Mon, 23 May 2005 14:33:03 -0700 (PDT) Message-ID: <42924C0C.6050209@gmail.com> Date: Mon, 23 May 2005 23:33:00 +0200 From: Pawel Worach User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050521) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jens Schweikhardt References: <20050516113420.GA786@schweikhardt.net> <20050518150346.S87264@carver.gumbysoft.com> <20050519190129.GA1048@schweikhardt.net> <20050520122944.B8229@carver.gumbysoft.com> <20050521092857.GA847@schweikhardt.net> <20050522112845.S27009@carver.gumbysoft.com> <20050523175609.GA779@schweikhardt.net> <20050523210141.GA779@schweikhardt.net> In-Reply-To: <20050523210141.GA779@schweikhardt.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Timekeeping hosed by factor 3, high lapic[01] interrupt rates X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 21:33:04 -0000 Jens Schweikhardt wrote: > ... > # # 3. Backout rev 1.218 of src/sys/i386/isa/clock.c so the irq0 interrupt > # # handler is reactivated and the RTC fiddled. > # > # Will do so next. I've nailed the change between March 6 and March 30. > # 1.218 is from 2005/03/24 21:34:16, which would fit. > > We have a winner. Backing out 1.218 from a 2005/03/24 system does the trick, > as well as a CURRENT without 1.218 (but 1.219-220 in there) bring back irq0 > and time dilation is gone. All clocks work correctly. > > Now the question is: what is so special in my system so that I appear > to be the only one to notice the problem? > > Regards, > > Jens I see this too, backing out 1.218 of clock.c did not help here but my system is overclocked and it's pretty old (Abit BP6) so the battery may very well be dead. This is with the 1.218 change backed out. # vmstat -i interrupt total rate irq0: clk 82734023 1000 irq4: sio0 2 0 irq6: fdc0 10 0 irq16: fxp1 10347 0 irq17: fxp0 29339 0 irq19: ahc0 187220 2 lapic0: timer 165447117 2000 lapic1: timer 165430135 1999 Total 413838193 5002 I'll check the battery and step it back down to 366Mhz (now at 510). -- Pawel From owner-freebsd-current@FreeBSD.ORG Mon May 23 21:41:17 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8B32E16A41C for ; Mon, 23 May 2005 21:41:17 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51BC743D1F for ; Mon, 23 May 2005 21:41:17 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from SMILEY (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 8E0FB19F3B; Mon, 23 May 2005 14:42:07 -0700 (PDT) From: "Darren Pilgrim" To: "'Darren Pilgrim'" , "'Alexander Leidinger'" Date: Mon, 23 May 2005 14:41:07 -0700 Message-ID: <000301c55fe0$2479eb10$0a2a15ac@SMILEY> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <002001c55fcd$b0d87f80$0a2a15ac@SMILEY> Importance: Normal Cc: freebsd-current@freebsd.org Subject: RE: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 21:41:17 -0000 From: Darren Pilgrim > From: Alexander Leidinger [mailto:Alexander@Leidinger.net] > > > > Can you please try if you get a broken loader when you > > remove the question mark from the CPUTYPE line? > > That's not correct usage of the define, though. The question > mark is there so that the value in make.conf is used only if > it isn't already set, presumably on the command line or in > another makefile. > > Just the same, I'll rebuild the loader without the ? and see > if it breaks. I changed CPUTYPE?=pentium-m to CPUTYPE=pentium-m, then did: # cd /usr/src/sys/boot/i386 && make && make install I then rebooted and it worked fine. Should I try using the FreeBSD MBR? Do I need to perform additional steps to properly install a new version of the loader? From owner-freebsd-current@FreeBSD.ORG Mon May 23 22:08:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2EA3416A41C for ; Mon, 23 May 2005 22:08:22 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms042pub.verizon.net (vms042pub.verizon.net [206.46.252.42]) by mx1.FreeBSD.org (Postfix) with ESMTP id EA01143D1D for ; Mon, 23 May 2005 22:08:21 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.190.81]) by vms042.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGY006AGQTWQS5C@vms042.mailsrvcs.net> for freebsd-current@freebsd.org; Mon, 23 May 2005 17:08:21 -0500 (CDT) Date: Mon, 23 May 2005 18:05:56 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <429211C9.4000903@savvis.net> To: Maksim Yevmenkin Message-id: <1116885956.3386.10.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-type: text/plain; charset=iso-8859-5 Content-transfer-encoding: 8BIT References: <4288EBEA.5030701@savvis.net> <428A5A58.6010601@savvis.net> <428B7B99.7080206@savvis.net> <428E7BAF.200@savvis.net> <1116788908.824.23.camel@RabbitsDen> <429211C9.4000903@savvis.net> Cc: freebsd-current@freebsd.org Subject: Re: keyboard mux driver (straw man proposal & code) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 22:08:22 -0000 On Mon, 2005-05-23 at 10:24 -0700, Maksim Yevmenkin wrote: > Alexandre, > > -- "Caps lock" would capitalize main keyboard (there are no letters on > > the keypad). > > "caps lock" on keypad or main keyboard? i'm not sure i understand the > problem. Sorry for not being clear -- it was mere statement of fact, not report of the problem. I guess, it should have said: ...despite LED not being lit, "caps lock" did capitalize keys on the main keyboard. Keypad does not have "caps lock" or "num lock". > > > -- "Num lock" would switch keypad into numeric mode, but leave main > > keyboard alone (as it is the case with laptop keyboards it has > > sprinkling of numerals on the right side overlapping letters). > > again "num lock" on keypad or main keyboard? "Num lock" on the main keyboard (keypad does not have one) switches *keypad* into numeric mode leaving main keyboard in alpha -- main keyboard does not really have a numeric part -- it overlaps some of the alpha keys. > thanks again for trying this and reporting the problems. i will try to > get myself a couple of usb keyboards and reproduce/fix the problems. If you are in or somewhere near :) continental US, send me your address in the private mail -- I'll ship you that keypad. > > thanks, > max Thank you, -- Alexandre "Sunny" Kovalenko (¾ÛÕÚáÐÝÔà ºÞÒÐÛÕÝÚÞ) From owner-freebsd-current@FreeBSD.ORG Mon May 23 22:24:40 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 227E116A41C for ; Mon, 23 May 2005 22:24:40 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-1.free.fr (postfix3-1.free.fr [213.228.0.44]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB48243D1F for ; Mon, 23 May 2005 22:24:39 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-1.free.fr (Postfix) with ESMTP id 08E6E1734A7; Tue, 24 May 2005 00:24:38 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 182B6407E; Tue, 24 May 2005 00:24:41 +0200 (CEST) Date: Tue, 24 May 2005 00:24:41 +0200 From: Jeremie Le Hen To: Bruno Ducrot Message-ID: <20050523222440.GM850@obiwan.tataz.chchile.org> References: <20050517163212.GG14297@obiwan.tataz.chchile.org> <20050523090425.GW21800@poupinou.org> <20050523132204.GZ850@obiwan.tataz.chchile.org> <20050523145810.GY21800@poupinou.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523145810.GY21800@poupinou.org> User-Agent: Mutt/1.5.9i Cc: freebsd-current@FreeBSD.org, Jeremie Le Hen Subject: Re: ACPI errors with recent laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 22:24:40 -0000 Bruno, > The patch attached allow to compile at least and will correct the problem > you encounter. There is 3 warnings still but there should be harmless (one > is related to video switching, the others to a docking station > apparently, so if you have trouble with those, please report). Thanks for your patch, it removed all warnings. However, it did just that, since I can't access hw.acpi.battery.life and hw.acpi.battery.time, they are just both set to the famous "Zero" :-). I have to say this is quite boring for a laptop, I would have prefered not being able to get the temperature, for example. The BIOS is quite old (the boot screen displays 2003), but the manufacturer doesn't provide any BIOS upgrade on their website ATM. Since this is a new special model reserved for promotions, I still hope they will provide an upgrade soon. Thanks again. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Mon May 23 22:38:03 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D2EC16A41C for ; Mon, 23 May 2005 22:38:03 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from mailgate1b.savvis.net (mailgate1b.savvis.net [216.91.182.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC49343D1D for ; Mon, 23 May 2005 22:38:02 +0000 (GMT) (envelope-from Maksim.Yevmenkin@savvis.net) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgate1b.savvis.net (Postfix) with ESMTP id 44D5D3BE8E; Mon, 23 May 2005 17:38:02 -0500 (CDT) Received: from mailgate1b.savvis.net ([127.0.0.1]) by localhost (mailgate1b.savvis.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05858-01-66; Mon, 23 May 2005 17:38:02 -0500 (CDT) Received: from out002.email.savvis.net (out002.apptix.savvis.net [216.91.32.45]) by mailgate1b.savvis.net (Postfix) with ESMTP id 17FF93BE88; Mon, 23 May 2005 17:38:02 -0500 (CDT) Received: from s228130hz1ew031.apptix-01.savvis.net ([10.146.4.28]) by out002.email.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 17:37:43 -0500 Received: from [10.254.186.111] ([66.35.239.94]) by s228130hz1ew031.apptix-01.savvis.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 17:37:43 -0500 Message-ID: <42925B36.9090400@savvis.net> Date: Mon, 23 May 2005 15:37:42 -0700 From: Maksim Yevmenkin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050404) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Alexandre \"Sunny\" Kovalenko" References: <4288EBEA.5030701@savvis.net> <428A5A58.6010601@savvis.net> <428B7B99.7080206@savvis.net> <428E7BAF.200@savvis.net> <1116788908.824.23.camel@RabbitsDen> <429211C9.4000903@savvis.net> <1116885956.3386.10.camel@RabbitsDen> In-Reply-To: <1116885956.3386.10.camel@RabbitsDen> Content-Type: text/plain; charset=ISO-8859-5; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 May 2005 22:37:43.0808 (UTC) FILETIME=[0901A000:01C55FE8] X-Virus-Scanned: amavisd-new at savvis.net Cc: freebsd-current@freebsd.org Subject: Re: keyboard mux driver (straw man proposal & code) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 22:38:03 -0000 Alexandre, >>> -- "Caps lock" would capitalize main keyboard (there are no >>> letters on the keypad). >> >> "caps lock" on keypad or main keyboard? i'm not sure i understand >> the problem. > > Sorry for not being clear -- it was mere statement of fact, not > report of the problem. I guess, it should have said: ...despite LED > not being lit, "caps lock" did capitalize keys on the main keyboard. > Keypad does not have "caps lock" or "num lock". now i get it :) just like i explained in previous email keyboard lights will not work for now. kbdmux does not call SETLED ioctl on slave keyboards yet. >>> -- "Num lock" would switch keypad into numeric mode, but leave >>> main keyboard alone (as it is the case with laptop keyboards it >>> has sprinkling of numerals on the right side overlapping >>> letters). >> >> again "num lock" on keypad or main keyboard? > > "Num lock" on the main keyboard (keypad does not have one) switches > *keypad* into numeric mode leaving main keyboard in alpha -- main > keyboard does not really have a numeric part -- it overlaps some of > the alpha keys. this is actually correct (i think). because slave keyboards are set to K_RAW mode, kbdmux will get raw scancodes, not characters. the (good or bad?) side effect of this is that kbdmux will act as if it was one huge keyboard with lots of duplicated keys :) that is you should be able to press "ctrl" on one keyboard and "c" on another keyboard but it will still look like you pressed ctrl+c on the same keyboard :) the keypad is probably programmed to send the same scancodes as normal 101/102-keys keyboard would. that is for the group of keys on the right side (numeric keypad typically found under the keyboard lights). as in 101/102-keys keyboard case hitting numlock will only switch this group of keys between numbers/arrows. i guess this gives an answer to what to do with SETLED ioctl. kbdmux probably should send SETLED ioctl to all slave keyboards. that is hitting capslock on one keyboard should set capslock on all keyboards. >> thanks again for trying this and reporting the problems. i will try >> to get myself a couple of usb keyboards and reproduce/fix the >> problems. > > If you are in or somewhere near :) continental US, send me your > address in the private mail -- I'll ship you that keypad. actually Eric Anderson is going to send me a couple of usb keyboards. he said he has a pile of them :) is this the keypad you currently have? http://www.walmart.com/catalog/product.gsp?product_id=3380773&sourceid=11790802501271934686 thanks, max From owner-freebsd-current@FreeBSD.ORG Tue May 24 01:33:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C62716A41C for ; Tue, 24 May 2005 01:33:26 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from vms048pub.verizon.net (vms048pub.verizon.net [206.46.252.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4ACD643D1F for ; Tue, 24 May 2005 01:33:26 +0000 (GMT) (envelope-from Alex.Kovalenko@verizon.net) Received: from RabbitsDen ([70.21.190.81]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IGZ00BSM0BP3GX6@vms048.mailsrvcs.net> for freebsd-current@freebsd.org; Mon, 23 May 2005 20:33:25 -0500 (CDT) Date: Mon, 23 May 2005 21:31:15 -0400 From: "Alexandre \"Sunny\" Kovalenko" In-reply-to: <42925B36.9090400@savvis.net> To: Maksim Yevmenkin Message-id: <1116898275.701.9.camel@RabbitsDen> MIME-version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-type: text/plain; charset=iso-8859-5 Content-transfer-encoding: 8BIT References: <4288EBEA.5030701@savvis.net> <428A5A58.6010601@savvis.net> <428B7B99.7080206@savvis.net> <428E7BAF.200@savvis.net> <1116788908.824.23.camel@RabbitsDen> <429211C9.4000903@savvis.net> <1116885956.3386.10.camel@RabbitsDen> <42925B36.9090400@savvis.net> Cc: freebsd-current@freebsd.org Subject: Re: keyboard mux driver (straw man proposal & code) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 01:33:26 -0000 On Mon, 2005-05-23 at 15:37 -0700, Maksim Yevmenkin wrote: > Alexandre, > > >>> -- "Num lock" would switch keypad into numeric mode, but leave > >>> main keyboard alone (as it is the case with laptop keyboards it > >>> has sprinkling of numerals on the right side overlapping > >>> letters). > >> > >> again "num lock" on keypad or main keyboard? > > > > "Num lock" on the main keyboard (keypad does not have one) switches > > *keypad* into numeric mode leaving main keyboard in alpha -- main > > keyboard does not really have a numeric part -- it overlaps some of > > the alpha keys. > > this is actually correct (i think). because slave keyboards are set to > K_RAW mode, kbdmux will get raw scancodes, not characters. the (good or > bad?) side effect of this is that kbdmux will act as if it was one huge > keyboard with lots of duplicated keys :) that is you should be able to > press "ctrl" on one keyboard and "c" on another keyboard but it will > still look like you pressed ctrl+c on the same keyboard :) > > the keypad is probably programmed to send the same scancodes as normal > 101/102-keys keyboard would. that is for the group of keys on the right > side (numeric keypad typically found under the keyboard lights). as in > 101/102-keys keyboard case hitting numlock will only switch this group > of keys between numbers/arrows. Well, in the case of the keypad, it, probably is desired behavior... I mean the fact that only keypad is switched into numeric mode and laptop's keyboard is not. Whether it is "right" in more general sense, I don't know. Probably not, because it takes away functionality available to the user before introduction of the mux. > is this the keypad you currently have? > > http://www.walmart.com/catalog/product.gsp?product_id=3380773&sourceid=11790802501271934686 Looks like it -- I would not recommend it for normal use, but it certainly is good for experimenting. -- Alexandre "Sunny" Kovalenko (¾ÛÕÚáÐÝÔà ºÞÒÐÛÕÝÚÞ) From owner-freebsd-current@FreeBSD.ORG Tue May 24 02:57:45 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43A1D16A41C for ; Tue, 24 May 2005 02:57:45 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4857B43D49 for ; Tue, 24 May 2005 02:57:43 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j4O2vbxK063300 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 May 2005 06:57:42 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.1/8.12.8) with ESMTP id j4O2va9b061767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2005 06:57:36 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j4O2vVLI061766; Tue, 24 May 2005 06:57:31 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 24 May 2005 06:57:31 +0400 From: Gleb Smirnoff To: Alexander Leidinger Message-ID: <20050524025730.GC61461@cell.sick.ru> References: <20050522135915.6117ef26@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050522135915.6117ef26@Magellan.Leidinger.net> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff on relay.bestcom.ru X-Virus-Status: Clean Cc: current@FreeBSD.org Subject: Re: wrong link state change message from vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 02:57:45 -0000 Alexander, On Sun, May 22, 2005 at 01:59:15PM +0200, Alexander Leidinger wrote: A> I get a "vr0: link state changed to DOWN" when it should be a UP-message A> (kernel as of May 2). I want to fix this, but don't know what part of A> the source is responsible and how it should look like. Can someone A> please give me a hint? AFAIK, Bill has already fixed this. The code is at if_vr.c, in calls to if_link_state_change(). -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Tue May 24 03:02:03 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 925B416A41F for ; Tue, 24 May 2005 03:02:03 +0000 (GMT) (envelope-from alanbryan1234@yahoo.com) Received: from web50309.mail.yahoo.com (web50309.mail.yahoo.com [206.190.38.242]) by mx1.FreeBSD.org (Postfix) with SMTP id D626E43D49 for ; Tue, 24 May 2005 03:02:00 +0000 (GMT) (envelope-from alanbryan1234@yahoo.com) Received: (qmail 84501 invoked by uid 60001); 24 May 2005 03:01:58 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=RLIdugl2JcbUV88DTCIR/4U72zDPH4SYuHQPmxQo9IVRJEHoFgO+0EbVf4quWlsg61qb1/6Hmh+EExVrmhaeRZtgFXTU9UYrJqkoHTeMHy1CoSJyH1hMcOzAkZNfYqNhC6Jy+erngTA4yaT5TGpWHk9iv3H1TgO3Ix0jIaOwJYM= ; Message-ID: <20050524030158.84499.qmail@web50309.mail.yahoo.com> Received: from [67.99.246.2] by web50309.mail.yahoo.com via HTTP; Mon, 23 May 2005 20:01:58 PDT Date: Mon, 23 May 2005 20:01:58 -0700 (PDT) From: alan bryan To: Doug White In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nForce 4, SATA Drive only runs at UDMA33? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 03:02:03 -0000 Here's a recap of all the things I've tried and discovered in a bunch of testing today. Tried mkIII "m" patches and that doesn't show atapici1 or atapici2 - they just show as GENERIC with drives as UDMA33 Tried mkIII "n" patches and then atapici1 shows as nForce4 with SATA drives but has further problems detailed below. atapici2 always shows up in dmesg as GENERIC no matter what. Tried custom kernel, disabling all other parts of ATA with no difference. # ATA and ATAPI devices device ata device atadisk # ATA disk drives #device ataraid # ATA RAID drives #device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives options ATA_STATIC_ID # Static device numbering Tried disabling the standard IDE ports in bios, turning off DMA on SATA, and other bios tweaks with no changes. With the "n" patches I get randomly alternating: lockup, Fatal trap 12 panic, or full boot but then it can't find the root filesystem as the disk is showing as detached. If I get lucky and it goes most of the way I get results like the following: ata2: CONNECT REQUESTED ata2: DISCONNECT REQUESTED ... (lots of those!) ad6: 70911MB at ata3-master SATA 150 ad6: detached ata3: DISCONNECTED ata2: CONNECTED ata2: SATA connect status=00000000 ata2: DISCONNECTED ata3: CONNECTED ata3: SATA connect ready time=0ms ... Mounting root from ufs:/dev/ad6s1a setrootbyname failed ffs_mountroot: can't find rootvp root mount failed:6 Is there something else I should try to help in debugging this further? Is there anything in -CURRENT that would help this to work better than 5-STABLE plus the ATA mkIII "n" patches? Thanks for all the help! --Alan Bryan --- Doug White wrote: > On Fri, 20 May 2005, alan bryan wrote: > > > > > --- Doug White wrote: > > > Can you post the output of "pciconf -lv"? The > nForce > > > IDE controller is > > > properly detected, but it looks like there's > another > > > one in the system. > > > Looking at the spec for the system it may be the > > > proprietary nVidia RAID > > > controller. The pciconf output should help us > > > identify if thats the > > > issue. > > > > FYI: RAID features are disabled in the BIOS, I'm > just > > trying to get a single SATA drive to work at full > > speed. The other drive in this system is IDE and > that > > seems to be working at proper speed. Thanks for > the > > help! > > I guess turning off the RAID converts the chips into > standard SATA > controllers. I'll have to look into that. An nForce > 4 machine recently > appeared at work, so I'll see what I can get it to > do. > > > atapci0@pci0:6:0: class=0x01018a > card=0x50361297 > > chip=0x005310de rev=0xa2 hdr=0x00 > > vendor = 'NVIDIA Corporation' > > class = mass storage > > subclass = ATA > > atapci1@pci0:7:0: class=0x010185 > card=0x50361297 > > chip=0x005410de rev=0xa3 hdr=0x00 > > vendor = 'NVIDIA Corporation' > > class = mass storage > > subclass = ATA > > atapci2@pci0:8:0: class=0x010185 > card=0xcb8410de > > chip=0x005510de rev=0xa3 hdr=0x00 > > vendor = 'NVIDIA Corporation' > > class = mass storage > > subclass = ATA > > It looks like sos added support for atapci1 and 2 in > this listing in the > ATAmkIII patchset. While that patchset is in > -CURRENT you'll have to > apply the -stable patches yourself. Search the list > archives for the > location, soren posts it now and again. > > -- > Doug White | FreeBSD: The Power > to Serve > dwhite@gumbysoft.com | www.FreeBSD.org > __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail From owner-freebsd-current@FreeBSD.ORG Tue May 24 03:08:08 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 604EC16A41C; Tue, 24 May 2005 03:08:08 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from relay.bestcom.ru (relay.bestcom.ru [217.72.144.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 79AA443D1D; Tue, 24 May 2005 03:08:07 +0000 (GMT) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (root@cell.sick.ru [217.72.144.68]) by relay.bestcom.ru (8.13.1/8.12.9) with ESMTP id j4O384Ir063515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 24 May 2005 07:08:04 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: from cell.sick.ru (glebius@localhost [127.0.0.1]) by cell.sick.ru (8.13.1/8.12.8) with ESMTP id j4O383vF061853 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2005 07:08:03 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j4O383mg061852; Tue, 24 May 2005 07:08:03 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Tue, 24 May 2005 07:08:02 +0400 From: Gleb Smirnoff To: Mike Jakubik , wpaul@FreeBSD.org Message-ID: <20050524030802.GD61461@cell.sick.ru> References: <3475.172.16.0.199.1116881734.squirrel@172.16.0.1> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <3475.172.16.0.199.1116881734.squirrel@172.16.0.1> User-Agent: Mutt/1.5.6i X-Virus-Scanned: ClamAV version devel-20050125, clamav-milter version 0.80ff on relay.bestcom.ru X-Virus-Status: Clean Cc: freebsd-current@FreeBSD.org Subject: Re: non-sleepable locks held (xl0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 03:08:08 -0000 Mike, Bill, On Mon, May 23, 2005 at 04:55:34PM -0400, Mike Jakubik wrote: M> Not sure if this is reported already, but i got this on a recently cvsuped M> -current system while booting. ACK, my fault. We can't just zero ta_pending flag, since task may have alredy been triggered, and now is being waiting on driver lock at xl_rxeof_task(). Probably we need to run taskqueue_drain() before locking driver mutex, that is before call to xl_lock(). Bill, what is your opinion? -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Tue May 24 03:46:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9CF5016A41C for ; Tue, 24 May 2005 03:46:15 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3711A43D1F for ; Tue, 24 May 2005 03:46:15 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from dibbler.crodrigues.org (c-66-30-114-143.hsd1.ma.comcast.net[66.30.114.143]) by comcast.net (sccrmhc12) with ESMTP id <2005052403461301200a5mjre>; Tue, 24 May 2005 03:46:13 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by dibbler.crodrigues.org (8.13.3/8.13.1) with ESMTP id j4O3kJIK063023; Mon, 23 May 2005 23:46:19 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.3/8.13.1/Submit) id j4O3kIcA063022; Mon, 23 May 2005 23:46:18 -0400 (EDT) (envelope-from rodrigc) Date: Mon, 23 May 2005 23:46:18 -0400 From: Craig Rodrigues To: freebsd-current@freebsd.org Message-ID: <20050524034618.GA62892@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Kirill Ponomarew Subject: Kernel compilation errors with GCC 4.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 03:46:15 -0000 Hi, There was recent mention here: http://lists.freebsd.org/pipermail/freebsd-current/2005-April/049165.html by Kirill Ponomarew that GCC 4.0 would be a good thing to look at for inclusion in the base FreeBSD system. Just out of curiousity, I tried to compile a GENERIC kernel from -CURRENT, and wanted to see how many things would break (because knowing GCC, I knew things would break :). I used the following compiler from ports: gcc version 4.0.1 20050423 (prerelease) [FreeBSD] The pruned down results of what I got are Approx. 70 errors: http://people.freebsd.org/~rodrigc/gcc4.0_fbsdkernel_errors.txt Approx. 2700 warnings, converted to errors by -Werror: http://people.freebsd.org/~rodrigc/gcc4.0_fbsdkernel_warnings.txt I found a few changes in compiler flags with gcc 4.0: (1) The compiler complains that "-I-" is deprecated and that you should use "-iquote DIR" instead. I changed it in src/sys/conf/kern.pre.mk (2) "-mno-align-long-strings" seems to be gone and gives an error if you use it. I commented it out of src/sys/conf/kern.mk (3) "-fformat-extensions" is a FreeBSD extension that is in the FreeBSD system gcc compiler, but not the FSF/ports gcc compiler. I commented it out of /usr/share/mk/bsd.kern.mk There were a lot of warnings (especially in the CAM layer, but in other places too) of the type: /usr/src/sys/cam/cam_periph.c:640: warning: pointer targets in assignment differ in signedness I don't know if these are legitimate things that should be addressed, or if GCC 4.0 is being needlessly pedantic. I did not bother to try to compile any FreeBSD userland or ports. >From what I can tell, a lot of things break with GCC 4.0, so I can't tell if it performs better than GCC 3.4 or not. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Tue May 24 04:11:46 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F18B16A41C for ; Tue, 24 May 2005 04:11:46 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4875D43D1F for ; Tue, 24 May 2005 04:11:46 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 947B5DAC2; Tue, 24 May 2005 00:11:45 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id 9EA1D1A082E; Tue, 24 May 2005 00:10:57 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17042.43345.594850.534649@canoe.dclg.ca> Date: Tue, 24 May 2005 00:10:57 -0400 To: freebsd-current@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Subject: 3 things working in -STABLE and not in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 04:11:46 -0000 I recently upgraded my laptop to -CURRENT from 5.4-STABLE. Curiously, I have found 3 unrelated things that broke. In each case, I have recompiled any code I believe remotely responsible. 1) atacontrol reinit 1 This command used to recognise the hot plug of my CDROM into my laptop bay. It now recognises that something is there, but can get no version string from the probe and definately doesn't recognise the drive. I suspect this is actually somehow related to ACPI ... as the hot-swapability of the drive bay has depended on acpi.ko being loaded in the past. 2) cdparanoia and USB CDROM. The same cdrom drive can be used in an external bay that is connected via USB (when the device is internal, it connects to an ATAPI bus). When external, cdparanoia will not recognise the drive... even though it claims to understand scsi cdroms. This one is likely not ACPI related. 3) IRDA and ircomm. I have traditionally used ircomm -Y -d /dev/cuaa1 to talk to my palm pilot. After the upgrade to -CURRENT, ircomm exits immediately without establishing a connection and without any diagnostics. The IR port still probes fine ... and the palm sees something ... I think but I'm not sure. It behaves differently than when there is no connection at all. Palm connections over USB seem fine. Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-current@FreeBSD.ORG Tue May 24 05:07:13 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: by hub.freebsd.org (Postfix, from userid 618) id 0935F16A41F; Tue, 24 May 2005 05:07:13 +0000 (GMT) In-Reply-To: <20050524030802.GD61461@cell.sick.ru> from Gleb Smirnoff at "May 24, 2005 07:08:02 am" To: glebius@FreeBSD.org (Gleb Smirnoff) Date: Tue, 24 May 2005 05:07:13 +0000 (GMT) X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20050524050713.0935F16A41F@hub.freebsd.org> From: wpaul@FreeBSD.ORG (Bill Paul) Cc: mikej@rogers.com, freebsd-current@FreeBSD.org Subject: Re: non-sleepable locks held (xl0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 05:07:13 -0000 > Mike, Bill, > > On Mon, May 23, 2005 at 04:55:34PM -0400, Mike Jakubik wrote: > M> Not sure if this is reported already, but i got this on a recently cvsuped > M> -current system while booting. > > ACK, my fault. > > We can't just zero ta_pending flag, since task may have alredy been > triggered, and now is being waiting on driver lock at xl_rxeof_task(). > > Probably we need to run taskqueue_drain() before locking driver > mutex, that is before call to xl_lock(). > > Bill, what is your opinion? You can't sleep in taskqueue_drain() with a lock held (clowns will eat you). Wait for the taskqueue to drain first, then lock. -Bill -- ============================================================================= -Bill Paul (510) 749-2329 | Senior Engineer, Master of Unix-Fu wpaul@windriver.com | Wind River Systems ============================================================================= you're just BEGGING to face the moose ============================================================================= From owner-freebsd-current@FreeBSD.ORG Tue May 24 05:25:48 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0219316A41C; Tue, 24 May 2005 05:25:48 +0000 (GMT) (envelope-from Peter_Losher@isc.org) Received: from farside.isc.org (farside.isc.org [204.152.187.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C936D43D4C; Tue, 24 May 2005 05:25:47 +0000 (GMT) (envelope-from Peter_Losher@isc.org) Received: from dhcp-2.sql1.plosh.net (c-24-4-233-31.hsd1.ca.comcast.net [24.4.233.31]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by farside.isc.org (Postfix) with ESMTP id 8D7F867503; Tue, 24 May 2005 05:25:47 +0000 (UTC) (envelope-from Peter_Losher@isc.org) From: Peter Losher Organization: ISC To: freebsd-current@freebsd.org Date: Mon, 23 May 2005 22:25:34 -0700 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2806927.7nh3Nfkrvg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505232225.46422.Peter_Losher@isc.org> Cc: Damien Bergamini Subject: ral driver and wpa_supplicant X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 05:25:48 -0000 --nextPart2806927.7nh3Nfkrvg Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline I bought a Belkin F5D7010 802.11g card (version 3001) which is based off of= =20 the RT2500 chipset to use on a WPA-PSK enabled network (running 6-CURRENT=20 kernel built from sources as of six hours ago) Running wpa_supplicant caus= es=20 a segfault with the following stack backtrace: =2D=3D- ral0: mem 0xf6002000-0xf6003fff irq 11 at device= =20 0.0 on cardbus0 ral0: MAC/BBP RT2560 (rev 0x04), RF RT2525 ral0: Ethernet address: 00:11:50:4a:8a:15 [...] malloc(M_WAITOK) of "32", forcing M_NOWAIT with the following non-sleepable= =20 locks held: exclusive sleep mutex ral0 (network driver) r =3D 0 (0xc20b8d54) locked=20 @ /usr/src/sys/modules/ral/../../dev/ral/if_ral.c:2161 KDB: stack backtrace: kdb_backtrace(1,1,1,20,c1052420) at kdb_backtrace+0x29 witness_warn(5,0,c085a34d,c085fc45,e6627b1c) at witness_warn+0x19a uma_zalloc_arg(c1052420,0,2) at uma_zalloc_arg+0x46 malloc(16,c08a1a20,2,801c69ea,c217148c) at malloc+0xae ieee80211_ioctl_setoptie(c20b825c,c228a7a0,e6627b70,246,c090ed40) at=20 ieee80211_ioctl_setoptie+0x38 ieee80211_ioctl_set80211(c20b825c,801c69ea,c228a7a0,0,c20b8000) at=20 ieee80211_ioctl_set80211+0x6bb ieee80211_ioctl(c20b825c,801c69ea,c228a7a0,c20b8d54,0) at=20 ieee80211_ioctl+0x105 ral_ioctl(c20b8000,801c69ea,c228a7a0,e6627c38,c06186f8) at ral_ioctl+0x4e in_control(c22a27c8,801c69ea,c228a7a0,c20b8000,c21dfc00) at in_control+0xabd ifioctl(c22a27c8,801c69ea,c228a7a0,c21dfc00,0) at ifioctl+0x198 soo_ioctl(c22141b0,801c69ea,c228a7a0,c1e2ba80,c21dfc00) at soo_ioctl+0x2db ioctl(c21dfc00,e6627d04,3,2,286) at ioctl+0x370 syscall(3b,3b,3b,bfbfeb3c,8074260) at syscall+0x227 Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x2823727f, esp =3D 0xbfb= feafc,=20 ebp =3D 0xbfbfeb58 --- pid 367 (wpa_supplicant), uid 0: exited on signal 11 (core dumped) =2D=3D- (I have the wpa_supplicant.core available if need be) Any Ideas? Best Wishes - Peter =2D-=20 Peter_Losher@isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow" --nextPart2806927.7nh3Nfkrvg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCkrraPtVx9OgEjQgRAvstAKC6mSnB97qh+rP39jbqf11UnFqJvACg2Ntx LMI33LTyTChHCPmLMVdGcH4= =wgH4 -----END PGP SIGNATURE----- --nextPart2806927.7nh3Nfkrvg-- From owner-freebsd-current@FreeBSD.ORG Tue May 24 05:29:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CA5A16A41C for ; Tue, 24 May 2005 05:29:34 +0000 (GMT) (envelope-from conrads@cox.net) Received: from lakermmtao05.cox.net (lakermmtao05.cox.net [68.230.240.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B25343D1F for ; Tue, 24 May 2005 05:29:33 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.70.216]) by lakermmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050524052934.HHZZ13442.lakermmtao05.cox.net@dolphin.local.net>; Tue, 24 May 2005 01:29:34 -0400 Received: from dolphin.local.net (localhost.local.net [IPv6:::1]) by dolphin.local.net (8.13.3/8.13.3) with ESMTP id j4O5TUmL033440; Tue, 24 May 2005 00:29:32 -0500 (CDT) (envelope-from conrads@cox.net) Date: Tue, 24 May 2005 00:29:25 -0500 From: "Conrad J. Sabatier" To: David Gilbert Message-ID: <20050524002925.2f05fc55@dolphin.local.net> In-Reply-To: <17042.43345.594850.534649@canoe.dclg.ca> References: <17042.43345.594850.534649@canoe.dclg.ca> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 3 things working in -STABLE and not in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 05:29:34 -0000 On Tue, 24 May 2005 00:10:57 -0400, David Gilbert wrote: > I recently upgraded my laptop to -CURRENT from 5.4-STABLE. Curiously, > I have found 3 unrelated things that broke. In each case, I have > recompiled any code I believe remotely responsible. > > 1) atacontrol reinit 1 > > This command used to recognise the hot plug of my CDROM into my laptop > bay. It now recognises that something is there, but can get no > version string from the probe and definately doesn't recognise the > drive. > > I suspect this is actually somehow related to ACPI ... as the > hot-swapability of the drive bay has depended on acpi.ko being loaded > in the past. I've been corresponding with Soren about a very similar problem. My DVD writer on ata1-master is not being recognized. Instead, my CD-RW on ata1-slave is being configured as acd0. I've been doing daily upgrades (amd64), but still to no avail, and Soren seems to be stumped as well. The hardware seems to be fine. I can boot a CD-ROM from the DVD drive with no problems, and a 5.2-RELEASE disc (i386) recognizes both drives. At least it's nice to know I'm not the only one. :-) -- Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Tue May 24 05:32:58 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3ECF016A41C; Tue, 24 May 2005 05:32:58 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id A662C43D1F; Tue, 24 May 2005 05:32:57 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j4O5QMCs054275; Tue, 24 May 2005 07:26:22 +0200 (CEST) (envelope-from sos@FreeBSD.org) In-Reply-To: <20050524030158.84499.qmail@web50309.mail.yahoo.com> References: <20050524030158.84499.qmail@web50309.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <681FA8EA-2B6E-4923-9529-4C1BB26BD846@FreeBSD.org> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Tue, 24 May 2005 07:32:51 +0200 To: alan bryan X-Mailer: Apple Mail (2.730) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-stable@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: nForce 4, SATA Drive only runs at UDMA33? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 05:32:58 -0000 On 24/05/2005, at 5:01, alan bryan wrote: > Here's a recap of all the things I've tried and > discovered in a bunch of testing today. > > Tried mkIII "m" patches and that doesn't show atapici1 > or atapici2 - they just show as GENERIC with drives as > UDMA33 > > Tried mkIII "n" patches and then atapici1 shows as > nForce4 with SATA drives but has further problems > detailed below. atapici2 always shows up in dmesg as > GENERIC no matter what. ... > Is there anything in -CURRENT that would help this to > work better than 5-STABLE plus the ATA mkIII "n" > patches? Yes, I've done quite a bit of changes that affects this on -current. =20 However its done blindfolded since I dont have a nForce4 based system =20= here yet (but should soon). - S=F8ren From owner-freebsd-current@FreeBSD.ORG Tue May 24 05:38:19 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9ACE816A41C for ; Tue, 24 May 2005 05:38:19 +0000 (GMT) (envelope-from yongari@rndsoft.co.kr) Received: from rndsoft.co.kr (michelle.rndsoft.co.kr [211.32.202.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BF5443D1D for ; Tue, 24 May 2005 05:38:18 +0000 (GMT) (envelope-from yongari@rndsoft.co.kr) Received: from yongari@rndsoft.co.kr(192.168.5.90) by MailFilter v1.05 with ESMTP Processed in 0.130548 secs; 24 May 2005 14:35:23 +0900 Received: from michelle.rndsoft.co.kr (localhost.rndsoft.co.kr [127.0.0.1]) by michelle.rndsoft.co.kr (8.13.1/8.13.1) with ESMTP id j4O5aSxf005988 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 24 May 2005 14:36:28 +0900 (KST) (envelope-from yongari@rndsoft.co.kr) Received: (from yongari@localhost) by michelle.rndsoft.co.kr (8.13.1/8.13.1/Submit) id j4O5aQWL005987; Tue, 24 May 2005 14:36:26 +0900 (KST) (envelope-from yongari@rndsoft.co.kr) Date: Tue, 24 May 2005 14:36:26 +0900 From: Pyun YongHyeon To: cpghost Message-ID: <20050524053626.GA5353@rndsoft.co.kr> References: <4286AB34.6050101@elischer.org> <20050515093422.GA18361@fw.farid-hajji.net> <42871944.4030506@elischer.org> <20050516022100.GB1020@rndsoft.co.kr> <4291D0CA.9090706@cordula.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4291D0CA.9090706@cordula.ws> User-Agent: Mutt/1.4.2.1i Cc: Current , Julian Elischer Subject: Re: skype on current/5.x and maestro-2E sound X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yongari@rndsoft.co.kr List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 05:38:19 -0000 On Mon, May 23, 2005 at 02:47:06PM +0200, cpghost wrote: > Pyun YongHyeon wrote: > > >On Sun, May 15, 2005 at 02:41:24AM -0700, Julian Elischer wrote: > >> cpghost@cordula.ws wrote: > >> >On Sat, May 14, 2005 at 06:51:48PM -0700, Julian Elischer wrote: > >> > > >> >>Has anyone run skype successfully on these versions (5 or 6) of > >freeBSD? > >> >>I can run it successfully on 4.x but on my 5.x machine the audio is > >> >>completely > >> >>broken up. like someone is chopping the audio stream. > >> > > >> > > >> >I'm running Skype on 5.4 (via82c686). On an AMD Duron 1200 MHz, the > >> >sound quality is all right; on an EPIA 5000 Eden 500 MHz (also > >via82c686), > >> >the sound is totally chopped and it is impossible to follow. > >> > >> hmm so maybe its the fact that my machine is too slow.. it's also 500MHz > >> my 1GHz 4.11 machine seems to run it fine. > >> > > > >I don't think 500MHz is too slow. Check if kernel converters > >are active when you play audio samples.(cat /dev/sndstat after > >setting hw.snd.verbose=2). > > > > > This is what I get while skype plays the chopped sound of the echo service: > > epia2# cat /dev/sndstat > FreeBSD Audio Driver (newpcm) > Installed devices: > pcm0: at io 0xdc00 irq 10 kld snd_via82c686 (1p/1r/0v > channels duplex default) > [pcm0:play:0]: spd 48000, fmt 0x00000010, flags 0x00003030, > 0x00000000, pid 78793 > interrupts 18062, underruns 4824, ready 3580 > {userland} -> feeder_root(0x00000010) -> {hardware} > [pcm0:record:0]: spd 48000, fmt 0x00000010, flags 0x00003030, > 0x00000000, pid 78793 > interrupts 16968, overruns 4808, hfree 512, sfree 3584 > {hardware} -> feeder_root(0x00000010) -> {userland} > > No idea how to interpret this. > Format : sampling rate 48KHz, signed 16bit little endian format channel flags : opened, block size set, DMA active, triggered feeder flags : no flags(no kernel converter involed) It seems that no kernel converters are active. But you have large feeder underrun counters. It means sound quality would be poor. Quick looking the driver source showed that via82c686 has fixed sampling rate(48KHz) for playback. So userland application may need to resampling operations which requires additional CPU cycles. I vaguely guess the driver should work better than other cheap audio cards as it supports scatter/gatter DMA operations. If 500MHz CPU is not sufficient for the driver to work correctly I think something is wrong in the driver. Since I don't have a copy of 82C686 data sheet and hardware I don't know where the problem is. :-( > >Since the driver also needs Giant lock it may suffer from interrupt > >latencies with other devices. In addition if it share IRQ with > >other devices(e.g. USB) the issue would be noticable. > > > > > None that I know of: > > epia2# vmstat -i > interrupt total rate > irq0: clk 30624081 99 > irq1: atkbd0 416592 1 > irq8: rtc 39199914 128 > irq10: pcm0 1210380 3 > irq11: vr0 531082 1 > irq12: psm0 1354640 4 > irq13: npx0 1 0 > irq14: ata0 3681643 12 > Total 77018333 251 > > irc10 is not shared by any other likely interrupt source, or so it seems. > Do you use VCHAN? How about increasing DMA buffer size to 8 or 16KB? Default DMA buffer size is 4KB(via82c686.c, line 44) which I guess too small to support scatter/gatter DMA operations. How many pcm interrupts do you see when you use skype? (Use systat -vmstat 1 to to see the number of interrupts/second.) -- Regards, Pyun YongHyeon http://www.kr.freebsd.org/~yongari | yongari@freebsd.org From owner-freebsd-current@FreeBSD.ORG Tue May 24 05:57:47 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9D5E916A41C for ; Tue, 24 May 2005 05:57:47 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BD2C43D1F for ; Tue, 24 May 2005 05:57:46 +0000 (GMT) (envelope-from sos@FreeBSD.org) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j4O5p4bv054524; Tue, 24 May 2005 07:51:04 +0200 (CEST) (envelope-from sos@FreeBSD.org) In-Reply-To: <20050524002925.2f05fc55@dolphin.local.net> References: <17042.43345.594850.534649@canoe.dclg.ca> <20050524002925.2f05fc55@dolphin.local.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <1FA05BA9-15DF-496B-95AE-664815096717@FreeBSD.org> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Tue, 24 May 2005 07:57:34 +0200 To: "Conrad J. Sabatier" X-Mailer: Apple Mail (2.730) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-current@FreeBSD.org, David Gilbert Subject: Re: 3 things working in -STABLE and not in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 05:57:47 -0000 On 24/05/2005, at 7:29, Conrad J. Sabatier wrote: > On Tue, 24 May 2005 00:10:57 -0400, David Gilbert > wrote: > > >> I recently upgraded my laptop to -CURRENT from 5.4-STABLE. =20 >> Curiously, >> I have found 3 unrelated things that broke. In each case, I have >> recompiled any code I believe remotely responsible. >> >> 1) atacontrol reinit 1 >> >> This command used to recognise the hot plug of my CDROM into my =20 >> laptop >> bay. It now recognises that something is there, but can get no >> version string from the probe and definately doesn't recognise the >> drive. Hmm, if you do a atacontrol detach ata1 then atacontrol attach ata1 =20 does that change the behavior ? >> I suspect this is actually somehow related to ACPI ... as the >> hot-swapability of the drive bay has depended on acpi.ko being loaded >> in the past. >> > > I've been corresponding with Soren about a very similar problem. My > DVD writer on ata1-master is not being recognized. Instead, my > CD-RW on ata1-slave is being configured as acd0. I've been doing =20 > daily > upgrades (amd64), but still to no avail, and Soren seems to be stumped > as well. I don't think this is the same problem, yours seem to be interaction =20 between the two drives that somehow makes the probe barf... - S=F8ren From owner-freebsd-current@FreeBSD.ORG Tue May 24 08:06:15 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8C91D16A41C for ; Tue, 24 May 2005 08:06:15 +0000 (GMT) (envelope-from roger@gwch.net) Received: from mail.gwch.net (80-219-201-207.dclient.hispeed.ch [80.219.201.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23E3443D1F for ; Tue, 24 May 2005 08:06:14 +0000 (GMT) (envelope-from roger@gwch.net) Received: from localhost (link [127.0.0.1]) by mail.gwch.net (Postfix) with ESMTP id CEFF140854 for ; Tue, 24 May 2005 10:08:45 +0200 (CEST) Received: from mail.gwch.net ([127.0.0.1]) by localhost (mail.gwch.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14938-03 for ; Tue, 24 May 2005 10:08:42 +0200 (CEST) Received: from www.gwch.net (mordor.gwch.net [192.168.2.102]) by mail.gwch.net (Postfix) with ESMTP id 5DAD540845 for ; Tue, 24 May 2005 10:08:42 +0200 (CEST) Received: from 62.2.21.164 (SquirrelMail authenticated user rogerg) by www.gwch.net with HTTP; Tue, 24 May 2005 10:06:09 +0200 (CEST) Message-ID: <49597.62.2.21.164.1116921969.squirrel@www.gwch.net> In-Reply-To: <20050523141411.S47305@maren.thelosingend.net> References: <53594.62.2.21.164.1116829270.squirrel@www.gwch.net> <20050523141411.S47305@maren.thelosingend.net> Date: Tue, 24 May 2005 10:06:09 +0200 (CEST) From: "Roger Grosswiler" To: current@freebsd.org User-Agent: SquirrelMail/1.4.4-2 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 gwch.net Cc: Subject: Re: openoffice-setup not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: roger@gwch.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 08:06:15 -0000 > > * Roger Grosswiler [2005-05-23 08:21 +0200] >> after having installed the packages from openoffice, i tried to install >> openoffice via openoffice-setup as explained in the manual. I only got >> the message "openoffice-setup not found" >> >> Is there a hint for openoffice? I even did not find oowriter.. > > > I'm nut sure what kind of manual you are talking about, but on my system > these applications are installed as > > openoffice.org-1.1.4-setup > openoffice.org-1.1.4-writer > &c. > > > These are just wrappers (or rather a wrapper) for > > /usr/local/OpenOffice.org1.1.4/program/setup > /usr/local/OpenOffice.org1.1.4/program/writer > &c. > > > I found in /usr/local/OpenOffice.org1.1.4/program/setup, which i runned for a local installation. Earlier versions required a server-install an then the workstation-install, but no longer 1.1.4? After the setup i had my apps, now they can be found in /usr/local/bin/ and are (eg writer) called openoffice.org-1.1.4-swriter. Unfortunately, i do not get any icons in gnome-menu. Roger From owner-freebsd-current@FreeBSD.ORG Tue May 24 08:55:12 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5FB4716A41C for ; Tue, 24 May 2005 08:55:12 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from peedub.jennejohn.org (J9fa5.j.pppool.de [85.74.159.165]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C95743D48 for ; Tue, 24 May 2005 08:55:11 +0000 (GMT) (envelope-from garyj@jennejohn.org) Received: from jennejohn.org (localhost [127.0.0.1]) by peedub.jennejohn.org (8.13.3/8.11.6) with ESMTP id j4O8sxGP003843; Tue, 24 May 2005 10:55:06 +0200 (CEST) (envelope-from garyj@jennejohn.org) Message-Id: <200505240855.j4O8sxGP003843@peedub.jennejohn.org> X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: David Gilbert In-Reply-To: Message from David Gilbert of "Tue, 24 May 2005 00:10:57 EDT." <17042.43345.594850.534649@canoe.dclg.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 24 May 2005 10:54:59 +0200 From: Gary Jennejohn Cc: freebsd-current@freebsd.org Subject: Re: 3 things working in -STABLE and not in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 08:55:12 -0000 David Gilbert writes: > 3) IRDA and ircomm. > > I have traditionally used ircomm -Y -d /dev/cuaa1 to talk to my palm > pilot. After the upgrade to -CURRENT, ircomm exits immediately > without establishing a connection and without any diagnostics. > This may be because -current uses cuad* and not cuaa*. At least, on my -current only cuad* is present. --- Gary Jennejohn / garyjATjennejohnDOTorg gjATfreebsdDOTorg garyjATdenxDOTde From owner-freebsd-current@FreeBSD.ORG Mon May 23 15:02:29 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB39516A41C for ; Mon, 23 May 2005 15:02:29 +0000 (GMT) (envelope-from steve@virtual-voodoo.com) Received: from energistic.com (mail.energistic.com [216.54.148.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 710D543D1D for ; Mon, 23 May 2005 15:02:28 +0000 (GMT) (envelope-from steve@virtual-voodoo.com) Received: from stevenew (bdsl.66.12.217.51.gte.net [66.12.217.51]) (authenticated bits=0) by energistic.com (8.13.3/8.13.3) with ESMTP id j4NF2PcS091396; Mon, 23 May 2005 10:02:27 -0500 (EST) (envelope-from steve@virtual-voodoo.com) Message-ID: <004d01c55fa8$736c9ed0$aa00030a@officescape.net> From: "Steve Ames" To: "Randy Bush" , "FreeBSD Current" References: <200504191530.j3JFUvWD030545@energistic.com><20050419165227.GA86651@energistic.com><20050420005744.Y64858@lexi.siliconlandmark.com><200504271404.10021.jhb@FreeBSD.org> <17041.60442.522858.744833@roam.psg.com> Date: Mon, 23 May 2005 10:02:33 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1478 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478 X-Spam-Status: No, score=-6.0 required=5.0 tests=AWL, BAYES_50, J_CHICKENPOX_63, SPF_FAIL,USER_IN_WHITELIST_TO autolearn=no version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on energistic.com X-Mailman-Approved-At: Tue, 24 May 2005 12:03:27 +0000 Cc: Subject: Re: kernel.old not used any longer? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 May 2005 15:02:30 -0000 Where you attempting to install the kernel into the same directory as the running kernel? That seems to be the condition to match. Previously if DESTDIR was set to / then it wouldn't do a kernel.old properly because the directory of the running kernel wouldn't match. ru@ fixed that. If DESTDIR is set to something other than / I wouldn't expect kernel.old to be created. ----- Original Message ----- From: "Randy Bush" To: "FreeBSD Current" Sent: Monday, May 23, 2005 9:43 AM Subject: Re: kernel.old not used any longer? > > On Wednesday 20 April 2005 01:02 am, Andre Guibert de Bruet wrote: > >> On Tue, 19 Apr 2005, Steve Ames wrote: > >>> Hrm. Almost the same as you. On mine that first comparison is actually > >>> "!= //boot/kernel". Likely because I have "DESTDIR?=/" in /etc/make.conf. > >>> > >>> Hrm. Suddenly all makes sense. I defined DESTDIR so that 'make world' > >>> would continue to work normally (instead of doing > >>> buildworld/installworld) and that probably happened around August '04. > >>> > >>> So I guess if I get rid of DESTDIR and start doing > >>> buildworld/installworld then I get kernel.old functionality again... > >>> however this tastes like a bug to me. Perhaps that comparison should be: > >>> > >>> "!= ${DESTIR}/boot/kernel" ?? > >> > >> This is not a bug. You are looking for the functionality that is offered > >> by HISTORICAL_MAKE_WORLD. > > > > This isn't part of make world. I do think he has found a bug. ru@ is the > > person to ask. > > sorry to be slow (marriage and honeymoon (aborted due to medical emergency > in wife's family)), but what happened to this thread? i just cvsupped and > did a make kernel with /etc/make.conf having KERNCONF=MYKERNEL, and did > not get kernel.old. > > randy > > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Tue May 24 05:49:32 2005 Return-Path: X-Original-To: freebsd-current@www.freebsd.org Delivered-To: freebsd-current@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0868D16A41C; Tue, 24 May 2005 05:49:32 +0000 (GMT) (envelope-from matt@mattford.net) Received: from mx.muttart.org (mx.muttart.org [66.18.201.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 648B943D1D; Tue, 24 May 2005 05:49:31 +0000 (GMT) (envelope-from matt@mattford.net) Received: from mail pickup service by mx.muttart.org with Microsoft SMTPSVC; Mon, 23 May 2005 23:48:56 -0600 Received: from mx2.freebsd.org ([216.136.204.119]) by mx.muttart.org with Microsoft SMTPSVC(6.0.3790.1830); Sat, 14 May 2005 04:54:08 -0600 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 967935596F; Sat, 14 May 2005 10:53:32 +0000 (GMT) (envelope-from owner-freebsd-questions@freebsd.org) Received: from hub.freebsd.org (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id DDEA716A4FB; Sat, 14 May 2005 10:53:16 +0000 (GMT) Delivered-To: freebsd-questions@www.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D7A8616A4CE; Sat, 14 May 2005 10:48:05 +0000 (GMT) Received: from monroe.tera-byte.com (monroe.tera-byte.com [216.194.64.209]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F21A43D5D; Sat, 14 May 2005 10:48:03 +0000 (GMT) (envelope-from matt@mattford.net) Received: from [192.168.7.9] (limend.plus.com [80.229.15.68]) (authenticated (0 bits)) by monroe.tera-byte.com (8.11.6/8.11.6) with ESMTP id j4EAm2406383; Sat, 14 May 2005 04:48:02 -0600 Message-ID: <4285D734.90400@mattford.net> Date: Sat, 14 May 2005 11:47:16 +0100 From: Matt User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050403) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@www.freebsd.org, freebsd-questions@www.freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Sender: owner-freebsd-questions@freebsd.org Errors-To: owner-freebsd-questions@freebsd.org X-OriginalArrivalTime: 14 May 2005 10:54:08.0840 (UTC) FILETIME=[4134F480:01C55873] X-Mailman-Approved-At: Tue, 24 May 2005 12:03:46 +0000 Cc: Subject: System Crash when kldload if_ndis X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 05:49:32 -0000 I'm not sure if the problem I am having is with the kernel modules I am using (I've tried with two different ones) or with the ndis module itself or what. I am running FreeBSD 5.4 amd64 on an Asus A8V-E Deluxe motherboard, AMD 64 3000+, 512MB RAM. The ndis drivers I am using are for a Marvell 88E8053 gigabit ehternet controller and the onBoard wifi controller of the Asus A8V-E Deluxe (i'm not sure what the chipset is). When using ndiscvt I get the error "section relocation failed". Other errors is when I am trying to ndiscvt the marvell driver I get the error: ndiscvt: line 238: Controlled%: syntax error. Here are the lines in the inf file: 237: HKR, Ndi\Params\WakeUpModeCap_A\enum, 0,, %Non% 238: HKR, Ndi\Params\WakeUpModeCap_A\enum, 15,, %OS Controlled% 239: HKR, Ndi\Params\WakeUpModeCap_A\enum, 25,, %Magic Packet% Basically I don't think it likes the spaces, so I went through the whole inf deleting the spaces wherever it threw up a syntax error and in the end it compiled a kernel module that then crashed the system. I didn't get a chance to get the error when it crashed the system. The wifi driver went through ndiscvt without any problems but when I try and kldload the wifi driver I get this error: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x96222d5b fault code = supervisor read, page not present instruction pointer = 0x8:0xffffffff961e2466 stack pointer = 0x10:0xffffffff961d75d0 frame pointer = 0x10:096222d57 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = Interrupt enabled, resume, IOPL = 0 current process = 472 (kldload) trap number = 12 panic: page fault Other points to note is that I had to run the marvell .inf file through iconv with the -c flag to ignore characters it couldn't convert, this could possibly have left out some important data from the inf maybe? I'll be gratefull for any suggestions _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Tue May 24 12:50:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 29D6D16A41C for ; Tue, 24 May 2005 12:50:35 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from poup.poupinou.org (poup.poupinou.org [195.101.94.96]) by mx1.FreeBSD.org (Postfix) with ESMTP id D524F43D1D for ; Tue, 24 May 2005 12:50:34 +0000 (GMT) (envelope-from ducrot@poupinou.org) Received: from ducrot by poup.poupinou.org with local (Exim) id 1DaYre-0006S8-00; Tue, 24 May 2005 14:50:30 +0200 Date: Tue, 24 May 2005 14:50:29 +0200 To: Jeremie Le Hen Message-ID: <20050524125029.GB21800@poupinou.org> References: <20050517163212.GG14297@obiwan.tataz.chchile.org> <20050523090425.GW21800@poupinou.org> <20050523132204.GZ850@obiwan.tataz.chchile.org> <20050523145810.GY21800@poupinou.org> <20050523222440.GM850@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050523222440.GM850@obiwan.tataz.chchile.org> User-Agent: Mutt/1.5.6+20040907i From: Bruno Ducrot Cc: freebsd-current@FreeBSD.org Subject: Re: ACPI errors with recent laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 12:50:35 -0000 On Tue, May 24, 2005 at 12:24:41AM +0200, Jeremie Le Hen wrote: > Thanks for your patch, it removed all warnings. However, it did just > that, since I can't access hw.acpi.battery.life and hw.acpi.battery.time, > they are just both set to the famous "Zero" :-). I have to say this is > quite boring for a laptop, I would have prefered not being able to > get the temperature, for example. The BIOS is quite old (the boot screen > displays 2003), but the manufacturer doesn't provide any BIOS upgrade > on their website ATM. Since this is a new special model reserved for > promotions, I still hope they will provide an upgrade soon. > Well. I will look a little bit further then. BTW, what say acpiconf -i 0 acpiconf -i 1 Cheers, -- Bruno Ducrot -- Which is worse: ignorance or apathy? -- Don't know. Don't care. From owner-freebsd-current@FreeBSD.ORG Tue May 24 13:32:09 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 058AC16A41C for ; Tue, 24 May 2005 13:32:09 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (eva.fit.vutbr.cz [147.229.10.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7865243D1D for ; Tue, 24 May 2005 13:32:07 +0000 (GMT) (envelope-from xdivac02@stud.fit.vutbr.cz) Received: from eva.fit.vutbr.cz (localhost [127.0.0.1]) by eva.fit.vutbr.cz (envelope-from xdivac02@eva.fit.vutbr.cz) (8.13.4/8.13.3) with ESMTP id j4ODW4du050207 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO) for ; Tue, 24 May 2005 15:32:04 +0200 (CEST) Received: (from xdivac02@localhost) by eva.fit.vutbr.cz (8.13.4/8.13.3/Submit) id j4ODW4qj050205 for freebsd-current@freebsd.org; Tue, 24 May 2005 15:32:04 +0200 (CEST) Date: Tue, 24 May 2005 15:32:04 +0200 From: Divacky Roman To: freebsd-current@freebsd.org Message-ID: <20050524133204.GA49389@stud.fit.vutbr.cz> References: <20050524034618.GA62892@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524034618.GA62892@crodrigues.org> User-Agent: Mutt/1.4.2i X-Scanned-By: MIMEDefang 2.49 on 147.229.10.14 Subject: Re: Kernel compilation errors with GCC 4.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 13:32:09 -0000 On Mon, May 23, 2005 at 11:46:18PM -0400, Craig Rodrigues wrote: > Hi, > > There was recent mention here: > > http://lists.freebsd.org/pipermail/freebsd-current/2005-April/049165.html > > by Kirill Ponomarew that GCC 4.0 would be a good thing to look > at for inclusion in the base FreeBSD system. dfly has just imported gcc40 into the tree, and I think their infracstructure for more than one gcc in tree is nice and usefull.. and I agree - gcc40 shows nice strict behaviour :) roman From owner-freebsd-current@FreeBSD.ORG Tue May 24 13:42:36 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 413C316A41C for ; Tue, 24 May 2005 13:42:36 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix3-2.free.fr (postfix3-2.free.fr [213.228.0.169]) by mx1.FreeBSD.org (Postfix) with ESMTP id D18F943D4C for ; Tue, 24 May 2005 13:42:35 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from tatooine.tataz.chchile.org (vol75-8-82-233-239-98.fbx.proxad.net [82.233.239.98]) by postfix3-2.free.fr (Postfix) with ESMTP id B2D89C08F; Tue, 24 May 2005 15:42:34 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 33CEA407E; Tue, 24 May 2005 15:42:34 +0200 (CEST) Date: Tue, 24 May 2005 15:42:34 +0200 From: Jeremie Le Hen To: Bruno Ducrot Message-ID: <20050524134234.GS850@obiwan.tataz.chchile.org> References: <20050517163212.GG14297@obiwan.tataz.chchile.org> <20050523090425.GW21800@poupinou.org> <20050523132204.GZ850@obiwan.tataz.chchile.org> <20050523145810.GY21800@poupinou.org> <20050523222440.GM850@obiwan.tataz.chchile.org> <20050524125029.GB21800@poupinou.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524125029.GB21800@poupinou.org> User-Agent: Mutt/1.5.9i Cc: freebsd-current@FreeBSD.org, Jeremie Le Hen Subject: Re: ACPI errors with recent laptop X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 13:42:36 -0000 Bruno, > Well. I will look a little bit further then. BTW, what say > acpiconf -i 0 > acpiconf -i 1 Forget it. I've used acpiconf(8) to retrieve battery informations and it seems in fact that I was certainly a little bit asleep last time : the laptop was plugged on AC-line. Indeed when I unplug the laptop, I can see how much power it consumes actually abd the remaining capacity. Sorry for the noise. Thanks again. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue May 24 13:44:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 48DD216A41C for ; Tue, 24 May 2005 13:44:57 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 089A943D49 for ; Tue, 24 May 2005 13:44:56 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 5840F10715; Tue, 24 May 2005 09:44:56 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id C74E51A08E7; Tue, 24 May 2005 09:44:53 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17043.12245.659170.557169@canoe.dclg.ca> Date: Tue, 24 May 2005 09:44:53 -0400 To: "Conrad J. Sabatier" In-Reply-To: <20050524002925.2f05fc55@dolphin.local.net> References: <17042.43345.594850.534649@canoe.dclg.ca> <20050524002925.2f05fc55@dolphin.local.net> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Cc: freebsd-current@freebsd.org, David Gilbert Subject: Re: 3 things working in -STABLE and not in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 13:44:57 -0000 >>>>> "Conrad" == Conrad J Sabatier writes: Conrad> On Tue, 24 May 2005 00:10:57 -0400, David Gilbert Conrad> wrote: >> I recently upgraded my laptop to -CURRENT from 5.4-STABLE. >> Curiously, I have found 3 unrelated things that broke. In each >> case, I have recompiled any code I believe remotely responsible. >> >> 1) atacontrol reinit 1 >> >> This command used to recognise the hot plug of my CDROM into my >> laptop bay. It now recognises that something is there, but can get >> no version string from the probe and definately doesn't recognise >> the drive. >> >> I suspect this is actually somehow related to ACPI ... as the >> hot-swapability of the drive bay has depended on acpi.ko being >> loaded in the past. Conrad> I've been corresponding with Soren about a very similar Conrad> problem. My DVD writer on ata1-master is not being Conrad> recognized. Instead, my CD-RW on ata1-slave is being Conrad> configured as acd0. I've been doing daily upgrades (amd64), Conrad> but still to no avail, and Soren seems to be stumped as well. Conrad> The hardware seems to be fine. I can boot a CD-ROM from the Conrad> DVD drive with no problems, and a 5.2-RELEASE disc (i386) Conrad> recognizes both drives. Conrad> At least it's nice to know I'm not the only one. :-) My case may or may not be different. My drive is recognised correctly on boot ... the only error is when hot swapping it (which did also work under 5.4). Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-current@FreeBSD.ORG Tue May 24 14:44:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4FD6E16A41C for ; Tue, 24 May 2005 14:44:50 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (trang.nuxi.com [66.93.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id D999843D53 for ; Tue, 24 May 2005 14:44:47 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.3/8.13.3) with ESMTP id j4OEijCm029302; Tue, 24 May 2005 07:44:45 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.3/8.13.1/Submit) id j4OEijEo029301; Tue, 24 May 2005 07:44:45 -0700 (PDT) (envelope-from obrien) Date: Tue, 24 May 2005 07:44:44 -0700 From: "David O'Brien" To: Scott Long Message-ID: <20050524144444.GA29113@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Scott Long , Peter Wemm , freebsd-current@freebsd.org, David Gurvich References: <20050518051111.GA33262@Athena.infor.org> <20050520164349.GD6982@dragon.NUXI.org> <428E1815.8080500@samsco.org> <200505221453.44007.peter@wemm.org> <429105D8.6000106@samsco.org> <20050523021527.GA62693@dragon.NUXI.org> <42914448.5020505@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42914448.5020505@samsco.org> X-Operating-System: FreeBSD 6.0-CURRENT Organization: The NUXI BSD Group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, David Gurvich Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: obrien@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 14:44:50 -0000 On Sun, May 22, 2005 at 08:47:36PM -0600, Scott Long wrote: > David O'Brien wrote: > >On Sun, May 22, 2005 at 04:21:12PM -0600, Scott Long wrote: > >>>What I fixed was an amd64 build problem. The thread starter here was > >>>talking about pentium-m builds, so I assume its i386 in this case. > >>Yes, the threads jumped back and forth between people experiencing > >>problems with non-default CFLAGS <..snip..> > > > > > >I've heard those problems on and off for a year now - with no one > >experiencing the problem spending sufficient effort to provide a decent > >analysis of the issue. > > Re-read the threads. There is a lot of good analysis on how gcc was > emitting SSE instructions. I don't see how that could be the case: RCS file: /home/ncvs/src/sys/boot/i386/Makefile.inc,v .. ---------------------------- revision 1.10 date: 2005/03/15 18:43:36; author: obrien; state: Exp; lines: +2 -1 Ensure GCC does not use FP registers in integer code. I think all we really need is -fno-sse2. I really don't like cluttering up the compiler invocation, but this bigger hammer will fix reported problems for now. ---------------------------- diff -u -u -0 -r1.9 -r1.10 --- Makefile.inc 9 Feb 2004 14:11:55 -0000 1.9 +++ Makefile.inc 15 Mar 2005 18:43:36 -0000 1.10 @@ -8 +8,2 @@ -CFLAGS+= -ffreestanding -mpreferred-stack-boundary=2 +CFLAGS+= -ffreestanding -mpreferred-stack-boundary=2 \ + -mno-mmx -mno-3dnow -mno-sse -mno-sse2 An _analysis_ would be someone experiencing a problem clearly showing SSE[2] instructions in their .s files. Along with figuring out why the above flags didn't handle the issue. Also telling the results of trying CPUTYPE={,i486,pentium,pentium-pro,pentium3m,pentium4,pentium4m} (or ,i486,pentium,k6,k6-2,athlon,athlon-xp). -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Tue May 24 15:30:21 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28A4416A41C; Tue, 24 May 2005 15:30:21 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBDA443D4C; Tue, 24 May 2005 15:30:20 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j4OFUkNH059944; Tue, 24 May 2005 11:30:46 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j4OFUJx4010660; Tue, 24 May 2005 11:30:19 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8C37E7306E; Tue, 24 May 2005 11:30:19 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050524153019.8C37E7306E@freebsd-current.sentex.ca> Date: Tue, 24 May 2005 11:30:19 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on clamscanner4 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [current tinderbox] failure on ia64/ia64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 15:30:21 -0000 TB --- 2005-05-24 13:29:54 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-05-24 13:29:54 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-05-24 13:29:54 - cleaning the object tree TB --- 2005-05-24 13:30:28 - checking out the source tree TB --- 2005-05-24 13:30:28 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-05-24 13:30:28 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-05-24 13:36:29 - building world (CFLAGS=-O2 -pipe) TB --- 2005-05-24 13:36:29 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-05-24 13:36:29 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-05-24 15:09:59 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-05-24 15:09:59 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-05-24 15:09:59 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue May 24 15:09:59 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Tue May 24 15:30:18 UTC 2005 TB --- 2005-05-24 15:30:18 - generating LINT kernel config TB --- 2005-05-24 15:30:18 - cd /home/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- 2005-05-24 15:30:18 - /usr/bin/make -B LINT TB --- 2005-05-24 15:30:19 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-05-24 15:30:19 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-05-24 15:30:19 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 24 15:30:19 UTC 2005 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf; PATH=/home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/tmp/legacy/usr/sbin:/home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/tmp/legacy/usr/bin:/home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/tmp/legacy/usr/games:/home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/tmp/usr/sbin:/home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/tmp/usr/bin:/home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/LINT /tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf/LINT /tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf/LINT: unknown option "REISERFS" *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-05-24 15:30:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-05-24 15:30:19 - ERROR: failed to build lint kernel TB --- 2005-05-24 15:30:19 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue May 24 18:24:30 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8023716A41C; Tue, 24 May 2005 18:24:30 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37F3243D1F; Tue, 24 May 2005 18:24:30 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp2.sentex.ca (smtp2c.sentex.ca [64.7.153.30]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j4OIOu0t075770; Tue, 24 May 2005 14:24:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp2.sentex.ca (8.13.3/8.13.3) with ESMTP id j4OIOTo3098681; Tue, 24 May 2005 14:24:29 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 608217306E; Tue, 24 May 2005 14:24:29 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050524182429.608217306E@freebsd-current.sentex.ca> Date: Tue, 24 May 2005 14:24:29 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on clamscanner2 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 18:24:30 -0000 TB --- 2005-05-24 16:57:45 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-05-24 16:57:45 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-05-24 16:57:45 - cleaning the object tree TB --- 2005-05-24 16:58:10 - checking out the source tree TB --- 2005-05-24 16:58:10 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-05-24 16:58:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-05-24 17:04:26 - building world (CFLAGS=-O2 -pipe) TB --- 2005-05-24 17:04:26 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-05-24 17:04:26 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything TB --- 2005-05-24 18:12:20 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-05-24 18:12:20 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-05-24 18:12:20 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue May 24 18:12:20 UTC 2005 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for GENERIC completed on Tue May 24 18:24:28 UTC 2005 TB --- 2005-05-24 18:24:28 - generating LINT kernel config TB --- 2005-05-24 18:24:28 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- 2005-05-24 18:24:28 - /usr/bin/make -B LINT TB --- 2005-05-24 18:24:28 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-05-24 18:24:28 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-05-24 18:24:28 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue May 24 18:24:29 UTC 2005 >>> stage 1: configuring the kernel -------------------------------------------------------------- cd /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf; PATH=/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/tmp/legacy/usr/sbin:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/tmp/legacy/usr/bin:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/tmp/legacy/usr/games:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/tmp/usr/sbin:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/tmp/usr/bin:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf/LINT /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf/LINT: unknown option "REISERFS" *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-05-24 18:24:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-05-24 18:24:29 - ERROR: failed to build lint kernel TB --- 2005-05-24 18:24:29 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue May 24 18:33:08 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8790016A41C; Tue, 24 May 2005 18:33:08 +0000 (GMT) (envelope-from mux@freebsd.org) Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63EB943D1D; Tue, 24 May 2005 18:33:08 +0000 (GMT) (envelope-from mux@freebsd.org) Received: by elvis.mu.org (Postfix, from userid 1920) id 4EDB85C985; Tue, 24 May 2005 11:33:08 -0700 (PDT) Date: Tue, 24 May 2005 20:33:08 +0200 From: Maxime Henrion To: FreeBSD Tinderbox Message-ID: <20050524183308.GA25142@elvis.mu.org> References: <20050524182429.608217306E@freebsd-current.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524182429.608217306E@freebsd-current.sentex.ca> User-Agent: Mutt/1.4.2.1i Cc: current@freebsd.org, sparc64@freebsd.org Subject: Re: [current tinderbox] failure on sparc64/sparc64 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 18:33:08 -0000 FreeBSD Tinderbox wrote: > TB --- 2005-05-24 16:57:45 - tinderbox 2.3 running on freebsd-current.sentex.ca > TB --- 2005-05-24 16:57:45 - starting CURRENT tinderbox run for sparc64/sparc64 > TB --- 2005-05-24 16:57:45 - cleaning the object tree > TB --- 2005-05-24 16:58:10 - checking out the source tree > TB --- 2005-05-24 16:58:10 - cd /home/tinderbox/CURRENT/sparc64/sparc64 > TB --- 2005-05-24 16:58:10 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src > TB --- 2005-05-24 17:04:26 - building world (CFLAGS=-O2 -pipe) > TB --- 2005-05-24 17:04:26 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src > TB --- 2005-05-24 17:04:26 - /usr/bin/make -B buildworld > >>> Building an up-to-date make(1) > >>> Rebuilding the temporary build tree > >>> stage 1.1: legacy release compatibility shims > >>> stage 1.2: bootstrap tools > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3: cross tools > >>> stage 4.1: building includes > >>> stage 4.2: building libraries > >>> stage 4.3: make dependencies > >>> stage 4.4: building everything > TB --- 2005-05-24 18:12:20 - building generic kernel (COPTFLAGS=-O2 -pipe) > TB --- 2005-05-24 18:12:20 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src > TB --- 2005-05-24 18:12:20 - /usr/bin/make buildkernel KERNCONF=GENERIC > >>> Kernel build for GENERIC started on Tue May 24 18:12:20 UTC 2005 > >>> stage 1: configuring the kernel > >>> stage 2.1: cleaning up the object tree > >>> stage 2.2: rebuilding the object tree > >>> stage 2.3: build tools > >>> stage 3.1: making dependencies > >>> stage 3.2: building everything > >>> Kernel build for GENERIC completed on Tue May 24 18:24:28 UTC 2005 > TB --- 2005-05-24 18:24:28 - generating LINT kernel config > TB --- 2005-05-24 18:24:28 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf > TB --- 2005-05-24 18:24:28 - /usr/bin/make -B LINT > TB --- 2005-05-24 18:24:28 - building LINT kernel (COPTFLAGS=-O2 -pipe) > TB --- 2005-05-24 18:24:28 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src > TB --- 2005-05-24 18:24:28 - /usr/bin/make buildkernel KERNCONF=LINT > >>> Kernel build for LINT started on Tue May 24 18:24:29 UTC 2005 > >>> stage 1: configuring the kernel > -------------------------------------------------------------- > cd /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf; PATH=/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/tmp/legacy/usr/sbin:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/tmp/legacy/usr/bin:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/tmp/legacy/usr/games:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/tmp/usr/sbin:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/tmp/usr/bin:/home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin config -d /home/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf/LINT > /tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf/LINT: unknown option "REISERFS" > *** Error code 1 This is now fixed, sorry for the inconvenience. Cheers, Maxime From owner-freebsd-current@FreeBSD.ORG Tue May 24 22:23:43 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 63DC316A41C for ; Tue, 24 May 2005 22:23:43 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from pipa.profix.cz (pipa.profix.cz [213.151.89.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0049243D48 for ; Tue, 24 May 2005 22:23:42 +0000 (GMT) (envelope-from dandee@hellteam.net) Received: from localhost (localhost [127.0.0.1]) by pipa.profix.cz (Postfix) with ESMTP id 2B2574E733; Wed, 25 May 2005 00:23:48 +0200 (CEST) Received: from pipa.profix.cz ([127.0.0.1]) by localhost (pipa [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28920-05; Wed, 25 May 2005 00:23:48 +0200 (CEST) Received: from gandalf (105.121.95.80.ip.b26.cz [80.95.121.105]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by pipa.profix.cz (Postfix) with ESMTP id 9C6514E70E; Wed, 25 May 2005 00:23:47 +0200 (CEST) From: =?iso-8859-2?Q?Daniel_Dvo=F8=E1k?= To: "'Sam Leffler'" Date: Wed, 25 May 2005 00:23:37 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 In-Reply-To: <42911B78.8080301@errno.com> thread-index: AcVfKYFyisv8KBkzQ0evwe+tSqLtqQBhEvdw Message-Id: <20050524222347.9C6514E70E@pipa.profix.cz> X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at example.com Cc: freebsd-current@freebsd.org, 'Emil Mikulic' Subject: RE: ath0 goes down periodically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: dandee@volny.cz List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 22:23:43 -0000 -----Original Message----- From: owner-freebsd-current@freebsd.org [mailto:owner-freebsd-current@freebsd.org] On Behalf Of Sam Leffler Sent: Monday, May 23, 2005 1:53 AM To: dandee@volny.cz Cc: freebsd-current@freebsd.org; 'Emil Mikulic' Subject: Re: ath0 goes down periodically > Not sure why you think your problem is related to this one. Oh yes, maybe a cause is not the same, but a result is the same. Yes, there are some differences between Emil's configuration and mine = and some things are the same. >Don't recall you had a panic; if so please post the strack trace. > > Sam I am so sorry, I am still beginner to FreeBSD, I don=B4t know what = "strack trace" means. :( Sorry Daniel From owner-freebsd-current@FreeBSD.ORG Tue May 24 23:12:33 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 65D1116A41C for ; Tue, 24 May 2005 23:12:33 +0000 (GMT) (envelope-from freebsd@dohd.org) Received: from nala.dohd.org (xaa.demon.nl [83.160.166.71]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF02C43D1F for ; Tue, 24 May 2005 23:12:32 +0000 (GMT) (envelope-from freebsd@dohd.org) Received: from localhost (localhost.local.dohd.org [127.0.0.1]) by nala.dohd.org (Postfix) with ESMTP id C44BA11607; Wed, 25 May 2005 01:12:30 +0200 (CEST) Received: from nala.dohd.org ([127.0.0.1]) by localhost (eeyore.local.dohd.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 01578-02-2; Wed, 25 May 2005 01:12:27 +0200 (CEST) Received: by nala.dohd.org (Postfix, from userid 1008) id A8F1A1160F; Wed, 25 May 2005 01:12:27 +0200 (CEST) Date: Wed, 25 May 2005 01:12:27 +0200 From: Mark Huizer To: Jeff , "Matthew D. Fuller" , current@freebsd.org Message-ID: <20050524231227.GA1530@eeyore.local.dohd.org> References: <20050425183733.GB24146@eeyore.local.dohd.org> <2323.216.177.243.38.1114457612.localmail@webmail.dnswatch.com> <20050425200052.GC24146@eeyore.local.dohd.org> <200504262133.42669.saturn@serv.net> <20050427131441.GB98718@over-yonder.net> <20050425183733.GB24146@eeyore.local.dohd.org> <2323.216.177.243.38.1114457612.localmail@webmail.dnswatch.com> <20050425200052.GC24146@eeyore.local.dohd.org> <200504262133.42669.saturn@serv.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050427131441.GB98718@over-yonder.net> <200504262133.42669.saturn@serv.net> User-Agent: Mutt/1.5.9i X-Virus-Scanned: amavisd-new at dohd.org Cc: Subject: Re: fxp0: device timeout X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 May 2005 23:12:33 -0000 On Tue, Apr 26, 2005 at 09:33:42PM +0000, Jeff wrote: > > > > uname -a > > FreeBSD 5.4-STABLE FreeBSD 5.4-STABLE #0: Sat Apr 23 19:52:42 UTC 2005 > > the kernel is the amd64 and I am running and amd64 processor > > I've also seen a couple (not many, but this is a low-traffic system > anyway) lately, which is unusual. > > FreeBSD 5.3-STABLE #0: Sat Jan 29 00:29:15 CST 2005 > What motherboards did you have in those machines? I have problemswith all kinds of cards now, and this was a Chaintech 7aja2 motherbord. I know put the disk and network card in a machine with asus MB and everything works fine (now I only need to find a 266 asus mb to replace the old one :-( But perhaps the chipset is broken or the handling of the chipset in -stable. Soon I hope to have replaced it, and then I might be able to use it for testing Mark -- Nice testing in little China... From owner-freebsd-current@FreeBSD.ORG Wed May 25 00:03:21 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 58D8816A41C; Wed, 25 May 2005 00:03:21 +0000 (GMT) (envelope-from conrads@cox.net) Received: from lakermmtao08.cox.net (lakermmtao08.cox.net [68.230.240.31]) by mx1.FreeBSD.org (Postfix) with ESMTP id A982743D1D; Wed, 25 May 2005 00:03:20 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.70.216]) by lakermmtao08.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050525000320.MPYU18139.lakermmtao08.cox.net@dolphin.local.net>; Tue, 24 May 2005 20:03:20 -0400 Received: from dolphin.local.net (localhost.local.net [IPv6:::1]) by dolphin.local.net (8.13.3/8.13.3) with ESMTP id j4P03GTL001076; Tue, 24 May 2005 19:03:16 -0500 (CDT) (envelope-from conrads@cox.net) Date: Tue, 24 May 2005 19:03:11 -0500 From: "Conrad J. Sabatier" To: =?ISO-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20050524190311.711870aa@dolphin.local.net> In-Reply-To: <1FA05BA9-15DF-496B-95AE-664815096717@FreeBSD.org> References: <17042.43345.594850.534649@canoe.dclg.ca> <20050524002925.2f05fc55@dolphin.local.net> <1FA05BA9-15DF-496B-95AE-664815096717@FreeBSD.org> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@FreeBSD.org, David Gilbert Subject: Re: 3 things working in -STABLE and not in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 00:03:21 -0000 On Tue, 24 May 2005 07:57:34 +0200, S=F8ren Schmidt wrote: > On 24/05/2005, at 7:29, Conrad J. Sabatier wrote: >=20 > > I've been corresponding with Soren about a very similar problem. My > > DVD writer on ata1-master is not being recognized. Instead, my > > CD-RW on ata1-slave is being configured as acd0. I've been doing =20 > > daily upgrades (amd64), but still to no avail, and Soren seems to be > > stumped as well. >=20 > I don't think this is the same problem, yours seem to be interaction =20 > between the two drives that somehow makes the probe barf... I've tried your suggestion, enabling/disabling each device (in the BIOS) and rebooting. I even completely disconnected the power to the box for a minute, just in case something had gotten "stuck" in some weird state. But no matter what I do, even with the ata1-slave device marked as "Not installed" in the BIOS, it keeps getting configured as acd0. Most baffling. Both devices used to probe and configure perfectly, and from what I can gather from booting from a CD-ROM (where both devices appear as normal), there are no hardware problems *per se* that I can discern. I wish I had known about the reputation of the nVidia nForce3 chipset *before* I (rather impulsively) bought this machine. I suspect my problem is due in no small part to the notorious wonkiness of this particular chipset. :-( Is there any way to gather some more verbose diagnostics, besides a simple "boot -v"? So far, atacontrol and pciconf haven't proved to be very useful at all. Are there any other tools, in the base system or in ports, that may shed some more light on what's happening here? I think for now I may just revert to RELENG_5 and see what happens.=20 The irony of the situation is that I had only just recently really started "getting into" using my DVD drive, and it really hurts now to be without it. :-( I do hope this problem will not continue to plague me through future FreeBSD releases. If so, that may leave me no choice but to switch to another OS entirely, which I would *really* hate to have to do, as I've been using FreeBSD for nine years now, and have really come to love it. Switching to a whole new OS at this point (even another BSD) would not only sadden me greatly, but I downright shudder at the prospect of having to come to grips with what I could only rightly consider an inferior platform, as FreeBSD is definitely the best in my book. Oh well, we'll just have to wait and see, I suppose. Things generally have a tendency to work themselves out eventually. I just wish it would be sooner rather than later. :-) --=20 Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Wed May 25 02:17:53 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D6CFC16A41F for ; Wed, 25 May 2005 02:17:52 +0000 (GMT) (envelope-from alanbryan1234@yahoo.com) Received: from web50305.mail.yahoo.com (web50305.mail.yahoo.com [206.190.38.59]) by mx1.FreeBSD.org (Postfix) with SMTP id 1A60743D55 for ; Wed, 25 May 2005 02:17:52 +0000 (GMT) (envelope-from alanbryan1234@yahoo.com) Received: (qmail 43554 invoked by uid 60001); 25 May 2005 02:17:51 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=vwBYfsGxOPhkaU2Ljpke16IXnI3MEJlS36INX1MUXejakFIj8QDmThf/Lgb+vB020ebhXM9FJVPtNrogBPplJ5pOXCwhkXEfmKV3XlPztxl3o+cxkOSH+EP8wcd62TJ9RQ86/vsMvOt0gxr8FZShI390kfmfaEI/zjYbREKkYQY= ; Message-ID: <20050525021751.43552.qmail@web50305.mail.yahoo.com> Received: from [67.99.246.2] by web50305.mail.yahoo.com via HTTP; Tue, 24 May 2005 19:17:51 PDT Date: Tue, 24 May 2005 19:17:51 -0700 (PDT) From: alan bryan To: "Søren" Schmidt In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: freebsd-current@FreeBSD.org, freebsd-stable@FreeBSD.org Subject: Re: nForce 4, SATA Drive only runs at UDMA33? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 02:17:53 -0000 --- Søren Schmidt wrote: > > Is there anything in -CURRENT that would help this > to > > work better than 5-STABLE plus the ATA mkIII "n" > > patches? > > Yes, I've done quite a bit of changes that affects > this on -current. > However its done blindfolded since I dont have a > nForce4 based system > here yet (but should soon). > > - Søren How soon is "soon"? I may be able to send you some hardware too if that would be helpful. I tried a -CURRENT kernel today but didn't build/install world or anything else as I don't want to mess up this machines 5.4 installation. The result was that it now seems to identify all the atapici0 - atapici3 controllers and doesn't do the repeated DISCONNECTED/CONNECTED messages but it still panicked near the end of the bootup process, around the USB area. I called a friend today who has a spare SATA drive I can borrow so I'll be picking that up tomorrow and I'll swap out drives and do a fresh -CURRENT install tomorrow on that new drive to see if I can get it any further along towards a successful boot. I'll report back with my findings. Thanks for the help! --Alan Bryan __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new Resources site http://smallbusiness.yahoo.com/resources/ From owner-freebsd-current@FreeBSD.ORG Wed May 25 03:04:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E28816A41F; Wed, 25 May 2005 03:04:18 +0000 (GMT) (envelope-from conrads@cox.net) Received: from lakermmtao05.cox.net (lakermmtao05.cox.net [68.230.240.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5906D43D55; Wed, 25 May 2005 03:04:17 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.70.216]) by lakermmtao05.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050525030417.WOCW13442.lakermmtao05.cox.net@dolphin.local.net>; Tue, 24 May 2005 23:04:17 -0400 Received: from dolphin.local.net (localhost.local.net [IPv6:::1]) by dolphin.local.net (8.13.3/8.13.3) with ESMTP id j4P34DB8000938; Tue, 24 May 2005 22:04:13 -0500 (CDT) (envelope-from conrads@cox.net) Date: Tue, 24 May 2005 22:04:08 -0500 From: "Conrad J. Sabatier" To: freebsd-current@freebsd.org Message-ID: <20050524220408.7cdf0ff7@dolphin.local.net> In-Reply-To: <20050524190311.711870aa@dolphin.local.net> References: <17042.43345.594850.534649@canoe.dclg.ca> <20050524002925.2f05fc55@dolphin.local.net> <1FA05BA9-15DF-496B-95AE-664815096717@FreeBSD.org> <20050524190311.711870aa@dolphin.local.net> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: David Gilbert , =?ISO-8859-1?Q?S=F8ren?= Schmidt Subject: Re: 3 things working in -STABLE and not in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 03:04:18 -0000 On Tue, 24 May 2005 19:03:11 -0500, "Conrad J. Sabatier" wrote: > On Tue, 24 May 2005 07:57:34 +0200, S=F8ren Schmidt > wrote: >=20 > > On 24/05/2005, at 7:29, Conrad J. Sabatier wrote: > >=20 > > > I've been corresponding with Soren about a very similar problem.=20 > > > My DVD writer on ata1-master is not being recognized. Instead, my > > > CD-RW on ata1-slave is being configured as acd0. I've been doing=20 > > > daily upgrades (amd64), but still to no avail, and Soren seems to > > > be stumped as well. > >=20 > > I don't think this is the same problem, yours seem to be interaction > > between the two drives that somehow makes the probe barf... >=20 > I've tried your suggestion, enabling/disabling each device (in the > BIOS) and rebooting. I even completely disconnected the power to the > box for a minute, just in case something had gotten "stuck" in some > weird state. But no matter what I do, even with the ata1-slave device > marked as "Not installed" in the BIOS, it keeps getting configured as > acd0. >=20 > Most baffling. Both devices used to probe and configure perfectly, > and from what I can gather from booting from a CD-ROM (where both > devices appear as normal), there are no hardware problems *per se* > that I can discern. >=20 > I think for now I may just revert to RELENG_5 and see what happens.=20 > The irony of the situation is that I had only just recently really > started "getting into" using my DVD drive, and it really hurts now to > be without it. :-( Sure enough, with a STABLE build, everything's back to normal: ata0-master: pio=3D0x0c wdma=3D0x22 udma=3D0x45 cable=3D80pin ata0-master: setting PIO4 on nVidia nForce3 chip ata0-master: setting UDMA100 on nVidia nForce3 chip ad0: ATA-6 disk at ata0-master ad0: 190782MB (390721968 sectors), 387621 C, 16 H, 63 S, 512 B ad0: 16 secs/int, 1 depth queue, UDMA100 ata1-slave: pio=3D0x0c wdma=3D0x22 udma=3D0x42 cable=3D40pin ata1-master: pio=3D0x0c wdma=3D0x22 udma=3D0x42 cable=3D40pin ata1-master: setting PIO4 on nVidia nForce3 chip ata1-slave: setting PIO4 on nVidia nForce3 chip acd0: CDRW drive at ata1 as master acd0: read 6890KB/s (6890KB/s) write 4134KB/s (4134KB/s), 8192KB buffer, PIO4 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, test write, burnproof acd0: Audio: play, 2 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc acd1: CDROM drive at ata1 as slave acd1: read 8250KB/s (8250KB/s), 128KB buffer, PIO4 acd1: Reads: CDR, CDRW, CDDA stream, packet acd1: Writes: acd1: Audio: play, 255 volume levels acd1: Mechanism: ejectable tray, unlocked acd1: Medium: no/blank disc Guess I'll stick with STABLE for the time being. :-) --=20 Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Wed May 25 04:04:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC3FC16A41C for ; Wed, 25 May 2005 04:04:56 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id A164243D4C for ; Wed, 25 May 2005 04:04:56 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1Dan8a-0008JJ-8j for freebsd-current@freebsd.org; Wed, 25 May 2005 04:04:56 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1Dan8Z-0003kk-HQ for freebsd-current@freebsd.org; Wed, 25 May 2005 00:04:55 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17043.63846.102229.814228@roam.psg.com> Date: Wed, 25 May 2005 00:04:54 -0400 To: FreeBSD Current Subject: t41 crashes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 04:04:56 -0000 cvs since 2005.05.21 getting me frequent (ten minutes to most of a day) full crashes on a thinkpad t41. reverting kernel did not fix, so it's likely in world. no dumps. anyone else seeing anything like this? randy From owner-freebsd-current@FreeBSD.ORG Wed May 25 04:28:57 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DCE1A16A41C for ; Wed, 25 May 2005 04:28:57 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A45A43D4C for ; Wed, 25 May 2005 04:28:56 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so8717rne for ; Tue, 24 May 2005 21:28:56 -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=kH6ZQ+H2NsdYgmZ4t0kgY6XKS2o/xEtdc0L7bWvMthd0Z3vboMbZiGI3jzapi60pqRU/0jBBO+LShaiHk3FsWVNRo+bJ7w9KBHbLlfltvvZ7TcDHTBEG6hy4wfGAijgenWi8FlErghSgiCXNwSBgcTlJg1p6wsmL5P2SWqDE4vs= Received: by 10.38.11.27 with SMTP id 27mr23970rnk; Tue, 24 May 2005 21:28:56 -0700 (PDT) Received: by 10.38.101.35 with HTTP; Tue, 24 May 2005 21:28:56 -0700 (PDT) Message-ID: Date: Wed, 25 May 2005 13:28:56 +0900 From: Eric Kjeldergaard To: delphij@delphij.net In-Reply-To: <1116815005.838.3.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20050522112612.GA37841@frontfree.net> <20050523003843.GO850@obiwan.tataz.chchile.org> <1116815005.838.3.camel@spirit> Cc: delphij@freebsd.org, freebsd-current@freebsd.org, Jeremie Le Hen Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric Kjeldergaard List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 04:28:58 -0000 2005/5/23, Xin LI : > Hi, Jeremie, > > $B:_(B 2005-05-23$B0lE*(B 02:38 +0200$B!$(BJeremie Le Hen$B [snip] > > One question however : is it supposed to consume more CPU than classical > > non-VESA text mode ? > > I think so, it should consume more CPU than classical text mode console > since it draws characters, rather than giving the responsibility to the > video card. A possible optimization would be to map the video card > memory into the space. Tested on my Thinkpad R40 : Radeon 7500. Is it supposed to consume a LOT of cpu? Perhaps there's something funny with -O2 or similar because some things are VERY slow. I have not, however, noticed any major bugs, but screen redraws will take ~1 second if the screen is not cleared and thus causes powerd to kick my processor up to full speed often. Also, the screensaver (logo_saver) seems to take a while to display. The screen goes black for 10 - 15 seconds before the screen saver displays. Through all this, though, it's still so worth it. -- If I write a signature, my emails will appear more personalised. From owner-freebsd-current@FreeBSD.ORG Wed May 25 04:56:55 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4694D16A41C for ; Wed, 25 May 2005 04:56:55 +0000 (GMT) (envelope-from Muthu_T@Dell.com) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id F3ABE43D4C for ; Wed, 25 May 2005 04:56:54 +0000 (GMT) (envelope-from Muthu_T@Dell.com) Received: from ausx2kcps315.aus.amer.dell.com (143.166.3.50) by ausc60ps301.us.dell.com with ESMTP; 24 May 2005 23:56:54 -0500 X-IronPort-AV: i="3.93,134,1115010000"; d="scan'208"; a="246950031:sNHT21089636" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 24 May 2005 23:54:25 -0500 Message-ID: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB670F1@blrx2kmbgl101.blr.amer.dell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Current Snapshot Thread-Index: AcVg5dKJkUfBPDAiQ56DZ225M/xoqw== From: To: X-OriginalArrivalTime: 25 May 2005 04:54:25.0947 (UTC) FILETIME=[D35816B0:01C560E5] Subject: New Current Snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 04:56:55 -0000 Release Enggrs, Could you provide the new CURRENT snapshots? I want to test some functionality on our DELL servers (especially HostRAID support on Adaptec 39320 SCSI card) I had created the HostRAID on the above card with 3 SCSI disks, but FreeBSD 5.4=20 don't detect it and shows individual SCSI disks. :-( Whenever you creates a new snapshot please send out a mail. Thanks. --T. Muthu Mohan From owner-freebsd-current@FreeBSD.ORG Wed May 25 05:00:31 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B36E16A41C for ; Wed, 25 May 2005 05:00:31 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD03C43D48 for ; Wed, 25 May 2005 05:00:30 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j4P50QtT083338; Wed, 25 May 2005 09:00:26 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Wed, 25 May 2005 09:00:26 +0400 (MSD) From: Maxim Konovalov To: Muthu_T@Dell.com In-Reply-To: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB670F1@blrx2kmbgl101.blr.amer.dell.com> Message-ID: <20050525090007.G83308@mp2.macomnet.net> References: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB670F1@blrx2kmbgl101.blr.amer.dell.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: New Current Snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 05:00:31 -0000 On Tue, 24 May 2005, 23:54-0500, Muthu_T@Dell.com wrote: > Release Enggrs, > > Could you provide the new CURRENT snapshots? > > I want to test some functionality on our DELL servers > (especially HostRAID support on Adaptec 39320 SCSI card) > > I had created the HostRAID on the above card with 3 SCSI disks, but > FreeBSD 5.4 > don't detect it and shows individual SCSI disks. :-( > > Whenever you creates a new snapshot please send out a mail. http://current.freebsd.org/ -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Wed May 25 05:59:30 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8F4E516A41C for ; Wed, 25 May 2005 05:59:30 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A67743D1D for ; Wed, 25 May 2005 05:59:30 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 02ED2EB3C21 for ; Wed, 25 May 2005 13:59:27 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 9AF6C1312DD; Wed, 25 May 2005 13:59:23 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31950-16; Wed, 25 May 2005 13:59:12 +0800 (CST) Received: from [10.217.12.87] (unknown [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id 91ECC1334D9; Wed, 25 May 2005 13:59:05 +0800 (CST) From: Xin LI To: Muthu_T@Dell.com In-Reply-To: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB670F1@blrx2kmbgl101.blr.amer.dell.com> References: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB670F1@blrx2kmbgl101.blr.amer.dell.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-NBocdOzpg1AA0v1xlC+l" Organization: The FreeBSD Simplified Chinese Project Date: Wed, 25 May 2005 13:58:55 +0800 Message-Id: <1117000735.731.11.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at frontfree.net Cc: freebsd-current@freebsd.org Subject: Re: New Current Snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 05:59:30 -0000 --=-NBocdOzpg1AA0v1xlC+l Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, =E5=9C=A8 2005-05-24=E4=BA=8C=E7=9A=84 23:54 -0500=EF=BC=8CMuthu_T@Dell.com= =E5=86=99=E9=81=93=EF=BC=9A > Release Enggrs, >=20 > Could you provide the new CURRENT snapshots? >=20 > I want to test some functionality on our DELL servers > (especially HostRAID support on Adaptec 39320 SCSI card) >=20 > I had created the HostRAID on the above card with 3 SCSI disks, but > FreeBSD 5.4=20 > don't detect it and shows individual SCSI disks. :-( Automated release build is done in a daily basis, at http://current.freebsd.org/ . The release engineering team provides monthly snapshots for all Tier-1 platforms, but I think if you wonder whether some new hardware would work on newer -STABLE and -CURRENT, it's ok to use current.freebsd.org's snapshots :-) Cheers, --=20 Xin LI http://www.delphij.net/ --=-NBocdOzpg1AA0v1xlC+l Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBClBQf/cVsHxFZiIoRAgp7AJsHcjCy9irLm2bE2shRZEQY7cqQogCfXsT3 vAXlPXTQEtJc0pWOoWKlfXs= =UcT8 -----END PGP SIGNATURE----- --=-NBocdOzpg1AA0v1xlC+l-- From owner-freebsd-current@FreeBSD.ORG Wed May 25 05:59:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F224E16A433 for ; Wed, 25 May 2005 05:59:33 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E0A943D49 for ; Wed, 25 May 2005 05:59:33 +0000 (GMT) (envelope-from kjelderg@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so13879rne for ; Tue, 24 May 2005 22:59:32 -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=J8Ng3vdRFqok6REdaV+Ur0qYnrWlj3KUtrYkRsHMIF3BWKRIznSrC2hTCoxNdEoOBrhF8XGL8a1ZLw+HTG7EwMx63HwySwnvVX7ltxHQmU/9/G0o6+eOuLl0U5PWooVHrTxNxa5MmTRXed/uIvYmmqcMxejRz+du2S8O/P4RV4I= Received: by 10.38.11.27 with SMTP id 27mr39990rnk; Tue, 24 May 2005 22:59:32 -0700 (PDT) Received: by 10.38.101.35 with HTTP; Tue, 24 May 2005 22:59:32 -0700 (PDT) Message-ID: Date: Wed, 25 May 2005 14:59:32 +0900 From: Eric Kjeldergaard To: Xin LI In-Reply-To: <1116999375.731.7.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20050522112612.GA37841@frontfree.net> <20050523003843.GO850@obiwan.tataz.chchile.org> <1116815005.838.3.camel@spirit> <1116999375.731.7.camel@spirit> Cc: Jeremie Le Hen , freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric Kjeldergaard List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 05:59:34 -0000 2005/5/25, Xin LI : > Hi, Eric, > > $B:_(B 2005-05-25$B;0E*(B 13:28 +0900$B!$(BEric Kjeldergaard$B > 2005/5/23, Xin LI : > > > Hi, Jeremie, > > > > > > $B:_(B 2005-05-23$B0lE*(B 02:38 +0200$B!$(BJeremie Le Hen$B > > [snip] > > > > One question however : is it supposed to consume more CPU than classical > > > > non-VESA text mode ? > > > > > > I think so, it should consume more CPU than classical text mode console > > > since it draws characters, rather than giving the responsibility to the > > > video card. A possible optimization would be to map the video card > > > memory into the space. > > > > Tested on my Thinkpad R40 : Radeon 7500. Is it supposed to consume a > > LOT of cpu? Perhaps there's something funny with -O2 or similar > > because some things are VERY slow. I have not, however, noticed any > > major bugs, but screen redraws will take ~1 second if the screen is > > not cleared and thus causes powerd to kick my processor up to full > > speed often. Also, the screensaver (logo_saver) seems to take a while > > to display. The screen goes black for 10 - 15 seconds before the > > screen saver displays. Through all this, though, it's still so worth > > it. > > Yes, it requires more CPU cycles if you use raster mode. Does it also > slow down your console if you are running under text mode? I hope > not :-) > If I'm in text mode it's fine, but of course low-res. When I'm in raster mode I think it's maybe slower than it needs to be? (Slower than similar situations in Linux, for instance.) Also, if I have some terminals in text and some in raster, the switch between them is long. That's hardly a problem by itself, though, as I rarely run mixed terminal resolutions. -- If I write a signature, my emails will appear more personalised. From owner-freebsd-current@FreeBSD.ORG Wed May 25 06:03:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 450CB16A41C for ; Wed, 25 May 2005 06:03:41 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from smtp817.mail.sc5.yahoo.com (smtp817.mail.sc5.yahoo.com [66.163.170.3]) by mx1.FreeBSD.org (Postfix) with SMTP id 9B93743D1F for ; Wed, 25 May 2005 06:03:40 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.205.64 with login) by smtp817.mail.sc5.yahoo.com with SMTP; 25 May 2005 06:03:39 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id EA87C6141; Wed, 25 May 2005 01:03:37 -0500 (CDT) Received: from optimator.noacks.org ([127.0.0.1]) by localhost (optimator.noacks.org [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 00635-08; Wed, 25 May 2005 01:03:35 -0500 (CDT) Received: from compgeek.noacks.org (compgeek [192.168.1.10]) by optimator.noacks.org (Postfix) with ESMTP id 85A7C60D2; Wed, 25 May 2005 01:03:35 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by compgeek.noacks.org (8.13.3/8.13.3) with ESMTP id j4P63WqZ037940; Wed, 25 May 2005 01:03:32 -0500 (CDT) (envelope-from noackjr@alumni.rice.edu) Message-ID: <4294152C.2000506@alumni.rice.edu> Date: Wed, 25 May 2005 01:03:24 -0500 From: Jonathan Noack User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050428) X-Accept-Language: en-us, en MIME-Version: 1.0 To: obrien@freebsd.org References: <20050518051111.GA33262@Athena.infor.org> <20050520164349.GD6982@dragon.NUXI.org> <428E1815.8080500@samsco.org> <200505221453.44007.peter@wemm.org> <429105D8.6000106@samsco.org> <20050523021527.GA62693@dragon.NUXI.org> <42914448.5020505@samsco.org> <20050524144444.GA29113@dragon.NUXI.org> In-Reply-To: <20050524144444.GA29113@dragon.NUXI.org> X-Enigmail-Version: 0.91.0.0 OpenPGP: id=991D8195; url=http://www.noacks.org/cert/noackjr.asc Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigD5C7118981B60F7E264E5E33" X-Virus-Scanned: amavisd-new at noacks.org Cc: freebsd-current@freebsd.org, David Gurvich Subject: Re: Newest loader from CVS not working X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: noackjr@alumni.rice.edu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 06:03:41 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigD5C7118981B60F7E264E5E33 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 05/24/05 09:44, David O'Brien wrote: > On Sun, May 22, 2005 at 08:47:36PM -0600, Scott Long wrote: >>David O'Brien wrote: >>>On Sun, May 22, 2005 at 04:21:12PM -0600, Scott Long wrote: >>>>>What I fixed was an amd64 build problem. The thread starter here was >>>>>talking about pentium-m builds, so I assume its i386 in this case. >>>> >>>>Yes, the threads jumped back and forth between people experiencing >>>>problems with non-default CFLAGS <..snip..> >>> >>>I've heard those problems on and off for a year now - with no one >>>experiencing the problem spending sufficient effort to provide a decent >>>analysis of the issue. >> >>Re-read the threads. There is a lot of good analysis on how gcc was >>emitting SSE instructions. > > I don't see how that could be the case: > > RCS file: /home/ncvs/src/sys/boot/i386/Makefile.inc,v > .. > ---------------------------- > revision 1.10 > date: 2005/03/15 18:43:36; author: obrien; state: Exp; lines: +2 -1 > Ensure GCC does not use FP registers in integer code. > I think all we really need is -fno-sse2. > I really don't like cluttering up the compiler invocation, > but this bigger hammer will fix reported problems for now. > ---------------------------- > diff -u -u -0 -r1.9 -r1.10 > --- Makefile.inc 9 Feb 2004 14:11:55 -0000 1.9 > +++ Makefile.inc 15 Mar 2005 18:43:36 -0000 1.10 > @@ -8 +8,2 @@ > -CFLAGS+= -ffreestanding -mpreferred-stack-boundary=2 > +CFLAGS+= -ffreestanding -mpreferred-stack-boundary=2 \ > + -mno-mmx -mno-3dnow -mno-sse -mno-sse2 > > An _analysis_ would be someone experiencing a problem clearly showing > SSE[2] instructions in their .s files. Along with figuring out why the > above flags didn't handle the issue. Also telling the results of trying > CPUTYPE={,i486,pentium,pentium-pro,pentium3m,pentium4,pentium4m} > (or ,i486,pentium,k6,k6-2,athlon,athlon-xp). In case someone doesn't know how to get at the .s files, here's a brief description from David and my response: http://lists.freebsd.org/pipermail/freebsd-current/2004-November/042127.html 5.4-RELEASE works perfectly for me, so my issue was fixed by the commit in March. Thanks! -- Jonathan Noack | noackjr@alumni.rice.edu | OpenPGP: 0x991D8195 --------------enigD5C7118981B60F7E264E5E33 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.1 (FreeBSD) iD8DBQFClBU0UFz01pkdgZURAq3yAKCxtHPBRS0dB7wCLm9rr33HhYUX5ACguO+B 4fv+Uwe3l9ud4Po3/4ARt94= =Nxo2 -----END PGP SIGNATURE----- --------------enigD5C7118981B60F7E264E5E33-- From owner-freebsd-current@FreeBSD.ORG Wed May 25 06:19:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E43F416A41C; Wed, 25 May 2005 06:19:49 +0000 (GMT) (envelope-from sos@freebsd.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B96843D4C; Wed, 25 May 2005 06:19:49 +0000 (GMT) (envelope-from sos@freebsd.org) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j4P6D0Ma072360; Wed, 25 May 2005 08:13:01 +0200 (CEST) (envelope-from sos@freebsd.org) In-Reply-To: <20050525021751.43552.qmail@web50305.mail.yahoo.com> References: <20050525021751.43552.qmail@web50305.mail.yahoo.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Wed, 25 May 2005 08:19:43 +0200 To: alan bryan X-Mailer: Apple Mail (2.730) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: Re: nForce 4, SATA Drive only runs at UDMA33? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 06:19:50 -0000 On 25/05/2005, at 4:17, alan bryan wrote: > > --- S=F8ren Schmidt wrote: > >>> Is there anything in -CURRENT that would help this >>> >> to >> >>> work better than 5-STABLE plus the ATA mkIII "n" >>> patches? >>> >> >> Yes, I've done quite a bit of changes that affects >> this on -current. >> However its done blindfolded since I dont have a >> nForce4 based system >> here yet (but should soon). >> >> - S=F8ren >> > > How soon is "soon"? I may be able to send you some > hardware too if that would be helpful. "one of these days" it should be in transit.. > I tried a -CURRENT kernel today but didn't > build/install world or anything else as I don't want > to mess up this machines 5.4 installation. The result > was that it now seems to identify all the atapici0 - > atapici3 controllers and doesn't do the repeated > DISCONNECTED/CONNECTED messages but it still panicked > near the end of the bootup process, around the USB > area. > > I called a friend today who has a spare SATA drive I > can borrow so I'll be picking that up tomorrow and > I'll swap out drives and do a fresh -CURRENT install > tomorrow on that new drive to see if I can get it any > further along towards a successful boot. I'll report > back with my findings. OK, let me know, I'll be away from mail Thurday to Sunday, so if I =20 dont respond as quickly as usual you know why... - S=F8ren From owner-freebsd-current@FreeBSD.ORG Wed May 25 06:23:27 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D3A3116A41C for ; Wed, 25 May 2005 06:23:27 +0000 (GMT) (envelope-from qhwt+fbsd@les.ath.cx) Received: from les.ath.cx (15.61.205.61.west.global.alpha-net.ne.jp [61.205.61.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 96A8D43D1D for ; Wed, 25 May 2005 06:23:27 +0000 (GMT) (envelope-from qhwt+fbsd@les.ath.cx) Received: by les.ath.cx (Postfix, from userid 1000) id C99631B8762; Wed, 25 May 2005 15:23:25 +0900 (JST) Date: Wed, 25 May 2005 15:23:25 +0900 From: YONETANI Tomokazu To: freebsd-current@freebsd.org Message-ID: <20050525062325.GA49706@les.ath.cx> References: <20050524034618.GA62892@crodrigues.org> <20050524133204.GA49389@stud.fit.vutbr.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050524133204.GA49389@stud.fit.vutbr.cz> User-Agent: Mutt/1.5.9i Subject: Re: Kernel compilation errors with GCC 4.0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 06:23:27 -0000 On Tue, May 24, 2005 at 03:32:04PM +0200, Divacky Roman wrote: > dfly has just imported gcc40 into the tree, and I think their infracstructure > for more than one gcc in tree is nice and usefull.. No it hasn't, it's gcc-3.4.4 that has just been imported. And here's the related discussion why it's not gcc-4 yet: http://leaf.dragonflybsd.org/mailarchive/submit/2005-05/msg00034.html A patch for gcc-4 has been posted to the same list for anyone to review. Cheers. From owner-freebsd-current@FreeBSD.ORG Wed May 25 06:32:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E43A416A41C for ; Wed, 25 May 2005 06:32:48 +0000 (GMT) (envelope-from sos@freebsd.org) Received: from spider.deepcore.dk (cpe.atm2-0-53484.0x50a6c9a6.abnxx9.customer.tele.dk [80.166.201.166]) by mx1.FreeBSD.org (Postfix) with ESMTP id 550FD43D1F for ; Wed, 25 May 2005 06:32:48 +0000 (GMT) (envelope-from sos@freebsd.org) Received: from [194.192.25.136] (mac.deepcore.dk [194.192.25.136]) by spider.deepcore.dk (8.13.3/8.13.3) with ESMTP id j4P6PpAt072508; Wed, 25 May 2005 08:25:51 +0200 (CEST) (envelope-from sos@freebsd.org) In-Reply-To: <20050524190311.711870aa@dolphin.local.net> References: <17042.43345.594850.534649@canoe.dclg.ca> <20050524002925.2f05fc55@dolphin.local.net> <1FA05BA9-15DF-496B-95AE-664815096717@FreeBSD.org> <20050524190311.711870aa@dolphin.local.net> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <07005604-836F-48E0-AC46-9CC80BF19BD5@freebsd.org> Content-Transfer-Encoding: quoted-printable From: =?ISO-8859-1?Q?S=F8ren_Schmidt?= Date: Wed, 25 May 2005 08:32:34 +0200 To: "Conrad J. Sabatier" X-Mailer: Apple Mail (2.730) X-mail-scanned: by DeepCore Virus & Spam killer v1.12 Cc: freebsd-current@freebsd.org, David Gilbert Subject: Re: 3 things working in -STABLE and not in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 06:32:49 -0000 On 25/05/2005, at 2:03, Conrad J. Sabatier wrote: > On Tue, 24 May 2005 07:57:34 +0200, S=F8ren Schmidt > wrote: > > >> On 24/05/2005, at 7:29, Conrad J. Sabatier wrote: >> >> >>> I've been corresponding with Soren about a very similar problem. My >>> DVD writer on ata1-master is not being recognized. Instead, my >>> CD-RW on ata1-slave is being configured as acd0. I've been doing >>> daily upgrades (amd64), but still to no avail, and Soren seems to be >>> stumped as well. >>> >> >> I don't think this is the same problem, yours seem to be interaction >> between the two drives that somehow makes the probe barf... >> > > I've tried your suggestion, enabling/disabling each device (in the =20 > BIOS) > and rebooting. I even completely disconnected the power to the box > for a minute, just in case something had gotten "stuck" in some weird > state. But no matter what I do, even with the ata1-slave device =20 > marked > as "Not installed" in the BIOS, it keeps getting configured as acd0. I told you to try *physically* disconnecting each drive and boot with =20= that, fiddling the BIOS doesn't do anything but keep the device out =20 of the BIOS tables. Then boot with each device verbosely and send me =20 the boot logs / dmesg. > Is there any way to gather some more verbose diagnostics, besides a > simple "boot -v"? So far, atacontrol and pciconf haven't proved to be > very useful at all. Are there any other tools, in the base system =20 > or in > ports, that may shed some more light on what's happening here? The tools are make, gcc etc and are in the base system :) You need to instrument the code and figure out what's going on during =20= the probe. Thats why its very handy to have hands on the HW when doing debugging =20= of such issues. > I think for now I may just revert to RELENG_5 and see what happens. > The irony of the situation is that I had only just recently really > started "getting into" using my DVD drive, and it really hurts now =20 > to be > without it. :-( > > I do hope this problem will not continue to plague me through future > FreeBSD releases. If so, that may leave me no choice but to switch to > another OS entirely, which I would *really* hate to have to do, as =20 > I've > been using FreeBSD for nine years now, and have really come to love =20= > it. > Switching to a whole new OS at this point (even another BSD) would not > only sadden me greatly, but I downright shudder at the prospect of > having to come to grips with what I could only rightly consider an > inferior platform, as FreeBSD is definitely the best in my book. How should I interpret that exactly ? If you have been using FreeBSD for 9 years you must have been =20 suffering a lot worse problems than this.. And BTW I don't react well to threats if that was the purpose :) > Oh well, we'll just have to wait and see, I suppose. Things > generally have a tendency to work themselves out eventually. I just > wish it would be sooner rather than later. :-) - S=F8ren From owner-freebsd-current@FreeBSD.ORG Wed May 25 06:59:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 089F316A41C for ; Wed, 25 May 2005 06:59:15 +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 A6E0343D49 for ; Wed, 25 May 2005 06:59:14 +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 1DaprF-0004z7-M4 for freebsd-current@freebsd.org; Wed, 25 May 2005 09:59:13 +0300 X-Mailer: exmh version 2.7.0 06/18/2004 with nmh-1.0.4 To: FreeBSD Current Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 25 May 2005 09:59:13 +0300 From: Danny Braniss Message-ID: Subject: serial hangs kernel X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 06:59:15 -0000 i've been having some boxes hang solid (only power cycle will work) when trying to open ttyd0/cuaa0/cuad0. the message sio0: port may not be enabled gave me the clue, notice that the above is ambivalent. I enabled it in the bios, and now it's working ok, at least on an IBM-R51, i still have to check it on an IBM-T21 (that DOES have a serial port/outlet), and a Intel/IBM blade. so it seems, at first site, that if the sio hardware is on the MB, but sort of not enabled - because there is no connector -, (why the parallel port was kept and not the serial is beyond me), trying to open /dev/cuaa0 hangs the kernel. Q: in such case, shouldn't it not appear in /dev ? btw, this is with -stable & -current danny From owner-freebsd-current@FreeBSD.ORG Wed May 25 09:44:47 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 04E3C16A41C for ; Wed, 25 May 2005 09:44:47 +0000 (GMT) (envelope-from emil@cs.rmit.edu.au) Received: from ppp162-47.static.internode.on.net (ppp162-47.static.internode.on.net [150.101.162.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1475D43D1F for ; Wed, 25 May 2005 09:44:44 +0000 (GMT) (envelope-from emil@cs.rmit.edu.au) Received: by ppp162-47.static.internode.on.net (Poofix, from userid 1001) id 181106218; Wed, 25 May 2005 19:44:37 +1000 (EST) Date: Wed, 25 May 2005 19:44:36 +1000 From: Emil Mikulic To: delphij@delphij.net, Muthu_T@Dell.com, freebsd-current@freebsd.org Message-ID: <20050525094436.GA61115@dmr.ath.cx> Mail-Followup-To: Emil Mikulic , delphij@delphij.net, Muthu_T@Dell.com, freebsd-current@freebsd.org References: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB670F1@blrx2kmbgl101.blr.amer.dell.com> <1117000735.731.11.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1117000735.731.11.camel@spirit> X-PGP-ID: 1024D/344A699F X-PGP-Fingerprint: EE97 2C84 6D07 E76C F075 C0BA ED2A 9319 344A 699F X-Written-On: dmr.ath.cx (FreeBSD 6.0-CURRENT i386) User-Agent: Mutt/1.5.9i Cc: Subject: Re: New Current Snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 09:44:47 -0000 On Wed, May 25, 2005 at 01:58:55PM +0800, Xin LI wrote: > Automated release build is done in a daily basis, at > http://current.freebsd.org/ . The release engineering team provides > monthly snapshots for all Tier-1 platforms Except the last one is from March. =) http://www.freebsd.org/snapshots/ --Emil (was also itching for a snapshot) From owner-freebsd-current@FreeBSD.ORG Wed May 25 11:13:48 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C71A16A41C for ; Wed, 25 May 2005 11:13:48 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id C082743D1F for ; Wed, 25 May 2005 11:13:47 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so35496rne for ; Wed, 25 May 2005 04:13: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:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=kVt/VELuI+DiwLNNFXt3vWN9s2FAzQ+sq7rDYxBSVLtX3Wk65CQcP3wXRBh3bgOrVbvKcRCb144S8LUbBXb9wzCjHA+lu6nLn4HZlEmmgUwtTZ7fRNITjbxZWzvKlkjWM41Kh+7E5XPb5ftI/eILEMimwpz6ViLbV03cIMhNADA= Received: by 10.38.75.4 with SMTP id x4mr118929rna; Wed, 25 May 2005 04:13:47 -0700 (PDT) Received: by 10.38.209.31 with HTTP; Wed, 25 May 2005 04:13:47 -0700 (PDT) Message-ID: <84dead72050525041318c6f224@mail.gmail.com> Date: Wed, 25 May 2005 16:43:47 +0530 From: Joseph Koshy To: "Muthu_T@dell.com" In-Reply-To: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB670F1@blrx2kmbgl101.blr.amer.dell.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB670F1@blrx2kmbgl101.blr.amer.dell.com> Cc: freebsd-current@freebsd.org Subject: Re: New Current Snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Joseph Koshy List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 11:13:48 -0000 > Whenever you creates a new snapshot please send out a mail. It is easy to track -current via a CVSup'ed source tree; a=20 complete build from source and installation of the fresh binaries can be done in less than an hour. --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Wed May 25 05:36:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 88F6F16A41C; Wed, 25 May 2005 05:36:38 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 10F6843D48; Wed, 25 May 2005 05:36:37 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 9E1F1EB3BDA; Wed, 25 May 2005 13:36:35 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 0013A131195; Wed, 25 May 2005 13:36:31 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31950-05; Wed, 25 May 2005 13:36:24 +0800 (CST) Received: from [10.217.12.87] (unknown [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id 610BD131661; Wed, 25 May 2005 13:36:21 +0800 (CST) From: Xin LI To: Eric Kjeldergaard In-Reply-To: References: <20050522112612.GA37841@frontfree.net> <20050523003843.GO850@obiwan.tataz.chchile.org> <1116815005.838.3.camel@spirit> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-VjWMJfzYjdDfrTH76MYS" Organization: The FreeBSD Simplified Chinese Project Date: Wed, 25 May 2005 13:36:15 +0800 Message-Id: <1116999375.731.7.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at frontfree.net X-Mailman-Approved-At: Wed, 25 May 2005 11:57:16 +0000 Cc: Jeremie Le Hen , freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 05:36:38 -0000 --=-VjWMJfzYjdDfrTH76MYS Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Eric, =E5=9C=A8 2005-05-25=E4=B8=89=E7=9A=84 13:28 +0900=EF=BC=8CEric Kjeldergaar= d=E5=86=99=E9=81=93=EF=BC=9A > 2005/5/23, Xin LI : > > Hi, Jeremie, > >=20 > > =1B$B:_=1B(B 2005-05-23=1B$B0lE*=1B(B 02:38 +0200=1B$B!$=1B(BJeremie Le= Hen=1B$B > [snip] > > > One question however : is it supposed to consume more CPU than classi= cal > > > non-VESA text mode ? > >=20 > > I think so, it should consume more CPU than classical text mode console > > since it draws characters, rather than giving the responsibility to the > > video card. A possible optimization would be to map the video card > > memory into the space. >=20 > Tested on my Thinkpad R40 : Radeon 7500. Is it supposed to consume a > LOT of cpu? Perhaps there's something funny with -O2 or similar > because some things are VERY slow. I have not, however, noticed any > major bugs, but screen redraws will take ~1 second if the screen is > not cleared and thus causes powerd to kick my processor up to full > speed often. Also, the screensaver (logo_saver) seems to take a while > to display. The screen goes black for 10 - 15 seconds before the > screen saver displays. Through all this, though, it's still so worth > it. Yes, it requires more CPU cycles if you use raster mode. Does it also slow down your console if you are running under text mode? I hope not :-) Cheers, --=20 Xin LI http://www.delphij.net/ --=-VjWMJfzYjdDfrTH76MYS Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBClA7P/cVsHxFZiIoRAjGPAJ9FJInxDSUkLwRpNkAWjAPyg/0R1ACcDCJn TvVy50CtqQhUKO8Ti2zCKjo= =bRzw -----END PGP SIGNATURE----- --=-VjWMJfzYjdDfrTH76MYS-- From owner-freebsd-current@FreeBSD.ORG Wed May 25 06:36:24 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EBE7A16A41C; Wed, 25 May 2005 06:36:24 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66AC043D1F; Wed, 25 May 2005 06:36:24 +0000 (GMT) (envelope-from delphij@delphij.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 18983EB3B46; Wed, 25 May 2005 14:36:21 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 616FA1314B4; Wed, 25 May 2005 14:36:17 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 33511-05; Wed, 25 May 2005 14:36:10 +0800 (CST) Received: from [10.220.99.133] (unknown [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id 2166C130C35; Wed, 25 May 2005 14:36:06 +0800 (CST) From: Xin LI To: Eric Kjeldergaard In-Reply-To: References: <20050522112612.GA37841@frontfree.net> <20050523003843.GO850@obiwan.tataz.chchile.org> <1116815005.838.3.camel@spirit> <1116999375.731.7.camel@spirit> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-srzcoqgIPiL7WaNYpsCo" Organization: The FreeBSD Simplified Chinese Project Date: Wed, 25 May 2005 14:19:27 +0800 Message-Id: <1117001968.731.14.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at frontfree.net X-Mailman-Approved-At: Wed, 25 May 2005 11:57:16 +0000 Cc: Jeremie Le Hen , freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 06:36:25 -0000 --=-srzcoqgIPiL7WaNYpsCo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E5=9C=A8 2005-05-25=E4=B8=89=E7=9A=84 14:59 +0900=EF=BC=8CEric Kjeldergaar= d=E5=86=99=E9=81=93=EF=BC=9A > 2005/5/25, Xin LI : > If I'm in text mode it's fine, but of course low-res. When I'm in > raster mode I think it's maybe slower than it needs to be? (Slower > than similar situations in Linux, for instance.) Also, if I have some > terminals in text and some in raster, the switch between them is long. > That's hardly a problem by itself, though, as I rarely run mixed > terminal resolutions. Yes. Someone has suggested that we should mmap the display buffer directly to gain good performance, but I do not have enough to implement it at this time :-( Cheers, --=20 Xin LI http://www.delphij.net/ --=-srzcoqgIPiL7WaNYpsCo Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBClBjv/cVsHxFZiIoRAt4xAJ48rXPHH9Su9poq2vJNYS0fo476JACcCAv+ 3yQZvNlerrOBPdUsT0uJHI8= =O7vA -----END PGP SIGNATURE----- --=-srzcoqgIPiL7WaNYpsCo-- From owner-freebsd-current@FreeBSD.ORG Wed May 25 12:00:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4444A16A42A; Wed, 25 May 2005 12:00:45 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id CB75943D54; Wed, 25 May 2005 12:00:44 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j4PC0FeM064074; Wed, 25 May 2005 07:00:15 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <429468C3.5040207@centtech.com> Date: Wed, 25 May 2005 07:00:03 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050504 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Kjeldergaard References: <20050522112612.GA37841@frontfree.net> <20050523003843.GO850@obiwan.tataz.chchile.org> <1116815005.838.3.camel@spirit> <1116999375.731.7.camel@spirit> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: ClamAV 0.82/893/Tue May 24 01:27:20 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: delphij@freebsd.org, Jeremie Le Hen , freebsd-current@freebsd.org, Xin LI Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 12:00:45 -0000 Eric Kjeldergaard wrote: > 2005/5/25, Xin LI : >=20 >>Hi, Eric, >> >>=E5=9C=A8 2005-05-25=E4=B8=89=E7=9A=84 13:28 +0900=EF=BC=8CEric Kjelder= gaard=E5=86=99=E9=81=93=EF=BC=9A >> >>>2005/5/23, Xin LI : >>> >>>>Hi, Jeremie, >>>> >>>>=E5=9C=A8 2005-05-23=E4=B8=80=E7=9A=84 02:38 +0200=EF=BC=8CJeremie Le= Hen=E5=86=99=E9=81=93=EF=BC=9A >>>>[snip] >>>> >>>>>One question however : is it supposed to consume more CPU than class= ical >>>>>non-VESA text mode ? >>>> >>>>I think so, it should consume more CPU than classical text mode conso= le >>>>since it draws characters, rather than giving the responsibility to t= he >>>>video card. A possible optimization would be to map the video card >>>>memory into the space. >>> >>>Tested on my Thinkpad R40 : Radeon 7500. Is it supposed to consume a >>>LOT of cpu? Perhaps there's something funny with -O2 or similar >>>because some things are VERY slow. I have not, however, noticed any >>>major bugs, but screen redraws will take ~1 second if the screen is >>>not cleared and thus causes powerd to kick my processor up to full >>>speed often. Also, the screensaver (logo_saver) seems to take a while= >>>to display. The screen goes black for 10 - 15 seconds before the >>>screen saver displays. Through all this, though, it's still so worth >>>it. >> >>Yes, it requires more CPU cycles if you use raster mode. Does it also >>slow down your console if you are running under text mode? I hope >>not :-) >> >=20 >=20 > If I'm in text mode it's fine, but of course low-res. When I'm in > raster mode I think it's maybe slower than it needs to be? (Slower > than similar situations in Linux, for instance.) Also, if I have some > terminals in text and some in raster, the switch between them is long. > That's hardly a problem by itself, though, as I rarely run mixed > terminal resolutions. I noticed that changing to 16bit (instead of 32 or 24) helped a lot. Eric --=20 ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed May 25 12:21:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C130D16A41C for ; Wed, 25 May 2005 12:21:59 +0000 (GMT) (envelope-from Muthu_T@Dell.com) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66F2443D53 for ; Wed, 25 May 2005 12:21:57 +0000 (GMT) (envelope-from Muthu_T@Dell.com) Received: from ausx2kcpc115.aus.amer.dell.com (10.166.84.69) by ausc60ps301.us.dell.com with ESMTP; 25 May 2005 07:21:56 -0500 X-IronPort-AV: i="3.93,135,1115010000"; d="txt'?scan'208"; a="247072280:sNHT82786564" X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C56123.058D2991" Date: Wed, 25 May 2005 07:12:29 -0500 Message-ID: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB67120@blrx2kmbgl101.blr.amer.dell.com> X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: FreeBSD 5.4 supports DELL PERC 4 cards Thread-Index: AcVhIwPBMdF1Je/lRhG0LQKxzL8/tQ== From: To: X-OriginalArrivalTime: 25 May 2005 12:12:29.0876 (UTC) FILETIME=[05C95F40:01C56123] Subject: FreeBSD 5.4 supports DELL PERC 4 cards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 12:21:59 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C56123.058D2991 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, =20 Could anyone add the following cards to the 'amr' man page as supported hardware? 1. DELL PERC 4/SC - PCI Card=20 2. DELL PERC 4/DC - PCI Card 3. DELL PERC 4e/DC - PCI Express card=20 I had installed FreeBSD 5.4 on PE2850 today and found that 'amr' detected the above last 2 cards. See the attached dmesg & 'pciconf -l -v' output. Also please change the text 'MegaRaid' to 'MegaRAID' in 'amr' source. Thanks. --T. Muthu Mohan ------_=_NextPart_001_01C56123.058D2991 Content-Type: text/plain; name="pe2850-pciconf.txt" Content-Transfer-Encoding: base64 Content-Description: pe2850-pciconf.txt Content-Disposition: attachment; filename="pe2850-pciconf.txt" aG9zdGIwQHBjaTA6MDowOgljbGFzcz0weDA2MDAwMCBjYXJkPTB4MDE2ZDEwMjggY2hpcD0weDM1 OTA4MDg2IHJldj0weDA5IGhkcj0weDAwCiAgICB2ZW5kb3IgICA9ICdJbnRlbCBDb3Jwb3JhdGlv bicKICAgIGRldmljZSAgID0gJ0U3NTJ4IFNlcnZlciBNZW1vcnkgQ29udHJvbGxlciBIdWInCiAg ICBjbGFzcyAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgPSBIT1NULVBDSQpwY2liMUBwY2kwOjI6 MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDUwIGNoaXA9MHgzNTk1ODA4NiByZXY9MHgw OSBoZHI9MHgwMQogICAgdmVuZG9yICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2Ug ICA9ICdFNzUyeCBNZW1vcnkgY29udHJvbGxlciBIdWIgUENJIEV4cHJlc3MgUG9ydCBBMCcKICAg IGNsYXNzICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyA9IFBDSS1QQ0kKcGNpYjRAcGNpMDo0OjA6 CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMDA1MCBjaGlwPTB4MzU5NzgwODYgcmV2PTB4MDkg aGRyPTB4MDEKICAgIHZlbmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAg PSAnRTc1MnggTWVtb3J5IGNvbnRyb2xsZXIgSHViIFBDSSBFeHByZXNzIFBvcnQgQjAnCiAgICBj bGFzcyAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgPSBQQ0ktUENJCnBjaWI1QHBjaTA6NTowOglj bGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDAwNTAgY2hpcD0weDM1OTg4MDg2IHJldj0weDA5IGhk cj0weDAxCiAgICB2ZW5kb3IgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgID0g J0U3NTJ4IE1lbW9yeSBDb250cm9sbGVyIEh1YiBQQ0kgRXhwcmVzcyBQb3J0IEIxJwogICAgY2xh c3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzID0gUENJLVBDSQpwY2liOEBwY2kwOjY6MDoJY2xh c3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDUwIGNoaXA9MHgzNTk5ODA4NiByZXY9MHgwOSBoZHI9 MHgwMQogICAgdmVuZG9yICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICA9ICdF NzUyeCBNZW1vcnkgQ29udHJvbGxlciBIdWIgUENJIEV4cHJlc3MgUG9ydCBDMCcKICAgIGNsYXNz ICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyA9IFBDSS1QQ0kKdWhjaTBAcGNpMDoyOTowOgljbGFz cz0weDBjMDMwMCBjYXJkPTB4MDE2ZDEwMjggY2hpcD0weDI0ZDI4MDg2IHJldj0weDAyIGhkcj0w eDAwCiAgICB2ZW5kb3IgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgID0gJzgy ODAxRUIvRVIgKElDSDUvSUNINVIpIFVTQiBVSENJIENvbnRyb2xsZXIgIzEnCiAgICBjbGFzcyAg ICA9IHNlcmlhbCBidXMKICAgIHN1YmNsYXNzID0gVVNCCnVoY2kxQHBjaTA6Mjk6MToJY2xhc3M9 MHgwYzAzMDAgY2FyZD0weDAxNmQxMDI4IGNoaXA9MHgyNGQ0ODA4NiByZXY9MHgwMiBoZHI9MHgw MAogICAgdmVuZG9yICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICA9ICc4Mjgw MUVCL0VSIChJQ0g1L0lDSDVSKSBVU0IgVUhDSSBDb250cm9sbGVyICMyJwogICAgY2xhc3MgICAg PSBzZXJpYWwgYnVzCiAgICBzdWJjbGFzcyA9IFVTQgp1aGNpMkBwY2kwOjI5OjI6CWNsYXNzPTB4 MGMwMzAwIGNhcmQ9MHgwMTZkMTAyOCBjaGlwPTB4MjRkNzgwODYgcmV2PTB4MDIgaGRyPTB4MDAK ICAgIHZlbmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgPSAnODI4MDFF Qi9FUiAoSUNINS9JQ0g1UikgVVNCIFVIQ0kgQ29udHJvbGxlciAjMycKICAgIGNsYXNzICAgID0g c2VyaWFsIGJ1cwogICAgc3ViY2xhc3MgPSBVU0IKbm9uZTBAcGNpMDoyOTo3OgljbGFzcz0weDBj MDMyMCBjYXJkPTB4MDE2ZDEwMjggY2hpcD0weDI0ZGQ4MDg2IHJldj0weDAyIGhkcj0weDAwCiAg ICB2ZW5kb3IgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgID0gJzgyODAxRUIv RVIgKElDSDUvSUNINVIpIFVTQiBFSENJIENvbnRyb2xsZXInCiAgICBjbGFzcyAgICA9IHNlcmlh bCBidXMKICAgIHN1YmNsYXNzID0gVVNCCnBjaWIxMUBwY2kwOjMwOjA6CWNsYXNzPTB4MDYwNDAw IGNhcmQ9MHgwMDAwMDAwMCBjaGlwPTB4MjQ0ZTgwODYgcmV2PTB4YzIgaGRyPTB4MDEKICAgIHZl bmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAgPSAnODI4MDFCQS9DQS9E Qi9EQkwvRUIvRVIgKElDSDIvMy80LzQtTC81LzVSKSwgNjMwMEVTQiBIdWIgSW50ZXJmYWNlIHRv IFBDSSBCcmlkZ2UnCiAgICBjbGFzcyAgICA9IGJyaWRnZQogICAgc3ViY2xhc3MgPSBQQ0ktUENJ CmlzYWIwQHBjaTA6MzE6MDoJY2xhc3M9MHgwNjAxMDAgY2FyZD0weDAwMDAwMDAwIGNoaXA9MHgy NGQwODA4NiByZXY9MHgwMiBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnSW50ZWwgQ29ycG9yYXRp b24nCiAgICBkZXZpY2UgICA9ICc4MjgwMUVCL0VSIChJQ0g1L0lDSDVSKSBMUEMgSW50ZXJmYWNl IEJyaWRnZScKICAgIGNsYXNzICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyA9IFBDSS1JU0EKYXRh cGNpMUBwY2kwOjMxOjE6CWNsYXNzPTB4MDEwMThhIGNhcmQ9MHgwMTZkMTAyOCBjaGlwPTB4MjRk YjgwODYgcmV2PTB4MDIgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9u JwogICAgZGV2aWNlICAgPSAnODI4MDFFQi9FUiAoSUNINS9JQ0g1UikgRUlERSBDb250cm9sbGVy JwogICAgY2xhc3MgICAgPSBtYXNzIHN0b3JhZ2UKICAgIHN1YmNsYXNzID0gQVRBCnBjaWIyQHBj aTE6MDowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDAwNDQgY2hpcD0weDAzMzA4MDg2IHJl dj0weDA2IGhkcj0weDAxCiAgICB2ZW5kb3IgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRl dmljZSAgID0gJzgwMzMyIFtEb2Jzb25dIEkvTyBwcm9jZXNzb3IgQS1zZWdtZW50IEJyaWRnZScK ICAgIGNsYXNzICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyA9IFBDSS1QQ0kKcGNpYjNAcGNpMTow OjI6CWNsYXNzPTB4MDYwNDAwIGNhcmQ9MHgwMDAwMDA0NCBjaGlwPTB4MDMzMjgwODYgcmV2PTB4 MDYgaGRyPTB4MDEKICAgIHZlbmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNl ICAgPSAnODAzMzIgW0RvYnNvbl0gSS9PIHByb2Nlc3NvciBCLXNlZ21lbnQgQnJpZGdlJwogICAg Y2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzID0gUENJLVBDSQphbXIwQHBjaTI6MTQ6MDoJ Y2xhc3M9MHgwMTA0MDAgY2FyZD0weDAxNmQxMDI4IGNoaXA9MHgwMDEzMTAyOCByZXY9MHgwNiBo ZHI9MHgwMAogICAgdmVuZG9yICAgPSAnRGVsbCBDb21wdXRlciBDb3Jwb3JhdGlvbicKICAgIGNs YXNzICAgID0gbWFzcyBzdG9yYWdlCiAgICBzdWJjbGFzcyA9IFJBSUQKYW1yMUBwY2kzOjExOjA6 CWNsYXNzPTB4MDEwNDAwIGNhcmQ9MHgwNTIwMTAyOCBjaGlwPTB4MTk2MDEwMDAgcmV2PTB4MDEg aGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ0xTSSBMb2dpYyAoV2FzOiBTeW1iaW9zIExvZ2ljLCBO Q1IpJwogICAgY2xhc3MgICAgPSBtYXNzIHN0b3JhZ2UKICAgIHN1YmNsYXNzID0gUkFJRApwY2li NkBwY2k1OjA6MDoJY2xhc3M9MHgwNjA0MDAgY2FyZD0weDAwMDAwMDQ0IGNoaXA9MHgwMzI5ODA4 NiByZXY9MHgwOSBoZHI9MHgwMQogICAgdmVuZG9yICAgPSAnSW50ZWwgQ29ycG9yYXRpb24nCiAg ICBkZXZpY2UgICA9ICdQQ0kgQnJpZGdlIEh1YiBBJwogICAgY2xhc3MgICAgPSBicmlkZ2UKICAg IHN1YmNsYXNzID0gUENJLVBDSQpwY2liN0BwY2k1OjA6MjoJY2xhc3M9MHgwNjA0MDAgY2FyZD0w eDAwMDAwMDQ0IGNoaXA9MHgwMzJhODA4NiByZXY9MHgwOSBoZHI9MHgwMQogICAgdmVuZG9yICAg PSAnSW50ZWwgQ29ycG9yYXRpb24nCiAgICBkZXZpY2UgICA9ICdQQ0kgQnJpZGdlIEh1YiBCJwog ICAgY2xhc3MgICAgPSBicmlkZ2UKICAgIHN1YmNsYXNzID0gUENJLVBDSQplbTBAcGNpNjo3OjA6 CWNsYXNzPTB4MDIwMDAwIGNhcmQ9MHgwMTZkMTAyOCBjaGlwPTB4MTA3NjgwODYgcmV2PTB4MDUg aGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ0ludGVsIENvcnBvcmF0aW9uJwogICAgZGV2aWNlICAg PSAnODI1NDdFSSBHaWdhYml0IEV0aGVybmV0IENvbnRyb2xsZXInCiAgICBjbGFzcyAgICA9IG5l dHdvcmsKICAgIHN1YmNsYXNzID0gZXRoZXJuZXQKZW0xQHBjaTc6ODowOgljbGFzcz0weDAyMDAw MCBjYXJkPTB4MDE2ZDEwMjggY2hpcD0weDEwNzY4MDg2IHJldj0weDA1IGhkcj0weDAwCiAgICB2 ZW5kb3IgICA9ICdJbnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgID0gJzgyNTQ3RUkgR2ln YWJpdCBFdGhlcm5ldCBDb250cm9sbGVyJwogICAgY2xhc3MgICAgPSBuZXR3b3JrCiAgICBzdWJj bGFzcyA9IGV0aGVybmV0CnBjaWI5QHBjaTg6MDowOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAw MDAwNDQgY2hpcD0weDAzMzA4MDg2IHJldj0weDA3IGhkcj0weDAxCiAgICB2ZW5kb3IgICA9ICdJ bnRlbCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgID0gJzgwMzMyIFtEb2Jzb25dIEkvTyBwcm9j ZXNzb3IgQS1zZWdtZW50IEJyaWRnZScKICAgIGNsYXNzICAgID0gYnJpZGdlCiAgICBzdWJjbGFz cyA9IFBDSS1QQ0kKcGNpYjEwQHBjaTg6MDoyOgljbGFzcz0weDA2MDQwMCBjYXJkPTB4MDAwMDAw NDQgY2hpcD0weDAzMzI4MDg2IHJldj0weDA3IGhkcj0weDAxCiAgICB2ZW5kb3IgICA9ICdJbnRl bCBDb3Jwb3JhdGlvbicKICAgIGRldmljZSAgID0gJzgwMzMyIFtEb2Jzb25dIEkvTyBwcm9jZXNz b3IgQi1zZWdtZW50IEJyaWRnZScKICAgIGNsYXNzICAgID0gYnJpZGdlCiAgICBzdWJjbGFzcyA9 IFBDSS1QQ0kKYW1yMkBwY2k5OjE0OjA6CWNsYXNzPTB4MDEwNDAwIGNhcmQ9MHgwMDAyMTAyOCBj aGlwPTB4MDQwODEwMDAgcmV2PTB4MDcgaGRyPTB4MDAKICAgIHZlbmRvciAgID0gJ0xTSSBMb2dp YyAoV2FzOiBTeW1iaW9zIExvZ2ljLCBOQ1IpJwogICAgY2xhc3MgICAgPSBtYXNzIHN0b3JhZ2UK ICAgIHN1YmNsYXNzID0gUkFJRApub25lMUBwY2kxMTo1OjA6CWNsYXNzPTB4ZmYwMDAwIGNhcmQ9 MHgwMDExMTAyOCBjaGlwPTB4MDAxMTEwMjggcmV2PTB4MDAgaGRyPTB4MDAKICAgIHZlbmRvciAg ID0gJ0RlbGwgQ29tcHV0ZXIgQ29ycG9yYXRpb24nCm5vbmUyQHBjaTExOjU6MToJY2xhc3M9MHhm ZjAwMDAgY2FyZD0weDAwMTIxMDI4IGNoaXA9MHgwMDEyMTAyOCByZXY9MHgwMCBoZHI9MHgwMAog ICAgdmVuZG9yICAgPSAnRGVsbCBDb21wdXRlciBDb3Jwb3JhdGlvbicKbm9uZTNAcGNpMTE6NToy OgljbGFzcz0weGZmMDAwMCBjYXJkPTB4MDAxNDEwMjggY2hpcD0weDAwMTQxMDI4IHJldj0weDAw IGhkcj0weDAwCiAgICB2ZW5kb3IgICA9ICdEZWxsIENvbXB1dGVyIENvcnBvcmF0aW9uJwphdGFw Y2kwQHBjaTExOjY6MDoJY2xhc3M9MHgwMTAxODUgY2FyZD0weDA2ODAxMDk1IGNoaXA9MHgwNjgw MTA5NSByZXY9MHgwMiBoZHI9MHgwMAogICAgdmVuZG9yICAgPSAnU2lsaWNvbiBJbWFnZSBJbmMg KFdhczogQ01EIFRlY2hub2xvZ3kgSW5jKScKICAgIGRldmljZSAgID0gJ1NpSSAwNjgwIChXYXM6 IFBDSS0wNjgwKSBVbHRyYSBBVEExMzMgRUlERSBDb250cm9sbGVyJwogICAgY2xhc3MgICAgPSBt YXNzIHN0b3JhZ2UKICAgIHN1YmNsYXNzID0gQVRBCm5vbmU0QHBjaTExOjEzOjA6CWNsYXNzPTB4 MDMwMDAwIGNhcmQ9MHgwMTZkMTAyOCBjaGlwPTB4NTE1OTEwMDIgcmV2PTB4MDAgaGRyPTB4MDAK ICAgIHZlbmRvciAgID0gJ0FUSSBUZWNobm9sb2dpZXMgSW5jLicKICAgIGRldmljZSAgID0gJ1JW MTAwIFJhZGVvbiA3MDAwIC8gUmFkZW9uIFZFJwogICAgY2xhc3MgICAgPSBkaXNwbGF5CiAgICBz dWJjbGFzcyA9IFZHQQo= ------_=_NextPart_001_01C56123.058D2991 Content-Type: text/plain; name="pe2850-dmesg.txt" Content-Transfer-Encoding: base64 Content-Description: pe2850-dmesg.txt Content-Disposition: attachment; filename="pe2850-dmesg.txt" Q29weXJpZ2h0IChjKSAxOTkyLTIwMDUgVGhlIEZyZWVCU0QgUHJvamVjdC4NCkNvcHlyaWdodCAo YykgMTk3OSwgMTk4MCwgMTk4MywgMTk4NiwgMTk4OCwgMTk4OSwgMTk5MSwgMTk5MiwgMTk5Mywg MTk5NA0KCVRoZSBSZWdlbnRzIG9mIHRoZSBVbml2ZXJzaXR5IG9mIENhbGlmb3JuaWEuIEFsbCBy aWdodHMgcmVzZXJ2ZWQuDQpGcmVlQlNEIDUuNC1SRUxFQVNFICMwOiBXZWQgTWF5IDI1IDE2OjA1 OjMxIElTVCAyMDA1DQogICAgcm9vdEA6L3Vzci9vYmovdXNyL3NyYy9zeXMvU01QDQpUaW1lY291 bnRlciAiaTgyNTQiIGZyZXF1ZW5jeSAxMTkzMTgyIEh6IHF1YWxpdHkgMA0KQ1BVOiBJbnRlbChS KSBYZW9uKFRNKSBDUFUgMy4yMEdIeiAoMzE5Mi4yMy1NSHogNjg2LWNsYXNzIENQVSkNCiAgT3Jp Z2luID0gIkdlbnVpbmVJbnRlbCIgIElkID0gMHhmNDEgIFN0ZXBwaW5nID0gMQ0KICBGZWF0dXJl cz0weGJmZWJmYmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAs TVRSUixQR0UsTUNBLENNT1YsUEFULFBTRTM2LENMRkxVU0gsRFRTLEFDUEksTU1YLEZYU1IsU1NF LFNTRTIsU1MsSFRULFRNLFBCRT4NCiAgSHlwZXJ0aHJlYWRpbmc6IDIgbG9naWNhbCBDUFVzDQpy ZWFsIG1lbW9yeSAgPSAyMTQ3MjIxNTA0ICgyMDQ3IE1CKQ0KYXZhaWwgbWVtb3J5ID0gMjA5NTc2 MzQ1NiAoMTk5OCBNQikNCkFDUEkgQVBJQyBUYWJsZTogPERFTEwgICBQRSBCS0MgID4NCkZyZWVC U0QvU01QOiBNdWx0aXByb2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDQgQ1BVcw0KIGNwdTAgKEJT UCk6IEFQSUMgSUQ6ICAwDQogY3B1MSAoQVApOiBBUElDIElEOiAgMQ0KIGNwdTIgKEFQKTogQVBJ QyBJRDogIDYNCiBjcHUzIChBUCk6IEFQSUMgSUQ6ICA3DQppb2FwaWMwOiBDaGFuZ2luZyBBUElD IElEIHRvIDgNCmlvYXBpYzE6IENoYW5naW5nIEFQSUMgSUQgdG8gOQ0KaW9hcGljMTogV0FSTklO RzogaW50YmFzZSAzMiAhPSBleHBlY3RlZCBiYXNlIDI0DQppb2FwaWMyOiBDaGFuZ2luZyBBUElD IElEIHRvIDEwDQppb2FwaWMyOiBXQVJOSU5HOiBpbnRiYXNlIDY0ICE9IGV4cGVjdGVkIGJhc2Ug NTYNCmlvYXBpYzAgPFZlcnNpb24gMi4wPiBpcnFzIDAtMjMgb24gbW90aGVyYm9hcmQNCmlvYXBp YzEgPFZlcnNpb24gMi4wPiBpcnFzIDMyLTU1IG9uIG1vdGhlcmJvYXJkDQppb2FwaWMyIDxWZXJz aW9uIDIuMD4gaXJxcyA2NC04NyBvbiBtb3RoZXJib2FyZA0KbnB4MDogPG1hdGggcHJvY2Vzc29y PiBvbiBtb3RoZXJib2FyZA0KbnB4MDogSU5UIDE2IGludGVyZmFjZQ0KYWNwaTA6IDxERUxMIFBF IEJLQz4gb24gbW90aGVyYm9hcmQNCmFjcGkwOiBQb3dlciBCdXR0b24gKGZpeGVkKQ0KVGltZWNv dW50ZXIgIkFDUEktZmFzdCIgZnJlcXVlbmN5IDM1Nzk1NDUgSHogcXVhbGl0eSAxMDAwDQphY3Bp X3RpbWVyMDogPDI0LWJpdCB0aW1lciBhdCAzLjU3OTU0NU1Iej4gcG9ydCAweDgwOC0weDgwYiBv biBhY3BpMA0KY3B1MDogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KY3B1MTogPEFDUEkgQ1BVPiBvbiBh Y3BpMA0KY3B1MjogPEFDUEkgQ1BVPiBvbiBhY3BpMA0KY3B1MzogPEFDUEkgQ1BVPiBvbiBhY3Bp MA0KcGNpYjA6IDxBQ1BJIEhvc3QtUENJIGJyaWRnZT4gcG9ydCAweGNmOC0weGNmZiBvbiBhY3Bp MA0KcGNpMDogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjANCnBjaWIxOiA8QUNQSSBQQ0ktUENJIGJy aWRnZT4gYXQgZGV2aWNlIDIuMCBvbiBwY2kwDQpwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li MQ0KcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMC4wIG9uIHBjaTENCnBj aTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyDQphbXIwOiA8TFNJTG9naWMgTWVnYVJBSUQgMS41 MT4gbWVtIDB4ZGZkYzAwMDAtMHhkZmRmZmZmZiwweGQ4MmYwMDAwLTB4ZDgyZmZmZmYgaXJxIDQ2 IGF0IGRldmljZSAxNC4wIG9uIHBjaTINCmFtcjA6IDxMU0lMb2dpYyBQRVJDIDRlL0RpPiBGaXJt d2FyZSA1MTZBLCBCSU9TIEg0MTgsIDI1Nk1CIFJBTQ0KcGNpYjM6IDxBQ1BJIFBDSS1QQ0kgYnJp ZGdlPiBhdCBkZXZpY2UgMC4yIG9uIHBjaTENCnBjaTM6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIz DQphbXIxOiA8TFNJTG9naWMgTWVnYVJBSUQgMS41MT4gbWVtIDB4ZDgxZjAwMDAtMHhkODFmZmZm ZiBpcnEgMzcgYXQgZGV2aWNlIDExLjAgb24gcGNpMw0KYW1yMTogPExTSUxvZ2ljIFBFUkMgNC9T Qz4gRmlybXdhcmUgMzUxTiwgQklPUyAxLjEwLCA2NE1CIFJBTQ0KcGNpYjQ6IDxBQ1BJIFBDSS1Q Q0kgYnJpZGdlPiBhdCBkZXZpY2UgNC4wIG9uIHBjaTANCnBjaTQ6IDxBQ1BJIFBDSSBidXM+IG9u IHBjaWI0DQpwY2liNTogPEFDUEkgUENJLVBDSSBicmlkZ2U+IGF0IGRldmljZSA1LjAgb24gcGNp MA0KcGNpNTogPEFDUEkgUENJIGJ1cz4gb24gcGNpYjUNCnBjaWI2OiA8QUNQSSBQQ0ktUENJIGJy aWRnZT4gYXQgZGV2aWNlIDAuMCBvbiBwY2k1DQpwY2k2OiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2li Ng0KZW0wOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uLCBWZXJzaW9uIC0g MS43LjM1PiBwb3J0IDB4ZWNjMC0weGVjZmYgbWVtIDB4ZGY5ZTAwMDAtMHhkZjlmZmZmZiBpcnEg NjQgYXQgZGV2aWNlIDcuMCBvbiBwY2k2DQplbTA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjExOjQz OmRlOjA4OjU0DQplbTA6ICBTcGVlZDpOL0EgIER1cGxleDpOL0ENCnBjaWI3OiA8QUNQSSBQQ0kt UENJIGJyaWRnZT4gYXQgZGV2aWNlIDAuMiBvbiBwY2k1DQpwY2k3OiA8QUNQSSBQQ0kgYnVzPiBv biBwY2liNw0KZW0xOiA8SW50ZWwoUikgUFJPLzEwMDAgTmV0d29yayBDb25uZWN0aW9uLCBWZXJz aW9uIC0gMS43LjM1PiBwb3J0IDB4ZGNjMC0weGRjZmYgbWVtIDB4ZGY3ZTAwMDAtMHhkZjdmZmZm ZiBpcnEgNjUgYXQgZGV2aWNlIDguMCBvbiBwY2k3DQplbTE6IEV0aGVybmV0IGFkZHJlc3M6IDAw OjExOjQzOmRlOjA4OjU1DQplbTE6ICBTcGVlZDpOL0EgIER1cGxleDpOL0ENCnBjaWI4OiA8QUNQ SSBQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDYuMCBvbiBwY2kwDQpwY2k4OiA8QUNQSSBQQ0kg YnVzPiBvbiBwY2liOA0KcGNpYjk6IDxQQ0ktUENJIGJyaWRnZT4gYXQgZGV2aWNlIDAuMCBvbiBw Y2k4DQpwY2k5OiA8UENJIGJ1cz4gb24gcGNpYjkNCmFtcjI6IDxMU0lMb2dpYyBNZWdhUkFJRCAx LjUxPiBtZW0gMHhkZjRjMDAwMC0weGRmNGZmZmZmLDB4ZDgwZjAwMDAtMHhkODBmZmZmZiBpcnEg MTggYXQgZGV2aWNlIDE0LjAgb24gcGNpOQ0KYW1yMjogPExTSUxvZ2ljIFBFUkMgNGUvREM+IEZp cm13YXJlIDUyMU4sIEJJT1MgSDQzMCwgMTI4TUIgUkFNDQpwY2liMTA6IDxQQ0ktUENJIGJyaWRn ZT4gYXQgZGV2aWNlIDAuMiBvbiBwY2k4DQpwY2kxMDogPFBDSSBidXM+IG9uIHBjaWIxMA0KdWhj aTA6IDxJbnRlbCA4MjgwMUVCIChJQ0g1KSBVU0IgY29udHJvbGxlciBVU0ItQT4gcG9ydCAweGJj ZTAtMHhiY2ZmIGlycSAxNiBhdCBkZXZpY2UgMjkuMCBvbiBwY2kwDQp1c2IwOiA8SW50ZWwgODI4 MDFFQiAoSUNINSkgVVNCIGNvbnRyb2xsZXIgVVNCLUE+IG9uIHVoY2kwDQp1c2IwOiBVU0IgcmV2 aXNpb24gMS4wDQp1aHViMDogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4w MC8xLjAwLCBhZGRyIDENCnVodWIwOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93 ZXJlZA0KdWhjaTE6IDxJbnRlbCA4MjgwMUVCIChJQ0g1KSBVU0IgY29udHJvbGxlciBVU0ItQj4g cG9ydCAweGJjYzAtMHhiY2RmIGlycSAxOSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwDQp1c2IxOiA8 SW50ZWwgODI4MDFFQiAoSUNINSkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IG9uIHVoY2kxDQp1c2Ix OiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMTogSW50ZWwgVUhDSSByb290IGh1YiwgY2xhc3MgOS8w LCByZXYgMS4wMC8xLjAwLCBhZGRyIDENCnVodWIxOiAyIHBvcnRzIHdpdGggMiByZW1vdmFibGUs IHNlbGYgcG93ZXJlZA0KdWhjaTI6IDxJbnRlbCA4MjgwMUVCIChJQ0g1KSBVU0IgY29udHJvbGxl ciBVU0ItQz4gcG9ydCAweGJjYTAtMHhiY2JmIGlycSAxOCBhdCBkZXZpY2UgMjkuMiBvbiBwY2kw DQp1c2IyOiA8SW50ZWwgODI4MDFFQiAoSUNINSkgVVNCIGNvbnRyb2xsZXIgVVNCLUM+IG9uIHVo Y2kyDQp1c2IyOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMjogSW50ZWwgVUhDSSByb290IGh1Yiwg Y2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDENCnVodWIyOiAyIHBvcnRzIHdpdGggMiBy ZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KcGNpMDogPHNlcmlhbCBidXMsIFVTQj4gYXQgZGV2aWNl IDI5LjcgKG5vIGRyaXZlciBhdHRhY2hlZCkNCnBjaWIxMTogPEFDUEkgUENJLVBDSSBicmlkZ2U+ IGF0IGRldmljZSAzMC4wIG9uIHBjaTANCnBjaTExOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMTEN CnBjaTExOiA8dW5rbm93bj4gYXQgZGV2aWNlIDUuMCAobm8gZHJpdmVyIGF0dGFjaGVkKQ0KcGNp MTE6IDx1bmtub3duPiBhdCBkZXZpY2UgNS4xIChubyBkcml2ZXIgYXR0YWNoZWQpDQpwY2kxMTog PHVua25vd24+IGF0IGRldmljZSA1LjIgKG5vIGRyaXZlciBhdHRhY2hlZCkNCmF0YXBjaTA6IDxT aUkgMDY4MCBVRE1BMTMzIGNvbnRyb2xsZXI+IHBvcnQgMHhjYzcwLTB4Y2M3ZiwweGNjZDAtMHhj Y2QzLDB4Y2NkOC0weGNjZGYsMHhjY2U0LTB4Y2NlNywweGNjZjAtMHhjY2Y3IGlycSAyMyBhdCBk ZXZpY2UgNi4wIG9uIHBjaTExDQphdGEyOiBjaGFubmVsICMwIG9uIGF0YXBjaTANCmF0YTM6IGNo YW5uZWwgIzEgb24gYXRhcGNpMA0KcGNpMTE6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAxMy4w IChubyBkcml2ZXIgYXR0YWNoZWQpDQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBhdCBkZXZpY2Ug MzEuMCBvbiBwY2kwDQppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjANCmF0YXBjaTE6IDxJbnRlbCBJ Q0g1IFVETUExMDAgY29udHJvbGxlcj4gcG9ydCAweGZjMDAtMHhmYzBmLDB4Mzc2LDB4MTcwLTB4 MTc3LDB4M2Y2LDB4MWYwLTB4MWY3IGF0IGRldmljZSAzMS4xIG9uIHBjaTANCmF0YTA6IGNoYW5u ZWwgIzAgb24gYXRhcGNpMQ0KYXRhMTogY2hhbm5lbCAjMSBvbiBhdGFwY2kxDQpmZGMwOiA8Zmxv cHB5IGRyaXZlIGNvbnRyb2xsZXI+IHBvcnQgMHgzZjcsMHgzZjAtMHgzZjUgaXJxIDYgZHJxIDIg b24gYWNwaTANCmZkMDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwDQphdGti ZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBwb3J0IDB4NjQsMHg2MCBpcnEgMSBv biBhY3BpMA0KYXRrYmQwOiA8QVQgS2V5Ym9hcmQ+IGlycSAxIG9uIGF0a2JkYzANCmtiZDAgYXQg YXRrYmQwDQpwc20wOiA8UFMvMiBNb3VzZT4gaXJxIDEyIG9uIGF0a2JkYzANCnBzbTA6IG1vZGVs IEludGVsbGlNb3VzZSBFeHBsb3JlciwgZGV2aWNlIElEIDQNCnNpbzA6IDwxNjU1MEEtY29tcGF0 aWJsZSBDT00gcG9ydD4gcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEwIG9uIGFjcGkw DQpzaW8wOiB0eXBlIDE2NTUwQQ0Kb3JtMDogPElTQSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhl YzAwMC0weGVmZmZmLDB4ZDM4MDAtMHhkNDdmZiwweGNiMDAwLTB4Y2JmZmYsMHhjMDAwMC0weGNh ZmZmIG9uIGlzYTANCnBtdGltZXIwIG9uIGlzYTANCnBwYzA6IHBhcmFsbGVsIHBvcnQgbm90IGZv dW5kLg0Kc2MwOiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTANCnNjMDog VkdBIDwxNiB2aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4NCnNpbzE6IGNvbmZpZ3VyZWQg aXJxIDMgbm90IGluIGJpdG1hcCBvZiBwcm9iZWQgaXJxcyAwDQpzaW8xOiBwb3J0IG1heSBub3Qg YmUgZW5hYmxlZA0KdmdhMDogPEdlbmVyaWMgSVNBIFZHQT4gYXQgcG9ydCAweDNjMC0weDNkZiBp b21lbSAweGEwMDAwLTB4YmZmZmYgb24gaXNhMA0KdWtiZDA6IERlbGwgRFJBQzQsIHJldiAxLjEw LzAuMDAsIGFkZHIgMiwgaWNsYXNzIDMvMQ0Ka2JkMSBhdCB1a2JkMA0KdW1zMDogRGVsbCBEUkFD NCwgcmV2IDEuMTAvMC4wMCwgYWRkciAyLCBpY2xhc3MgMy8xDQp1bXMwOiBYIHJlcG9ydCAweDAw MDIgbm90IHN1cHBvcnRlZA0KZGV2aWNlX2F0dGFjaDogdW1zMCBhdHRhY2ggcmV0dXJuZWQgNg0K dWh1YjM6IERlbGwgcHJvZHVjdCAweGEwMDEsIGNsYXNzIDkvMCwgcmV2IDIuMDAvMC4wMCwgYWRk ciAyDQp1aHViMzogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQNClRpbWVj b3VudGVycyB0aWNrIGV2ZXJ5IDEwLjAwMCBtc2VjDQphY2QwOiBDRFJXIDxITC1EVC1TVENELVJX L0RWRC1ST00gR0NDLTQyNDNOL0ExMDI+IGF0IGF0YTAtbWFzdGVyIFBJTzQNCmF0YTItbWFzdGVy OiBGQUlMVVJFIC0gU0VURkVBVFVSRVMgU0VUIFRSQU5TRkVSIE1PREUgc3RhdHVzPTQxPFJFQURZ LEVSUk9SPiBlcnJvcj00PEFCT1JURUQ+DQphdGEyLXNsYXZlOiBGQUlMVVJFIC0gU0VURkVBVFVS RVMgU0VUIFRSQU5TRkVSIE1PREUgc3RhdHVzPTQxPFJFQURZLEVSUk9SPiBlcnJvcj00PEFCT1JU RUQ+DQphY2QxOiBDRFJPTSA8VklSVFVBTENEUk9NIERSSVZFLz4gYXQgYXRhMi1zbGF2ZSBCSU9T UElPDQphbXJkMDogPExTSUxvZ2ljIE1lZ2FSQUlEIGxvZ2ljYWwgZHJpdmU+IG9uIGFtcjANCmFt cmQwOiAxMzg3MjBNQiAoMjg0MDk4NTYwIHNlY3RvcnMpIFJBSUQgMCAob3B0aW1hbCkNCnNlczAg YXQgYW1yMCBidXMgMCB0YXJnZXQgNiBsdW4gMA0Kc2VzMDogPFBFL1BWIDF4NiBTQ1NJIEJQIDEu MD4gRml4ZWQgUHJvY2Vzc29yIFNDU0ktMiBkZXZpY2UgDQpzZXMwOiBTQUYtVEUgQ29tcGxpYW50 IERldmljZQ0KU01QOiBBUCBDUFUgIzMgTGF1bmNoZWQhDQpTTVA6IEFQIENQVSAjMSBMYXVuY2hl ZCENClNNUDogQVAgQ1BVICMyIExhdW5jaGVkIQ0KTW91bnRpbmcgcm9vdCBmcm9tIHVmczovZGV2 L2FtcmQwczFhDQoNCg== ------_=_NextPart_001_01C56123.058D2991-- From owner-freebsd-current@FreeBSD.ORG Wed May 25 13:04:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2568116A41C for ; Wed, 25 May 2005 13:04:18 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: from mailserv1.neuroflux.com (ns2.neuroflux.com [204.228.228.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8265B43D49 for ; Wed, 25 May 2005 13:04:17 +0000 (GMT) (envelope-from ryans@gamersimpact.com) Received: (qmail 44330 invoked by uid 1003); 25 May 2005 13:05:48 -0000 Received: from ryans@gamersimpact.com by mailserv1.neuroflux.com by uid 89 with qmail-scanner-1.22 (clamscan: 0.65. spamassassin: 2.60. Clear:RC:1(63.231.154.152):. Processed in 1.391968 secs); 25 May 2005 13:05:48 -0000 Received: from unknown (HELO ?192.168.0.5?) (63.231.154.152) by mailserv1.neuroflux.com with SMTP; 25 May 2005 13:05:46 -0000 Message-ID: <429477D1.8060206@gamersimpact.com> Date: Wed, 25 May 2005 08:04:17 -0500 From: Ryan Sommers User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Muthu_T@Dell.com References: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB67120@blrx2kmbgl101.blr.amer.dell.com> In-Reply-To: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB67120@blrx2kmbgl101.blr.amer.dell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, doc@freebsd.org Subject: Re: FreeBSD 5.4 supports DELL PERC 4 cards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 13:04:18 -0000 Muthu_T@Dell.com wrote: > All, > > Could anyone add the following cards to the 'amr' man page as > supported hardware? > > 1. DELL PERC 4/SC - PCI Card > 2. DELL PERC 4/DC - PCI Card > 3. DELL PERC 4e/DC - PCI Express card > > I had installed FreeBSD 5.4 on PE2850 today and found that 'amr' > detected the above last 2 cards. > > See the attached dmesg & 'pciconf -l -v' output. > > Also please change the text 'MegaRaid' to 'MegaRAID' in 'amr' source. > > Thanks. > --T. Muthu Mohan First off, thanks for providing the feedback and testing! Seeing manufacturers contribute is a blessing to anyone following the project. Second, while src committers (those that are supposed to monitor current@) have the ability to modify man pages it is generally felt that is one of the tasks of the Documentation project team. All requests for documentation changes are asked to be sent to doc@freebsd.org mailing list. However, they are more than welcome to be CC'd here as well if it's something like an RFC! Doc. Project is at http://www.freebsd.org/docproj/docproj.html PS I CC'd doc@ so don't worry about sending another one. Thanks again. -- Ryan Sommers ryans@gamersimpact.com From owner-freebsd-current@FreeBSD.ORG Wed May 25 15:36:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2057516A422 for ; Wed, 25 May 2005 15:36:49 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from ms-dienst.rz.rwth-aachen.de (ms-2.rz.RWTH-Aachen.DE [134.130.3.131]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A70443D49 for ; Wed, 25 May 2005 15:36:48 +0000 (GMT) (envelope-from chris@haakonia.hitnet.rwth-aachen.de) Received: from r220-1 (r220-1.rz.RWTH-Aachen.DE [134.130.3.31]) by ms-dienst.rz.rwth-aachen.de (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0IH1002ASY1ASF@ms-dienst.rz.rwth-aachen.de> for freebsd-current@freebsd.org; Wed, 25 May 2005 17:36:47 +0200 (MEST) Received: from relay.rwth-aachen.de ([134.130.3.1]) by r220-1 (MailMonitor for SMTP v1.2.2 ) ; Wed, 25 May 2005 17:36:46 +0200 (MEST) Received: from haakonia.hitnet.rwth-aachen.de (mulzirak.hitnet.RWTH-Aachen.DE [137.226.181.149]) by relay.rwth-aachen.de (8.13.3/8.13.3/1) with ESMTP id j4PFajHm006106; Wed, 25 May 2005 17:36:46 +0200 (MEST) Received: by haakonia.hitnet.rwth-aachen.de (Postfix, from userid 1001) id 9437728460; Wed, 25 May 2005 17:36:45 +0200 (CEST) Date: Wed, 25 May 2005 17:36:45 +0200 From: Christian Brueffer In-reply-to: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB67120@blrx2kmbgl101.blr.amer.dell.com> To: Muthu_T@Dell.com Message-id: <20050525153645.GD1167@unixpages.org> MIME-version: 1.0 Content-type: multipart/signed; boundary=orO6xySwJI16pVnm; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-disposition: inline User-Agent: Mutt/1.5.6i X-Operating-System: FreeBSD 5.4-STABLE X-PGP-Key: http://people.FreeBSD.org/~brueffer/brueffer.key.asc X-PGP-Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D References: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB67120@blrx2kmbgl101.blr.amer.dell.com> Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 5.4 supports DELL PERC 4 cards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 15:36:49 -0000 --orO6xySwJI16pVnm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 25, 2005 at 07:12:29AM -0500, Muthu_T@Dell.com wrote: > All, > =20 > Could anyone add the following cards to the 'amr' man page as > supported hardware? >=20 > 1. DELL PERC 4/SC - PCI Card=20 > 2. DELL PERC 4/DC - PCI Card > 3. DELL PERC 4e/DC - PCI Express card=20 >=20 > I had installed FreeBSD 5.4 on PE2850 today and found that 'amr' > detected the above last 2 cards. >=20 > See the attached dmesg & 'pciconf -l -v' output. >=20 I have added them to the manpage, thanks! - Christian --=20 Christian Brueffer chris@unixpages.org brueffer@FreeBSD.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --orO6xySwJI16pVnm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFClJuNbHYXjKDtmC0RAllRAJ99vbQ7YRKAWkf44BxjhlniBxhdsACcD1S+ 6RUBFWAQQGbiHKR7hkEv+Sg= =J/NK -----END PGP SIGNATURE----- --orO6xySwJI16pVnm-- From owner-freebsd-current@FreeBSD.ORG Wed May 25 18:06:46 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ADF3516A41C; Wed, 25 May 2005 18:06:46 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 738DB43D49; Wed, 25 May 2005 18:06:46 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Wed, 25 May 2005 11:06:45 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BBB165D07; Wed, 25 May 2005 11:06:45 -0700 (PDT) To: Xin LI In-reply-to: Your message of "Sun, 22 May 2005 19:26:12 +0800." <20050522112612.GA37841@frontfree.net> Date: Wed, 25 May 2005 11:06:45 -0700 From: "Kevin Oberman" Message-Id: <20050525180645.BBB165D07@ptavv.es.net> Cc: freebsd-current@FreeBSD.org, delphij@FreeBSD.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 18:06:46 -0000 I have now completely updated my system (IBM T30 with Radeon M7 7500 graphics) to current with the patches applied. I am loading vesa a boot time. I see all of the graphics modes (about 30 of them), but am unable to enable them. I get either: vidcontrol: Setting video mode: Inappropriate ioctl for device or vidcontrol: cannot activate raster mode: Inappropriate ioctl for device depending on the mode selected. If I get the first message, it is almost instantaneous. If I get the second, the display blanks for several seconds before the message comes out. Any suggestions Should I build the kernel with vesa as opposed to loading the module? -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Wed May 25 18:26:01 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0AF1B16A41C; Wed, 25 May 2005 18:26:01 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B304843D49; Wed, 25 May 2005 18:26:00 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j4PIPt0M068307; Wed, 25 May 2005 13:25:55 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4294C327.2070806@centtech.com> Date: Wed, 25 May 2005 13:25:43 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050504 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kevin Oberman References: <20050525180645.BBB165D07@ptavv.es.net> In-Reply-To: <20050525180645.BBB165D07@ptavv.es.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/894/Wed May 25 07:53:16 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 18:26:01 -0000 Kevin Oberman wrote: > I have now completely updated my system (IBM T30 with Radeon M7 7500 > graphics) to current with the patches applied. I am loading vesa a boot > time. > > I see all of the graphics modes (about 30 of them), but am unable to > enable them. I get either: > vidcontrol: Setting video mode: Inappropriate ioctl for device > or > vidcontrol: cannot activate raster mode: Inappropriate ioctl for device > > depending on the mode selected. If I get the first message, it is almost > instantaneous. If I get the second, the display blanks for several > seconds before the message comes out. > > Any suggestions Should I build the kernel with vesa as opposed to loading > the module? I'm using the vesa module, and it works fine. Did you add the SC_PIXEL_MODE line to your kernel config before rebuilding? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Wed May 25 18:46:41 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEBD116A41C for ; Wed, 25 May 2005 18:46:41 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CE6C43D48 for ; Wed, 25 May 2005 18:46:40 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 25702 invoked by uid 89); 25 May 2005 18:45:55 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 25 May 2005 18:45:55 -0000 Date: Wed, 25 May 2005 20:46:38 +0200 From: Oliver Lehmann To: current@freebsd.org Message-Id: <20050525204638.4e383feb.lehmann@ans-netz.de> X-Mailer: Sylpheed version 1.9.11 (GTK+ 2.6.7; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org Subject: problems with nfs+TCP - Resource temporarily unavailable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 18:46:42 -0000 Hi, I'm getting the following error when dding a big file on an nfs mount which is mounted using TCP. root@kartoffel olivleh1> dd if=/usr/tmp.data of=/mnt/files/tmp.data bs=32k dd: /mnt/files/tmp.data: Resource temporarily unavailable 639+0 records in 638+0 records out 20905984 bytes transferred in 15.066490 secs (1387582 bytes/sec) Exit 1 root@dill olivleh1> dd if=/usr/tmp.data of=/mnt/files/tmp.data bs=32k dd: /mnt/files/tmp.data: Resource temporarily unavailable 1035+0 records in 1034+0 records out 33882112 bytes transferred in 14.698220 secs (2305185 bytes/sec) Exit 1 dmesg gives me "nfs send error 35 for server file:/mnt/files" fstab entry on kartoffel and dill: file:/mnt/files /mnt/files nfs tcp,nfsv3,soft,bg,rw,noauto 0 0 - kartoffel is an amd64 system with an onboard re0 running CURRENT from May 24th evening. - dill is an alpha system with an xl0 running 5.4 STABLE from May 20th - file is an i386 SMP system with an xl0 running 5.4 STABLE from May 20th - dill and file are connected directly through an switch - kartoffel and file are connected through an router+switches. - kartoffel and nudel are running rpc.lockd and rpc.statd - dill doesn't run rpc.lockd neither rpc.statd Switching from nfsv3 to a nfsv2 mount is much slower and breaks sooner or later with an error too. It doesn't give me an "error 35" on client side, but an "nfsd send error 32" on server side and a slightly different error message: root@kartoffel olivleh1> dd if=/usr/tmp.data of=/mnt/files/tmp.data bs=32k dd: /mnt/files/tmp.data: Operation timed out 67+0 records in 66+0 records out 2162688 bytes transferred in 6.221855 secs (347595 bytes/sec) Exit 1 Switching from TCP to UDP makes this error gone. Any ideas how to fix this properly? (please CC me, I'm not subscribed to stable@) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Wed May 25 19:00:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 769FA16A41C; Wed, 25 May 2005 19:00:37 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal1.es.net (postal1.es.net [198.128.3.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B6F143D1D; Wed, 25 May 2005 19:00:37 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal1.es.net (Postal Node 1) with ESMTP (SSL) id IBA74465; Wed, 25 May 2005 12:00:36 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id 95FAC5D07; Wed, 25 May 2005 12:00:36 -0700 (PDT) To: Eric Anderson In-reply-to: Your message of "Wed, 25 May 2005 13:25:43 CDT." <4294C327.2070806@centtech.com> Date: Wed, 25 May 2005 12:00:36 -0700 From: "Kevin Oberman" Message-Id: <20050525190036.95FAC5D07@ptavv.es.net> Cc: freebsd-current@freebsd.org, delphij@freebsd.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 19:00:37 -0000 > Date: Wed, 25 May 2005 13:25:43 -0500 > From: Eric Anderson > > Kevin Oberman wrote: > > I have now completely updated my system (IBM T30 with Radeon M7 7500 > > graphics) to current with the patches applied. I am loading vesa a boot > > time. > > > > I see all of the graphics modes (about 30 of them), but am unable to > > enable them. I get either: > > vidcontrol: Setting video mode: Inappropriate ioctl for device > > or > > vidcontrol: cannot activate raster mode: Inappropriate ioctl for device > > > > depending on the mode selected. If I get the first message, it is almost > > instantaneous. If I get the second, the display blanks for several > > seconds before the message comes out. > > > > Any suggestions Should I build the kernel with vesa as opposed to loading > > the module? > > I'm using the vesa module, and it works fine. Did you add the > SC_PIXEL_MODE line to your kernel config before rebuilding? Thanks, Eric. I'll be away from my desk for a bit to get lunch and have "moron" tattooed on my forehead. :-) How many FreeBSD systems do I have that I have SC_PIXEL_MODE on? Almost all of them. I guess I pulled it from this system because it didn't support a graphics console and then I forgot all about it. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Wed May 25 19:39:34 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0764216A41C for ; Wed, 25 May 2005 19:39:34 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5CC343D4C for ; Wed, 25 May 2005 19:39:33 +0000 (GMT) (envelope-from csjp@FreeBSD.org) Received: from freefall.freebsd.org (csjp@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j4PJdX3i033287 for ; Wed, 25 May 2005 19:39:33 GMT (envelope-from csjp@freefall.freebsd.org) Received: (from csjp@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4PJdXZi033286 for freebsd-current@FreeBSD.org; Wed, 25 May 2005 19:39:33 GMT (envelope-from csjp) Date: Wed, 25 May 2005 19:39:33 +0000 From: "Christian S.J. Peron" To: freebsd-current@FreeBSD.org Message-ID: <20050525193933.GA32095@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: [patch] 2Gb SYSVSHM limitation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 19:39:34 -0000 I am looking for a review and testers for a fix to the 2 Gig memory limitation when allocating system V shared memory segments. A couple of notes: 1) This patch breaks ABI because it changes the size of the shminfo structure. This means that ipcs will need to be recompiled. (and anything else which uses struct shminfo). 2) Because this changes the size limitations stored in struct shminfo from a signed integer to an unsigned long, it allows x86 to allocate up to 4 gigs and also allows 64 bit architectures to do far more. Even though the size parameter used by shmget(2) is a size_t, the upper size limit is currently stored in a signed int. Limiting the maximum size of an allocation to 2147483647 bytes. Patch can be downloaded from: http://people.freebsd.org/~csjp/bigsharedmem.1117028863.diff Should apply to any recent version of -CURRENT cleanly. Thanks! -- Christian S.J. Peron csjp@FreeBSD.ORG FreeBSD Committer From owner-freebsd-current@FreeBSD.ORG Wed May 25 22:43:46 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A03CF16A41F for ; Wed, 25 May 2005 22:43:46 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from smtp103.rog.mail.re2.yahoo.com (smtp103.rog.mail.re2.yahoo.com [206.190.36.81]) by mx1.FreeBSD.org (Postfix) with SMTP id C4F4A43D4C for ; Wed, 25 May 2005 22:43:45 +0000 (GMT) (envelope-from mikej@rogers.com) Received: from unknown (HELO 172.16.0.1) (mikej@69.193.222.195 with login) by smtp103.rog.mail.re2.yahoo.com with SMTP; 25 May 2005 22:43:44 -0000 Received: from 172.16.0.199 (SquirrelMail authenticated user mikej) by 172.16.0.1 with HTTP; Wed, 25 May 2005 18:43:44 -0400 (EDT) Message-ID: <1354.172.16.0.199.1117061024.squirrel@172.16.0.1> In-Reply-To: <20050524050713.0935F16A41F@hub.freebsd.org> References: <20050524030802.GD61461@cell.sick.ru> from Gleb Smirnoff at "May 24, 2005 07:08:02 am" <20050524050713.0935F16A41F@hub.freebsd.org> Date: Wed, 25 May 2005 18:43:44 -0400 (EDT) From: "Mike Jakubik" To: "Bill Paul" User-Agent: SquirrelMail/1.5.1 [CVS] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Gleb Smirnoff , freebsd-current@freebsd.org Subject: Re: non-sleepable locks held (xl0) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 22:43:46 -0000 On Tue, May 24, 2005 1:07 am, Bill Paul said: > You can't sleep in taskqueue_drain() with a lock held (clowns > will eat you). Wait for the taskqueue to drain first, then lock. Let me know when there is a patch commited to -current, and i will gladly rebuild and test. From owner-freebsd-current@FreeBSD.ORG Wed May 25 23:03:29 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5CBB16A41C for ; Wed, 25 May 2005 23:03:29 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id BA6DB43D49 for ; Wed, 25 May 2005 23:03:28 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 32547 invoked by uid 89); 25 May 2005 23:02:42 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 25 May 2005 23:02:42 -0000 Date: Thu, 26 May 2005 01:03:25 +0200 From: Oliver Lehmann To: Mohan Srinivasan Message-Id: <20050526010325.02415410.lehmann@ans-netz.de> In-Reply-To: <20050525223355.56551.qmail@web80601.mail.yahoo.com> References: <20050525223355.56551.qmail@web80601.mail.yahoo.com> X-Mailer: Sylpheed version 1.9.11 (GTK+ 2.6.7; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current@freebsd.org Subject: Re: problems with nfs+TCP - Resource temporarily unavailable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 23:03:29 -0000 Hi Mohan, Mohan Srinivasan wrote: > Is this consistently reproducible ? it is - everytime > I tried reproducing this with this morning's > current, it also happens with STABLE > How big was your file that you tried to dd ? I need to reproduce this here > in order to track it down. dd if=/dev/urandom of=/usr/tmp.data bs=512k count=200 > Also, can you try the test without using the soft mount option ? I don't see > soft causing this, but just to eliminate those code paths. I removed soft and bb, but still the same results: root@kartoffel olivleh1> dd if=/usr/tmp.data of=/mnt/files/temp bs=32k dd: /mnt/files/temp: Resource temporarily unavailable 1797+0 records in 1796+0 records out 58851328 bytes transferred in 33.651500 secs (1748847 bytes/sec) ###### I tried the same with an other nfs server (using dill as nfs server this time - system description is in my 1st mail, same mount options like / mnt/files). And guess what? dill rebooted immediate... dd came never back, gave no output dill's dmesg shows me: fatal kernel trap: trap entry = 0x4 (unaligned access fault) faulting va = 0xfffffc0006b6f44d opcode = 0x28 register = 0x5 pc = 0xfffffc0000541e08 ra = 0xfffffc0000541df4 sp = 0xfffffe000a0f9b70 usp = 0x11ffea80 curthread = 0xfffffc000f91ee10 pid = 343, comm = nfsd panic: trap Uptime: 3d14h15m51s Dumping 253 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 Dump complete unfortunately... root@dill tmp> kgdb vmcore.1 /usr/obj/alpha-5.4/usr/src/sys/DILL/ kernel.debug kgdb: bad namelist Exit 1 and.... damn! yes that panic is reproduceable! 2nd try writing on dill: root@kartoffel olivleh1> dd if=/usr/tmp.data of=/mnt/www/temp bs=32k dd: /mnt/www/temp: Resource temporarily unavailable 387+0 records in 386+0 records out 12648448 bytes transferred in 11.766768 secs (1074930 bytes/sec) So.. using i386 as an tcp nfs-server - the only thing which happens is that dd gets interruped, using alpha as an tcp nfs-server makes the alpha panic. And now it looks I should at first unmount the tcp mount, and then let my alpha system come back online ;) (which is of course not possible w/o the nfsd available of course....) May 26 00:59:44 dill rpcbind: cannot create socket for udp6 Starting mountd. NFS on reserved port only=YES Starting nfsd. Starting local daemons: fatal kernel trap: trap entry = 0x4 (unaligned access fault) faulting va = 0xfffffc000f908929 opcode = 0x28 register = 0x5 pc = 0xfffffc0000532164 ra = 0xfffffc0000532138 sp = 0xfffffe000a1118c0 usp = 0x11ffea80 curthread = 0xfffffc000f91f950 pid = 409, comm = nfsd panic: trap Uptime: 8m17s Dumping 253 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... *** keyboard not plugged in... halted CPU 0 halt code = 5 HALT instruction executed PC = fffffc00005bfac0 *** no timer interrupts on CPU 0 *** CPU 0 booting If someone want me to test sth.. let me know Systems available are 6.0/ i386, 6.0/amd64, 5.4-SMP/i386, 5.4/i386, 5.4/alpha, 4.11/i386 -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Wed May 25 23:25:15 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5739E16A41C for ; Wed, 25 May 2005 23:25:15 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 61CF143D55 for ; Wed, 25 May 2005 23:25:14 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 33038 invoked by uid 89); 25 May 2005 23:24:28 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 25 May 2005 23:24:28 -0000 Date: Thu, 26 May 2005 01:25:11 +0200 From: Oliver Lehmann To: mohan_srinivasan@yahoo.com Message-Id: <20050526012511.2b7828aa.lehmann@ans-netz.de> In-Reply-To: <20050526010325.02415410.lehmann@ans-netz.de> References: <20050525223355.56551.qmail@web80601.mail.yahoo.com> <20050526010325.02415410.lehmann@ans-netz.de> X-Mailer: Sylpheed version 1.9.11 (GTK+ 2.6.7; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current@freebsd.org Subject: Re: problems with nfs+TCP - Resource temporarily unavailable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 May 2005 23:25:15 -0000 Oliver Lehmann wrote: > So.. using i386 as an tcp nfs-server - the only thing which happens is > that dd gets interruped, using alpha as an tcp nfs-server makes the alpha > panic. Ok, maybe the alpha has other problems... Disk worked for 7 years without problems but I just rebooted the system once more and now I'm getting several SCSI CAM messages (da0:sym0:0:0:0): Retrying Command (per Sense Data) (da0:sym0:0:0:0): READ(10). CDB: 28 0 0 57 72 80 0 0 20 0 (da0:sym0:0:0:0): CAM Status: SCSI Status Error (da0:sym0:0:0:0): SCSI Status: Check Condition (da0:sym0:0:0:0): MEDIUM ERROR info:577280 asc:11,0 (da0:sym0:0:0:0): Unrecovered read error field replaceable unit: e4 actual retry count: 257 So - it looks like I need a new disk... damn so drop that alpha problem for now -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Thu May 26 00:18:08 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0BCC116A41C for ; Thu, 26 May 2005 00:18:08 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9CA4543D48 for ; Thu, 26 May 2005 00:18:07 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j4Q0I7WD001106 for ; Wed, 25 May 2005 17:18:07 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j4Q0I7bE001105 for freebsd-current@freebsd.org; Wed, 25 May 2005 17:18:07 -0700 (PDT) (envelope-from faber) Date: Wed, 25 May 2005 17:18:06 -0700 From: Ted Faber To: freebsd-current@freebsd.org Message-ID: <20050526001806.GA1008@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="z6Eq5LdranGa6ru8" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Subject: hard deadlock(?) on -current; some debugging info, need help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 00:18:08 -0000 --z6Eq5LdranGa6ru8 Content-Type: multipart/mixed; boundary="9amGYk9869ThD9tj" Content-Disposition: inline --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi. I'm experiencing intermittent but frequent deadlocks running under -current. The kernel I'm currently running, which exhibits the problem, is from Monday morning: pun:~$ uname -a FreeBSD pun.isi.edu 6.0-CURRENT FreeBSD 6.0-CURRENT #6: Mon May 23 08:07:01 PDT 2005 root@pun.isi.edu:/usr/obj/usr/src/sys/PUN i386 The system slowly grinds to a halt, and the lockup seems to invlove the disk system. I have not found a sequence that triggers them (other than trying to write mail to the list to report them), and I know how difficult that makes things. It is common to have 2-5 a day. Even when I can get to the debugger during a lockup, I cannot generate a crash dump - the kernel reports starting the dump and moves no bytes. WITNESS and INVARIENTS report no information. I have to physically unplug the machine to reboot. I've attached a dmesg from a -v boot and the kernel config (the dmesg is not from the lockup run). Last friday when the system locked I had a digital camera with me and took pictures of the ps output in the hopes that someone could look at them. These images are at http://www.isi.edu/~faber/tmp/deadlock/DSCN04{75,76,77,78,79,80,81,82}.JPG I'm delighted to to my part to get this fixed, but I really don't even know where to start. I'm happy to gather whatever information I can from the debugger and post. I'm happy to try patches. I'm happy to test my hardware to see if it's the problem (if you'll suggest a way). Let me know what I can do to help fix this. Any help at all would be great. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=dmesg nfs server pid391@pun:/home: not responding KDB: enter: manual escape to debugger 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-CURRENT #6: Mon May 23 08:07:01 PDT 2005 root@pun.isi.edu:/usr/obj/usr/src/sys/PUN Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1795.60-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf12 Stepping = 2 Features=0x3febfbff real memory = 268173312 (255 MB) avail memory = 257212416 (245 MB) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: Power Button (fixed) pci_link0: irq 11 on acpi0 pci_link1: irq 10 on acpi0 pci_link2: irq 0 on acpi0 pci_link3: irq 5 on acpi0 pci_link4: irq 0 on acpi0 pci_link5: irq 3 on acpi0 pci_link6: irq 0 on acpi0 pci_link7: irq 9 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 agp0: mem 0xe0000000-0xefffffff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 pci2: on pcib2 pci2: at device 12.0 (no driver attached) pcm0: port 0xdf00-0xdf3f irq 3 at device 13.0 on pci2 pcm0: pcm0: [GIANT-LOCKED] isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 uhci0: port 0xef40-0xef5f irq 5 at device 31.2 on pci0 uhci0: [GIANT-LOCKED] 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 pci0: at device 31.3 (no driver attached) uhci1: port 0xef80-0xef9f irq 9 at device 31.4 on pci0 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] fdc0: port 0x3f0-0x3f1,0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 pmtimer0 on isa0 orm0: at iomem 0xc0000-0xca7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled uhub2: vendor 0x0451 product 0x2046, class 9/0, rev 1.10/1.25, addr 2 uhub2: 4 ports with 4 removable, self powered ukbd0: vendor 0x0430 product 0x0005, rev 1.00/1.02, addr 3, iclass 3/1 kbd1 at ukbd0 ums0: Logitech USB-PS/2 Trackball, rev 1.00/2.10, addr 4, iclass 3/1 ums0: 3 buttons and Z dir. Timecounter "TSC" frequency 1795604520 Hz quality 800 Timecounters tick every 1.000 msec ad0: 38166MB at ata0-master UDMA100 acd0: CDROM at ata1-master UDMA33 Trying to mount root from ufs:/dev/ad0s1a WARNING: / was not properly dismounted WARNING: /usr was not properly dismounted WARNING: /var was not properly dismounted ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled dc0: port 0xd800-0xd8ff mem 0xfeaffc00-0xfeafffff irq 10 at device 12.0 on pci2 dc0: Ethernet address: 00:04:5a:63:0b:50 dc0: if_start running deferred for Giant dc0: [GIANT-LOCKED] miibus0: on dc0 ukphy0: on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...3 3 0 2 2 0 0 0 0 done All buffers synced. unmount of /dev failed (BUSY) Uptime: 16m41s Shutting down ACPI Rebooting... 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-CURRENT #6: Mon May 23 08:07:01 PDT 2005 root@pun.isi.edu:/usr/obj/usr/src/sys/PUN Preloaded elf kernel "/boot/kernel/kernel" at 0xc075c000. Preloaded elf module "/boot/kernel/snd_es137x.ko" at 0xc075c1b0. Preloaded elf module "/boot/kernel/sound.ko" at 0xc075c260. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc075c30c. Calibrating clock(s) ... i8254 clock: 1193165 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 1795600136 Hz CPU: Intel(R) Pentium(R) 4 CPU 1.80GHz (1795.60-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf12 Stepping = 2 Features=0x3febfbff real memory = 268173312 (255 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009efff, 647168 bytes (158 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000825000 - 0x000000000fb10fff, 254722048 bytes (62188 pages) avail memory = 257212416 (245 MB) bios32: Found BIOS32 Service Directory header at 0xc00fda60 bios32: Entry = 0xfda74 (c00fda74) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xda95 pnpbios: Found PnP BIOS data at 0xc00f3080 pnpbios: Entry = f0000:293a Rev = 1.0 Other BIOS signatures found: random: mem: Pentium Pro MTRR support enabled null: io: npx0: [FAST] npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x0000281c pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25308086) pcibios: BIOS version 2.10 Found $PIR table, 11 entries at 0xc00f35f0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 1 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 1 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 C 0x6b 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 7 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 2 8 A 0x68 9 10 11 slot 1 2 9 A 0x69 3 4 5 6 7 9 10 11 12 14 15 slot 1 2 9 B 0x6a 3 4 5 6 7 9 10 11 12 14 15 slot 1 2 9 C 0x6b 3 4 5 6 7 9 10 11 12 14 15 slot 1 2 9 D 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 2 2 10 A 0x6a 3 4 5 6 7 9 10 11 12 14 15 slot 2 2 10 B 0x6b 3 4 5 6 7 9 10 11 12 14 15 slot 2 2 10 C 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 2 2 10 D 0x69 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 11 A 0x6b 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 11 B 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 11 C 0x69 3 4 5 6 7 9 10 11 12 14 15 slot 3 2 11 D 0x6a 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 12 A 0x61 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 12 B 0x69 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 12 C 0x6a 3 4 5 6 7 9 10 11 12 14 15 slot 4 2 12 D 0x6b 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 13 A 0x69 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 13 B 0x6a 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 13 C 0x6b 3 4 5 6 7 9 10 11 12 14 15 slot 5 2 13 D 0x61 3 4 5 6 7 9 10 11 12 14 15 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi0: Power Button (fixed) AcpiOsDerivePciId: bus 0 dev 0 func 0 AcpiOsDerivePciId: bus 0 dev 0 func 0 pci_link0: irq 11 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: irq 10 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 10 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: irq 0 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: irq 5 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 5 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link4: irq 0 on acpi0 pci_link4: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 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 9 10 11 12 14 15 pci_link4: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link5: irq 3 on acpi0 pci_link5: Links after initial probe: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link5: Links after initial validation: Index IRQ Rtd Ref IRQs 0 3 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link6: irq 0 on acpi0 pci_link6: Links after initial probe: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link6: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link6: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link7: irq 9 on acpi0 pci_link7: Links after initial probe: Index IRQ Rtd Ref IRQs 0 9 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link7: Links after initial validation: Index IRQ Rtd Ref IRQs 0 9 N 0 3 4 5 6 7 9 10 11 12 14 15 pci_link7: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 AcpiOsDerivePciId: bus 0 dev 31 func 0 ACPI timer: 1/1 1/1 1/1 1/2 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 0x408-0x40b on acpi0 cpu0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x2530, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2090, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[10]: type 3, range 32, base e0000000, size 28, enabled found-> vendor=0x8086, dev=0x2532, revid=0x02 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x00a0, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0a (2500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x244e, revid=0x04 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x0107, statreg=0x0080, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x02 (500 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x2440, revid=0x04 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x000f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x244b, revid=0x04 bus=0, slot=31, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base 0000ffa0, size 4, enabled found-> vendor=0x8086, dev=0x2442, revid=0x04 bus=0, slot=31, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=5 map[20]: type 4, range 32, base 0000ef40, size 5, enabled pcib0: matched entry for 0.31.INTD (src \\_SB_.LNKD:0) pcib0: slot 31 INTD routed to irq 5 via \\_SB_.LNKD found-> vendor=0x8086, dev=0x2443, revid=0x04 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 map[20]: type 4, range 32, base 0000efa0, size 4, enabled pcib0: matched entry for 0.31.INTB (src \\_SB_.LNKB:0) pcib0: slot 31 INTB routed to irq 10 via \\_SB_.LNKB found-> vendor=0x8086, dev=0x2444, revid=0x04 bus=0, slot=31, func=4 class=0c-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=c, irq=9 map[20]: type 4, range 32, base 0000ef80, size 5, enabled pcib0: matched entry for 0.31.INTC (src \\_SB_.LNKH:0) pcib0: slot 31 INTC routed to irq 9 via \\_SB_.LNKH agp0: mem 0xe0000000-0xefffffff at device 0.0 on pci0 agp0: Reserved 0x10000000 bytes for rid 0x10 type 3 at 0xe0000000 agp0: allocating GATT for aperture of size 256M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xf000-0xfff pcib1: memory decode 0xfc900000-0xfe9fffff pcib1: prefetched decode 0xcc600000-0xdc6fffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x10de, dev=0x0111, revid=0xb2 bus=1, 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 fd000000, size 24, enabled pcib1: (null) requested memory range 0xfd000000-0xfdffffff: good map[14]: type 3, range 32, base d0000000, size 27, enabled pcib1: (null) requested memory range 0xd0000000-0xd7ffffff: good pcib0: matched entry for 0.1.INTA (src \\_SB_.LNKA:0) pcib0: slot 1 INTA routed to irq 11 via \\_SB_.LNKA pcib1: slot 0 INTA is routed to irq 11 pci1: at device 0.0 (no driver attached) pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xd000-0xdfff pcib2: memory decode 0xfea00000-0xfeafffff pcib2: prefetched decode 0xdc700000-0xdc7fffff pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x1317, dev=0x0985, revid=0x11 bus=2, slot=12, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=4 (dwords) lattimer=0x20 (960 ns), mingnt=0xff (63750 ns), maxlat=0xff (63750 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000d800, size 8, enabled pcib2: (null) requested I/O range 0xd800-0xd8ff: in range map[14]: type 1, range 32, base feaffc00, size 10, enabled pcib2: (null) requested memory range 0xfeaffc00-0xfeafffff: good pcib2: matched entry for 2.12.INTA (src \\_SB_.LNKB:0) pcib2: slot 12 INTA routed to irq 10 via \\_SB_.LNKB found-> vendor=0x1274, dev=0x1371, revid=0x09 bus=2, slot=13, func=0 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0105, statreg=0x0410, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x0c (3000 ns), maxlat=0x80 (32000 ns) intpin=a, irq=3 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 4, range 32, base 0000df00, size 6, enabled pcib2: (null) requested I/O range 0xdf00-0xdf3f: in range pcib2: matched entry for 2.13.INTA (src \\_SB_.LNKF:0) pcib2: slot 13 INTA routed to irq 3 via \\_SB_.LNKF pci2: at device 12.0 (no driver attached) pci2:12:0: Transition from D0 to D3 pcm0: port 0xdf00-0xdf3f irq 3 at device 13.0 on pci2 pcm0: Reserved 0x40 bytes for rid 0x10 type 4 at 0xdf00 pcm0: pcm0: Codec features headphone, 20 bit DAC, 18 bit ADC, 6 bit master volume, Crystal Semi 3D Stereo Enhancement pcm0: Primary codec extended features AMAP pcm0: [GIANT-LOCKED] pcm0: sndbuf_setmap 182000, 1000; 0xc118e000 -> 182000 pcm0: sndbuf_setmap 1e0000, 1000; 0xc118c000 -> 1e0000 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xffa0-0xffaf at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xffa0 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=00 ata0: stat0=0x50 err=0x01 lsb=0x00 msb=0x00 ata0: stat1=0x00 err=0x01 lsb=0x00 msb=0x00 ata0: reset tp2 stat0=50 stat1=00 devices=0x1 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=00 ata1: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb ata1: stat1=0x00 err=0x01 lsb=0x7f msb=0x7f ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] uhci0: port 0xef40-0xef5f irq 5 at device 31.2 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xef40 uhci0: [GIANT-LOCKED] 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 pci0: at device 31.3 (no driver attached) uhci1: port 0xef80-0xef9f irq 9 at device 31.4 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xef80 uhci1: [GIANT-LOCKED] usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 kbd0: atkbd0, generic (0), config:0x0, flags:0x3f0000 atkbd0: [GIANT-LOCKED] fdc0: port 0x3f0-0x3f1,0x3f2-0x3f3,0x3f4-0x3f5,0x3f7 irq 6 drq 2 on acpi0 fdc0: ic_type 90 part_id 80 fdc0: [MPSAFE] fdc0: [FAST] fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0: irq maps: 0x1 0x11 0x1 0x1 sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A ppc0: using extended I/O port range ppc0: ECP SPP ECP+EPP SPP ppc0: port 0x378-0x37f,0x778-0x77f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 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 ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it fdc: fdc0 already exists; skipping it ppc: ppc0 already exists; skipping it sc: sc0 already exists; skipping it sio: sio0 already exists; skipping it vga: vga0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xca7ff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) vga0: at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0 adv0: not probed (disabled) aha0: not probed (disabled) aic0: not probed (disabled) bt0: not probed (disabled) cs0: not probed (disabled) ed0: not probed (disabled) fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled sio1: irq maps: 0x1 0x1 0x1 0x1 sio1: probe failed test(s): 0 1 2 4 6 7 9 sio1 failed to probe at port 0x2f8-0x2ff irq 3 on isa0 sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices uhub2: vendor 0x0451 product 0x2046, class 9/0, rev 1.10/1.25, addr 2 uhub2: 4 ports with 4 removable, self powered ukbd0: vendor 0x0430 product 0x0005, rev 1.00/1.02, addr 3, iclass 3/1 kbd: new array size 4 kbd1 at ukbd0 kbd1: ukbd0, generic (0), config:0x0, flags:0x1d0000 ums0: Logitech USB-PS/2 Trackball, rev 1.00/2.10, addr 4, iclass 3/1 ums0: 3 buttons and Z dir. Device configuration finished. Timecounter "TSC" frequency 1795600136 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire ad0: setting PIO4 on Intel ICH2 chip ad0: setting UDMA100 on Intel ICH2 chip ad0: 38166MB at ata0-master UDMA100 ad0: 78165360 sectors [77545C/16H/63S] 16 sectors/interrupt 1 depth queue ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on Intel ICH2 chip acd0: setting UDMA33 on Intel ICH2 chip acd0: CDROM drive at ata1 as master acd0: 128KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, packet acd0: Writes: acd0: Audio: play, 255 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: no/blank disc GEOM: new disk ad0 Trying to mount root from ufs:/dev/ad0s1a start_init: trying /sbin/init procfs registered Linux ELF exec handler installed linprocfs registered ipfw2 (+ipv6) initialized, divert loadable, rule-based forwarding disabled, default to deny, logging disabled pci0: driver added found-> vendor=0x8086, dev=0x2443, revid=0x04 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 cmdreg=0x0001, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=10 pci0:31:3: reprobing on driver added pci1: driver added found-> vendor=0x10de, dev=0x0111, revid=0xb2 bus=1, 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 pci1:0:0: reprobing on driver added pci2: driver added found-> vendor=0x1317, dev=0x0985, revid=0x11 bus=2, slot=12, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0117, statreg=0x0290, cachelnsz=4 (dwords) lattimer=0x20 (960 ns), mingnt=0xff (63750 ns), maxlat=0xff (63750 ns) intpin=a, irq=10 powerspec 2 supports D0 D1 D2 D3 current D3 pci2:12:0: reprobing on driver added pci2:12:0: Transition from D3 to D0 dc0: port 0xd800-0xd8ff mem 0xfeaffc00-0xfeafffff irq 10 at device 12.0 on pci2 dc0: Reserved 0x100 bytes for rid 0x10 type 4 at 0xd800 dc0: bpf attached dc0: Ethernet address: 00:04:5a:63:0b:50 dc0: if_start running deferred for Giant dc0: [GIANT-LOCKED] miibus0: on dc0 ukphy0: on miibus0 ukphy0: OUI 0x000895, model 0x0001, rev. 0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto nfslock: pseudo-device --9amGYk9869ThD9tj Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename=PUN # # GENERIC -- Generic kernel configuration file for FreeBSD/i386 # # For more information on this file, please read the handbook section on # Kernel Configuration Files: # # http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-config.html # # The handbook is also available locally in /usr/share/doc/handbook # if you've installed the doc distribution, otherwise always see the # FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the # latest information. # # An exhaustive list of options and more detailed explanations of the # device lines is also present in the ../../conf/NOTES and NOTES files. # If you are in doubt as to the purpose or necessity of a line, check first # in NOTES. # # $FreeBSD: src/sys/i386/conf/GENERIC,v 1.420 2004/11/02 20:57:19 andre Exp $ machine i386 cpu I486_CPU cpu I586_CPU cpu I686_CPU ident PUN options SCHED_4BSD # 4BSD scheduler options PREEMPTION # Enable kernel thread preemption 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 GEOM_GPT # GUID Partition Tables. options COMPAT_43 # Compatible with BSD 4.3 [KEEP THIS!] options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options SCSI_DELAY=5000 # Delay (in ms) before probing SCSI 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. # Debugging for use in -current options KDB # Enable kernel debugger support. options DDB # Support DDB. options GDB # Support remote GDB. #options INVARIANTS # Enable calls of extra sanity checking #options INVARIANT_SUPPORT # Extra sanity checks of internal structures, required by INVARIANTS #options WITNESS # Enable checks to detect deadlocks and cycles #options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed # 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 atapicd # ATAPI CDROM drives options ATA_STATIC_ID # Static device numbering # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard 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 device agp # support several AGP chipsets # Floating point support - do not disable. device npx # Add suspend/resume support for the i8254. device pmtimer # Serial (COM) ports device sio # 8250, 16[45]50 based serial ports # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device # 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 dc # DEC/Intel 21143 and various workalikes # 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 sl # Kernel SLIP device ppp # Kernel PPP 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 ohci # OHCI PCI->USB interface device usb # USB Bus (required) device ugen # Generic device uhid # "Human Interface Devices" device ukbd # Keyboard device ulpt # Printer device ums # Mouse --9amGYk9869ThD9tj-- --z6Eq5LdranGa6ru8 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFClRW+aUz3f+Zf+XsRAltXAKD7PvfmKH4pqTVezmDyeLkzRFO9qQCgo+Ka r5FMQuiuLm7VoQmEs2Wiilg= =69lP -----END PGP SIGNATURE----- --z6Eq5LdranGa6ru8-- From owner-freebsd-current@FreeBSD.ORG Thu May 26 01:33:06 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9A27616A41C; Thu, 26 May 2005 01:33:06 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 27AD443D55; Thu, 26 May 2005 01:33:05 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.25] ([192.168.42.25]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j4Q1X2nC045761; Wed, 25 May 2005 20:33:02 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42952740.6020400@centtech.com> Date: Wed, 25 May 2005 20:32:48 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050504 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Oliver Lehmann References: <20050525223355.56551.qmail@web80601.mail.yahoo.com> <20050526010325.02415410.lehmann@ans-netz.de> In-Reply-To: <20050526010325.02415410.lehmann@ans-netz.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, Mohan Srinivasan , current@freebsd.org Subject: Re: problems with nfs+TCP - Resource temporarily unavailable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 01:33:06 -0000 Oliver Lehmann wrote: > Hi Mohan, > > Mohan Srinivasan wrote: > > > >>Is this consistently reproducible ? > > > it is - everytime > > > >>I tried reproducing this with this morning's >>current, > > > it also happens with STABLE > > > >>How big was your file that you tried to dd ? I need to reproduce this here >>in order to track it down. > > > dd if=/dev/urandom of=/usr/tmp.data bs=512k count=200 > > > >>Also, can you try the test without using the soft mount option ? I don't see >>soft causing this, but just to eliminate those code paths. > > > I removed soft and bb, but still the same results: > > root@kartoffel olivleh1> dd if=/usr/tmp.data of=/mnt/files/temp bs=32k > dd: /mnt/files/temp: Resource temporarily unavailable > 1797+0 records in > 1796+0 records out > 58851328 bytes transferred in 33.651500 secs (1748847 bytes/sec) > > > ###### > > > I tried the same with an other nfs server (using dill as nfs server this > time - system description is in my 1st mail, same mount options like / > mnt/files). And guess what? dill rebooted immediate... dd came never > back, gave no output > Just for a data point here - I have a 5.3-STABLE (from about January 15th) that is serving up data via NFS (tcp and udp, FreeBSD, Linux, Solaris clients) to about 1000 clients. The server is constantly getting pounded. I haven't seen any issues like this on this machine. I'm about to bring up a 5.4R box that will be in the same environment. If I have any issues, I'll make sure to note them here. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu May 26 02:01:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E828616A41C for ; Thu, 26 May 2005 02:01:37 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc14.comcast.net (rwcrmhc14.comcast.net [216.148.227.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id B807643D4C for ; Thu, 26 May 2005 02:01:37 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from dibbler.crodrigues.org (c-66-30-114-143.hsd1.ma.comcast.net[66.30.114.143]) by comcast.net (rwcrmhc14) with ESMTP id <200505260201370140097h9oe>; Thu, 26 May 2005 02:01:37 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by dibbler.crodrigues.org (8.13.3/8.13.1) with ESMTP id j4Q21iaR080424 for ; Wed, 25 May 2005 22:01:44 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.3/8.13.1/Submit) id j4Q21i8i080423 for freebsd-current@freebsd.org; Wed, 25 May 2005 22:01:44 -0400 (EDT) (envelope-from rodrigc) Date: Wed, 25 May 2005 22:01:43 -0400 From: Craig Rodrigues To: freebsd-current@freebsd.org Message-ID: <20050526020143.GA80396@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: [GCC 4.0 PATCH] devfs_vnops.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 02:01:38 -0000 Hi, When I tried to compile src/sys/fs/devfs/devs_vnops.c with GCC 4.0, I got the following compilation errors: /usr/src/sys/fs/devfs/devfs_vnops.c:1389: error: static declaration of 'devfs_vnodeops' follows non-static declaration /usr/src/sys/fs/devfs/devfs_vnops.c:114: error: previous declaration of 'devfs_vnodeops' was here /usr/src/sys/fs/devfs/devfs_vnops.c:1411: error: static declaration of 'devfs_specops' follows non-static declaration /usr/src/sys/fs/devfs/devfs_vnops.c:115: error: previous declaration of 'devfs_specops' was here Apparently, it is not valid C to define something as extern and then later on static in the same file, like: extern struct foo bar; static struct foo bar = { .... }; What do people think of the following patch to fix it? http://people.freebsd.org/~rodrigc/devfs_vnops.c.diff.txt -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Thu May 26 03:43:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D61E16A41C for ; Thu, 26 May 2005 03:43:58 +0000 (GMT) (envelope-from arr@watson.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26E9A43D48 for ; Thu, 26 May 2005 03:43:55 +0000 (GMT) (envelope-from arr@watson.org) Received: from fledge.watson.org (localhost.watson.org [127.0.0.1]) by fledge.watson.org (8.13.3/8.13.3) with ESMTP id j4Q3iqfw012170; Wed, 25 May 2005 23:44:52 -0400 (EDT) (envelope-from arr@watson.org) Received: from localhost (arr@localhost) by fledge.watson.org (8.13.3/8.13.3/Submit) with ESMTP id j4Q3iq1B012167; Wed, 25 May 2005 23:44:52 -0400 (EDT) (envelope-from arr@watson.org) X-Authentication-Warning: fledge.watson.org: arr owned process doing -bs Date: Wed, 25 May 2005 23:44:52 -0400 (EDT) From: "Andrew R. Reiter" To: Craig Rodrigues In-Reply-To: <20050526020143.GA80396@crodrigues.org> Message-ID: <20050525234400.H5498@fledge.watson.org> References: <20050526020143.GA80396@crodrigues.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: [GCC 4.0 PATCH] devfs_vnops.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 03:43:58 -0000 On Wed, 25 May 2005, Craig Rodrigues wrote: :Hi, : :When I tried to compile src/sys/fs/devfs/devs_vnops.c :with GCC 4.0, I got the following compilation errors: : :/usr/src/sys/fs/devfs/devfs_vnops.c:1389: error: static declaration of 'devfs_vnodeops' follows non-static declaration :/usr/src/sys/fs/devfs/devfs_vnops.c:114: error: previous declaration of 'devfs_vnodeops' was here :/usr/src/sys/fs/devfs/devfs_vnops.c:1411: error: static declaration of 'devfs_specops' follows non-static declaration :/usr/src/sys/fs/devfs/devfs_vnops.c:115: error: previous declaration of 'devfs_specops' was here : :Apparently, it is not valid C to define something as extern :and then later on static in the same file, like: : :extern struct foo bar; :static struct foo bar = { .... }; : : :What do people think of the following patch to fix it? : :http://people.freebsd.org/~rodrigc/devfs_vnops.c.diff.txt : Is this a GCC-ism or a standards related issue that 4.0 now addresses? -- Andrew R. Reiter arr@watson.org From owner-freebsd-current@FreeBSD.ORG Thu May 26 04:42:41 2005 Return-Path: X-Original-To: current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 162F516A41F for ; Thu, 26 May 2005 04:42:41 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from mail.bitfreak.org (mail.bitfreak.org [65.75.198.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id D524043D4C for ; Thu, 26 May 2005 04:42:40 +0000 (GMT) (envelope-from dmp@bitfreak.org) Received: from SMILEY (mail.bitfreak.org [65.75.198.146]) by mail.bitfreak.org (Postfix) with ESMTP id 10DFE19F3B for ; Wed, 25 May 2005 21:43:34 -0700 (PDT) From: "Darren Pilgrim" To: Date: Wed, 25 May 2005 21:42:24 -0700 Message-ID: <000b01c561ad$538356c0$0a2a15ac@SMILEY> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal Cc: Subject: usbd not opening all usb busses for event watching. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 04:42:41 -0000 I appear to be running up against the hard-coded limit of four usb hubs in usbd. The problems were devices not attaching properly. The machines in question are a new notebook with four USB 2.0 ports and an older desktop with onboard USB 1.1 and a USB 2.0 card. The notebook produces 5 hubs and the desktop produces 7. The problems disappeared after I increased MAXUSBDEV to match the number of hubs present. This isn't really a bug, so I wasn't sure if send-pr was appropriate. Should I file a PR for this? From owner-freebsd-current@FreeBSD.ORG Thu May 26 04:48:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3BE7416A41C for ; Thu, 26 May 2005 04:48:22 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [204.127.198.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id D96F443D48 for ; Thu, 26 May 2005 04:48:21 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from dibbler.crodrigues.org (c-66-30-114-143.hsd1.ma.comcast.net[66.30.114.143]) by comcast.net (rwcrmhc11) with ESMTP id <2005052604481701300ekjrue>; Thu, 26 May 2005 04:48:21 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by dibbler.crodrigues.org (8.13.3/8.13.1) with ESMTP id j4Q4mPGs081421; Thu, 26 May 2005 00:48:25 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.3/8.13.1/Submit) id j4Q4mOAD081420; Thu, 26 May 2005 00:48:24 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 26 May 2005 00:48:24 -0400 From: Craig Rodrigues To: "Andrew R. Reiter" Message-ID: <20050526044824.GA81201@crodrigues.org> References: <20050526020143.GA80396@crodrigues.org> <20050525234400.H5498@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050525234400.H5498@fledge.watson.org> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: [GCC 4.0 PATCH] devfs_vnops.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 04:48:22 -0000 On Wed, May 25, 2005 at 11:44:52PM -0400, Andrew R. Reiter wrote: > Is this a GCC-ism or a standards related issue that 4.0 now addresses? This is a standards issue that GCC 4.0 addresses, which GCC 3.4.2 did not (newer versions of the GCC 3.4.x tree might address is but I haven't checked). In 6.2.2 paragraph 7 of the ISO C standard, "If, within a translation unit, the same identifier appears with both internal and external linkage, the behavior is undefined." So, if you have: extern struct foo bar; static struct foo bar = { ..... }; This is illegal. When the compiler hits the first line, there was no previous declaration of "struct foo bar", so the linkage of "struct foo bar" defaults to external linkage. However, the next line declares "struct foo bar" to have internal linkage. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Thu May 26 05:26:24 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B08EC16A41C for ; Thu, 26 May 2005 05:26:24 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5ECAF43D1F for ; Thu, 26 May 2005 05:26:24 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x535c0e2a.sgnxx1.adsl-dhcp.tele.dk [83.92.14.42]) by pasmtp.tele.dk (Postfix) with ESMTP id D7A821EC307 for ; Thu, 26 May 2005 07:26:22 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j4Q5QD9b003632; Thu, 26 May 2005 07:26:13 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Craig Rodrigues From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 26 May 2005 00:48:24 EDT." <20050526044824.GA81201@crodrigues.org> Date: Thu, 26 May 2005 07:26:13 +0200 Message-ID: <3631.1117085173@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: [GCC 4.0 PATCH] devfs_vnops.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 05:26:24 -0000 In message <20050526044824.GA81201@crodrigues.org>, Craig Rodrigues writes: >"If, within a translation unit, the same identifier appears with both >internal and external linkage, the behavior is undefined." > >So, if you have: > >extern struct foo bar; >static struct foo bar = { ..... }; Well, the reason is it like that is that you cannot forward declare a static (at least in the -current GCC) static struct foo bar; [...] static struct foo bare = { ... }; This might be a bug in C. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu May 26 07:28:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E571816A41C for ; Thu, 26 May 2005 07:28:10 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (chello213047085026.6.14.vie.surfer.at [213.47.85.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 891DE43D1F for ; Thu, 26 May 2005 07:28:10 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id 164444180; Thu, 26 May 2005 09:28:05 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 2D4EF15D; Thu, 26 May 2005 09:28:03 +0200 (CEST) Date: Thu, 26 May 2005 09:28:02 +0200 From: Stefan Farfeleder To: Craig Rodrigues Message-ID: <20050526072801.GM596@wombat.fafoe.narf.at> Mail-Followup-To: Craig Rodrigues , freebsd-current@freebsd.org References: <20050526020143.GA80396@crodrigues.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526020143.GA80396@crodrigues.org> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: [GCC 4.0 PATCH] devfs_vnops.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 07:28:11 -0000 On Wed, May 25, 2005 at 10:01:43PM -0400, Craig Rodrigues wrote: > Hi, > > When I tried to compile src/sys/fs/devfs/devs_vnops.c > with GCC 4.0, I got the following compilation errors: > > /usr/src/sys/fs/devfs/devfs_vnops.c:1389: error: static declaration of 'devfs_vnodeops' follows non-static declaration > /usr/src/sys/fs/devfs/devfs_vnops.c:114: error: previous declaration of 'devfs_vnodeops' was here > /usr/src/sys/fs/devfs/devfs_vnops.c:1411: error: static declaration of 'devfs_specops' follows non-static declaration > /usr/src/sys/fs/devfs/devfs_vnops.c:115: error: previous declaration of 'devfs_specops' was here > > Apparently, it is not valid C to define something as extern > and then later on static in the same file, like: > > extern struct foo bar; > static struct foo bar = { .... }; Yes. > What do people think of the following patch to fix it? > > http://people.freebsd.org/~rodrigc/devfs_vnops.c.diff.txt Contrary to what Poul-Henning said, in this case it's perfectly legal to use: static struct foo bar; [...] static struct foo bar = { ... }; The first declaration is a tentative definition (it defines the object only if no `real' definition with an initialiser is found), the second declaration defines the object bar. There is only a problem if bar had array type and bar's initialiser was used to define the array size, because then the tentative definition static struct foo bar[]; would be illegal since bar has an incomplete type (6.9.2#3). Stefan From owner-freebsd-current@FreeBSD.ORG Thu May 26 07:33:46 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F3A2216A422 for ; Thu, 26 May 2005 07:33:45 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from fafoe.narf.at (chello213047085026.6.14.vie.surfer.at [213.47.85.26]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0B70643D1D for ; Thu, 26 May 2005 07:33:44 +0000 (GMT) (envelope-from stefan@fafoe.narf.at) Received: from wombat.fafoe.narf.at (wombat.fafoe.narf.at [192.168.1.42]) by fafoe.narf.at (Postfix) with ESMTP id F0E0E4180; Thu, 26 May 2005 09:33:40 +0200 (CEST) Received: by wombat.fafoe.narf.at (Postfix, from userid 1001) id 8E25215D; Thu, 26 May 2005 09:33:39 +0200 (CEST) Date: Thu, 26 May 2005 09:33:39 +0200 From: Stefan Farfeleder To: Poul-Henning Kamp Message-ID: <20050526073335.GN596@wombat.fafoe.narf.at> Mail-Followup-To: Poul-Henning Kamp , Craig Rodrigues , freebsd-current@freebsd.org References: <20050526044824.GA81201@crodrigues.org> <3631.1117085173@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3631.1117085173@critter.freebsd.dk> User-Agent: Mutt/1.5.9i Cc: Craig Rodrigues , freebsd-current@freebsd.org Subject: Re: [GCC 4.0 PATCH] devfs_vnops.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 07:33:46 -0000 On Thu, May 26, 2005 at 07:26:13AM +0200, Poul-Henning Kamp wrote: > In message <20050526044824.GA81201@crodrigues.org>, Craig Rodrigues writes: > > >"If, within a translation unit, the same identifier appears with both > >internal and external linkage, the behavior is undefined." > > > >So, if you have: > > > >extern struct foo bar; > >static struct foo bar = { ..... }; > > Well, the reason is it like that is that you cannot forward > declare a static (at least in the -current GCC) > > static struct foo bar; > [...] > static struct foo bare = { ... }; > > This might be a bug in C. Do you mean the 'warning: redundant redeclaration of ...' warning caused by -Wredundant-decls? Stefan From owner-freebsd-current@FreeBSD.ORG Thu May 26 08:00:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B0C1616A43C for ; Thu, 26 May 2005 08:00:36 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4496243D49 for ; Thu, 26 May 2005 08:00:36 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x535c0e2a.sgnxx1.adsl-dhcp.tele.dk [83.92.14.42]) by pasmtp.tele.dk (Postfix) with ESMTP id 39AE11EC34B for ; Thu, 26 May 2005 10:00:34 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j4Q80KOm004396; Thu, 26 May 2005 10:00:20 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Stefan Farfeleder From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 26 May 2005 09:33:39 +0200." <20050526073335.GN596@wombat.fafoe.narf.at> Date: Thu, 26 May 2005 10:00:20 +0200 Message-ID: <4395.1117094420@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Craig Rodrigues , freebsd-current@freebsd.org Subject: Re: [GCC 4.0 PATCH] devfs_vnops.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 08:00:37 -0000 In message <20050526073335.GN596@wombat.fafoe.narf.at>, Stefan Farfeleder write s: >> >So, if you have: >> > >> >extern struct foo bar; >> >static struct foo bar = { ..... }; >> >> Well, the reason is it like that is that you cannot forward >> declare a static (at least in the -current GCC) >> >> static struct foo bar; >> [...] >> static struct foo bare = { ... }; >> >> This might be a bug in C. > >Do you mean the 'warning: redundant redeclaration of ...' warning caused >by -Wredundant-decls? Can't remember the specific warning, sorry. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu May 26 08:09:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6EB6316A429 for ; Thu, 26 May 2005 08:09:37 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail13.syd.optusnet.com.au (mail13.syd.optusnet.com.au [211.29.132.194]) by mx1.FreeBSD.org (Postfix) with ESMTP id 635E343D55 for ; Thu, 26 May 2005 08:09:34 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mail13.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j4Q89VRE026628 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 26 May 2005 18:09:32 +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 j4Q89URx017254; Thu, 26 May 2005 18:09:30 +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 j4Q89ToI017253; Thu, 26 May 2005 18:09:29 +1000 (EST) (envelope-from pjeremy) Date: Thu, 26 May 2005 18:09:28 +1000 From: Peter Jeremy To: Ted Faber Message-ID: <20050526080928.GE12640@cirb503493.alcatel.com.au> References: <20050526001806.GA1008@pun.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526001806.GA1008@pun.isi.edu> User-Agent: Mutt/1.4.2i Cc: freebsd-current@freebsd.org Subject: Re: hard deadlock(?) on -current; some debugging info, need help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 08:09:37 -0000 On Wed, 2005-May-25 17:18:06 -0700, Ted Faber wrote: >The system slowly grinds to a halt, and the lockup seems to invlove the >disk system. Nothing is waiting on physical I/O, but there are lots of locked vnodes. I notice there's a sh(? - pid 10715) blocked on nfsreq. Can you reproduce the problem without the NFS mounted filesystems? > I have not found a sequence that triggers them (other than >trying to write mail to the list to report them), and I know how >difficult that makes things. It is common to have 2-5 a day. Even when >I can get to the debugger during a lockup, I cannot generate a crash >dump - the kernel reports starting the dump and moves no bytes. Not nice. That suggests something below the filesystem is sick because a filesystem deadlock won't affect the crashdump. >I've attached a dmesg from a -v boot and the kernel config (the dmesg is >not from the lockup run). Last friday when the system locked I had a >digital camera with me and took pictures of the ps output in the hopes >that someone could look at them. These images are at > >http://www.isi.edu/~faber/tmp/deadlock/DSCN04{75,76,77,78,79,80,81,82}.JPG The other information we need is "show lockedvnods". This will hopefully point to the process that started the problem. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Thu May 26 08:58:24 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A557716A421; Thu, 26 May 2005 08:58:24 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id C379143D1D; Thu, 26 May 2005 08:58:21 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j4Q8wH4J076711 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 26 May 2005 10:58:19 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j4Q8vqhs048055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 May 2005 10:57:53 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j4Q8vqNX057510; Thu, 26 May 2005 10:57:52 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j4Q8vpJv057509; Thu, 26 May 2005 10:57:51 +0200 (CEST) (envelope-from ticso) Date: Thu, 26 May 2005 10:57:51 +0200 From: Bernd Walter To: Oliver Lehmann Message-ID: <20050526085750.GZ80082@cicely12.cicely.de> References: <20050525223355.56551.qmail@web80601.mail.yahoo.com> <20050526010325.02415410.lehmann@ans-netz.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526010325.02415410.lehmann@ans-netz.de> X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=no version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0000] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Cc: stable@freebsd.org, Mohan Srinivasan , current@freebsd.org Subject: Re: problems with nfs+TCP - Resource temporarily unavailable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 08:58:24 -0000 On Thu, May 26, 2005 at 01:03:25AM +0200, Oliver Lehmann wrote: > ###### > > > I tried the same with an other nfs server (using dill as nfs server this > time - system description is in my 1st mail, same mount options like / > mnt/files). And guess what? dill rebooted immediate... dd came never > back, gave no output > > dill's dmesg shows me: > > fatal kernel trap: > > trap entry = 0x4 (unaligned access fault) > faulting va = 0xfffffc0006b6f44d > opcode = 0x28 > register = 0x5 > pc = 0xfffffc0000541e08 > ra = 0xfffffc0000541df4 > sp = 0xfffffe000a0f9b70 > usp = 0x11ffea80 > curthread = 0xfffffc000f91ee10 > pid = 343, comm = nfsd This is absolutely known - TCP/nfs has bugs in realigning packets. Don't use TCP on strong aligned architectures. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Thu May 26 09:34:33 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7319016A423 for ; Thu, 26 May 2005 09:34:33 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: from avocado.salatschuessel.net (avocado.salatschuessel.net [83.136.81.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 002EA43D77 for ; Thu, 26 May 2005 09:34:27 +0000 (GMT) (envelope-from lehmann@ans-netz.de) Received: (qmail 48996 invoked by uid 89); 26 May 2005 09:33:40 -0000 Received: from unknown (HELO kartoffel.salatschuessel.net) (83.136.81.185) by avocado.salatschuessel.net with SMTP; 26 May 2005 09:33:40 -0000 Date: Thu, 26 May 2005 11:34:23 +0200 From: Oliver Lehmann To: mohan_srinivasan@yahoo.com Message-Id: <20050526113423.33d56f4f.lehmann@ans-netz.de> In-Reply-To: <20050526010325.02415410.lehmann@ans-netz.de> References: <20050525223355.56551.qmail@web80601.mail.yahoo.com> <20050526010325.02415410.lehmann@ans-netz.de> X-Mailer: Sylpheed version 1.9.11 (GTK+ 2.6.7; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: stable@freebsd.org, current@freebsd.org Subject: Re: problems with nfs+TCP - Resource temporarily unavailable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 09:34:33 -0000 Oliver Lehmann wrote: > Hi Mohan, > > Mohan Srinivasan wrote: > > > > Is this consistently reproducible ? > > it is - everytime I found out that I can reproducible make it work by writing on an other harddisk. file:/mnt/files 151368706 109165638 30093572 78% /mnt/files file:/usr/ports 18162862 8410690 8299144 50% /usr/ports file:/mnt/backups 19324310 17016301 762065 96% /mnt/tmp writing to /mnt/files... we know what happend. But writing to /usr/ports works w/o an error: root@kartoffel olivleh1> umount /usr/ports/ root@kartoffel olivleh1> mount_nfs -T -3 -o soft,bg nudel:/usr/ports /usr/ports root@kartoffel olivleh1> dd if=/usr/tmp.data of=/usr/ports/tmp.data bs=32k 3200+0 records in 3200+0 records out 104857600 bytes transferred in 9.905884 secs (10585385 bytes/sec) root@kartoffel olivleh1> dd if=/usr/tmp.data of=/usr/ports/tmp.data bs=32k 3200+0 records in 3200+0 records out 104857600 bytes transferred in 9.566243 secs (10961210 bytes/sec) root@kartoffel olivleh1> umount /mnt/backups/ root@kartoffel olivleh1> mount_nfs -T -3 -o soft,bg file:/mnt/backups /mnt/backups root@kartoffel olivleh1> dd if=/usr/tmp.data of=/mnt/backups/tmp.data bs=32k dd: /mnt/backups/tmp.data: Resource temporarily unavailable 674+0 records in 673+0 records out 22052864 bytes transferred in 16.141799 secs (1366196 bytes/sec) root@kartoffel olivleh1> dd if=/usr/tmp.data of=/mnt/backups/tmp.data bs=32k dd: /mnt/backups/tmp.data: Resource temporarily unavailable 242+0 records in 241+0 records out 7897088 bytes transferred in 7.301958 secs (1081503 bytes/sec) on file (which is a nickname for nudel) root@nudel olivleh1> df Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/ad0s1a 257838 132236 104976 56% / devfs 1 1 0 100% /dev /dev/ad0s1d 257838 22888 214324 10% /tmp /dev/ad0s1f 18162862 8410690 8299144 50% /usr /dev/ad0s1e 257838 111122 126090 47% /var /dev/ad5s1 151368706 109198438 30060772 78% /mnt/files /dev/ad6s1 19324310 17023989 754377 96% /mnt/backups /dev/da0s1e 4304663 2568753 1391537 65% /mnt/documents ad0: 19092MB [38792/16/63] at ata0-master UDMA33 ad5: 152627MB [310101/16/63] at ata2-slave UDMA100 ad6: 19470MB [39560/16/63] at ata3-master UDMA66 atapci0: port 0xf000-0xf00f,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 7.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 atapci1: port 0x8800-0x880f,0x8400-0x8403, 0x8000-0x8007,0x7c00-0x7c03,0x7800-0x7807 mem 0xe0405000-0xe04050ff irq 16 at device 13.0 on pci0 ata2: channel #0 on atapci1 ata3: channel #1 on atapci1 dmesg shows me no errors neither regarding ad5 nor ata2-master. smartctl shows no recorded errors for ad5 for example. I'm wondering what is wrong with atapci1 Any ideas whats going wrong? -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ From owner-freebsd-current@FreeBSD.ORG Thu May 26 09:45:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7D43E16A420 for ; Thu, 26 May 2005 09:45:11 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from sccrmhc12.comcast.net (sccrmhc12.comcast.net [204.127.202.56]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1EB8443D1D for ; Thu, 26 May 2005 09:45:10 +0000 (GMT) (envelope-from rodrigc@crodrigues.org) Received: from dibbler.crodrigues.org (c-66-30-114-143.hsd1.ma.comcast.net[66.30.114.143]) by comcast.net (sccrmhc12) with ESMTP id <2005052609450901200a181ue>; Thu, 26 May 2005 09:45:10 +0000 Received: from c-66-30-114-143.hsd1.ma.comcast.net (localhost.127.in-addr.arpa [127.0.0.1]) by dibbler.crodrigues.org (8.13.3/8.13.1) with ESMTP id j4Q9jIPE082642; Thu, 26 May 2005 05:45:18 -0400 (EDT) (envelope-from rodrigc@c-66-30-114-143.hsd1.ma.comcast.net) Received: (from rodrigc@localhost) by c-66-30-114-143.hsd1.ma.comcast.net (8.13.3/8.13.1/Submit) id j4Q9jHCv082641; Thu, 26 May 2005 05:45:17 -0400 (EDT) (envelope-from rodrigc) Date: Thu, 26 May 2005 05:45:17 -0400 From: Craig Rodrigues To: freebsd-current@freebsd.org Message-ID: <20050526094517.GA82579@crodrigues.org> References: <20050526020143.GA80396@crodrigues.org> <20050526072801.GM596@wombat.fafoe.narf.at> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526072801.GM596@wombat.fafoe.narf.at> User-Agent: Mutt/1.5.9i Cc: Stefan Farfeleder Subject: Re: [GCC 4.0 PATCH] devfs_vnops.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 09:45:11 -0000 On Thu, May 26, 2005 at 09:28:02AM +0200, Stefan Farfeleder wrote: > > What do people think of the following patch to fix it? > > > > http://people.freebsd.org/~rodrigc/devfs_vnops.c.diff.txt > > Contrary to what Poul-Henning said, in this case it's perfectly legal to > use: > > static struct foo bar; > [...] > static struct foo bar = { ... }; If I change the code in devfs_vnops.c as follows: --- devfs_vnops.c.orig Wed May 25 19:58:21 2005 +++ devfs_vnops.c Thu May 26 05:34:08 2005 @@ -111,8 +111,8 @@ #endif static vop_symlink_t devfs_symlink; -extern struct vop_vector devfs_vnodeops; -extern struct vop_vector devfs_specops; +static struct vop_vector devfs_vnodeops; +static struct vop_vector devfs_specops; static u_int devfs_random(void) Then I get this compiler warning with gcc 4.0: cc1: warnings being treated as errors /usr/src/sys/fs/devfs/devfs_vnops.c:1389: warning: redundant redeclaration of 'devfs_vnodeops' /usr/src/sys/fs/devfs/devfs_vnops.c:114: warning: previous declaration of 'devfs_vnodeops' was here /usr/src/sys/fs/devfs/devfs_vnops.c:1411: warning: redundant redeclaration of 'devfs_specops' /usr/src/sys/fs/devfs/devfs_vnops.c:115: warning: previous declaration of 'devfs_specops' was here So, with that in mind, is there any objection to the patch at: http://people.freebsd.org/~rodrigc/devfs_vnops.c.diff.txt It moves things around, but I can compile with no warnings or errors with GCC 4.0. -- Craig Rodrigues rodrigc@crodrigues.org From owner-freebsd-current@FreeBSD.ORG Thu May 26 10:06:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E486C16A41C for ; Thu, 26 May 2005 10:06:11 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from pasmtp.tele.dk (pasmtp.tele.dk [193.162.159.95]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65DB543D1F for ; Thu, 26 May 2005 10:06:11 +0000 (GMT) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (0x535c0e2a.sgnxx1.adsl-dhcp.tele.dk [83.92.14.42]) by pasmtp.tele.dk (Postfix) with ESMTP id 3CF271EC320 for ; Thu, 26 May 2005 12:06:10 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.3/8.13.3) with ESMTP id j4QA5twe005697; Thu, 26 May 2005 12:05:56 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Craig Rodrigues From: "Poul-Henning Kamp" In-Reply-To: Your message of "Thu, 26 May 2005 05:45:17 EDT." <20050526094517.GA82579@crodrigues.org> Date: Thu, 26 May 2005 12:05:55 +0200 Message-ID: <5696.1117101955@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: Stefan Farfeleder , freebsd-current@freebsd.org Subject: Re: [GCC 4.0 PATCH] devfs_vnops.c X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 10:06:12 -0000 In message <20050526094517.GA82579@crodrigues.org>, Craig Rodrigues writes: >So, with that in mind, is there any objection to the patch at: > >http://people.freebsd.org/~rodrigc/devfs_vnops.c.diff.txt > >It moves things around, but I can compile with no warnings or errors with >GCC 4.0. That's ok with me... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. From owner-freebsd-current@FreeBSD.ORG Thu May 26 10:45:54 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BDAFF16A41F; Thu, 26 May 2005 10:45:54 +0000 (GMT) (envelope-from sten@blinkenlights.nl) Received: from ford.blinkenlights.nl (ford.blinkenlights.nl [213.204.211.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 184B743D5D; Thu, 26 May 2005 10:45:51 +0000 (GMT) (envelope-from sten@blinkenlights.nl) Received: from tea.blinkenlights.nl (tea.blinkenlights.nl [IPv6:2001:960:301:3:a00:20ff:fe85:fa39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ford.blinkenlights.nl (Postfix) with ESMTP id AC8063F294; Thu, 26 May 2005 12:45:50 +0200 (CEST) Received: by tea.blinkenlights.nl (Postfix, from userid 101) id 4169E23B; Thu, 26 May 2005 12:45:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tea.blinkenlights.nl (Postfix) with ESMTP id 2CF22E7; Thu, 26 May 2005 12:45:50 +0200 (CEST) Date: Thu, 26 May 2005 12:45:50 +0200 (CEST) From: Sten Spans To: ticso@cicely.de In-Reply-To: <20050526085750.GZ80082@cicely12.cicely.de> Message-ID: References: <20050525223355.56551.qmail@web80601.mail.yahoo.com> <20050526010325.02415410.lehmann@ans-netz.de> <20050526085750.GZ80082@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, stable@freebsd.org, Oliver Lehmann , Mohan Srinivasan Subject: Re: problems with nfs+TCP - Resource temporarily unavailable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 10:45:54 -0000 On Thu, 26 May 2005, Bernd Walter wrote: > On Thu, May 26, 2005 at 01:03:25AM +0200, Oliver Lehmann wrote: >> ###### >> >> >> I tried the same with an other nfs server (using dill as nfs server this >> time - system description is in my 1st mail, same mount options like / >> mnt/files). And guess what? dill rebooted immediate... dd came never >> back, gave no output >> >> dill's dmesg shows me: >> >> fatal kernel trap: >> >> trap entry = 0x4 (unaligned access fault) >> faulting va = 0xfffffc0006b6f44d >> opcode = 0x28 >> register = 0x5 >> pc = 0xfffffc0000541e08 >> ra = 0xfffffc0000541df4 >> sp = 0xfffffe000a0f9b70 >> usp = 0x11ffea80 >> curthread = 0xfffffc000f91ee10 >> pid = 343, comm = nfsd > > This is absolutely known - TCP/nfs has bugs in realigning packets. > Don't use TCP on strong aligned architectures. Still a pr with a proper backtrace would be nice. Or does one exist already ? -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem From owner-freebsd-current@FreeBSD.ORG Thu May 26 10:58:34 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C1AF916A434; Thu, 26 May 2005 10:58:34 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4243243D5E; Thu, 26 May 2005 10:58:30 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j4QAwL4J080114 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 26 May 2005 12:58:22 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j4QAw7hs048762 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 May 2005 12:58:08 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j4QAw7gR058039; Thu, 26 May 2005 12:58:07 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j4QAw6Xb058038; Thu, 26 May 2005 12:58:06 +0200 (CEST) (envelope-from ticso) Date: Thu, 26 May 2005 12:58:06 +0200 From: Bernd Walter To: Sten Spans Message-ID: <20050526105806.GB80082@cicely12.cicely.de> References: <20050525223355.56551.qmail@web80601.mail.yahoo.com> <20050526010325.02415410.lehmann@ans-netz.de> <20050526085750.GZ80082@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-4.9 required=3.0 tests=BAYES_00 autolearn=no version=2.64 X-Spam-Report: * -4.9 BAYES_00 BODY: Bayesian spam probability is 0 to 1% * [score: 0.0098] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Cc: current@freebsd.org, Mohan Srinivasan , stable@freebsd.org, ticso@cicely.de, Oliver Lehmann Subject: Re: problems with nfs+TCP - Resource temporarily unavailable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 10:58:35 -0000 On Thu, May 26, 2005 at 12:45:50PM +0200, Sten Spans wrote: > On Thu, 26 May 2005, Bernd Walter wrote: > > >On Thu, May 26, 2005 at 01:03:25AM +0200, Oliver Lehmann wrote: > >>###### > >> > >> > >>I tried the same with an other nfs server (using dill as nfs server this > >>time - system description is in my 1st mail, same mount options like / > >>mnt/files). And guess what? dill rebooted immediate... dd came never > >>back, gave no output > >> > >>dill's dmesg shows me: > >> > >>fatal kernel trap: > >> > >> trap entry = 0x4 (unaligned access fault) > >> faulting va = 0xfffffc0006b6f44d > >> opcode = 0x28 > >> register = 0x5 > >> pc = 0xfffffc0000541e08 > >> ra = 0xfffffc0000541df4 > >> sp = 0xfffffe000a0f9b70 > >> usp = 0x11ffea80 > >> curthread = 0xfffffc000f91ee10 > >> pid = 343, comm = nfsd > > > >This is absolutely known - TCP/nfs has bugs in realigning packets. > >Don't use TCP on strong aligned architectures. > > Still a pr with a proper backtrace would be nice. > Or does one exist already ? Not that I know. I did know exactly when this happens years ago. The backtrace as such will not help you as the panic happens much later than the cause. IIRC the basic problem was that the realignment code only fixes a single missalignment, while theres a chance for more then one. Verify nfs_realign in nfsserver and nfsclient to get an idea. If you are interested - I've found a (non-working) patch that I wrote for it, but the intention of it should be clear. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Thu May 26 12:08:05 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 28BB416A41C; Thu, 26 May 2005 12:08:05 +0000 (GMT) (envelope-from conrads@cox.net) Received: from lakermmtao03.cox.net (lakermmtao03.cox.net [68.230.240.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6957243D48; Thu, 26 May 2005 12:08:04 +0000 (GMT) (envelope-from conrads@cox.net) Received: from dolphin.local.net ([68.11.70.216]) by lakermmtao03.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050526120801.MZSP18229.lakermmtao03.cox.net@dolphin.local.net>; Thu, 26 May 2005 08:08:01 -0400 Received: from dolphin.local.net (localhost.local.net [IPv6:::1]) by dolphin.local.net (8.13.3/8.13.3) with ESMTP id j4QC822E006432; Thu, 26 May 2005 07:08:02 -0500 (CDT) (envelope-from conrads@cox.net) Date: Thu, 26 May 2005 07:07:57 -0500 From: "Conrad J. Sabatier" To: =?ISO-8859-1?Q?S=F8ren?= Schmidt Message-ID: <20050526070757.7df71fad@dolphin.local.net> In-Reply-To: <07005604-836F-48E0-AC46-9CC80BF19BD5@freebsd.org> References: <17042.43345.594850.534649@canoe.dclg.ca> <20050524002925.2f05fc55@dolphin.local.net> <1FA05BA9-15DF-496B-95AE-664815096717@FreeBSD.org> <20050524190311.711870aa@dolphin.local.net> <07005604-836F-48E0-AC46-9CC80BF19BD5@freebsd.org> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; amd64-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org, David Gilbert Subject: Re: 3 things working in -STABLE and not in -CURRENT X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 12:08:05 -0000 On Wed, 25 May 2005 08:32:34 +0200, S=F8ren Schmidt wrote: >=20 > On 25/05/2005, at 2:03, Conrad J. Sabatier wrote: > > > > I've tried your suggestion, enabling/disabling each device (in the =20 > > BIOS) and rebooting. I even completely disconnected the power to > > the box for a minute, just in case something had gotten "stuck" in > > some weird state. But no matter what I do, even with the ata1-slave > > device marked as "Not installed" in the BIOS, it keeps getting > > configured as acd0. >=20 > I told you to try *physically* disconnecting each drive and boot with=20 > that, fiddling the BIOS doesn't do anything but keep the device out =20 > of the BIOS tables. Then boot with each device verbosely and send me =20 > the boot logs / dmesg. Ah, my misunderstanding. I'll try doing that, probably in a few more days, when I have some free time. > > Is there any way to gather some more verbose diagnostics, besides a > > simple "boot -v"? So far, atacontrol and pciconf haven't proved to > > be very useful at all. Are there any other tools, in the base > > system or in ports, that may shed some more light on what's > > happening here? >=20 > The tools are make, gcc etc and are in the base system :) > You need to instrument the code and figure out what's going on during=20 > the probe. > Thats why its very handy to have hands on the HW when doing debugging=20 > of such issues. OK, but I really have no idea what more I could do with the actual code, to be honest. > > I think for now I may just revert to RELENG_5 and see what happens. > > The irony of the situation is that I had only just recently really > > started "getting into" using my DVD drive, and it really hurts now =20 > > to be without it. :-( > > > > I do hope this problem will not continue to plague me through future > > FreeBSD releases. If so, that may leave me no choice but to switch > > to another OS entirely, which I would *really* hate to have to do, > > as I've been using FreeBSD for nine years now, and have really come > > to love it. > > > > Switching to a whole new OS at this point (even another BSD) would > > not only sadden me greatly, but I downright shudder at the prospect > > of having to come to grips with what I could only rightly consider > > an inferior platform, as FreeBSD is definitely the best in my book. >=20 > How should I interpret that exactly ? > If you have been using FreeBSD for 9 years you must have been =20 > suffering a lot worse problems than this.. True, and they did eventually get resolved, some not nearly as quickly as I would have liked, though, of course. :-) > And BTW I don't react well to threats if that was the purpose :) No, it wasn't meant as a threat, just as a simple statement of reality.=20 If I can't get these devices to work properly anymore as FreeBSD continues to evolve, I just may be forced to try some alternatives, that's all. In fact, adding this to the long-standing non-existent MIDI support only increases the likelihood of my being forced to seek out some other alternative. That's not a threat, either, just a simple statement of my increasing frustration and diminishing patience with FreeBSD's lack of hardware support in certain areas that are very important to me (namely, MIDI). I'm not ready to "throw in the towel" just yet. We'll see what I can dig up in a few days. I'll let you know. Thanks for your patience and understanding. Conrad --=20 Conrad J. Sabatier -- "In Unix veritas" From owner-freebsd-current@FreeBSD.ORG Thu May 26 12:12:18 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BBAB316A43C; Thu, 26 May 2005 12:12:18 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5396043D5D; Thu, 26 May 2005 12:12:15 +0000 (GMT) (envelope-from avg@icyb.net.ua) Received: from [212.40.38.87] (oddity-e.topspin.kiev.ua [212.40.38.87]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id PAA25760; Thu, 26 May 2005 15:12:13 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <4295BD1C.6020507@icyb.net.ua> Date: Thu, 26 May 2005 15:12:12 +0300 From: Andriy Gapon User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050328) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-stable@freebsd.org, freebsd-current@freebsd.org References: <428C6489.3040609@icyb.net.ua> <429206BB.2050409@icyb.net.ua> In-Reply-To: <429206BB.2050409@icyb.net.ua> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Subject: Re: ad and da do not set interface type in devstat entry [Was: acd lacks devstat] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 12:12:19 -0000 On a devstat+disks related note: I see that (scsi) cd device driver pre-creates devstat entry before calling geom disk_create() and sets device type to DEVSTAT_TYPE_CDROM|DEVSTAT_TYPE_IF_SCSI, which is perfect IMHO. On the other hand, da and ad drivers rely on disk_create() to create a devstat entry and it is created with device type DEVSTAT_TYPE_DIRECT, which is not incorrect but is not complete either: iostat -d -t SCSI or iostat -d -t IDE wouldn't show any ad or da devices, only cd. Btw, I have file a PR for acd not having devstat support: http://www.freebsd.org/cgi/query-pr.cgi?pr=81496 -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Thu May 26 12:37:41 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4A07016A41F; Thu, 26 May 2005 12:37:41 +0000 (GMT) (envelope-from sten@blinkenlights.nl) Received: from ford.blinkenlights.nl (ford.blinkenlights.nl [213.204.211.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 114FC43D58; Thu, 26 May 2005 12:37:36 +0000 (GMT) (envelope-from sten@blinkenlights.nl) Received: from tea.blinkenlights.nl (tea.blinkenlights.nl [192.168.1.21]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ford.blinkenlights.nl (Postfix) with ESMTP id E42703F294; Thu, 26 May 2005 14:37:35 +0200 (CEST) Received: by tea.blinkenlights.nl (Postfix, from userid 101) id 763B323B; Thu, 26 May 2005 14:37:35 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by tea.blinkenlights.nl (Postfix) with ESMTP id 5C3BDE7; Thu, 26 May 2005 14:37:35 +0200 (CEST) Date: Thu, 26 May 2005 14:37:35 +0200 (CEST) From: Sten Spans To: ticso@cicely.de In-Reply-To: <20050526105806.GB80082@cicely12.cicely.de> Message-ID: References: <20050525223355.56551.qmail@web80601.mail.yahoo.com> <20050526010325.02415410.lehmann@ans-netz.de> <20050526085750.GZ80082@cicely12.cicely.de> <20050526105806.GB80082@cicely12.cicely.de> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: current@freebsd.org, stable@freebsd.org, Oliver Lehmann , Mohan Srinivasan Subject: Re: problems with nfs+TCP - Resource temporarily unavailable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 12:37:41 -0000 On Thu, 26 May 2005, Bernd Walter wrote: >>> >>> This is absolutely known - TCP/nfs has bugs in realigning packets. >>> Don't use TCP on strong aligned architectures. >> >> Still a pr with a proper backtrace would be nice. >> Or does one exist already ? > > Not that I know. > I did know exactly when this happens years ago. > The backtrace as such will not help you as the panic happens much > later than the cause. > IIRC the basic problem was that the realignment code only fixes > a single missalignment, while theres a chance for more then one. > Verify nfs_realign in nfsserver and nfsclient to get an idea. > If you are interested - I've found a (non-working) patch that I wrote > for it, but the intention of it should be clear. > Sure. This is an nfsd specific problem, Or does nfsclient have issues as well ? I'll get a pr going to make sure that the issue is documented, and possibly narrowed down enough for other people to start painting a bikeshed about how it should be fixed. -- Sten Spans "There is a crack in everything, that's how the light gets in." Leonard Cohen - Anthem From owner-freebsd-current@FreeBSD.ORG Thu May 26 12:38:53 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 041B716A41C; Thu, 26 May 2005 12:38:53 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout04.sul.t-online.com (mailout04.sul.t-online.com [194.25.134.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6509643D49; Thu, 26 May 2005 12:38:51 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd29.aul.t-online.de by mailout04.sul.t-online.com with smtp id 1DbHdS-0001fd-01; Thu, 26 May 2005 14:38:50 +0200 Received: from Andro-Beta.Leidinger.net (Ze8Z7yZpoenB4dHWr7WJgQRqKqD1lEXyZnhGmrhL4hPrzwwenZSYsS@[84.165.249.17]) by fwd29.sul.t-online.de with esmtp id 1DbHdI-1rmgm80; Thu, 26 May 2005 14:38:40 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j4QCca6p054800; Thu, 26 May 2005 14:38:37 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Thu, 26 May 2005 14:38:36 +0200 From: Alexander Leidinger To: current@freebsd.org, sos@freebsd.org Message-ID: <20050526143836.0bf9dc5a@Magellan.Leidinger.net> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: Ze8Z7yZpoenB4dHWr7WJgQRqKqD1lEXyZnhGmrhL4hPrzwwenZSYsS@t-dialin.net X-TOI-MSGID: 4f203388-110e-42ef-8176-4a557ab6044b Cc: Subject: ATA as modules -> panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 12:38:53 -0000 Hi, I've tried to remove the ata code from my kernel config and to load it as a module (loading ata and atadisk from loader.conf). When I do this in my (ata-only) systems I get a panic at boot. Loading atapicd or atapicam as a module (having ata and atadisk in the kernel) works for me. Is this known or do I need to send a backtrace? Bye, Alexander. -- Where do you think you're going today? http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Thu May 26 12:52:51 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A8ED016A423; Thu, 26 May 2005 12:52:51 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E0BB43D90; Thu, 26 May 2005 12:52:39 +0000 (GMT) (envelope-from ticso@cicely12.cicely.de) Received: from cicely5.cicely.de (cicely5.cicely.de [10.1.1.7]) (authenticated bits=0) by srv1.cosmo-project.de (8.12.10/8.12.10) with ESMTP id j4QCqL4J084123 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Thu, 26 May 2005 14:52:23 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (cicely12.cicely.de [IPv6:3ffe:400:8d0:301::12]) by cicely5.cicely.de (8.12.10/8.12.10) with ESMTP id j4QCpuhs049385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 26 May 2005 14:51:56 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: from cicely12.cicely.de (localhost [127.0.0.1]) by cicely12.cicely.de (8.12.11/8.12.11) with ESMTP id j4QCptLB058589; Thu, 26 May 2005 14:51:55 +0200 (CEST) (envelope-from ticso@cicely12.cicely.de) Received: (from ticso@localhost) by cicely12.cicely.de (8.12.11/8.12.11/Submit) id j4QCpt08058588; Thu, 26 May 2005 14:51:55 +0200 (CEST) (envelope-from ticso) Date: Thu, 26 May 2005 14:51:55 +0200 From: Bernd Walter To: Sten Spans Message-ID: <20050526125154.GC80082@cicely12.cicely.de> References: <20050525223355.56551.qmail@web80601.mail.yahoo.com> <20050526010325.02415410.lehmann@ans-netz.de> <20050526085750.GZ80082@cicely12.cicely.de> <20050526105806.GB80082@cicely12.cicely.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely12.cicely.de 5.2-CURRENT alpha User-Agent: Mutt/1.5.6i X-Spam-Status: No, hits=-1.4 required=3.0 tests=BAYES_20 autolearn=no version=2.64 X-Spam-Report: * -1.4 BAYES_20 BODY: Bayesian spam probability is 20 to 30% * [score: 0.2041] X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on cicely12.cicely.de Cc: current@freebsd.org, Mohan Srinivasan , stable@freebsd.org, ticso@cicely.de, Oliver Lehmann Subject: Re: problems with nfs+TCP - Resource temporarily unavailable X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 12:52:51 -0000 On Thu, May 26, 2005 at 02:37:35PM +0200, Sten Spans wrote: > On Thu, 26 May 2005, Bernd Walter wrote: > > >>> > >>>This is absolutely known - TCP/nfs has bugs in realigning packets. > >>>Don't use TCP on strong aligned architectures. > >> > >>Still a pr with a proper backtrace would be nice. > >>Or does one exist already ? > > > >Not that I know. > >I did know exactly when this happens years ago. > >The backtrace as such will not help you as the panic happens much > >later than the cause. > >IIRC the basic problem was that the realignment code only fixes > >a single missalignment, while theres a chance for more then one. > >Verify nfs_realign in nfsserver and nfsclient to get an idea. > >If you are interested - I've found a (non-working) patch that I wrote > >for it, but the intention of it should be clear. > > > > Sure. This is an nfsd specific problem, > Or does nfsclient have issues as well ? The code is the same in client and server - as well as the risk to get packets in that form from network. > I'll get a pr going to make sure that the issue > is documented, and possibly narrowed down enough for > other people to start painting a bikeshed about how > it should be fixed. OK. -- B.Walter BWCT http://www.bwct.de bernd@bwct.de info@bwct.de From owner-freebsd-current@FreeBSD.ORG Thu May 26 13:34:16 2005 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E88F916A41F; Thu, 26 May 2005 13:34:16 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout10.sul.t-online.com (mailout10.sul.t-online.com [194.25.134.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88D4443D1D; Thu, 26 May 2005 13:34:16 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd16.aul.t-online.de by mailout10.sul.t-online.com with smtp id 1DbIV4-0008HA-00; Thu, 26 May 2005 15:34:14 +0200 Received: from Andro-Beta.Leidinger.net (S8Bb34Z6reO4eQclKN92KbpWRW+B3Qf9CUckERDd5VF49MNc-5aygJ@[84.165.249.17]) by fwd16.sul.t-online.de with esmtp id 1DbIUz-1CyIjI0; Thu, 26 May 2005 15:34:09 +0200 Received: from Magellan.Leidinger.net (Magellan.Leidinger.net [192.168.1.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j4QDY8Oa062620; Thu, 26 May 2005 15:34:09 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Thu, 26 May 2005 15:34:08 +0200 From: Alexander Leidinger To: "Andreas Heijdendael" Message-ID: <20050526153408.793d1d7d@Magellan.Leidinger.net> In-Reply-To: <001a01c561f1$db6c5610$04a8a8c0@windows> References: <20050526143836.0bf9dc5a@Magellan.Leidinger.net> <001a01c561f1$db6c5610$04a8a8c0@windows> X-Mailer: Sylpheed-Claws 1.0.4a (GTK+ 1.2.10; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: S8Bb34Z6reO4eQclKN92KbpWRW+B3Qf9CUckERDd5VF49MNc-5aygJ@t-dialin.net X-TOI-MSGID: fe134df6-7c49-4983-bac8-d2ae48bd0a6d Cc: current@freebsd.org, sos@freebsd.org Subject: Re: ATA as modules -> panic X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 13:34:17 -0000 On Thu, 26 May 2005 14:53:03 +0200 "Andreas Heijdendael" wrote: > Why would you want to remove the ata device from the kernel config in the > first place? Because I don't need it twice (as a module and in the kernel itself). > Seems to me a bit like you're removing the wheels from a car just before you > want to get onto the road. No, I'm loading it as a module instead. It's more like putting everything into the trunk before I get onto the road instead of always having everything in it. But this is a bad metaphor too, since I don't change the hardware that much that I _have_ to remove the ata code, it's just that it is possible (at least it looks like it should be possible) and I want to try this out. > Shouldn't the kernel be able to access the file system in order to even > remotely read the loader.conf file? > Removing the ata device from the kernel would prohibit this. Correct me if > I'm wrong there. The loader works independent from the kernel. So removing the ata code, or anything at all, from the kernel doesn't change the way the loader behaves. Bye, Alexander. -- It is easier to fix Unix than to live with NT. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 From owner-freebsd-current@FreeBSD.ORG Thu May 26 13:54:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4C4F016A438 for ; Thu, 26 May 2005 13:54:56 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 01FE643D1D for ; Thu, 26 May 2005 13:54:54 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j4QDsr4B077630 for ; Thu, 26 May 2005 08:54:53 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <4295D51F.50106@centtech.com> Date: Thu, 26 May 2005 08:54:39 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050504 X-Accept-Language: en-us, en MIME-Version: 1.0 To: FreeBSD Current Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/894/Wed May 25 07:53:16 2005 on mh1.centtech.com X-Virus-Status: Clean Subject: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 13:54:56 -0000 Is it possible to disable all read and write caching to a disk? I'm playing with the ever so dangerous multiple hosts mounting (rw and/or ro) the same filesystem over fiber channel. Also - what exactly are the issues with forcing an unclean filesystem to mount rw? I know you could (will?) have data corruption, but on which data? Only data that has not been synced to disk? Any random amount of data? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu May 26 16:08:47 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8968316A41C for ; Thu, 26 May 2005 16:08:47 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D98443D1D for ; Thu, 26 May 2005 16:08:47 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j4QG8kot006914; Thu, 26 May 2005 09:08:46 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j4QG8kQT006913; Thu, 26 May 2005 09:08:46 -0700 (PDT) (envelope-from faber) Date: Thu, 26 May 2005 09:08:46 -0700 From: Ted Faber To: Peter Jeremy Message-ID: <20050526160846.GA6851@pun.isi.edu> References: <20050526001806.GA1008@pun.isi.edu> <20050526080928.GE12640@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb" Content-Disposition: inline In-Reply-To: <20050526080928.GE12640@cirb503493.alcatel.com.au> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Cc: freebsd-current@freebsd.org Subject: Re: hard deadlock(?) on -current; some debugging info, need help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 16:08:47 -0000 --VS++wcV0S1rZb1Fb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, May 26, 2005 at 06:09:28PM +1000, Peter Jeremy wrote: > On Wed, 2005-May-25 17:18:06 -0700, Ted Faber wrote: > >The system slowly grinds to a halt, and the lockup seems to invlove the > >disk system. > > Nothing is waiting on physical I/O, but there are lots of locked vnodes. > I notice there's a sh(? - pid 10715) blocked on nfsreq. Can you reproduce > the problem without the NFS mounted filesystems? I have a laptop on the same network that uses NFS much less aggressively and it has never locked up. I understand that's anecdotal. It's pretty hard to reconfigure the desktop into a position where I get work done and don't use NFS here. > > > I have not found a sequence that triggers them (other than > >trying to write mail to the list to report them), and I know how > >difficult that makes things. It is common to have 2-5 a day. Even when > > >I can get to the debugger during a lockup, I cannot generate a crash > >dump - the kernel reports starting the dump and moves no bytes. > > Not nice. That suggests something below the filesystem is sick > because a filesystem deadlock won't affect the crashdump. I've let it sit a few minutes. I'll try it again next lockup, just in case. I've just typed "panic" from the debugger. If there's a better way, please let me know. > > >I've attached a dmesg from a -v boot and the kernel config (the dmesg is > >not from the lockup run). Last friday when the system locked I had a > >digital camera with me and took pictures of the ps output in the hopes > >that someone could look at them. These images are at > > > >http://www.isi.edu/~faber/tmp/deadlock/DSCN04{75,76,77,78,79,80,81,82}.JPG > > The other information we need is "show lockedvnods". This will hopefully > point to the process that started the problem. Next lockup I'll get it. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --VS++wcV0S1rZb1Fb Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFClfSOaUz3f+Zf+XsRAgnaAJ9K9L7nSPPs8N4tt0DwjPzxA2ilHACg99rn MbKS77iwXP5EWJ39haXbsjg= =IBOv -----END PGP SIGNATURE----- --VS++wcV0S1rZb1Fb-- From owner-freebsd-current@FreeBSD.ORG Thu May 26 17:27:51 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2FF0516A41C for ; Thu, 26 May 2005 17:27:51 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from mail.efacilitas.de (efacilitas.de [213.133.110.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C2FF43D55 for ; Thu, 26 May 2005 17:27:50 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-37-137.dynamic.qsc.de [212.202.37.137]) by mail.efacilitas.de (Postfix) with ESMTP id 019D012397E; Thu, 26 May 2005 19:26:24 +0200 (CEST) Received: from localhost (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id EE1D012B09E; Thu, 26 May 2005 19:26:56 +0200 (CEST) Received: from eurystheus.local ([192.168.1.67]) by localhost (eurystheus.locaL [192.168.1.67]) (amavisd-new, port 10024) with ESMTP id 35653-07; Thu, 26 May 2005 19:26:50 +0200 (CEST) Received: from [192.168.1.67] (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id 0999012B09A; Thu, 26 May 2005 19:26:50 +0200 (CEST) Message-ID: <429606D9.6080602@cs.tu-berlin.de> Date: Thu, 26 May 2005 19:26:49 +0200 From: Bjoern Koenig User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050517 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <4295D51F.50106@centtech.com> In-Reply-To: <4295D51F.50106@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at example.com Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 17:27:51 -0000 Eric Anderson wrote: > Is it possible to disable all read and write caching to a disk? You can disable write the cache by adding the line hw.ata.wc="0" to /boot/loader.conf. I'm not sure if there are methods to disable the read cache of the hard disk drive. I can't imagine that the read cache is relevant concerning file system consistency. You can mount partitions that I/O will done synchronously by adding the option 'sync' to fstab. > Also - what exactly are the issues with forcing an unclean filesystem to > mount rw? I know you could (will?) have data corruption, but on which > data? Only data that has not been synced to disk? Any random amount of > data? If you use soft updates, then you will notice that some files disappear. This is not corruption, but rather a loss. In theory you won't have corruption under certain circumstances, practically it's a controversial issue. My machine crashes around three or four times a week for the last four month and I still don't have serious problems with the filesystem consistency. Read more about soft updates in the handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-disk.html#SOFT-UPDATES There are some discussions about this topic in the mailing list archive. Regards Björn From owner-freebsd-current@FreeBSD.ORG Thu May 26 17:30:16 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CC1E816A41C for ; Thu, 26 May 2005 17:30:16 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A339A43D4C for ; Thu, 26 May 2005 17:30:16 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 6C9D272DD9; Thu, 26 May 2005 10:30:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 6A5EE72DD4; Thu, 26 May 2005 10:30:16 -0700 (PDT) Date: Thu, 26 May 2005 10:30:16 -0700 (PDT) From: Doug White To: Jens Schweikhardt In-Reply-To: <20050523210141.GA779@schweikhardt.net> Message-ID: <20050526102606.T69716@carver.gumbysoft.com> References: <20050516113420.GA786@schweikhardt.net> <20050518150346.S87264@carver.gumbysoft.com> <20050519190129.GA1048@schweikhardt.net> <20050520122944.B8229@carver.gumbysoft.com> <20050521092857.GA847@schweikhardt.net> <20050522112845.S27009@carver.gumbysoft.com> <20050523175609.GA779@schweikhardt.net> <20050523210141.GA779@schweikhardt.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: Timekeeping hosed by factor 3, high lapic[01] interrupt rates X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 17:30:17 -0000 On Mon, 23 May 2005, Jens Schweikhardt wrote: > ... > # # 3. Backout rev 1.218 of src/sys/i386/isa/clock.c so the irq0 interrupt > # # handler is reactivated and the RTC fiddled. > # > # Will do so next. I've nailed the change between March 6 and March 30. > # 1.218 is from 2005/03/24 21:34:16, which would fit. > > We have a winner. Backing out 1.218 from a 2005/03/24 system does the trick, > as well as a CURRENT without 1.218 (but 1.219-220 in there) bring back irq0 > and time dilation is gone. All clocks work correctly. Hm ... not sure what part of that commit is the bad part. You might try changing if (!using_lapic_timer) { to if(1) { in the most recent rev of clock.c to register irq0 again. If that doesn't chang ethe dialation then something else in the system must be depending on the RTC periodic interrupt. > Now the question is: what is so special in my system so that I appear > to be the only one to notice the problem? Good question. What CPUs do you have in that machine again? Copy out the 'CPU' and related lines from dmesg. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu May 26 17:37:31 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2C87416A41F; Thu, 26 May 2005 17:37:31 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0838D43D58; Thu, 26 May 2005 17:37:30 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id AB05772DD4; Thu, 26 May 2005 10:37:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id A63F272DCB; Thu, 26 May 2005 10:37:30 -0700 (PDT) Date: Thu, 26 May 2005 10:37:30 -0700 (PDT) From: Doug White To: Gleb Smirnoff In-Reply-To: <20050524025730.GC61461@cell.sick.ru> Message-ID: <20050526103616.V69716@carver.gumbysoft.com> References: <20050522135915.6117ef26@Magellan.Leidinger.net> <20050524025730.GC61461@cell.sick.ru> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Alexander Leidinger , current@FreeBSD.org Subject: Re: wrong link state change message from vr0 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 17:37:31 -0000 On Tue, 24 May 2005, Gleb Smirnoff wrote: > Alexander, > > On Sun, May 22, 2005 at 01:59:15PM +0200, Alexander Leidinger wrote: > A> I get a "vr0: link state changed to DOWN" when it should be a UP-message > A> (kernel as of May 2). I want to fix this, but don't know what part of > A> the source is responsible and how it should look like. Can someone > A> please give me a hint? > > AFAIK, Bill has already fixed this. > > The code is at if_vr.c, in calls to if_link_state_change(). He hasn't committed it yet, then; last commit for src/sys/pci/if_vr.c was 2 1/2 months ago. wpaul hasnt' commited to it in over 3 years. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu May 26 17:40:42 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B5CF516A41C for ; Thu, 26 May 2005 17:40:42 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4DF1943D4C for ; Thu, 26 May 2005 17:40:41 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j4QHeXGM053685; Thu, 26 May 2005 12:40:34 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42960A03.6020001@centtech.com> Date: Thu, 26 May 2005 12:40:19 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050504 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bjoern Koenig References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> In-Reply-To: <429606D9.6080602@cs.tu-berlin.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 17:40:42 -0000 Bjoern Koenig wrote: > Eric Anderson wrote: > >> Is it possible to disable all read and write caching to a disk? > > > You can disable write the cache by adding the line > > hw.ata.wc="0" That appears to be for ata devices only, correct? I'm using fiber channel so it's scsi-like. > to /boot/loader.conf. I'm not sure if there are methods to disable the > read cache of the hard disk drive. I can't imagine that the read cache > is relevant concerning file system consistency. Host A has filesystem mounted rw, host B has it mounted ro. If host A makes changes, host B cannot see them without unmounting and remounting ro. I wanted to find out if it was a read caching issue on host B. > You can mount partitions that I/O will done synchronously by adding the > option 'sync' to fstab. I've tried this. I'm not sure if it made any difference. >> Also - what exactly are the issues with forcing an unclean filesystem >> to mount rw? I know you could (will?) have data corruption, but on >> which data? Only data that has not been synced to disk? Any random >> amount of data? > > > If you use soft updates, then you will notice that some files disappear. > This is not corruption, but rather a loss. In theory you won't have > corruption under certain circumstances, practically it's a controversial > issue. I've turned off softupdates to minimize my variables. > My machine crashes around three or four times a week for the last four > month and I still don't have serious problems with the filesystem > consistency. > > Read more about soft updates in the handbook: > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/configtuning-disk.html#SOFT-UPDATES > > > There are some discussions about this topic in the mailing list archive. I'll look again.. Thanks Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu May 26 17:44:40 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 346E016A41F for ; Thu, 26 May 2005 17:44:38 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from mail.efacilitas.de (efacilitas.de [213.133.110.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE8FB43D58 for ; Thu, 26 May 2005 17:44:37 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-37-137.dynamic.qsc.de [212.202.37.137]) by mail.efacilitas.de (Postfix) with ESMTP id B9D3212397E; Thu, 26 May 2005 19:43:12 +0200 (CEST) Received: from localhost (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id B11DB12B09E; Thu, 26 May 2005 19:43:44 +0200 (CEST) Received: from eurystheus.local ([192.168.1.67]) by localhost (eurystheus.locaL [192.168.1.67]) (amavisd-new, port 10024) with ESMTP id 50057-06; Thu, 26 May 2005 19:43:40 +0200 (CEST) Received: from [192.168.1.67] (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id 5769012B09A; Thu, 26 May 2005 19:43:40 +0200 (CEST) Message-ID: <42960ACB.7090801@cs.tu-berlin.de> Date: Thu, 26 May 2005 19:43:39 +0200 From: Bjoern Koenig User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050517 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> In-Reply-To: <429606D9.6080602@cs.tu-berlin.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at example.com Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 17:44:40 -0000 Bjoern Koenig wrote: > Eric Anderson wrote: > >> Is it possible to disable all read and write caching to a disk? > > You can disable write the cache by adding the line > > hw.ata.wc="0" I assumed that you use ATA. If you use SCSI devices then read at least the manpages da(4) and camcontrol(8). Björn From owner-freebsd-current@FreeBSD.ORG Thu May 26 17:44:42 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2E72A16A420 for ; Thu, 26 May 2005 17:44:42 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE24943D1F for ; Thu, 26 May 2005 17:44:41 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id BDC3172DD4; Thu, 26 May 2005 10:44:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id B8C2B72DCB; Thu, 26 May 2005 10:44:41 -0700 (PDT) Date: Thu, 26 May 2005 10:44:41 -0700 (PDT) From: Doug White To: Randy Bush In-Reply-To: <17043.63846.102229.814228@roam.psg.com> Message-ID: <20050526104402.I69716@carver.gumbysoft.com> References: <17043.63846.102229.814228@roam.psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: FreeBSD Current Subject: Re: t41 crashes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 17:44:43 -0000 On Wed, 25 May 2005, Randy Bush wrote: > cvs since 2005.05.21 getting me frequent (ten minutes to most of a day) > full crashes on a thinkpad t41. reverting kernel did not fix, so it's > likely in world. no dumps. anyone else seeing anything like this? What's a "full crash"? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu May 26 17:53:20 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 17FC116A41C for ; Thu, 26 May 2005 17:53:20 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADB6D43D53 for ; Thu, 26 May 2005 17:53:19 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j4QHrHxr053808; Thu, 26 May 2005 12:53:17 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42960CFE.4060307@centtech.com> Date: Thu, 26 May 2005 12:53:02 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050504 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bjoern Koenig References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> In-Reply-To: <42960ACB.7090801@cs.tu-berlin.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 17:53:20 -0000 Bjoern Koenig wrote: > Bjoern Koenig wrote: > >> Eric Anderson wrote: >> >>> Is it possible to disable all read and write caching to a disk? >> >> >> You can disable write the cache by adding the line >> >> hw.ata.wc="0" > > > I assumed that you use ATA. If you use SCSI devices then read at least > the manpages da(4) and camcontrol(8). Thanks.. I've just read (quickly) both man pages. It seems as though you are suggesting disabling the physical disk caching, which should not make a difference in my case. The disk would report whatever it needs to report to either host, and those should be in sync. When I mount the filesystem on host B ro, it shows me the filesystem as of the time that I mounted it ro. Any subsequent changes on host A (which has it mounted rw) are not seem on host B unless I unmount and mount again on host B. This seems like a FreeBSD feature and not a general scsi feature. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu May 26 18:02:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8CB4216A41C for ; Thu, 26 May 2005 18:02:10 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from mail.efacilitas.de (efacilitas.de [213.133.110.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2F23543D49 for ; Thu, 26 May 2005 18:02:10 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-37-137.dynamic.qsc.de [212.202.37.137]) by mail.efacilitas.de (Postfix) with ESMTP id F251B123A33; Thu, 26 May 2005 20:00:44 +0200 (CEST) Received: from localhost (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id 00BEA12B09E; Thu, 26 May 2005 20:01:16 +0200 (CEST) Received: from eurystheus.local ([192.168.1.67]) by localhost (eurystheus.locaL [192.168.1.67]) (amavisd-new, port 10024) with ESMTP id 52092-09; Thu, 26 May 2005 20:01:12 +0200 (CEST) Received: from [192.168.1.67] (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id 14C8112B09A; Thu, 26 May 2005 20:01:12 +0200 (CEST) Message-ID: <42960EE7.30607@cs.tu-berlin.de> Date: Thu, 26 May 2005 20:01:11 +0200 From: Bjoern Koenig User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050517 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> In-Reply-To: <42960CFE.4060307@centtech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at example.com Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 18:02:10 -0000 Eric Anderson wrote: > Bjoern Koenig wrote: > > Thanks.. I've just read (quickly) both man pages. It seems as though > you are suggesting disabling the physical disk caching, which should not > make a difference in my case. The disk would report whatever it needs > to report to either host, and those should be in sync. Oh, I'm sorry. I have misunderstood you then. > When I mount the filesystem on host B ro, it shows me the filesystem as > of the time that I mounted it ro. Any subsequent changes on host A > (which has it mounted rw) are not seem on host B unless I unmount and > mount again on host B. This seems like a FreeBSD feature and not a > general scsi feature. By what mechanism do you mount the partitions remote? I'm not very experienced with this. I'm thinking of a typical network file system or GEOM gate. Björn From owner-freebsd-current@FreeBSD.ORG Thu May 26 18:05:35 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 02FA916A41C for ; Thu, 26 May 2005 18:05: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 4A0C443D1F for ; Thu, 26 May 2005 18:05:33 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4QI7IAX043976; Thu, 26 May 2005 12:07:18 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42960F8F.2050109@samsco.org> Date: Thu, 26 May 2005 12:03:59 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> In-Reply-To: <42960CFE.4060307@centtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 18:05:35 -0000 Eric Anderson wrote: > Bjoern Koenig wrote: > >> Bjoern Koenig wrote: >> >>> Eric Anderson wrote: >>> >>>> Is it possible to disable all read and write caching to a disk? >>> >>> >>> >>> You can disable write the cache by adding the line >>> >>> hw.ata.wc="0" >> >> >> >> I assumed that you use ATA. If you use SCSI devices then read at least >> the manpages da(4) and camcontrol(8). > > > Thanks.. I've just read (quickly) both man pages. It seems as though > you are suggesting disabling the physical disk caching, which should not > make a difference in my case. The disk would report whatever it needs > to report to either host, and those should be in sync. > > When I mount the filesystem on host B ro, it shows me the filesystem as > of the time that I mounted it ro. Any subsequent changes on host A > (which has it mounted rw) are not seem on host B unless I unmount and > mount again on host B. This seems like a FreeBSD feature and not a > general scsi feature. > > Eric > > > > You simply cannot disable OS caching in FreeBSD. It's a fundamental part of the block I/O and VM layers. There are filesystems like GFS that deal with the issue of directly connecting more than one computer to a disk or set of disks, and there are distributed filesystems like AFS and Coda that deal with making the storage on multiple computers appear as a single network filesystem. Unfortunately, no port of GFS has been done yet, and I estimate that such a port would take 4-6 months. Scott From owner-freebsd-current@FreeBSD.ORG Thu May 26 18:07:33 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CA0C216A41C for ; Thu, 26 May 2005 18:07:33 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0B3643D58 for ; Thu, 26 May 2005 18:07:32 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j4QI7Uc4054012; Thu, 26 May 2005 13:07:30 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42961053.2060900@centtech.com> Date: Thu, 26 May 2005 13:07:15 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050504 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bjoern Koenig References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960EE7.30607@cs.tu-berlin.de> In-Reply-To: <42960EE7.30607@cs.tu-berlin.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 18:07:33 -0000 Bjoern Koenig wrote: > Eric Anderson wrote: > >> Bjoern Koenig wrote: >> >> Thanks.. I've just read (quickly) both man pages. It seems as though >> you are suggesting disabling the physical disk caching, which should >> not make a difference in my case. The disk would report whatever it >> needs to report to either host, and those should be in sync. > > > Oh, I'm sorry. I have misunderstood you then. > >> When I mount the filesystem on host B ro, it shows me the filesystem >> as of the time that I mounted it ro. Any subsequent changes on host A >> (which has it mounted rw) are not seem on host B unless I unmount and >> mount again on host B. This seems like a FreeBSD feature and not a >> general scsi feature. > > > By what mechanism do you mount the partitions remote? I'm not very > experienced with this. I'm thinking of a typical network file system or > GEOM gate. I have two servers connected directly to a fiber channel disk array (containing 16 WD Raptor SATA drives in RAID0+1 configuration). Each server sees the same exact luns, so I create the partition and filesystem from host A. I mount it (rw) on host A. Then, if I do a: camcontrol rescan all on host B, I pick up the fiber channel disk and it sees it as da0 (just like on host A). I can then mount it rw or ro on host B. I think using GEOM gate might give a similar situation. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu May 26 18:12:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 26C1F16A41C for ; Thu, 26 May 2005 18:12:53 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh1.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id B129A43D48 for ; Thu, 26 May 2005 18:12:52 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh1.centtech.com (8.13.1/8.13.1) with ESMTP id j4QICprg080732; Thu, 26 May 2005 13:12:51 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42961195.30608@centtech.com> Date: Thu, 26 May 2005 13:12:37 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050504 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> In-Reply-To: <42960F8F.2050109@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/894/Wed May 25 07:53:16 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 18:12:53 -0000 Scott Long wrote: > Eric Anderson wrote: > >> Bjoern Koenig wrote: >> >>> Bjoern Koenig wrote: >>> >>>> Eric Anderson wrote: >>>> >>>>> Is it possible to disable all read and write caching to a disk? >>>> >>>> >>>> >>>> >>>> You can disable write the cache by adding the line >>>> >>>> hw.ata.wc="0" >>> >>> >>> >>> >>> I assumed that you use ATA. If you use SCSI devices then read at >>> least the manpages da(4) and camcontrol(8). >> >> >> >> Thanks.. I've just read (quickly) both man pages. It seems as though >> you are suggesting disabling the physical disk caching, which should >> not make a difference in my case. The disk would report whatever it >> needs to report to either host, and those should be in sync. >> >> When I mount the filesystem on host B ro, it shows me the filesystem >> as of the time that I mounted it ro. Any subsequent changes on host A >> (which has it mounted rw) are not seem on host B unless I unmount and >> mount again on host B. This seems like a FreeBSD feature and not a >> general scsi feature. >> >> Eric >> >> >> >> > > You simply cannot disable OS caching in FreeBSD. It's a fundamental > part of the block I/O and VM layers. There are filesystems like GFS > that deal with the issue of directly connecting more than one computer > to a disk or set of disks, and there are distributed filesystems like > AFS and Coda that deal with making the storage on multiple computers > appear as a single network filesystem. Unfortunately, no port of GFS > has been done yet, and I estimate that such a port would take 4-6 months. Thanks Scott. I know of GFS, and would *love* to see it ported to FreeBSD. I wonder if there is a group of developers that would be willing to do that? I understand what I am doing is 'illegal', but I'm wondering why the ro mount only sees the changes from the time of ro mount. Mounting rw also shows the same thing. Do you think it's a caching issue, or something with UFS that makes it work this way? I'm in no way advocating doing this, nor am I saying 'it should work' - I'm trying to learn more, understand it, and maybe use it as a failover mechanism. Does anyone know the real dangers of forcing an unclean UFS filesystem mounted rw and skipping the fsck? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Thu May 26 18:24:14 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0D7CD16A41C for ; Thu, 26 May 2005 18:24:14 +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 ACFF243D49 for ; Thu, 26 May 2005 18:24:13 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4QIQAtS044080; Thu, 26 May 2005 12:26:10 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <429613FB.80100@samsco.org> Date: Thu, 26 May 2005 12:22:51 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Anderson References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> In-Reply-To: <42961195.30608@centtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 18:24:14 -0000 Eric Anderson wrote: > Scott Long wrote: > >> Eric Anderson wrote: >> >>> Bjoern Koenig wrote: >>> >>>> Bjoern Koenig wrote: >>>> >>>>> Eric Anderson wrote: >>>>> >>>>>> Is it possible to disable all read and write caching to a disk? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> You can disable write the cache by adding the line >>>>> >>>>> hw.ata.wc="0" >>>> >>>> >>>> >>>> >>>> >>>> I assumed that you use ATA. If you use SCSI devices then read at >>>> least the manpages da(4) and camcontrol(8). >>> >>> >>> >>> >>> Thanks.. I've just read (quickly) both man pages. It seems as though >>> you are suggesting disabling the physical disk caching, which should >>> not make a difference in my case. The disk would report whatever it >>> needs to report to either host, and those should be in sync. >>> >>> When I mount the filesystem on host B ro, it shows me the filesystem >>> as of the time that I mounted it ro. Any subsequent changes on host >>> A (which has it mounted rw) are not seem on host B unless I unmount >>> and mount again on host B. This seems like a FreeBSD feature and not >>> a general scsi feature. >>> >>> Eric >>> >>> >>> >>> >> >> You simply cannot disable OS caching in FreeBSD. It's a fundamental >> part of the block I/O and VM layers. There are filesystems like GFS >> that deal with the issue of directly connecting more than one computer >> to a disk or set of disks, and there are distributed filesystems like >> AFS and Coda that deal with making the storage on multiple computers >> appear as a single network filesystem. Unfortunately, no port of GFS >> has been done yet, and I estimate that such a port would take 4-6 months. > > > Thanks Scott. I know of GFS, and would *love* to see it ported to > FreeBSD. I wonder if there is a group of developers that would be > willing to do that? I'd love to do it sometime. Some diligence would have to be done on the license and possible patents, though. I'm not sure what RedHat's stance is on sharing in this regard. > > I understand what I am doing is 'illegal', but I'm wondering why the ro > mount only sees the changes from the time of ro mount. Mounting rw also > shows the same thing. > > Do you think it's a caching issue, or something with UFS that makes it > work this way? > Even on a read-only mount, reads are cached. Cached blocks are only evicted when there is memory pressure or when the OS specifically invalidates them, and it's rather unpredictable when this will happen. > I'm in no way advocating doing this, nor am I saying 'it should work' - > I'm trying to learn more, understand it, and maybe use it as a failover > mechanism. The only thing that is moderately workable is to have all client machines mount the FS read-only, and have none of them do any writing to it. > > Does anyone know the real dangers of forcing an unclean UFS filesystem > mounted rw and skipping the fsck? Assuming that the previous shutdown allowed all cached metadata in the disk to get to the platters in the proper order (which is not terribly true with ATA), the main inconsistency that you'll have is that deleted files might still have allocated inodes and thus will consume space on the filesystem even though they aren't accessible. This is the premise that background fsck operates on, btw. However, there is a real possibility for there being other inconsistencies that are not safe to run with. Scott From owner-freebsd-current@FreeBSD.ORG Thu May 26 19:12:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 10AF616A41C for ; Thu, 26 May 2005 19:12:21 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail05.syd.optusnet.com.au (mail05.syd.optusnet.com.au [211.29.132.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 610B943D48 for ; Thu, 26 May 2005 19:12:21 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mail05.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j4QJCItQ012337 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 May 2005 05:12:19 +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 j4QJCHRx018129; Fri, 27 May 2005 05:12:17 +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 j4QJCHD2018128; Fri, 27 May 2005 05:12:17 +1000 (EST) (envelope-from pjeremy) Date: Fri, 27 May 2005 05:12:17 +1000 From: Peter Jeremy To: Ted Faber Message-ID: <20050526191217.GA17267@cirb503493.alcatel.com.au> References: <20050526001806.GA1008@pun.isi.edu> <20050526080928.GE12640@cirb503493.alcatel.com.au> <20050526160846.GA6851@pun.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526160846.GA6851@pun.isi.edu> User-Agent: Mutt/1.4.2i Cc: freebsd-current@freebsd.org Subject: Re: hard deadlock(?) on -current; some debugging info, need help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 19:12:22 -0000 On Thu, 2005-May-26 09:08:46 -0700, Ted Faber wrote: >On Thu, May 26, 2005 at 06:09:28PM +1000, Peter Jeremy wrote: >> Nothing is waiting on physical I/O, but there are lots of locked vnodes. >> I notice there's a sh(? - pid 10715) blocked on nfsreq. Can you reproduce >> the problem without the NFS mounted filesystems? > >I have a laptop on the same network that uses NFS much less aggressively >and it has never locked up. I understand that's anecdotal. It's pretty >hard to reconfigure the desktop into a position where I get work done >and don't use NFS here. OK. I have no reason to believe the problem is in NFS, it was just a "reduce the number of possibilities" type suggestion. >I've let it sit a few minutes. I'll try it again next lockup, just in >case. I've just typed "panic" from the debugger. If there's a better >way, please let me know. You could try "call doadump". -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Thu May 26 19:24:26 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 83BF216A41C for ; Thu, 26 May 2005 19:24:26 +0000 (GMT) (envelope-from smkelly@FreeBSD.org) Received: from edgemaster.zombie.org (edgemaster.creighton.edu [147.134.65.224]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F84D43D1D for ; Thu, 26 May 2005 19:24:25 +0000 (GMT) (envelope-from smkelly@FreeBSD.org) Received: by edgemaster.zombie.org (Postfix, from userid 1001) id 4461F39838; Thu, 26 May 2005 14:24:25 -0500 (CDT) Date: Thu, 26 May 2005 14:24:25 -0500 From: Sean Kelly To: Muthu_T@Dell.com Message-ID: <20050526192424.GA39522@edgemaster.zombie.org> References: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB67120@blrx2kmbgl101.blr.amer.dell.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tKW2IUtsqtDRztdT" Content-Disposition: inline In-Reply-To: <71F713C5E3CB7F4F9ACCBBB8E9BE318AB67120@blrx2kmbgl101.blr.amer.dell.com> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: FreeBSD 5.4 supports DELL PERC 4 cards X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 19:24:26 -0000 --tKW2IUtsqtDRztdT Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable As others have said, it is great to see a vendor involved! While you're in the game, any chance of getting a FreeBSD native version of the sysutils/linux-afaapps port, and possibly newer ones for the newer PERCs? Wishful thinking... On Wed, May 25, 2005 at 07:12:29AM -0500, Muthu_T@Dell.com wrote: > Could anyone add the following cards to the 'amr' man page as > supported hardware? >=20 > 1. DELL PERC 4/SC - PCI Card=20 > 2. DELL PERC 4/DC - PCI Card > 3. DELL PERC 4e/DC - PCI Express card=20 >=20 > I had installed FreeBSD 5.4 on PE2850 today and found that 'amr' > detected the above last 2 cards. >=20 > See the attached dmesg & 'pciconf -l -v' output. >=20 > Also please change the text 'MegaRaid' to 'MegaRAID' in 'amr' source. >=20 > Thanks. > --T. Muthu Mohan --=20 Sean Kelly | PGP KeyID: D2E5E296 smkelly@FreeBSD.org | http://www.sean-kelly.org/ --tKW2IUtsqtDRztdT Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCliJoPm7A9NLl4pYRAt7TAJ9hVQRtPBP0PyMiJPbKhpt2TPu4uwCeMCgQ RiAhdb1ZTAGuyJDIZGIJMAU= =diR3 -----END PGP SIGNATURE----- --tKW2IUtsqtDRztdT-- From owner-freebsd-current@FreeBSD.ORG Thu May 26 19:54:25 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8D56D16A41C for ; Thu, 26 May 2005 19:54:25 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6433343D1D for ; Thu, 26 May 2005 19:54:25 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbOQy-000OnV-VS; Thu, 26 May 2005 19:54:25 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DbOQw-0002TD-8X; Thu, 26 May 2005 15:54:22 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17046.10603.670016.599622@roam.psg.com> Date: Thu, 26 May 2005 15:54:19 -0400 To: Doug White References: <17043.63846.102229.814228@roam.psg.com> <20050526104402.I69716@carver.gumbysoft.com> Cc: FreeBSD Current Subject: Re: t41 crashes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 19:54:25 -0000 >> cvs since 2005.05.21 getting me frequent (ten minutes to most of a day) >> full crashes on a thinkpad t41. reverting kernel did not fix, so it's >> likely in world. no dumps. anyone else seeing anything like this? > What's a "full crash"? in this case, the system just reboots leaving no crashdump. as there is no serial port, i can not see if it spewed anything on the console. kevin oberman suggested trying a kernel with CPUTYPE=pentium-m, and that has been up for 15 hours now. of course, it will crash as soon as i hit C-c C-c. randy From owner-freebsd-current@FreeBSD.ORG Thu May 26 20:22:36 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 928E216A41C; Thu, 26 May 2005 20:22:36 +0000 (GMT) (envelope-from des@des.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1FF743D48; Thu, 26 May 2005 20:22:35 +0000 (GMT) (envelope-from des@des.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH4008LPBT11740@osl1smout1.broadpark.no>; Fri, 27 May 2005 00:29:25 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH400C2863UKHD0@osl1sminn1.broadpark.no>; Thu, 26 May 2005 22:26:18 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 2D60E456B0; Thu, 26 May 2005 22:22:33 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 05C824561A; Thu, 26 May 2005 22:22:29 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id E466B33C1C; Thu, 26 May 2005 22:22:28 +0200 (CEST) Date: Thu, 26 May 2005 22:22:28 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <1116787423.786.10.camel@RabbitsDen> To: "Alexandre \"Sunny\" Kovalenko" Message-id: <86br6xka9n.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <20050522112612.GA37841@frontfree.net> <1116787423.786.10.camel@RabbitsDen> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: Cc: freebsd-current@FreeBSD.org, delphij@FreeBSD.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 20:22:36 -0000 "Alexandre \"Sunny\" Kovalenko" writes: > I have observed some odd behavior when X display becomes garbled if USB > stack is loaded and USB keyboard is attached after user has logged into > X desktop (Gnome in my case). I am setting MODE_280 (1024x768x32) in > rc.conf using 'allscreens_flags'. In recent -CURRENT, plugging in a USB keyboard or mouse triggers '/etc/rc.d/syscons restart' which applies allscreens_flags to all active consoles, including the one X runs on. This is not a bug in delphij's code; /etc/rc.d/syscons should skip consoles that are in use by X. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu May 26 20:28:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id ACACA16A41C; Thu, 26 May 2005 20:28:54 +0000 (GMT) (envelope-from des@des.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id 375C143D4C; Thu, 26 May 2005 20:28:54 +0000 (GMT) (envelope-from des@des.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH4008QRC3K0Q40@osl1smout1.broadpark.no>; Fri, 27 May 2005 00:35:44 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH400C706EDKHE0@osl1sminn1.broadpark.no>; Thu, 26 May 2005 22:32:37 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 5DB464561A; Thu, 26 May 2005 22:28:52 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id B8584451B3; Thu, 26 May 2005 22:28:46 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id A9A3733C1C; Thu, 26 May 2005 22:28:46 +0200 (CEST) Date: Thu, 26 May 2005 22:28:46 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <429468C3.5040207@centtech.com> To: Eric Anderson Message-id: <867jhlk9z5.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <20050522112612.GA37841@frontfree.net> <20050523003843.GO850@obiwan.tataz.chchile.org> <1116815005.838.3.camel@spirit> <1116999375.731.7.camel@spirit> <429468C3.5040207@centtech.com> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: Cc: Jeremie Le Hen , Eric Kjeldergaard , freebsd-current@freebsd.org, delphij@freebsd.org, Xin LI Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 20:28:54 -0000 Eric Anderson writes: > I noticed that changing to 16bit (instead of 32 or 24) helped a lot. ...because more pixels fit in a single 64 kB page, so the console code doesn't have to switch pages as much while redrawing the screen. Switching pages requires switching to virtual x86 mode (stalling the CPU and invalidating the cache) to invoke the VESA BIOS. On graphic adapters with linear framebuffer support (pretty much all of them today), you can map the entire framebuffer into memory to avoid paging, but our VESA driver doesn't know how to do that. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu May 26 20:31:45 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 43C5616A41C; Thu, 26 May 2005 20:31:45 +0000 (GMT) (envelope-from des@des.no) Received: from osl1smout1.broadpark.no (osl1smout1.broadpark.no [80.202.4.58]) by mx1.FreeBSD.org (Postfix) with ESMTP id C928A43D1D; Thu, 26 May 2005 20:31:44 +0000 (GMT) (envelope-from des@des.no) Received: from osl1sminn1.broadpark.no ([80.202.4.59]) by osl1smout1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH4008ZXC8B0Z40@osl1smout1.broadpark.no>; Fri, 27 May 2005 00:38:35 +0200 (CEST) Received: from dsa.des.no ([80.203.228.37]) by osl1sminn1.broadpark.no (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0IH400C8Q6J3KHF0@osl1sminn1.broadpark.no>; Thu, 26 May 2005 22:35:28 +0200 (CEST) Received: by dsa.des.no (Pony Express, from userid 666) id 254B845165; Thu, 26 May 2005 22:31:43 +0200 (CEST) Received: from xps.des.no (xps.des.no [10.0.0.12]) by dsa.des.no (Pony Express) with ESMTP id 744B145157; Thu, 26 May 2005 22:31:38 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 6DBD333C1C; Thu, 26 May 2005 22:31:38 +0200 (CEST) Date: Thu, 26 May 2005 22:31:38 +0200 From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) In-reply-to: <20050523075128.GP850@obiwan.tataz.chchile.org> To: Jeremie Le Hen Message-id: <863bs9k9ud.fsf@xps.des.no> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on dsa.des.no References: <20050522112612.GA37841@frontfree.net> <20050523003843.GO850@obiwan.tataz.chchile.org> <20050523075128.GP850@obiwan.tataz.chchile.org> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED,AWL autolearn=disabled version=3.0.2 X-Spam-Level: Cc: freebsd-current@FreeBSD.org, delphij@FreeBSD.org Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 20:31:45 -0000 Jeremie Le Hen writes: > Nearly perfect :-). I use the fade saver and when I woke up this morning, > going back from the screen saver turned the VESA console text into blue. > Not the whole text, just the non-brilliant one. This is not the case on > non-VESA consoles. The fade screensaver plays games with the palette; syscons should always assume that the screensaver may have altered the palette, and restore it when the screensaver stops, but apparently it doesn't. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu May 26 20:32:44 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78A7216A41C for ; Thu, 26 May 2005 20:32:44 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4124943D1F for ; Thu, 26 May 2005 20:32:44 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j4QKWhWS001243; Thu, 26 May 2005 13:32:43 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j4QKWhE5001242; Thu, 26 May 2005 13:32:43 -0700 (PDT) (envelope-from faber) Date: Thu, 26 May 2005 13:32:43 -0700 From: Ted Faber To: Peter Jeremy Message-ID: <20050526203243.GB1055@pun.isi.edu> References: <20050526001806.GA1008@pun.isi.edu> <20050526080928.GE12640@cirb503493.alcatel.com.au> <20050526160846.GA6851@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="nVMJ2NtxeReIH9PS" Content-Disposition: inline In-Reply-To: <20050526160846.GA6851@pun.isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Cc: freebsd-current@freebsd.org Subject: Re: hard deadlock(?) on -current; some debugging info, need help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 20:32:44 -0000 --nVMJ2NtxeReIH9PS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, May 26, 2005 at 09:08:46AM -0700, Ted Faber wrote: > On Thu, May 26, 2005 at 06:09:28PM +1000, Peter Jeremy wrote: > > The other information we need is "show lockedvnods". This will hopefully > > point to the process that started the problem. > > Next lockup I'll get it. Next lock up is now. Same kernel, pics are at http://www.isi.edu/~faber/tmp/deadlock/DSCN048{83,84,85,86,87,88,89,90,91}.JPG My inexpert reading is that one of the threads of the psi jabber client is locked on something. "Something" why I need help. :-) The "show lockedvnods" is in the last pic and the psi process is in the first. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --nVMJ2NtxeReIH9PS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCljJraUz3f+Zf+XsRAqtDAKC7fAMhyAHba3ihuA3v+HOXxHOQAgCg6gyN uTG5vru9xNxe6qa3JaPevPc= =Cqvp -----END PGP SIGNATURE----- --nVMJ2NtxeReIH9PS-- From owner-freebsd-current@FreeBSD.ORG Thu May 26 20:40:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 19FCE16A41C for ; Thu, 26 May 2005 20:40:49 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC32A43D49 for ; Thu, 26 May 2005 20:40:48 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j4QKemVK007072; Thu, 26 May 2005 13:40:48 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j4QKemPE007071; Thu, 26 May 2005 13:40:48 -0700 (PDT) (envelope-from faber) Date: Thu, 26 May 2005 13:40:48 -0700 From: Ted Faber To: Peter Jeremy Message-ID: <20050526204048.GC1055@pun.isi.edu> References: <20050526001806.GA1008@pun.isi.edu> <20050526080928.GE12640@cirb503493.alcatel.com.au> <20050526160846.GA6851@pun.isi.edu> <20050526203243.GB1055@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="f0KYrhQ4vYSV2aJu" Content-Disposition: inline In-Reply-To: <20050526203243.GB1055@pun.isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Cc: freebsd-current@freebsd.org Subject: Re: hard deadlock(?) on -current; some debugging info, need help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 20:40:49 -0000 --f0KYrhQ4vYSV2aJu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, May 26, 2005 at 01:32:43PM -0700, Ted Faber wrote: > On Thu, May 26, 2005 at 09:08:46AM -0700, Ted Faber wrote: > > On Thu, May 26, 2005 at 06:09:28PM +1000, Peter Jeremy wrote: > > > The other information we need is "show lockedvnods". This will hopefully > > > point to the process that started the problem. > > > > Next lockup I'll get it. > > Next lock up is now. Same kernel, pics are at > > http://www.isi.edu/~faber/tmp/deadlock/DSCN048{83,84,85,86,87,88,89,90,91}.JPG > > My inexpert reading is that one of the threads of the psi jabber client > is locked on something. "Something" why I need help. :-) > > The "show lockedvnods" is in the last pic and the psi process is in the > first. Just to anticipate the question, I'm running psi-0.9.3 from ports, and I'm a little behind (current is 0.9.3_2). I can upgrade if you think it's an issue, but otherwise I won't in order to change the minimal number of things. -- Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG --f0KYrhQ4vYSV2aJu Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCljRQaUz3f+Zf+XsRAtyBAJwIoUGKmNKEgf6U2rWI5zEznZgURgCfUmVb w4+vRu2RKWTuX+qZ6o974p0= =lu9H -----END PGP SIGNATURE----- --f0KYrhQ4vYSV2aJu-- From owner-freebsd-current@FreeBSD.ORG Thu May 26 20:58:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8BFA316A41C for ; Thu, 26 May 2005 20:58:45 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: from bremen.shuttle.de (bremen.shuttle.de [194.95.249.251]) by mx1.FreeBSD.org (Postfix) with ESMTP id F056443D1F for ; Thu, 26 May 2005 20:58:44 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id 68C473B8E0; Thu, 26 May 2005 22:58:43 +0200 (CEST) Received: from hal9000.schweikhardt.net (localhost [127.0.0.1]) by hal9000.schweikhardt.net (8.13.3/8.13.3) with ESMTP id j4QKwV2A000992; Thu, 26 May 2005 22:58:31 +0200 (CEST) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.13.3/8.13.3/Submit) id j4QKwVV5000991; Thu, 26 May 2005 22:58:31 +0200 (CEST) (envelope-from schweikh) Date: Thu, 26 May 2005 22:58:31 +0200 From: Jens Schweikhardt To: Doug White Message-ID: <20050526205831.GA958@schweikhardt.net> References: <20050516113420.GA786@schweikhardt.net> <20050518150346.S87264@carver.gumbysoft.com> <20050519190129.GA1048@schweikhardt.net> <20050520122944.B8229@carver.gumbysoft.com> <20050521092857.GA847@schweikhardt.net> <20050522112845.S27009@carver.gumbysoft.com> <20050523175609.GA779@schweikhardt.net> <20050523210141.GA779@schweikhardt.net> <20050526102606.T69716@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526102606.T69716@carver.gumbysoft.com> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: Timekeeping hosed by factor 3, high lapic[01] interrupt rates X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 20:58:45 -0000 On Thu, May 26, 2005 at 10:30:16AM -0700, Doug White wrote: # On Mon, 23 May 2005, Jens Schweikhardt wrote: # # > ... # > # # 3. Backout rev 1.218 of src/sys/i386/isa/clock.c so the irq0 interrupt # > # # handler is reactivated and the RTC fiddled. # > # # > # Will do so next. I've nailed the change between March 6 and March 30. # > # 1.218 is from 2005/03/24 21:34:16, which would fit. # > # > We have a winner. Backing out 1.218 from a 2005/03/24 system does the trick, # > as well as a CURRENT without 1.218 (but 1.219-220 in there) bring back irq0 # > and time dilation is gone. All clocks work correctly. # # Hm ... not sure what part of that commit is the bad part. You might try # changing # # if (!using_lapic_timer) { # # to # # if(1) { # # in the most recent rev of clock.c to register irq0 again. If that doesn't # chang ethe dialation then something else in the system must be depending # on the RTC periodic interrupt. It does make time dilation go away. # > Now the question is: what is so special in my system so that I appear # > to be the only one to notice the problem? # # Good question. What CPUs do you have in that machine again? Copy out the # 'CPU' and related lines from dmesg. One P4 Prescott, with HT enabled, 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-CURRENT #0: Mon May 23 22:38:19 CEST 2005 toor@hal9000.schweikhardt.net:/share/HEAD/obj/share/HEAD/src/sys/HAL9000 MPTable: Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2994.90-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf33 Stepping = 3 Features=0xbfebfbff Features2=0x41d,MON,DS_CPL,CNTX-ID> Hyperthreading: 2 logical CPUs real memory = 1072627712 (1022 MB) avail memory = 1040846848 (992 MB) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0: Assuming intbase of 0 ioapic1: Assuming intbase of 24 ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard [...] Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-current@FreeBSD.ORG Thu May 26 21:24:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5B28816A41C for ; Thu, 26 May 2005 21:24:58 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3497943D48 for ; Thu, 26 May 2005 21:24:58 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbPqb-00011Y-SO; Thu, 26 May 2005 21:24:57 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DbPqY-000A9b-Up; Thu, 26 May 2005 17:24:55 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17046.16036.242355.771711@roam.psg.com> Date: Thu, 26 May 2005 17:24:52 -0400 To: Doug White References: <17043.63846.102229.814228@roam.psg.com> <20050526104402.I69716@carver.gumbysoft.com> Cc: FreeBSD Current Subject: Re: t41 crashes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 21:24:58 -0000 >> cvs since 2005.05.21 getting me frequent (ten minutes to most of a day) >> full crashes on a thinkpad t41. reverting kernel did not fix, so it's >> likely in world. no dumps. anyone else seeing anything like this? > What's a "full crash"? CPUTYPE=pentium-m was no cure. it crashed ten minutes after i hit C-c C-c. randy From owner-freebsd-current@FreeBSD.ORG Thu May 26 21:38:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EEFAE16A41C for ; Thu, 26 May 2005 21:38:34 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id B58BF43D49 for ; Thu, 26 May 2005 21:38:34 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id EE425E96A; Thu, 26 May 2005 17:38:32 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id 246361A0899; Thu, 26 May 2005 17:38:29 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17046.16853.93063.286760@canoe.dclg.ca> Date: Thu, 26 May 2005 17:38:29 -0400 To: freebsd-current@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Subject: usb2 and audio? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 21:38:35 -0000 I get the following when I plug my headphones into my usb2 hub: uaudio0: Logitech Logitech USB Headset, rev 1.10/10.12, addr 5 uaudio0: ignored input endpoint of type adaptive uaudio0: audio rev 1.00 pcm1: on uaudio0 record channel supported format list invalid pcm1: chn_init(pcm1:record:0) failed: err = 19 pcm1: pcm_chn_create(ua_chan, -1, 0xc401f880) failed usb3: *** WARNING: opening low/full speed device, this does not work yet. usb3: *** WARNING: opening low/full speed device, this does not work yet. usb3: *** WARNING: opening low/full speed device, this does not work yet. ... whereas my mouse (low speed) and other usb 2.0 devices work. Also... when I plug the headset into the laptops port directly, it works ... and the probe looks identical (includingt the complaints). Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-current@FreeBSD.ORG Thu May 26 22:32:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AD7B516A41C for ; Thu, 26 May 2005 22:32:11 +0000 (GMT) (envelope-from oberman@es.net) Received: from postal2.es.net (postal2.es.net [198.128.3.206]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8899543D1F for ; Thu, 26 May 2005 22:32:11 +0000 (GMT) (envelope-from oberman@es.net) Received: from ptavv.es.net ([198.128.4.29]) by postal2.es.net (Postal Node 2) with ESMTP (SSL) id IBA74465; Thu, 26 May 2005 15:32:11 -0700 Received: from ptavv (localhost [127.0.0.1]) by ptavv.es.net (Tachyon Server) with ESMTP id BE1BF5D08; Thu, 26 May 2005 15:32:10 -0700 (PDT) To: Randy Bush In-reply-to: Your message of "Thu, 26 May 2005 17:24:52 EDT." <17046.16036.242355.771711@roam.psg.com> Date: Thu, 26 May 2005 15:32:10 -0700 From: "Kevin Oberman" Message-Id: <20050526223210.BE1BF5D08@ptavv.es.net> Cc: FreeBSD Current Subject: Re: t41 crashes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 22:32:11 -0000 > From: Randy Bush > Date: Thu, 26 May 2005 17:24:52 -0400 > Sender: owner-freebsd-current@freebsd.org > > >> cvs since 2005.05.21 getting me frequent (ten minutes to most of a day) > >> full crashes on a thinkpad t41. reverting kernel did not fix, so it's > >> likely in world. no dumps. anyone else seeing anything like this? > > What's a "full crash"? > > CPUTYPE=pentium-m was no cure. it crashed ten minutes after i > hit C-c C-c. Sorry. I told you that it was a long shot. I am rebuilding my system now. I'll see how it does tomorrow. I really get annoyed that so many laptops have dropped the serial console. I think you can get a serial console with a port replicator. -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: oberman@es.net Phone: +1 510 486-8634 From owner-freebsd-current@FreeBSD.ORG Thu May 26 22:53:33 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8347E16A41C for ; Thu, 26 May 2005 22:53:33 +0000 (GMT) (envelope-from randy@psg.com) Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D60F43D49 for ; Thu, 26 May 2005 22:53:33 +0000 (GMT) (envelope-from randy@psg.com) Received: from localhost ([127.0.0.1] helo=roam.psg.com) by rip.psg.com with esmtp (Exim 4.50 (FreeBSD)) id 1DbREK-000381-R6; Thu, 26 May 2005 22:53:32 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DbREH-00061D-Qk; Thu, 26 May 2005 18:53:29 -0400 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17046.21351.240792.304978@roam.psg.com> Date: Thu, 26 May 2005 18:53:27 -0400 To: "Kevin Oberman" References: <17046.16036.242355.771711@roam.psg.com> <20050526223210.BE1BF5D08@ptavv.es.net> Cc: FreeBSD Current Subject: Re: t41 crashes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 May 2005 22:53:33 -0000 >> CPUTYPE=pentium-m was no cure. it crashed ten minutes after i >> hit C-c C-c. > Sorry. I told you that it was a long shot. i demand a full refund! :-) > I think you can get a serial console with a port replicator. one more thing in my backback? yechhhh. i can capture crashes to screen with a digital camera. the good news is that yesterday's current seems to let a 1ru in the westin rdump again sans crash. randy From owner-freebsd-current@FreeBSD.ORG Fri May 27 02:50:24 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 806CF16A41C for ; Fri, 27 May 2005 02:50:24 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 33EDA43D49 for ; Fri, 27 May 2005 02:50:23 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [192.168.42.25] ([192.168.42.25]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j4R2oBwX059464; Thu, 26 May 2005 21:50:22 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42968AD4.3020603@centtech.com> Date: Thu, 26 May 2005 21:49:56 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050504 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> In-Reply-To: <429613FB.80100@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 02:50:24 -0000 Scott Long wrote: > Eric Anderson wrote: > >> Scott Long wrote: >> >>> Eric Anderson wrote: >>> >>>> Bjoern Koenig wrote: >>>> >>>>> Bjoern Koenig wrote: >>>>> >>>>>> Eric Anderson wrote: >>>>>> >>>>>>> Is it possible to disable all read and write caching to a disk? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> You can disable write the cache by adding the line >>>>>> >>>>>> hw.ata.wc="0" >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> I assumed that you use ATA. If you use SCSI devices then read at >>>>> least the manpages da(4) and camcontrol(8). >>>> >>>> >>>> >>>> >>>> >>>> Thanks.. I've just read (quickly) both man pages. It seems as >>>> though you are suggesting disabling the physical disk caching, which >>>> should not make a difference in my case. The disk would report >>>> whatever it needs to report to either host, and those should be in >>>> sync. >>>> >>>> When I mount the filesystem on host B ro, it shows me the filesystem >>>> as of the time that I mounted it ro. Any subsequent changes on host >>>> A (which has it mounted rw) are not seem on host B unless I unmount >>>> and mount again on host B. This seems like a FreeBSD feature and >>>> not a general scsi feature. >>>> >>>> Eric >>>> >>>> >>>> >>>> >>> >>> You simply cannot disable OS caching in FreeBSD. It's a fundamental >>> part of the block I/O and VM layers. There are filesystems like GFS >>> that deal with the issue of directly connecting more than one computer >>> to a disk or set of disks, and there are distributed filesystems like >>> AFS and Coda that deal with making the storage on multiple computers >>> appear as a single network filesystem. Unfortunately, no port of GFS >>> has been done yet, and I estimate that such a port would take 4-6 >>> months. >> >> >> >> Thanks Scott. I know of GFS, and would *love* to see it ported to >> FreeBSD. I wonder if there is a group of developers that would be >> willing to do that? > > > I'd love to do it sometime. Some diligence would have to be done on the > license and possible patents, though. I'm not sure what RedHat's stance > is on sharing in this regard. If you are serious about working on it, I could look into the RedHat side of things. This is something I really think is important for FreeBSD (in the future). If GFS isn't right, maybe another clustering shared file system, or a Global UFS (I don't even know if that's possible). >> I understand what I am doing is 'illegal', but I'm wondering why the >> ro mount only sees the changes from the time of ro mount. Mounting rw >> also shows the same thing. >> >> Do you think it's a caching issue, or something with UFS that makes it >> work this way? >> > > Even on a read-only mount, reads are cached. Cached blocks are only > evicted when there is memory pressure or when the OS specifically > invalidates them, and it's rather unpredictable when this will happen. I see. So most likely the lack of updates being visible on host B is due to read caches. >> I'm in no way advocating doing this, nor am I saying 'it should work' >> - I'm trying to learn more, understand it, and maybe use it as a >> failover mechanism. > > > The only thing that is moderately workable is to have all client > machines mount the FS read-only, and have none of them do any writing > to it. > >> >> Does anyone know the real dangers of forcing an unclean UFS filesystem >> mounted rw and skipping the fsck? > > > Assuming that the previous shutdown allowed all cached metadata in the > disk to get to the platters in the proper order (which is not terribly > true with ATA), the main inconsistency that you'll have is that deleted > files might still have allocated inodes and thus will consume space on > the filesystem even though they aren't accessible. This is the premise > that background fsck operates on, btw. > > However, there is a real possibility for there being other > inconsistencies that are not safe to run with. So it sounds dangerous, but not disastrous.. Sounds like soft-updates would help this alot, so I'll turn them back on for this filesystem (I typically do use it). At a minimum, it would be awesome to even have a way to do one host rw and several doing ro. Think of the case of a web server farm, where it's nearly all reads. Thanks for the details and information! Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri May 27 03:02:21 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 95E2116A41C for ; Fri, 27 May 2005 03:02:21 +0000 (GMT) (envelope-from david.freebsd@verizon.net) Received: from vms048pub.verizon.net (vms048pub.verizon.net [206.46.252.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 604D843D1F for ; Fri, 27 May 2005 03:02:21 +0000 (GMT) (envelope-from david.freebsd@verizon.net) Received: from OSTest ([68.161.118.114]) by vms048.mailsrvcs.net (Sun Java System Messaging Server 6.2 HotFix 0.04 (built Dec 24 2004)) with ESMTPA id <0IH4004GZOFWZQG2@vms048.mailsrvcs.net> for freebsd-current@freebsd.org; Thu, 26 May 2005 22:02:21 -0500 (CDT) Date: Thu, 26 May 2005 22:06:03 -0400 From: David Gurvich To: freebsd-current@freebsd.org Message-id: <200505262206.03894.david.freebsd@verizon.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Content-disposition: inline User-Agent: KMail/1.8 Subject: libssl_p.a not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 03:02:21 -0000 During recent installworld got the message that libssl_p.a was not found. Has anyone else had this? From owner-freebsd-current@FreeBSD.ORG Fri May 27 03:43:17 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1913016A41F for ; Fri, 27 May 2005 03:43:17 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id B496E43D55 for ; Fri, 27 May 2005 03:43:16 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id j4R3h4qg069447; Thu, 26 May 2005 23:43:04 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id j4R3h4Z3069444; Thu, 26 May 2005 23:43:04 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Thu, 26 May 2005 23:43:04 -0400 (EDT) From: Andre Guibert de Bruet To: David Gilbert In-Reply-To: <17046.16853.93063.286760@canoe.dclg.ca> Message-ID: <20050526232120.Q54386@lexi.siliconlandmark.com> References: <17046.16853.93063.286760@canoe.dclg.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.543, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: freebsd-current@freebsd.org Subject: Re: usb2 and audio? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 03:43:17 -0000 On Thu, 26 May 2005, David Gilbert wrote: > I get the following when I plug my headphones into my usb2 hub: > > uaudio0: Logitech Logitech USB Headset, rev 1.10/10.12, addr 5 > uaudio0: ignored input endpoint of type adaptive > uaudio0: audio rev 1.00 > pcm1: on uaudio0 > record channel supported format list invalid > pcm1: chn_init(pcm1:record:0) failed: err = 19 > pcm1: pcm_chn_create(ua_chan, -1, 0xc401f880) failed > usb3: *** WARNING: opening low/full speed device, this does not work yet. > usb3: *** WARNING: opening low/full speed device, this does not work yet. > usb3: *** WARNING: opening low/full speed device, this does not work yet. > > ... whereas my mouse (low speed) and other usb 2.0 devices work. > > Also... when I plug the headset into the laptops port directly, it > works ... and the probe looks identical (includingt the complaints). Does the device work if you plug it into your USB hub and you do not have ehci compiled-in? Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ From owner-freebsd-current@FreeBSD.ORG Fri May 27 03:44:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3B8FF16A41C for ; Fri, 27 May 2005 03:44:56 +0000 (GMT) (envelope-from chad@shire.net) Received: from hobbiton.shire.net (hobbiton.shire.net [166.70.252.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB10343D53 for ; Fri, 27 May 2005 03:44:55 +0000 (GMT) (envelope-from chad@shire.net) Received: from [67.161.222.227] (helo=[192.168.99.68]) by hobbiton.shire.net with esmtpa (Exim 4.43) id 1DbVmI-0007Cf-Iz; Thu, 26 May 2005 21:44:55 -0600 In-Reply-To: <42968AD4.3020603@centtech.com> References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: From: "Chad Leigh -- Shire.Net LLC" Date: Thu, 26 May 2005 21:44:50 -0600 To: Eric Anderson X-Mailer: Apple Mail (2.730) X-SA-Exim-Connect-IP: 67.161.222.227 X-SA-Exim-Mail-From: chad@shire.net Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on hobbiton.shire.net X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_50 autolearn=disabled version=3.0.0 X-Spam-Level: X-SA-Exim-Version: 4.1+cvs (built Mon, 23 Aug 2004 08:44:05 -0700) X-SA-Exim-Scanned: Yes (on hobbiton.shire.net) Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 03:44:56 -0000 On May 26, 2005, at 8:49 PM, Eric Anderson wrote: > > So it sounds dangerous, but not disastrous.. Sounds like soft- > updates would help this alot, so I'll turn them back on for this > filesystem (I typically do use it). > > At a minimum, it would be awesome to even have a way to do one host > rw and several doing ro. Think of the case of a web server farm, > where it's nearly all reads. > > Thanks for the details and information! use NFS or something. Not ideal but it allows you to have lots of clients using the same space without the disasters. Chad From owner-freebsd-current@FreeBSD.ORG Fri May 27 03:53:52 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4883B16A41C for ; Fri, 27 May 2005 03:53:52 +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 AFC0F43D1F for ; Fri, 27 May 2005 03:53:49 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4R3thRJ046797; Thu, 26 May 2005 21:55:43 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <4296997C.9030700@samsco.org> Date: Thu, 26 May 2005 21:52:28 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Chad Leigh -- Shire.Net LLC" References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: FreeBSD Current , Eric Anderson Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 03:53:52 -0000 Chad Leigh -- Shire.Net LLC wrote: > > On May 26, 2005, at 8:49 PM, Eric Anderson wrote: > >> >> So it sounds dangerous, but not disastrous.. Sounds like soft- >> updates would help this alot, so I'll turn them back on for this >> filesystem (I typically do use it). >> >> At a minimum, it would be awesome to even have a way to do one host >> rw and several doing ro. Think of the case of a web server farm, >> where it's nearly all reads. >> >> Thanks for the details and information! > > > > use NFS or something. Not ideal but it allows you to have lots of > clients using the same space without the disasters. > > Chad > NFS and Coda/AFS require that you have an intelligent node, i.e. a computer, in front of each disk. The whole idea of a Fibre Channel or iSCSI SAN is that you have a network of disks connected to a network of computers, all able to communicate with each other and not have to be fronted by a computer. This is quite important for high-availability storage networks that want the reliability and scalability of not having a single computer be the choke point or single-point-of-failure for a particular set of data. Granted it's still somewhat of a niche, but as persistent storage and data mining become more part of the mainstream, it'll start becoming very important. Right now FreeBSD simply isn't an option, while Solaris, NT, and Linux are. Scott From owner-freebsd-current@FreeBSD.ORG Fri May 27 03:57:25 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CFB3916A41C for ; Fri, 27 May 2005 03:57:25 +0000 (GMT) (envelope-from chad@shire.net) Received: from hobbiton.shire.net (hobbiton.shire.net [166.70.252.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82CF343D1D for ; Fri, 27 May 2005 03:57:25 +0000 (GMT) (envelope-from chad@shire.net) Received: from [67.161.222.227] (helo=[192.168.99.68]) by hobbiton.shire.net with esmtpa (Exim 4.43) id 1DbVyO-0007yH-Ln; Thu, 26 May 2005 21:57:25 -0600 In-Reply-To: <4296997C.9030700@samsco.org> References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> <4296997C.9030700@samsco.org> Mime-Version: 1.0 (Apple Message framework v730) Message-Id: From: "Chad Leigh -- Shire.Net LLC" Date: Thu, 26 May 2005 21:57:23 -0600 To: Scott Long X-Mailer: Apple Mail (2.730) X-SA-Exim-Connect-IP: 67.161.222.227 X-SA-Exim-Mail-From: chad@shire.net Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.0.0 (2004-09-13) on hobbiton.shire.net X-Spam-Status: No, score=-0.1 required=5.0 tests=AWL,BAYES_50 autolearn=disabled version=3.0.0 X-Spam-Level: X-SA-Exim-Version: 4.1+cvs (built Mon, 23 Aug 2004 08:44:05 -0700) X-SA-Exim-Scanned: Yes (on hobbiton.shire.net) Cc: FreeBSD Current , Eric Anderson Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 03:57:25 -0000 On May 26, 2005, at 9:52 PM, Scott Long wrote: > Chad Leigh -- Shire.Net LLC wrote: > > >> On May 26, 2005, at 8:49 PM, Eric Anderson wrote: >> >>> >>> So it sounds dangerous, but not disastrous.. Sounds like soft- >>> updates would help this alot, so I'll turn them back on for this >>> filesystem (I typically do use it). >>> >>> At a minimum, it would be awesome to even have a way to do one >>> host rw and several doing ro. Think of the case of a web server >>> farm, where it's nearly all reads. >>> >>> Thanks for the details and information! >>> >> use NFS or something. Not ideal but it allows you to have lots of >> clients using the same space without the disasters. >> Chad >> > > NFS and Coda/AFS require that you have an intelligent node, i.e. a > computer, in front of each disk. The whole idea of a Fibre Channel > or iSCSI SAN is that you have a network of disks connected to a > network > of computers, all able to communicate with each other and not have to > be fronted by a computer. This is quite important for high- > availability > storage networks that want the reliability and scalability of not > having > a single computer be the choke point or single-point-of-failure for a > particular set of data. Granted it's still somewhat of a niche, > but as > persistent storage and data mining become more part of the mainstream, > it'll start becoming very important. Right now FreeBSD simply > isn't an > option, while Solaris, NT, and Linux are. And OpenVMS :-) Agreed, but as you say, FreeBSD is not there yet, and since the OP is on FreeBSD, and wants to have multiple computers attached, NFS would be one way of making that happen. And if you leave the other computers attached by the FC but not mounted, if on goes down, you can replace it with another, and switch your nfs server over. Not as ideal but doable on FreeBSD. Best Chad From owner-freebsd-current@FreeBSD.ORG Fri May 27 04:00:45 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BE61816A41C for ; Fri, 27 May 2005 04:00:45 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D60443D48 for ; Fri, 27 May 2005 04:00:45 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id j4R40geK069593; Fri, 27 May 2005 00:00:42 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id j4R40gP9069590; Fri, 27 May 2005 00:00:42 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Fri, 27 May 2005 00:00:42 -0400 (EDT) From: Andre Guibert de Bruet To: Scott Long In-Reply-To: <4296997C.9030700@samsco.org> Message-ID: <20050526235852.M54386@lexi.siliconlandmark.com> References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> <4296997C.9030700@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.543, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 04:00:45 -0000 On Thu, 26 May 2005, Scott Long wrote: > Chad Leigh -- Shire.Net LLC wrote: >> On May 26, 2005, at 8:49 PM, Eric Anderson wrote: >>> So it sounds dangerous, but not disastrous.. Sounds like soft- updates >>> would help this alot, so I'll turn them back on for this filesystem (I >>> typically do use it). >>> >>> At a minimum, it would be awesome to even have a way to do one host rw >>> and several doing ro. Think of the case of a web server farm, where it's >>> nearly all reads. >> >> use NFS or something. Not ideal but it allows you to have lots of clients >> using the same space without the disasters. > > NFS and Coda/AFS require that you have an intelligent node, i.e. a > computer, in front of each disk. The whole idea of a Fibre Channel > or iSCSI SAN is that you have a network of disks connected to a network > of computers, all able to communicate with each other and not have to > be fronted by a computer. This is quite important for high-availability > storage networks that want the reliability and scalability of not having > a single computer be the choke point or single-point-of-failure for a > particular set of data. Granted it's still somewhat of a niche, but as > persistent storage and data mining become more part of the mainstream, > it'll start becoming very important. Right now FreeBSD simply isn't an > option, while Solaris, NT, and Linux are. Fair enough. So the question becomes: What are the Linux folks doing that we aren't and how? Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ From owner-freebsd-current@FreeBSD.ORG Fri May 27 04:04:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 75D0016A41C for ; Fri, 27 May 2005 04:04:59 +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 E0FE043D48 for ; Fri, 27 May 2005 04:04:58 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4R46stC046851; Thu, 26 May 2005 22:06:54 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42969C1B.5010301@samsco.org> Date: Thu, 26 May 2005 22:03:39 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Guibert de Bruet References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> <4296997C.9030700@samsco.org> <20050526235852.M54386@lexi.siliconlandmark.com> In-Reply-To: <20050526235852.M54386@lexi.siliconlandmark.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 04:04:59 -0000 Andre Guibert de Bruet wrote: > > On Thu, 26 May 2005, Scott Long wrote: > >> Chad Leigh -- Shire.Net LLC wrote: >> >>> On May 26, 2005, at 8:49 PM, Eric Anderson wrote: >>> >>>> So it sounds dangerous, but not disastrous.. Sounds like soft- >>>> updates would help this alot, so I'll turn them back on for this >>>> filesystem (I typically do use it). >>>> >>>> At a minimum, it would be awesome to even have a way to do one host >>>> rw and several doing ro. Think of the case of a web server farm, >>>> where it's nearly all reads. >>> >>> >>> use NFS or something. Not ideal but it allows you to have lots of >>> clients using the same space without the disasters. >> >> >> NFS and Coda/AFS require that you have an intelligent node, i.e. a >> computer, in front of each disk. The whole idea of a Fibre Channel >> or iSCSI SAN is that you have a network of disks connected to a network >> of computers, all able to communicate with each other and not have to >> be fronted by a computer. This is quite important for high-availability >> storage networks that want the reliability and scalability of not having >> a single computer be the choke point or single-point-of-failure for a >> particular set of data. Granted it's still somewhat of a niche, but as >> persistent storage and data mining become more part of the mainstream, >> it'll start becoming very important. Right now FreeBSD simply isn't an >> option, while Solaris, NT, and Linux are. > > > Fair enough. So the question becomes: What are the Linux folks doing > that we aren't and how? > > Andy > RedHat offers a SAN filesystem called GFS, which they aquired when they bought Sistina several years ago. GFS was originally written for IRIX, but then ported to Linux and mostly kept there. It would be wonderful to get access to the old IRIX code and port it over, since their VFS is much more similar to ours than Linux. That's probably just wishful thinking though. The Linux source is available under the GPL, so it's a matter of either porting it over (and living with the GPL), or re-implementing the protocol (or something similar) from scratch. A few people have suggested modifying UFS to fill this role. It probably is just as much work as porting GFS, if not more, since UFS/FFS is closely tied to the buffer cache and block layers on BSD, and divorcing probably would be quite difficult. Scott Scott From owner-freebsd-current@FreeBSD.ORG Fri May 27 04:08:54 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 841F016A41C for ; Fri, 27 May 2005 04:08:54 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 204DB43D1F for ; Fri, 27 May 2005 04:08:53 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id j4R48pBo069662; Fri, 27 May 2005 00:08:51 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id j4R48pgY069659; Fri, 27 May 2005 00:08:51 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Fri, 27 May 2005 00:08:51 -0400 (EDT) From: Andre Guibert de Bruet To: "Chad Leigh -- Shire.Net LLC" In-Reply-To: Message-ID: <20050527000105.E54386@lexi.siliconlandmark.com> References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> <4296997C.9030700@samsco.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.543, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 04:08:54 -0000 On Thu, 26 May 2005, Chad Leigh -- Shire.Net LLC wrote: > Agreed, but as you say, FreeBSD is not there yet, and since the OP is on > FreeBSD, and wants to have multiple computers attached, NFS would be one way > of making that happen. And if you leave the other computers attached by the > FC but not mounted, if on goes down, you can replace it with another, and > switch your nfs server over. Not as ideal but doable on FreeBSD. This hack would not be suitable in an HA environment -- It requires human intervention or some really fugly scripts not just for the NFS server, but also for the clients. These scripts would have to figure out how to recover NFS file locking state and consistency when the backup machine fails over. It seems as if NFS in this type of setup introduces more problems than it solves. Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ From owner-freebsd-current@FreeBSD.ORG Fri May 27 04:12:23 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EDB8016A41C for ; Fri, 27 May 2005 04:12:23 +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 48ADA43D48 for ; Fri, 27 May 2005 04:12:23 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4R4EI8E046894; Thu, 26 May 2005 22:14:18 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42969DD8.4060701@samsco.org> Date: Thu, 26 May 2005 22:11:04 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Guibert de Bruet References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> <4296997C.9030700@samsco.org> <20050527000105.E54386@lexi.siliconlandmark.com> In-Reply-To: <20050527000105.E54386@lexi.siliconlandmark.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: FreeBSD Current , "Chad Leigh -- Shire.Net LLC" Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 04:12:24 -0000 Andre Guibert de Bruet wrote: > > On Thu, 26 May 2005, Chad Leigh -- Shire.Net LLC wrote: > >> Agreed, but as you say, FreeBSD is not there yet, and since the OP is >> on FreeBSD, and wants to have multiple computers attached, NFS would >> be one way of making that happen. And if you leave the other >> computers attached by the FC but not mounted, if on goes down, you can >> replace it with another, and switch your nfs server over. Not as >> ideal but doable on FreeBSD. > > > This hack would not be suitable in an HA environment -- It requires > human intervention or some really fugly scripts not just for the NFS > server, but also for the clients. These scripts would have to figure out > how to recover NFS file locking state and consistency when the backup > machine fails over. > > It seems as if NFS in this type of setup introduces more problems than > it solves. > > Andy > So what we need is some manpower. I estimate that a proof-of-concept port of GFS would take about 4-6 solid months. There is also a volume management aspect to GFS, but that is less important and the existing GEOM classes can largely fill the role already. Anyone interested in taking a serious look at it? Scott From owner-freebsd-current@FreeBSD.ORG Fri May 27 04:23:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 62AEF16A41C for ; Fri, 27 May 2005 04:23:53 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: from obsecurity.dyndns.org (CPE0050040655c8-CM00111ae02aac.cpe.net.cable.rogers.com [69.194.102.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id 09C5D43D4C for ; Fri, 27 May 2005 04:23:53 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id E2E725131A; Thu, 26 May 2005 21:24:40 -0700 (PDT) Date: Thu, 26 May 2005 21:24:40 -0700 From: Kris Kennaway To: David Gurvich Message-ID: <20050527042440.GA62464@xor.obsecurity.org> References: <200505262206.03894.david.freebsd@verizon.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="TB36FDmn/VVEgNH/" Content-Disposition: inline In-Reply-To: <200505262206.03894.david.freebsd@verizon.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: libssl_p.a not found X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 04:23:53 -0000 --TB36FDmn/VVEgNH/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, May 26, 2005 at 10:06:03PM -0400, David Gurvich wrote: > During recent installworld got the message that libssl_p.a was not found. > Has anyone else had this? Did you build world with NO_PROFILE but install world without it? Kris --TB36FDmn/VVEgNH/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFClqEIWry0BWjoQKURAjQ6AKCsQoJnAc2rQuB/Zen0rOaeuXKTKgCgjMQ2 fTq7S166yQgi5muXmig3K0Y= =l4gZ -----END PGP SIGNATURE----- --TB36FDmn/VVEgNH/-- From owner-freebsd-current@FreeBSD.ORG Fri May 27 08:37:38 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 14B9F16A41C for ; Fri, 27 May 2005 08:37:38 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail27.syd.optusnet.com.au (mail27.syd.optusnet.com.au [211.29.133.168]) by mx1.FreeBSD.org (Postfix) with ESMTP id 80C3E43D53 for ; Fri, 27 May 2005 08:37:36 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mail27.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j4R8bYxf031545 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 May 2005 18:37:35 +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 j4R8bYRx018788; Fri, 27 May 2005 18:37:34 +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 j4R8bYRL018787; Fri, 27 May 2005 18:37:34 +1000 (EST) (envelope-from pjeremy) Date: Fri, 27 May 2005 18:37:34 +1000 From: Peter Jeremy To: Ted Faber Message-ID: <20050527083734.GA18696@cirb503493.alcatel.com.au> References: <20050526001806.GA1008@pun.isi.edu> <20050526080928.GE12640@cirb503493.alcatel.com.au> <20050526160846.GA6851@pun.isi.edu> <20050526203243.GB1055@pun.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050526203243.GB1055@pun.isi.edu> User-Agent: Mutt/1.4.2i Cc: freebsd-current@freebsd.org Subject: Re: hard deadlock(?) on -current; some debugging info, need help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 08:37:38 -0000 On Thu, 2005-May-26 13:32:43 -0700, Ted Faber wrote: >On Thu, May 26, 2005 at 09:08:46AM -0700, Ted Faber wrote: >Next lock up is now. Same kernel, pics are at > >http://www.isi.edu/~faber/tmp/deadlock/DSCN048{83,84,85,86,87,88,89,90,91}.JPG After comparing it with the last URL, I worked out it was actually http://www.isi.edu/~faber/tmp/deadlock/DSCN04{83,84,85,86,87,88,89,90,91}.JPG >My inexpert reading is that one of the threads of the psi jabber client >is locked on something. "Something" why I need help. :-) There are two filesystem locks: - The psi process (pid 6936) is holding a lock on ad0s1a (probably /) The thread in question is waiting on a nfs lock. - A bash process (pid 6598) is holding an NFS lock and waiting on nfsreq According to the vnode locks, there's one process waiting on the NFS lock held by bash and 7 processes waiting on the ufs lock held by psi. Without access to the actual process and lock structures, I can't be certain but it looks very much like psi is waiting on the NFS lock held by bash (there are no other processes waiting on nfs). It's looking more like an NFS problem. I'm not sure where to go next but I'd more strongly suggest that you try to get the system running without NFS. It might be useful to know some more details about that NFS mount (fsid 0x0600ff07). Can you tell us the mount parameters and what the server is (OS type). -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Fri May 27 09:25:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DB82816A41C for ; Fri, 27 May 2005 09:25:53 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail03.syd.optusnet.com.au (mail03.syd.optusnet.com.au [211.29.132.184]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5337343D4C for ; Fri, 27 May 2005 09:25:53 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mail03.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j4R9Plqq032226 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 27 May 2005 19:25:50 +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 j4R9PlRx018840; Fri, 27 May 2005 19:25:47 +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 j4R9Pi4l018839; Fri, 27 May 2005 19:25:44 +1000 (EST) (envelope-from pjeremy) Date: Fri, 27 May 2005 19:25:44 +1000 From: Peter Jeremy To: Scott Long Message-ID: <20050527092544.GB18696@cirb503493.alcatel.com.au> References: <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> <4296997C.9030700@samsco.org> <20050526235852.M54386@lexi.siliconlandmark.com> <42969C1B.5010301@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42969C1B.5010301@samsco.org> User-Agent: Mutt/1.4.2i Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 09:25:54 -0000 On Thu, 2005-May-26 22:03:39 -0600, Scott Long wrote: >A few people have suggested modifying UFS to fill this role. It probably >is just as much work as porting GFS, if not more, since UFS/FFS is >closely tied to the buffer cache and block layers on BSD, and divorcing >probably would be quite difficult. It's probably worth noting that (AFAIK) none of the commercial vendors have managed to build a multi-master shared UFS filesystem. This suggests that the effort is considerable. Solaris clustering routes all I/O to a shared filesystem to a single 'master' node, which is responsible for all physical I/O to the disk. This would significantly simplify cache coherency management. Tru64 clustering only really supports AdvFS. Limited UFS support was added in 5.1B - all the cluster members can mount a UFS filesystem but only one can have a R/W mount and all I/O is routed through a single "master" node. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Fri May 27 11:17:31 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4E29D16A41C; Fri, 27 May 2005 11:17:31 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id D351843D53; Fri, 27 May 2005 11:17:30 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 0B004EB3E25; Fri, 27 May 2005 19:17:28 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 442C0135758; Fri, 27 May 2005 19:17:26 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 73576-13; Fri, 27 May 2005 19:17:20 +0800 (CST) Received: from [10.217.12.87] (unknown [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id 5D064135750; Fri, 27 May 2005 19:17:19 +0800 (CST) From: Xin LI To: freebsd-current@FreeBSD.org, freebsd-threads@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0gpT6ubUEdGtjeWV0vaZ" Organization: The FreeBSD Simplified Chinese Project Date: Fri, 27 May 2005 19:17:16 +0800 Message-Id: <1117192636.9676.8.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at frontfree.net Cc: Xin LI Subject: Unkillable process under SCHED_ULE and [FULL_]PREEMPTION X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 11:17:31 -0000 --=-0gpT6ubUEdGtjeWV0vaZ Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Dear folks, When I have upgraded several ports installed on my system using package, I have finally hit a bug which causes my firefox to stuck in "STOP" state, with 2 threads. When I attempt to attach gdb on the process, my laptop reboots instantly. Moreover, it is impossible to kill the firefox-bin process even with kill -9. When I go to single user mode with "kill -15 1", init will finally give me an "ps auxl advised" advise, with firefox-bin remaining. Is there anything I can provide to track down the issue, or is there some tricks that I can work on this issue by myself? The system is running fresh 6-CURRENT before <200505270607.j4R67LHU054037@repoman.freebsd.org> commit. My kernel is built with SCHED_ULE with FULL_PREEMPTION, PREEMPTION, WITESS, INVARIANTS, kdb, ddb built in, minus some hardware drivers that I don't use. More information available upon request. Thanks in advance! Cheers, --=20 Xin LI http://www.delphij.net/ --=-0gpT6ubUEdGtjeWV0vaZ Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBClwG8/cVsHxFZiIoRAiEPAJ4yJz/P6cR/gKGKc2FPyisQZmN4awCfXEB4 R+jw99sjooVnJAIXJEYtp1w= =tb8m -----END PGP SIGNATURE----- --=-0gpT6ubUEdGtjeWV0vaZ-- From owner-freebsd-current@FreeBSD.ORG Fri May 27 13:10:47 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 0222A16A41C; Fri, 27 May 2005 13:10:46 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0A1C143D49; Fri, 27 May 2005 13:10:42 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: from beastie.frontfree.net (unknown [219.239.99.7]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id C000EEB38E7; Fri, 27 May 2005 21:10:38 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 104E9130DB2; Fri, 27 May 2005 21:10:37 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75711-18; Fri, 27 May 2005 21:10:30 +0800 (CST) Received: from [10.217.12.87] (unknown [61.135.152.194]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by beastie.frontfree.net (Postfix) with ESMTP id 048C41358A8; Fri, 27 May 2005 21:10:25 +0800 (CST) From: Xin LI To: freebsd-current@FreeBSD.org In-Reply-To: <1117192636.9676.8.camel@spirit> References: <1117192636.9676.8.camel@spirit> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-hG/iNLbwITDw0rfTDxFL" Organization: The FreeBSD Simplified Chinese Project Date: Fri, 27 May 2005 21:10:23 +0800 Message-Id: <1117199423.57809.2.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port X-Virus-Scanned: by amavisd-new at frontfree.net Cc: Xin LI , freebsd-threads@FreeBSD.org Subject: Re: Unkillable process under SCHED_ULE and [FULL_]PREEMPTION X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: delphij@delphij.net List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 13:10:47 -0000 --=-hG/iNLbwITDw0rfTDxFL Content-Type: multipart/mixed; boundary="=-laGMJx4+yahJXgie/sBx" --=-laGMJx4+yahJXgie/sBx Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Okay it seems that I made some progress. Having exit from GUI and try to attach the process I got a panic and a crashdump. "bt full" output attached for reference. Cheers, --=20 Xin LI http://www.delphij.net/ --=-laGMJx4+yahJXgie/sBx Content-Disposition: attachment; filename=bt Content-Type: application/octet-stream; name=bt Content-Transfer-Encoding: base64 R05VIGdkYiA2LjEuMSBbRnJlZUJTRF0KQ29weXJpZ2h0IDIwMDQgRnJlZSBTb2Z0d2FyZSBGb3Vu ZGF0aW9uLCBJbmMuCkdEQiBpcyBmcmVlIHNvZnR3YXJlLCBjb3ZlcmVkIGJ5IHRoZSBHTlUgR2Vu ZXJhbCBQdWJsaWMgTGljZW5zZSwgYW5kIHlvdSBhcmUKd2VsY29tZSB0byBjaGFuZ2UgaXQgYW5k L29yIGRpc3RyaWJ1dGUgY29waWVzIG9mIGl0IHVuZGVyIGNlcnRhaW4gY29uZGl0aW9ucy4KVHlw ZSAic2hvdyBjb3B5aW5nIiB0byBzZWUgdGhlIGNvbmRpdGlvbnMuClRoZXJlIGlzIGFic29sdXRl bHkgbm8gd2FycmFudHkgZm9yIEdEQi4gIFR5cGUgInNob3cgd2FycmFudHkiIGZvciBkZXRhaWxz LgpUaGlzIEdEQiB3YXMgY29uZmlndXJlZCBhcyAiaTM4Ni1tYXJjZWwtZnJlZWJzZCIuCiMwICBk b2FkdW1wICgpIGF0IHBjcHUuaDoxNjUKMTY1CQlfX2FzbSBfX3ZvbGF0aWxlKCJtb3ZsICUlZnM6 MCwlMCIgOiAiPXIiICh0ZCkpOwooa2dkYikgYnQgZnVsbAojMCAgZG9hZHVtcCAoKSBhdCBwY3B1 Lmg6MTY1Ck5vIGxvY2Fscy4KIzEgIDB4YzA0NjBjMTIgaW4gZGJfZm5jYWxsIChkdW1teTE9MCwg ZHVtbXkyPTAsIGR1bW15Mz0tMTA2NzMwNDg4OSwgZHVtbXk0PTB4ZThiNGM5ZmMgIijKtOhcMjMw XDAzM2LAXDAyNMq06FwwMzDKtOhcMjIwXDAyNyIpCiAgICBhdCAvdXNyL3NyYy9zeXMvZGRiL2Ri X2NvbW1hbmQuYzo1MzEKCWZuX2FkZHIgPSAtMTA2ODQwOTY4NAoJYXJncyA9IHswIDxyZXBlYXRz IDExIHRpbWVzPn0KCW5hcmdzID0gMTEKCXJldHZhbCA9IDAKCWZ1bmMgPSAoZmNuXzEwYXJnc190 ICopIDB4YzA1MTVjYWMgPGRvYWR1bXA+Cgl0ID0gMAojMiAgMHhjMDQ2MGEyMCBpbiBkYl9jb21t YW5kIChsYXN0X2NtZHA9MHhjMDZkMjRhNCwgY21kX3RhYmxlPTB4MCwgYXV4X2NtZF90YWJsZXA9 MHhjMDY5YjZmMCwgYXV4X2NtZF90YWJsZXBfZW5kPTB4YzA2OWI2ZjQpCiAgICBhdCAvdXNyL3Ny Yy9zeXMvZGRiL2RiX2NvbW1hbmQuYzozNDkKCWNtZCA9IChzdHJ1Y3QgY29tbWFuZCAqKSAweGMw NmExMTYwCgl0ID0gMAoJbW9kaWYgPSAiKMq06FwyMzBcMDMzYsBcMDI0yrToXDAzMMq06FwyMjBc MDI3XDAwMFwwMDBcMjIwXDAyN1wwMDBcMDAw/1wwMjdcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDBc MDAw9nPAXHJcMDAwXDAwMFwwMDBcMDAw9nPAXDAwMPZzwFxyXDAwMFwwMDBcMDAwXDAwMVwwMDBc MDAwXDAwMFTKtOjLXDAyNGLAVMq06ORcMDI0YsDgwnLAwHtywHhcMDAwXDAwMFwwMDCgLW3AXGZc MDAwXDAwMFwwMDB0yrToXDAyMCpGwCa9Z8BcMDAwJ0bAXGZcMDAwXDAwMFwwMDCgLW3AslwwMzZG wCIKCWFkZHIgPSAwCgljb3VudCA9IC0xMDY3MzA0ODg5CgloYXZlX2FkZHIgPSAwCglyZXN1bHQg PSAwCiMzICAweGMwNDYwYWU4IGluIGRiX2NvbW1hbmRfbG9vcCAoKSBhdCAvdXNyL3NyYy9zeXMv ZGRiL2RiX2NvbW1hbmQuYzo0NTUKTm8gbG9jYWxzLgojNCAgMHhjMDQ2MjY2ZCBpbiBkYl90cmFw ICh0eXBlPTEyLCBjb2RlPTApIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfbWFpbi5jOjIyMQoJamIg PSB7e19qYiA9IHstMzkwODA0ODEyLCAtMzkwODA0ODMyLCAtMzkwODA0NzYwLCAtMzkwODA0NjMy LCAxMiwgLTEwNjkxNDQ1NzAsIDEyLCAtMzkwODA0NzM2LCAtMTA2ODMwMzE0NSwgCiAgICAgIC0x MDY2ODM5MTI1LCAtMTA2ODMwMzAxMiwgLTM5MDgwNDc1Nn19fQoJcHJldl9qYiA9ICh2b2lkICop IDB4MAoJYmtwdCA9IDAKIzUgIDB4YzA1MmU0ZDMgaW4ga2RiX3RyYXAgKHR5cGU9MTIsIGNvZGU9 MCwgdGY9MHhlOGI0Y2I2OCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9rZGIuYzo0NzEKCWhh bmRsZWQgPSAtMzkwODA0NjMyCiM2ICAweGMwNjM5N2U3IGluIHRyYXBfZmF0YWwgKGZyYW1lPTB4 ZThiNGNiNjgsIGV2YT03MikgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni90cmFwLmM6ODA5Cglj b2RlID0gNDAKCXR5cGUgPSAxMgoJc3MgPSA0MAoJZXNwID0gMAoJc29mdHNlZyA9IHtzc2RfYmFz ZSA9IDAsIHNzZF9saW1pdCA9IDEwNDg1NzUsIHNzZF90eXBlID0gMjcsIHNzZF9kcGwgPSAwLCBz c2RfcCA9IDEsIHNzZF94eCA9IDAsIHNzZF94eDEgPSAwLCAKICBzc2RfZGVmMzIgPSAxLCBzc2Rf Z3JhbiA9IDF9CiM3ICAweGMwNjM4Zjg2IGluIHRyYXAgKGZyYW1lPQogICAgICB7dGZfZnMgPSA4 LCB0Zl9lcyA9IC0zOTA4NTY2NjQsIHRmX2RzID0gLTEwNjg0OTg5MDQsIHRmX2VkaSA9IC0xMDM5 NjE1NDg4LCB0Zl9lc2kgPSAxNiwgdGZfZWJwID0gLTM5MDgwNDQ3NiwgdGZfaXNwID0gLTM5MDgw NDU4OCwgdGZfZWJ4ID0gLTEwNDMyMzczMTIsIHRmX2VkeCA9IC0xMDM5NjA4MjU2LCB0Zl9lY3gg PSAxLCB0Zl9lYXggPSAwLCB0Zl90cmFwbm8gPSAxMiwgdGZfZXJyID0gMiwgdGZfZWlwID0gLTEw NjgyNDI2NjYsIHRmX2NzID0gMzIsIHRmX2VmbGFncyA9IDY1NjY3LCB0Zl9lc3AgPSAtMTA2Njky OTQ4NCwgdGZfc3MgPSAxNzA3fSkgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni90cmFwLmM6MjUy Cgl0ZCA9IChzdHJ1Y3QgdGhyZWFkICopIDB4YzIwOGQ2NDAKCXAgPSAoc3RydWN0IHByb2MgKikg MHhjMjA4YjYwMAoJc3RpY2tzID0gMzkwNDE2MjY3MgoJaSA9IDAKCXVjb2RlID0gMAoJdHlwZSA9 IDEyCgljb2RlID0gMgoJZXZhID0gNzIKIzggIDB4YzA2MmNmMGEgaW4gY2FsbHRyYXAgKCkgYXQg L3Vzci9zcmMvc3lzL2kzODYvaTM4Ni9leGNlcHRpb24uczoxMzkKTm8gbG9jYWxzLgojOSAgMHgw MDAwMDAwOCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxMCAweGU4 YjQwMDI4IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzExIDB4YzA1 MDAwMjggaW4gZXhlY19tYXBfZmlyc3RfcGFnZSAoaW1ncD0weGMyMDhkNjQwKSBhdCAvdXNyL3Ny Yy9zeXMva2Vybi9rZXJuX2V4ZWMuYzo4MDMKCWkgPSAtMTA0MzIzNzMxMgoJaW5pdGlhbF9wYWdl aW4gPSAtMTAzOTYxNTQ4OAoJbWEgPSB7MHgxODcyYywgMHgxLCAweDI0NiwgMHgwLCAweGMyMDhi NjAwLCAweDAsIDB4YzIwOGQ2YjgsIDB4ZThiNGNiZjAsIDB4YzA1Mjc2ZTcsIDB4YzA2ZGJjYzAs IDB4MiwgMHhjMDY3ZDFlMiwgCiAgMHgyNTcsIDB4YzIwOGQ2NDAsIDB4ZThiNGNiZmMsIDB4MjQ2 fQoJb2JqZWN0ID0gMHgxMAojMTIgMHhjMDUzZTAxMiBpbiBwdHJhY2UgKHRkPTB4YzIwOGQ2NDAs IHVhcD0weGU4YjRjZDA0KSBhdCAvdXNyL3NyYy9zeXMva2Vybi9zeXNfcHJvY2Vzcy5jOjMzOQoJ ciA9IHtwaW9kID0ge3Bpb2Rfb3AgPSAtMTA2NjUyNjU5MiwgcGlvZF9vZmZzID0gMHgwLCBwaW9k X2FkZHIgPSAweGMwNjdmMmI0LCBwaW9kX2xlbiA9IDE3MDd9LCBwbCA9IHsKICAgIHBsX2x3cGlk ID0gLTEwNjY1MjY1OTIsIHBsX2V2ZW50ID0gMCwgcGxfZmxhZ3MgPSAtMTA2NjkyOTQ4NH0sIGRi cmVnID0ge2RyID0gezMyMjg0NDA3MDQsIDAsIDMyMjgwMzc4MTIsIDE3MDcsIAogICAgICAzMjI4 NzI3MzgwLCAzOTA0MTYyOTAwLCAzMjI2Njk4MjE0LCAzMjI4NzI3Mzc2fX0sIGZwcmVnID0ge2Zw cl9lbnYgPSB7MzIyODQ0MDcwNCwgMCwgMzIyODAzNzgxMiwgMTcwNywgMzIyODcyNzM4MCwgCiAg ICAgIDM5MDQxNjI5MDAsIDMyMjY2OTgyMTR9LCBmcHJfYWNjID0geyJQeHLARlwwMDJcMDAwXDAw MMg7IiwgImvAXDIwMKhWwUNcYlwwMDAiLCAiolwyMDdnwHjMtOjs3yIsIAogICAgICAiUMBcMjAw qFbBXDAwMVwwMDBcMDAwIiwgIu2sZ8ArXDAwMVwwMDBcMDAw2CAiLCAifMFcMDA0zbToQNZcYsIi LCAiXDIzMMy06GyxT8BcMjAwqCIsICJWwVwwMDBcMDAwXDAwMFwwMDCiXDIwN2fAIn0sIAogICAg ZnByX2V4X3N3ID0gMjExNSwgCiAgICBmcHJfcGFkID0gItggfMFcMDA0zbTovMy06CixT8DYIHzB QNZcYsJcMjAwqFbBXDAwMFwwMDBcMDAwXDAwMKJcMjA3Z8AyXGJcMDAwXDAwMFwwMDBcMDAwXDAw MFwwMDBA1lxiwlwwMDC2XGLCMM206FwwMDBcMDAwXDAwMFwwMDBA1lxiwiJ9LCByZWcgPSB7cl9m cyA9IDMyMjg0NDA3MDQsIHJfZXMgPSAwLCByX2RzID0gMzIyODAzNzgxMiwgcl9lZGkgPSAxNzA3 LCByX2VzaSA9IDMyMjg3MjczODAsIHJfZWJwID0gMzkwNDE2MjkwMCwgCiAgICByX2lzcCA9IDMy MjY2OTgyMTQsIHJfZWJ4ID0gMzIyODcyNzM3Niwgcl9lZHggPSA1ODIsIHJfZWN4ID0gMzIyODI1 MzEyOCwgcl9lYXggPSAzMjQzNjgxOTIwLCByX3RyYXBubyA9IDIxMTUsIAogICAgcl9lcnIgPSAz MjI4MDEwNDAyLCByX2VpcCA9IDM5MDQxNjI5MzYsIHJfY3MgPSAzMjI2NTI1Njc2LCByX2VmbGFn cyA9IDMyNDM2ODE5MjAsIHJfZXNwID0gMSwgcl9zcyA9IDMyMjgwMTk5NDksIAogICAgcl9ncyA9 IDI5OX19CglhZGRyID0gKHZvaWQgKikgMHgwCgllcnJvciA9IDAKIzEzIDB4YzA2MzlhOWYgaW4g c3lzY2FsbCAoZnJhbWU9CiAgICAgIHt0Zl9mcyA9IDU5LCB0Zl9lcyA9IDU5LCB0Zl9kcyA9IDU5 LCB0Zl9lZGkgPSAtMTA3Nzk0MDc5NiwgdGZfZXNpID0gNjg3LCB0Zl9lYnAgPSAtMTA3Nzk0MjEz NiwgdGZfaXNwID0gLTM5MDgwNDEyNCwgdGZfZWJ4ID0gNjg3LCB0Zl9lZHggPSA2NzQ5ODYwOTIs IHRmX2VjeCA9IDY3NDkwMzI2OCwgdGZfZWF4ID0gMjYsIHRmX3RyYXBubyA9IDEyLCB0Zl9lcnIg PSAyLCB0Zl9laXAgPSA2NzQyNjAwMTEsIHRmX2NzID0gNTEsIHRmX2VmbGFncyA9IDUxOCwgdGZf ZXNwID0gLTEwNzc5NDIxNjQsIHRmX3NzID0gNTl9KSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2 L3RyYXAuYzo5NTkKCXBhcmFtcyA9IDB4YmZiZmU4NzAgPEFkZHJlc3MgMHhiZmJmZTg3MCBvdXQg b2YgYm91bmRzPgoJY2FsbHAgPSAoc3RydWN0IHN5c2VudCAqKSAweGMwNmFmYWYwCgl0ZCA9IChz dHJ1Y3QgdGhyZWFkICopIDB4YzIwOGQ2NDAKCXAgPSAoc3RydWN0IHByb2MgKikgMHhjMjA4YjYw MAoJb3JpZ190Zl9lZmxhZ3MgPSA1MTgKCXN0aWNrcyA9IDEKCWVycm9yID0gMAoJbmFyZyA9IDQK CWFyZ3MgPSB7MTAsIDY4NywgMCwgMCwgMCwgMCwgMSwgLTEwMzk2MTY1MTJ9Cgljb2RlID0gMjYK IzE0IDB4YzA2MmNmNWYgaW4gWGludDB4ODBfc3lzY2FsbCAoKSBhdCAvdXNyL3NyYy9zeXMvaTM4 Ni9pMzg2L2V4Y2VwdGlvbi5zOjIwMApObyBsb2NhbHMuCiMxNSAweDAwMDAwMDNiIGluID8/ICgp Ck5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzE2IDB4MDAwMDAwM2IgaW4gPz8gKCkK Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTcgMHgwMDAwMDAzYiBpbiA/PyAoKQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxOCAweGJmYmZlZGM0IGluID8/ICgpCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzE5IDB4MDAwMDAyYWYgaW4gPz8gKCkKTm8g c3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjAgMHhiZmJmZTg4OCBpbiA/PyAoKQpObyBz eW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyMSAweGU4YjRjZDY0IGluID8/ICgpCk5vIHN5 bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzIyIDB4MDAwMDAyYWYgaW4gPz8gKCkKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjMgMHgyODNiNzg2YyBpbiA/PyAoKQpObyBzeW1i b2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNCAweDI4M2EzNGU0IGluID8/ICgpCk5vIHN5bWJv bCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI1IDB4MDAwMDAwMWEgaW4gPz8gKCkKTm8gc3ltYm9s IHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjYgMHgwMDAwMDAwYyBpbiA/PyAoKQpObyBzeW1ib2wg dGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNyAweDAwMDAwMDAyIGluID8/ICgpCk5vIHN5bWJvbCB0 YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI4IDB4MjgzMDY0MmIgaW4gPz8gKCkKTm8gc3ltYm9sIHRh YmxlIGluZm8gYXZhaWxhYmxlLgojMjkgMHgwMDAwMDAzMyBpbiA/PyAoKQpObyBzeW1ib2wgdGFi bGUgaW5mbyBhdmFpbGFibGUuCiMzMCAweDAwMDAwMjA2IGluID8/ICgpCk5vIHN5bWJvbCB0YWJs ZSBpbmZvIGF2YWlsYWJsZS4KIzMxIDB4YmZiZmU4NmMgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxl IGluZm8gYXZhaWxhYmxlLgojMzIgMHgwMDAwMDAzYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUg aW5mbyBhdmFpbGFibGUuCiMzMyAweDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBp bmZvIGF2YWlsYWJsZS4KIzM0IDB4MDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGlu Zm8gYXZhaWxhYmxlLgojMzUgMHgwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5m byBhdmFpbGFibGUuCiMzNiAweDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZv IGF2YWlsYWJsZS4KIzM3IDB4MWY0YjkwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8g YXZhaWxhYmxlLgojMzggMHhjMjA4ZDc5NCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBh dmFpbGFibGUuCiMzOSAweGMxNTgwZTEwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2 YWlsYWJsZS4KIzQwIDB4ZThiNGNjN2MgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLgojNDEgMHhlOGI0Y2M2NCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFp bGFibGUuCiM0MiAweGMyMDhkNjQwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWls YWJsZS4KIzQzIDB4YzA1MjY4ZTcgaW4gc2NoZWRfc3dpdGNoICh0ZD0weDJhZiwgbmV3dGQ9MHgy YWYsIGZsYWdzPTApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE0MDMKCWtlID0g KHN0cnVjdCB0ZF9zY2hlZCAqKSAweGJmYmZlZGM0CihrZ2RiKSAKIzAgIGRvYWR1bXAgKCkgYXQg cGNwdS5oOjE2NQpObyBsb2NhbHMuCiMxICAweGMwNDYwYzEyIGluIGRiX2ZuY2FsbCAoZHVtbXkx PTAsIGR1bW15Mj0wLCBkdW1teTM9LTEwNjczMDQ4ODksIGR1bW15ND0weGU4YjRjOWZjICIoyrTo XDIzMFwwMzNiwFwwMjTKtOhcMDMwyrToXDIyMFwwMjciKQogICAgYXQgL3Vzci9zcmMvc3lzL2Rk Yi9kYl9jb21tYW5kLmM6NTMxCglmbl9hZGRyID0gLTEwNjg0MDk2ODQKCWFyZ3MgPSB7MCA8cmVw ZWF0cyAxMSB0aW1lcz59CgluYXJncyA9IDExCglyZXR2YWwgPSAwCglmdW5jID0gKGZjbl8xMGFy Z3NfdCAqKSAweGMwNTE1Y2FjIDxkb2FkdW1wPgoJdCA9IDAKIzIgIDB4YzA0NjBhMjAgaW4gZGJf Y29tbWFuZCAobGFzdF9jbWRwPTB4YzA2ZDI0YTQsIGNtZF90YWJsZT0weDAsIGF1eF9jbWRfdGFi bGVwPTB4YzA2OWI2ZjAsIGF1eF9jbWRfdGFibGVwX2VuZD0weGMwNjliNmY0KQogICAgYXQgL3Vz ci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6MzQ5CgljbWQgPSAoc3RydWN0IGNvbW1hbmQgKikg MHhjMDZhMTE2MAoJdCA9IDAKCW1vZGlmID0gIijKtOhcMjMwXDAzM2LAXDAyNMq06FwwMzDKtOhc MjIwXDAyN1wwMDBcMDAwXDIyMFwwMjdcMDAwXDAwMP9cMDI3XDAwMFwwMDBcMDAwXDAwMFwwMDBc MDAwXDAwMPZzwFxyXDAwMFwwMDBcMDAwXDAwMPZzwFwwMDD2c8BcclwwMDBcMDAwXDAwMFwwMDFc MDAwXDAwMFwwMDBUyrToy1wwMjRiwFTKtOjkXDAyNGLA4MJywMB7csB4XDAwMFwwMDBcMDAwoC1t wFxmXDAwMFwwMDBcMDAwdMq06FwwMjAqRsAmvWfAXDAwMCdGwFxmXDAwMFwwMDBcMDAwoC1twLJc MDM2RsAiCglhZGRyID0gMAoJY291bnQgPSAtMTA2NzMwNDg4OQoJaGF2ZV9hZGRyID0gMAoJcmVz dWx0ID0gMAojMyAgMHhjMDQ2MGFlOCBpbiBkYl9jb21tYW5kX2xvb3AgKCkgYXQgL3Vzci9zcmMv c3lzL2RkYi9kYl9jb21tYW5kLmM6NDU1Ck5vIGxvY2Fscy4KIzQgIDB4YzA0NjI2NmQgaW4gZGJf dHJhcCAodHlwZT0xMiwgY29kZT0wKSBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX21haW4uYzoyMjEK CWpiID0ge3tfamIgPSB7LTM5MDgwNDgxMiwgLTM5MDgwNDgzMiwgLTM5MDgwNDc2MCwgLTM5MDgw NDYzMiwgMTIsIC0xMDY5MTQ0NTcwLCAxMiwgLTM5MDgwNDczNiwgLTEwNjgzMDMxNDUsIAogICAg ICAtMTA2NjgzOTEyNSwgLTEwNjgzMDMwMTIsIC0zOTA4MDQ3NTZ9fX0KCXByZXZfamIgPSAodm9p ZCAqKSAweDAKCWJrcHQgPSAwCiM1ICAweGMwNTJlNGQzIGluIGtkYl90cmFwICh0eXBlPTEyLCBj b2RlPTAsIHRmPTB4ZThiNGNiNjgpIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfa2RiLmM6NDcx CgloYW5kbGVkID0gLTM5MDgwNDYzMgojNiAgMHhjMDYzOTdlNyBpbiB0cmFwX2ZhdGFsIChmcmFt ZT0weGU4YjRjYjY4LCBldmE9NzIpIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvdHJhcC5jOjgw OQoJY29kZSA9IDQwCgl0eXBlID0gMTIKCXNzID0gNDAKCWVzcCA9IDAKCXNvZnRzZWcgPSB7c3Nk X2Jhc2UgPSAwLCBzc2RfbGltaXQgPSAxMDQ4NTc1LCBzc2RfdHlwZSA9IDI3LCBzc2RfZHBsID0g MCwgc3NkX3AgPSAxLCBzc2RfeHggPSAwLCBzc2RfeHgxID0gMCwgCiAgc3NkX2RlZjMyID0gMSwg c3NkX2dyYW4gPSAxfQojNyAgMHhjMDYzOGY4NiBpbiB0cmFwIChmcmFtZT0KICAgICAge3RmX2Zz ID0gOCwgdGZfZXMgPSAtMzkwODU2NjY0LCB0Zl9kcyA9IC0xMDY4NDk4OTA0LCB0Zl9lZGkgPSAt MTAzOTYxNTQ4OCwgdGZfZXNpID0gMTYsIHRmX2VicCA9IC0zOTA4MDQ0NzYsIHRmX2lzcCA9IC0z OTA4MDQ1ODgsIHRmX2VieCA9IC0xMDQzMjM3MzEyLCB0Zl9lZHggPSAtMTAzOTYwODI1NiwgdGZf ZWN4ID0gMSwgdGZfZWF4ID0gMCwgdGZfdHJhcG5vID0gMTIsIHRmX2VyciA9IDIsIHRmX2VpcCA9 IC0xMDY4MjQyNjY2LCB0Zl9jcyA9IDMyLCB0Zl9lZmxhZ3MgPSA2NTY2NywgdGZfZXNwID0gLTEw NjY5Mjk0ODQsIHRmX3NzID0gMTcwN30pIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvdHJhcC5j OjI1MgoJdGQgPSAoc3RydWN0IHRocmVhZCAqKSAweGMyMDhkNjQwCglwID0gKHN0cnVjdCBwcm9j ICopIDB4YzIwOGI2MDAKCXN0aWNrcyA9IDM5MDQxNjI2NzIKCWkgPSAwCgl1Y29kZSA9IDAKCXR5 cGUgPSAxMgoJY29kZSA9IDIKCWV2YSA9IDcyCiM4ICAweGMwNjJjZjBhIGluIGNhbGx0cmFwICgp IGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvZXhjZXB0aW9uLnM6MTM5Ck5vIGxvY2Fscy4KIzkg IDB4MDAwMDAwMDggaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTAg MHhlOGI0MDAyOCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxMSAw eGMwNTAwMDI4IGluIGV4ZWNfbWFwX2ZpcnN0X3BhZ2UgKGltZ3A9MHhjMjA4ZDY0MCkgYXQgL3Vz ci9zcmMvc3lzL2tlcm4va2Vybl9leGVjLmM6ODAzCglpID0gLTEwNDMyMzczMTIKCWluaXRpYWxf cGFnZWluID0gLTEwMzk2MTU0ODgKCW1hID0gezB4MTg3MmMsIDB4MSwgMHgyNDYsIDB4MCwgMHhj MjA4YjYwMCwgMHgwLCAweGMyMDhkNmI4LCAweGU4YjRjYmYwLCAweGMwNTI3NmU3LCAweGMwNmRi Y2MwLCAweDIsIDB4YzA2N2QxZTIsIAogIDB4MjU3LCAweGMyMDhkNjQwLCAweGU4YjRjYmZjLCAw eDI0Nn0KCW9iamVjdCA9IDB4MTAKIzEyIDB4YzA1M2UwMTIgaW4gcHRyYWNlICh0ZD0weGMyMDhk NjQwLCB1YXA9MHhlOGI0Y2QwNCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4vc3lzX3Byb2Nlc3MuYzoz MzkKCXIgPSB7cGlvZCA9IHtwaW9kX29wID0gLTEwNjY1MjY1OTIsIHBpb2Rfb2ZmcyA9IDB4MCwg cGlvZF9hZGRyID0gMHhjMDY3ZjJiNCwgcGlvZF9sZW4gPSAxNzA3fSwgcGwgPSB7CiAgICBwbF9s d3BpZCA9IC0xMDY2NTI2NTkyLCBwbF9ldmVudCA9IDAsIHBsX2ZsYWdzID0gLTEwNjY5Mjk0ODR9 LCBkYnJlZyA9IHtkciA9IHszMjI4NDQwNzA0LCAwLCAzMjI4MDM3ODEyLCAxNzA3LCAKICAgICAg MzIyODcyNzM4MCwgMzkwNDE2MjkwMCwgMzIyNjY5ODIxNCwgMzIyODcyNzM3Nn19LCBmcHJlZyA9 IHtmcHJfZW52ID0gezMyMjg0NDA3MDQsIDAsIDMyMjgwMzc4MTIsIDE3MDcsIDMyMjg3MjczODAs IAogICAgICAzOTA0MTYyOTAwLCAzMjI2Njk4MjE0fSwgZnByX2FjYyA9IHsiUHhywEZcMDAyXDAw MFwwMDDIOyIsICJrwFwyMDCoVsFDXGJcMDAwIiwgIqJcMjA3Z8B4zLTo7N8iLCAKICAgICAgIlDA XDIwMKhWwVwwMDFcMDAwXDAwMCIsICLtrGfAK1wwMDFcMDAwXDAwMNggIiwgInzBXDAwNM206EDW XGLCIiwgIlwyMzDMtOhssU/AXDIwMKgiLCAiVsFcMDAwXDAwMFwwMDBcMDAwolwyMDdnwCJ9LCAK ICAgIGZwcl9leF9zdyA9IDIxMTUsIAogICAgZnByX3BhZCA9ICLYIHzBXDAwNM206LzMtOgosU/A 2CB8wUDWXGLCXDIwMKhWwVwwMDBcMDAwXDAwMFwwMDCiXDIwN2fAMlxiXDAwMFwwMDBcMDAwXDAw MFwwMDBcMDAwQNZcYsJcMDAwtlxiwjDNtOhcMDAwXDAwMFwwMDBcMDAwQNZcYsIifSwgcmVnID0g e3JfZnMgPSAzMjI4NDQwNzA0LCByX2VzID0gMCwgcl9kcyA9IDMyMjgwMzc4MTIsIHJfZWRpID0g MTcwNywgcl9lc2kgPSAzMjI4NzI3MzgwLCByX2VicCA9IDM5MDQxNjI5MDAsIAogICAgcl9pc3Ag PSAzMjI2Njk4MjE0LCByX2VieCA9IDMyMjg3MjczNzYsIHJfZWR4ID0gNTgyLCByX2VjeCA9IDMy MjgyNTMxMjgsIHJfZWF4ID0gMzI0MzY4MTkyMCwgcl90cmFwbm8gPSAyMTE1LCAKICAgIHJfZXJy ID0gMzIyODAxMDQwMiwgcl9laXAgPSAzOTA0MTYyOTM2LCByX2NzID0gMzIyNjUyNTY3Niwgcl9l ZmxhZ3MgPSAzMjQzNjgxOTIwLCByX2VzcCA9IDEsIHJfc3MgPSAzMjI4MDE5OTQ5LCAKICAgIHJf Z3MgPSAyOTl9fQoJYWRkciA9ICh2b2lkICopIDB4MAoJZXJyb3IgPSAwCiMxMyAweGMwNjM5YTlm IGluIHN5c2NhbGwgKGZyYW1lPQogICAgICB7dGZfZnMgPSA1OSwgdGZfZXMgPSA1OSwgdGZfZHMg PSA1OSwgdGZfZWRpID0gLTEwNzc5NDA3OTYsIHRmX2VzaSA9IDY4NywgdGZfZWJwID0gLTEwNzc5 NDIxMzYsIHRmX2lzcCA9IC0zOTA4MDQxMjQsIHRmX2VieCA9IDY4NywgdGZfZWR4ID0gNjc0OTg2 MDkyLCB0Zl9lY3ggPSA2NzQ5MDMyNjgsIHRmX2VheCA9IDI2LCB0Zl90cmFwbm8gPSAxMiwgdGZf ZXJyID0gMiwgdGZfZWlwID0gNjc0MjYwMDExLCB0Zl9jcyA9IDUxLCB0Zl9lZmxhZ3MgPSA1MTgs IHRmX2VzcCA9IC0xMDc3OTQyMTY0LCB0Zl9zcyA9IDU5fSkgYXQgL3Vzci9zcmMvc3lzL2kzODYv aTM4Ni90cmFwLmM6OTU5CglwYXJhbXMgPSAweGJmYmZlODcwIDxBZGRyZXNzIDB4YmZiZmU4NzAg b3V0IG9mIGJvdW5kcz4KCWNhbGxwID0gKHN0cnVjdCBzeXNlbnQgKikgMHhjMDZhZmFmMAoJdGQg PSAoc3RydWN0IHRocmVhZCAqKSAweGMyMDhkNjQwCglwID0gKHN0cnVjdCBwcm9jICopIDB4YzIw OGI2MDAKCW9yaWdfdGZfZWZsYWdzID0gNTE4CglzdGlja3MgPSAxCgllcnJvciA9IDAKCW5hcmcg PSA0CglhcmdzID0gezEwLCA2ODcsIDAsIDAsIDAsIDAsIDEsIC0xMDM5NjE2NTEyfQoJY29kZSA9 IDI2CiMxNCAweGMwNjJjZjVmIGluIFhpbnQweDgwX3N5c2NhbGwgKCkgYXQgL3Vzci9zcmMvc3lz L2kzODYvaTM4Ni9leGNlcHRpb24uczoyMDAKTm8gbG9jYWxzLgojMTUgMHgwMDAwMDAzYiBpbiA/ PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxNiAweDAwMDAwMDNiIGluID8/ ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzE3IDB4MDAwMDAwM2IgaW4gPz8g KCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTggMHhiZmJmZWRjNCBpbiA/PyAo KQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxOSAweDAwMDAwMmFmIGluID8/ICgp Ck5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzIwIDB4YmZiZmU4ODggaW4gPz8gKCkK Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjEgMHhlOGI0Y2Q2NCBpbiA/PyAoKQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyMiAweDAwMDAwMmFmIGluID8/ICgpCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzIzIDB4MjgzYjc4NmMgaW4gPz8gKCkKTm8g c3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjQgMHgyODNhMzRlNCBpbiA/PyAoKQpObyBz eW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNSAweDAwMDAwMDFhIGluID8/ICgpCk5vIHN5 bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI2IDB4MDAwMDAwMGMgaW4gPz8gKCkKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjcgMHgwMDAwMDAwMiBpbiA/PyAoKQpObyBzeW1i b2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyOCAweDI4MzA2NDJiIGluID8/ICgpCk5vIHN5bWJv bCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI5IDB4MDAwMDAwMzMgaW4gPz8gKCkKTm8gc3ltYm9s IHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzAgMHgwMDAwMDIwNiBpbiA/PyAoKQpObyBzeW1ib2wg dGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMSAweGJmYmZlODZjIGluID8/ICgpCk5vIHN5bWJvbCB0 YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMyIDB4MDAwMDAwM2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRh YmxlIGluZm8gYXZhaWxhYmxlLgojMzMgMHgwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFi bGUgaW5mbyBhdmFpbGFibGUuCiMzNCAweDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJs ZSBpbmZvIGF2YWlsYWJsZS4KIzM1IDB4MDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxl IGluZm8gYXZhaWxhYmxlLgojMzYgMHgwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUg aW5mbyBhdmFpbGFibGUuCiMzNyAweDFmNGI5MDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBp bmZvIGF2YWlsYWJsZS4KIzM4IDB4YzIwOGQ3OTQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGlu Zm8gYXZhaWxhYmxlLgojMzkgMHhjMTU4MGUxMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5m byBhdmFpbGFibGUuCiM0MCAweGU4YjRjYzdjIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZv IGF2YWlsYWJsZS4KIzQxIDB4ZThiNGNjNjQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8g YXZhaWxhYmxlLgojNDIgMHhjMjA4ZDY0MCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBh dmFpbGFibGUuCiM0MyAweGMwNTI2OGU3IGluIHNjaGVkX3N3aXRjaCAodGQ9MHgyYWYsIG5ld3Rk PTB4MmFmLCBmbGFncz0wKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxNDAzCglr ZSA9IChzdHJ1Y3QgdGRfc2NoZWQgKikgMHhiZmJmZWRjNAooa2dkYikgCiMwICBkb2FkdW1wICgp IGF0IHBjcHUuaDoxNjUKTm8gbG9jYWxzLgojMSAgMHhjMDQ2MGMxMiBpbiBkYl9mbmNhbGwgKGR1 bW15MT0wLCBkdW1teTI9MCwgZHVtbXkzPS0xMDY3MzA0ODg5LCBkdW1teTQ9MHhlOGI0YzlmYyAi KMq06FwyMzBcMDMzYsBcMDI0yrToXDAzMMq06FwyMjBcMDI3IikKICAgIGF0IC91c3Ivc3JjL3N5 cy9kZGIvZGJfY29tbWFuZC5jOjUzMQoJZm5fYWRkciA9IC0xMDY4NDA5Njg0CglhcmdzID0gezAg PHJlcGVhdHMgMTEgdGltZXM+fQoJbmFyZ3MgPSAxMQoJcmV0dmFsID0gMAoJZnVuYyA9IChmY25f MTBhcmdzX3QgKikgMHhjMDUxNWNhYyA8ZG9hZHVtcD4KCXQgPSAwCiMyICAweGMwNDYwYTIwIGlu IGRiX2NvbW1hbmQgKGxhc3RfY21kcD0weGMwNmQyNGE0LCBjbWRfdGFibGU9MHgwLCBhdXhfY21k X3RhYmxlcD0weGMwNjliNmYwLCBhdXhfY21kX3RhYmxlcF9lbmQ9MHhjMDY5YjZmNCkKICAgIGF0 IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjM0OQoJY21kID0gKHN0cnVjdCBjb21tYW5k ICopIDB4YzA2YTExNjAKCXQgPSAwCgltb2RpZiA9ICIoyrToXDIzMFwwMzNiwFwwMjTKtOhcMDMw yrToXDIyMFwwMjdcMDAwXDAwMFwyMjBcMDI3XDAwMFwwMDD/XDAyN1wwMDBcMDAwXDAwMFwwMDBc MDAwXDAwMFwwMDD2c8BcclwwMDBcMDAwXDAwMFwwMDD2c8BcMDAw9nPAXHJcMDAwXDAwMFwwMDBc MDAxXDAwMFwwMDBcMDAwVMq06MtcMDI0YsBUyrTo5FwwMjRiwODCcsDAe3LAeFwwMDBcMDAwXDAw MKAtbcBcZlwwMDBcMDAwXDAwMHTKtOhcMDIwKkbAJr1nwFwwMDAnRsBcZlwwMDBcMDAwXDAwMKAt bcCyXDAzNkbAIgoJYWRkciA9IDAKCWNvdW50ID0gLTEwNjczMDQ4ODkKCWhhdmVfYWRkciA9IDAK CXJlc3VsdCA9IDAKIzMgIDB4YzA0NjBhZTggaW4gZGJfY29tbWFuZF9sb29wICgpIGF0IC91c3Iv c3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjQ1NQpObyBsb2NhbHMuCiM0ICAweGMwNDYyNjZkIGlu IGRiX3RyYXAgKHR5cGU9MTIsIGNvZGU9MCkgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9tYWluLmM6 MjIxCglqYiA9IHt7X2piID0gey0zOTA4MDQ4MTIsIC0zOTA4MDQ4MzIsIC0zOTA4MDQ3NjAsIC0z OTA4MDQ2MzIsIDEyLCAtMTA2OTE0NDU3MCwgMTIsIC0zOTA4MDQ3MzYsIC0xMDY4MzAzMTQ1LCAK ICAgICAgLTEwNjY4MzkxMjUsIC0xMDY4MzAzMDEyLCAtMzkwODA0NzU2fX19CglwcmV2X2piID0g KHZvaWQgKikgMHgwCglia3B0ID0gMAojNSAgMHhjMDUyZTRkMyBpbiBrZGJfdHJhcCAodHlwZT0x MiwgY29kZT0wLCB0Zj0weGU4YjRjYjY4KSBhdCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX2tkYi5j OjQ3MQoJaGFuZGxlZCA9IC0zOTA4MDQ2MzIKIzYgIDB4YzA2Mzk3ZTcgaW4gdHJhcF9mYXRhbCAo ZnJhbWU9MHhlOGI0Y2I2OCwgZXZhPTcyKSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L3RyYXAu Yzo4MDkKCWNvZGUgPSA0MAoJdHlwZSA9IDEyCglzcyA9IDQwCgllc3AgPSAwCglzb2Z0c2VnID0g e3NzZF9iYXNlID0gMCwgc3NkX2xpbWl0ID0gMTA0ODU3NSwgc3NkX3R5cGUgPSAyNywgc3NkX2Rw bCA9IDAsIHNzZF9wID0gMSwgc3NkX3h4ID0gMCwgc3NkX3h4MSA9IDAsIAogIHNzZF9kZWYzMiA9 IDEsIHNzZF9ncmFuID0gMX0KIzcgIDB4YzA2MzhmODYgaW4gdHJhcCAoZnJhbWU9CiAgICAgIHt0 Zl9mcyA9IDgsIHRmX2VzID0gLTM5MDg1NjY2NCwgdGZfZHMgPSAtMTA2ODQ5ODkwNCwgdGZfZWRp ID0gLTEwMzk2MTU0ODgsIHRmX2VzaSA9IDE2LCB0Zl9lYnAgPSAtMzkwODA0NDc2LCB0Zl9pc3Ag PSAtMzkwODA0NTg4LCB0Zl9lYnggPSAtMTA0MzIzNzMxMiwgdGZfZWR4ID0gLTEwMzk2MDgyNTYs IHRmX2VjeCA9IDEsIHRmX2VheCA9IDAsIHRmX3RyYXBubyA9IDEyLCB0Zl9lcnIgPSAyLCB0Zl9l aXAgPSAtMTA2ODI0MjY2NiwgdGZfY3MgPSAzMiwgdGZfZWZsYWdzID0gNjU2NjcsIHRmX2VzcCA9 IC0xMDY2OTI5NDg0LCB0Zl9zcyA9IDE3MDd9KSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L3Ry YXAuYzoyNTIKCXRkID0gKHN0cnVjdCB0aHJlYWQgKikgMHhjMjA4ZDY0MAoJcCA9IChzdHJ1Y3Qg cHJvYyAqKSAweGMyMDhiNjAwCglzdGlja3MgPSAzOTA0MTYyNjcyCglpID0gMAoJdWNvZGUgPSAw Cgl0eXBlID0gMTIKCWNvZGUgPSAyCglldmEgPSA3MgojOCAgMHhjMDYyY2YwYSBpbiBjYWxsdHJh cCAoKSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlvbi5zOjEzOQpObyBsb2NhbHMu CiM5ICAweDAwMDAwMDA4IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4K IzEwIDB4ZThiNDAwMjggaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgoj MTEgMHhjMDUwMDAyOCBpbiBleGVjX21hcF9maXJzdF9wYWdlIChpbWdwPTB4YzIwOGQ2NDApIGF0 IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhlYy5jOjgwMwoJaSA9IC0xMDQzMjM3MzEyCglpbml0 aWFsX3BhZ2VpbiA9IC0xMDM5NjE1NDg4CgltYSA9IHsweDE4NzJjLCAweDEsIDB4MjQ2LCAweDAs IDB4YzIwOGI2MDAsIDB4MCwgMHhjMjA4ZDZiOCwgMHhlOGI0Y2JmMCwgMHhjMDUyNzZlNywgMHhj MDZkYmNjMCwgMHgyLCAweGMwNjdkMWUyLCAKICAweDI1NywgMHhjMjA4ZDY0MCwgMHhlOGI0Y2Jm YywgMHgyNDZ9CglvYmplY3QgPSAweDEwCiMxMiAweGMwNTNlMDEyIGluIHB0cmFjZSAodGQ9MHhj MjA4ZDY0MCwgdWFwPTB4ZThiNGNkMDQpIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3N5c19wcm9jZXNz LmM6MzM5CglyID0ge3Bpb2QgPSB7cGlvZF9vcCA9IC0xMDY2NTI2NTkyLCBwaW9kX29mZnMgPSAw eDAsIHBpb2RfYWRkciA9IDB4YzA2N2YyYjQsIHBpb2RfbGVuID0gMTcwN30sIHBsID0gewogICAg cGxfbHdwaWQgPSAtMTA2NjUyNjU5MiwgcGxfZXZlbnQgPSAwLCBwbF9mbGFncyA9IC0xMDY2OTI5 NDg0fSwgZGJyZWcgPSB7ZHIgPSB7MzIyODQ0MDcwNCwgMCwgMzIyODAzNzgxMiwgMTcwNywgCiAg ICAgIDMyMjg3MjczODAsIDM5MDQxNjI5MDAsIDMyMjY2OTgyMTQsIDMyMjg3MjczNzZ9fSwgZnBy ZWcgPSB7ZnByX2VudiA9IHszMjI4NDQwNzA0LCAwLCAzMjI4MDM3ODEyLCAxNzA3LCAzMjI4NzI3 MzgwLCAKICAgICAgMzkwNDE2MjkwMCwgMzIyNjY5ODIxNH0sIGZwcl9hY2MgPSB7IlB4csBGXDAw MlwwMDBcMDAwyDsiLCAia8BcMjAwqFbBQ1xiXDAwMCIsICKiXDIwN2fAeMy06OzfIiwgCiAgICAg ICJQwFwyMDCoVsFcMDAxXDAwMFwwMDAiLCAi7axnwCtcMDAxXDAwMFwwMDDYICIsICJ8wVwwMDTN tOhA1lxiwiIsICJcMjMwzLTobLFPwFwyMDCoIiwgIlbBXDAwMFwwMDBcMDAwXDAwMKJcMjA3Z8Ai fSwgCiAgICBmcHJfZXhfc3cgPSAyMTE1LCAKICAgIGZwcl9wYWQgPSAi2CB8wVwwMDTNtOi8zLTo KLFPwNggfMFA1lxiwlwyMDCoVsFcMDAwXDAwMFwwMDBcMDAwolwyMDdnwDJcYlwwMDBcMDAwXDAw MFwwMDBcMDAwXDAwMEDWXGLCXDAwMLZcYsIwzbToXDAwMFwwMDBcMDAwXDAwMEDWXGLCIn0sIHJl ZyA9IHtyX2ZzID0gMzIyODQ0MDcwNCwgcl9lcyA9IDAsIHJfZHMgPSAzMjI4MDM3ODEyLCByX2Vk aSA9IDE3MDcsIHJfZXNpID0gMzIyODcyNzM4MCwgcl9lYnAgPSAzOTA0MTYyOTAwLCAKICAgIHJf aXNwID0gMzIyNjY5ODIxNCwgcl9lYnggPSAzMjI4NzI3Mzc2LCByX2VkeCA9IDU4Miwgcl9lY3gg PSAzMjI4MjUzMTI4LCByX2VheCA9IDMyNDM2ODE5MjAsIHJfdHJhcG5vID0gMjExNSwgCiAgICBy X2VyciA9IDMyMjgwMTA0MDIsIHJfZWlwID0gMzkwNDE2MjkzNiwgcl9jcyA9IDMyMjY1MjU2NzYs IHJfZWZsYWdzID0gMzI0MzY4MTkyMCwgcl9lc3AgPSAxLCByX3NzID0gMzIyODAxOTk0OSwgCiAg ICByX2dzID0gMjk5fX0KCWFkZHIgPSAodm9pZCAqKSAweDAKCWVycm9yID0gMAojMTMgMHhjMDYz OWE5ZiBpbiBzeXNjYWxsIChmcmFtZT0KICAgICAge3RmX2ZzID0gNTksIHRmX2VzID0gNTksIHRm X2RzID0gNTksIHRmX2VkaSA9IC0xMDc3OTQwNzk2LCB0Zl9lc2kgPSA2ODcsIHRmX2VicCA9IC0x MDc3OTQyMTM2LCB0Zl9pc3AgPSAtMzkwODA0MTI0LCB0Zl9lYnggPSA2ODcsIHRmX2VkeCA9IDY3 NDk4NjA5MiwgdGZfZWN4ID0gNjc0OTAzMjY4LCB0Zl9lYXggPSAyNiwgdGZfdHJhcG5vID0gMTIs IHRmX2VyciA9IDIsIHRmX2VpcCA9IDY3NDI2MDAxMSwgdGZfY3MgPSA1MSwgdGZfZWZsYWdzID0g NTE4LCB0Zl9lc3AgPSAtMTA3Nzk0MjE2NCwgdGZfc3MgPSA1OX0pIGF0IC91c3Ivc3JjL3N5cy9p Mzg2L2kzODYvdHJhcC5jOjk1OQoJcGFyYW1zID0gMHhiZmJmZTg3MCA8QWRkcmVzcyAweGJmYmZl ODcwIG91dCBvZiBib3VuZHM+CgljYWxscCA9IChzdHJ1Y3Qgc3lzZW50ICopIDB4YzA2YWZhZjAK CXRkID0gKHN0cnVjdCB0aHJlYWQgKikgMHhjMjA4ZDY0MAoJcCA9IChzdHJ1Y3QgcHJvYyAqKSAw eGMyMDhiNjAwCglvcmlnX3RmX2VmbGFncyA9IDUxOAoJc3RpY2tzID0gMQoJZXJyb3IgPSAwCglu YXJnID0gNAoJYXJncyA9IHsxMCwgNjg3LCAwLCAwLCAwLCAwLCAxLCAtMTAzOTYxNjUxMn0KCWNv ZGUgPSAyNgojMTQgMHhjMDYyY2Y1ZiBpbiBYaW50MHg4MF9zeXNjYWxsICgpIGF0IC91c3Ivc3Jj L3N5cy9pMzg2L2kzODYvZXhjZXB0aW9uLnM6MjAwCk5vIGxvY2Fscy4KIzE1IDB4MDAwMDAwM2Ig aW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTYgMHgwMDAwMDAzYiBp biA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxNyAweDAwMDAwMDNiIGlu ID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzE4IDB4YmZiZmVkYzQgaW4g Pz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTkgMHgwMDAwMDJhZiBpbiA/ PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyMCAweGJmYmZlODg4IGluID8/ ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzIxIDB4ZThiNGNkNjQgaW4gPz8g KCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjIgMHgwMDAwMDJhZiBpbiA/PyAo KQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyMyAweDI4M2I3ODZjIGluID8/ICgp Ck5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI0IDB4MjgzYTM0ZTQgaW4gPz8gKCkK Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjUgMHgwMDAwMDAxYSBpbiA/PyAoKQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNiAweDAwMDAwMDBjIGluID8/ICgpCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI3IDB4MDAwMDAwMDIgaW4gPz8gKCkKTm8g c3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjggMHgyODMwNjQyYiBpbiA/PyAoKQpObyBz eW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyOSAweDAwMDAwMDMzIGluID8/ICgpCk5vIHN5 bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMwIDB4MDAwMDAyMDYgaW4gPz8gKCkKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzEgMHhiZmJmZTg2YyBpbiA/PyAoKQpObyBzeW1i b2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMiAweDAwMDAwMDNiIGluID8/ICgpCk5vIHN5bWJv bCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMzIDB4MDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9s IHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzQgMHgwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wg dGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNSAweDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0 YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM2IDB4MDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRh YmxlIGluZm8gYXZhaWxhYmxlLgojMzcgMHgxZjRiOTAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFi bGUgaW5mbyBhdmFpbGFibGUuCiMzOCAweGMyMDhkNzk0IGluID8/ICgpCk5vIHN5bWJvbCB0YWJs ZSBpbmZvIGF2YWlsYWJsZS4KIzM5IDB4YzE1ODBlMTAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxl IGluZm8gYXZhaWxhYmxlLgojNDAgMHhlOGI0Y2M3YyBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUg aW5mbyBhdmFpbGFibGUuCiM0MSAweGU4YjRjYzY0IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBp bmZvIGF2YWlsYWJsZS4KIzQyIDB4YzIwOGQ2NDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGlu Zm8gYXZhaWxhYmxlLgojNDMgMHhjMDUyNjhlNyBpbiBzY2hlZF9zd2l0Y2ggKHRkPTB4MmFmLCBu ZXd0ZD0weDJhZiwgZmxhZ3M9MCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTQw MwoJa2UgPSAoc3RydWN0IHRkX3NjaGVkICopIDB4YmZiZmVkYzQKKGtnZGIpIAojMCAgZG9hZHVt cCAoKSBhdCBwY3B1Lmg6MTY1Ck5vIGxvY2Fscy4KIzEgIDB4YzA0NjBjMTIgaW4gZGJfZm5jYWxs IChkdW1teTE9MCwgZHVtbXkyPTAsIGR1bW15Mz0tMTA2NzMwNDg4OSwgZHVtbXk0PTB4ZThiNGM5 ZmMgIijKtOhcMjMwXDAzM2LAXDAyNMq06FwwMzDKtOhcMjIwXDAyNyIpCiAgICBhdCAvdXNyL3Ny Yy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo1MzEKCWZuX2FkZHIgPSAtMTA2ODQwOTY4NAoJYXJncyA9 IHswIDxyZXBlYXRzIDExIHRpbWVzPn0KCW5hcmdzID0gMTEKCXJldHZhbCA9IDAKCWZ1bmMgPSAo ZmNuXzEwYXJnc190ICopIDB4YzA1MTVjYWMgPGRvYWR1bXA+Cgl0ID0gMAojMiAgMHhjMDQ2MGEy MCBpbiBkYl9jb21tYW5kIChsYXN0X2NtZHA9MHhjMDZkMjRhNCwgY21kX3RhYmxlPTB4MCwgYXV4 X2NtZF90YWJsZXA9MHhjMDY5YjZmMCwgYXV4X2NtZF90YWJsZXBfZW5kPTB4YzA2OWI2ZjQpCiAg ICBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQuYzozNDkKCWNtZCA9IChzdHJ1Y3QgY29t bWFuZCAqKSAweGMwNmExMTYwCgl0ID0gMAoJbW9kaWYgPSAiKMq06FwyMzBcMDMzYsBcMDI0yrTo XDAzMMq06FwyMjBcMDI3XDAwMFwwMDBcMjIwXDAyN1wwMDBcMDAw/1wwMjdcMDAwXDAwMFwwMDBc MDAwXDAwMFwwMDBcMDAw9nPAXHJcMDAwXDAwMFwwMDBcMDAw9nPAXDAwMPZzwFxyXDAwMFwwMDBc MDAwXDAwMVwwMDBcMDAwXDAwMFTKtOjLXDAyNGLAVMq06ORcMDI0YsDgwnLAwHtywHhcMDAwXDAw MFwwMDCgLW3AXGZcMDAwXDAwMFwwMDB0yrToXDAyMCpGwCa9Z8BcMDAwJ0bAXGZcMDAwXDAwMFww MDCgLW3AslwwMzZGwCIKCWFkZHIgPSAwCgljb3VudCA9IC0xMDY3MzA0ODg5CgloYXZlX2FkZHIg PSAwCglyZXN1bHQgPSAwCiMzICAweGMwNDYwYWU4IGluIGRiX2NvbW1hbmRfbG9vcCAoKSBhdCAv dXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo0NTUKTm8gbG9jYWxzLgojNCAgMHhjMDQ2MjY2 ZCBpbiBkYl90cmFwICh0eXBlPTEyLCBjb2RlPTApIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfbWFp bi5jOjIyMQoJamIgPSB7e19qYiA9IHstMzkwODA0ODEyLCAtMzkwODA0ODMyLCAtMzkwODA0NzYw LCAtMzkwODA0NjMyLCAxMiwgLTEwNjkxNDQ1NzAsIDEyLCAtMzkwODA0NzM2LCAtMTA2ODMwMzE0 NSwgCiAgICAgIC0xMDY2ODM5MTI1LCAtMTA2ODMwMzAxMiwgLTM5MDgwNDc1Nn19fQoJcHJldl9q YiA9ICh2b2lkICopIDB4MAoJYmtwdCA9IDAKIzUgIDB4YzA1MmU0ZDMgaW4ga2RiX3RyYXAgKHR5 cGU9MTIsIGNvZGU9MCwgdGY9MHhlOGI0Y2I2OCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9r ZGIuYzo0NzEKCWhhbmRsZWQgPSAtMzkwODA0NjMyCiM2ICAweGMwNjM5N2U3IGluIHRyYXBfZmF0 YWwgKGZyYW1lPTB4ZThiNGNiNjgsIGV2YT03MikgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni90 cmFwLmM6ODA5Cgljb2RlID0gNDAKCXR5cGUgPSAxMgoJc3MgPSA0MAoJZXNwID0gMAoJc29mdHNl ZyA9IHtzc2RfYmFzZSA9IDAsIHNzZF9saW1pdCA9IDEwNDg1NzUsIHNzZF90eXBlID0gMjcsIHNz ZF9kcGwgPSAwLCBzc2RfcCA9IDEsIHNzZF94eCA9IDAsIHNzZF94eDEgPSAwLCAKICBzc2RfZGVm MzIgPSAxLCBzc2RfZ3JhbiA9IDF9CiM3ICAweGMwNjM4Zjg2IGluIHRyYXAgKGZyYW1lPQogICAg ICB7dGZfZnMgPSA4LCB0Zl9lcyA9IC0zOTA4NTY2NjQsIHRmX2RzID0gLTEwNjg0OTg5MDQsIHRm X2VkaSA9IC0xMDM5NjE1NDg4LCB0Zl9lc2kgPSAxNiwgdGZfZWJwID0gLTM5MDgwNDQ3NiwgdGZf aXNwID0gLTM5MDgwNDU4OCwgdGZfZWJ4ID0gLTEwNDMyMzczMTIsIHRmX2VkeCA9IC0xMDM5NjA4 MjU2LCB0Zl9lY3ggPSAxLCB0Zl9lYXggPSAwLCB0Zl90cmFwbm8gPSAxMiwgdGZfZXJyID0gMiwg dGZfZWlwID0gLTEwNjgyNDI2NjYsIHRmX2NzID0gMzIsIHRmX2VmbGFncyA9IDY1NjY3LCB0Zl9l c3AgPSAtMTA2NjkyOTQ4NCwgdGZfc3MgPSAxNzA3fSkgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4 Ni90cmFwLmM6MjUyCgl0ZCA9IChzdHJ1Y3QgdGhyZWFkICopIDB4YzIwOGQ2NDAKCXAgPSAoc3Ry dWN0IHByb2MgKikgMHhjMjA4YjYwMAoJc3RpY2tzID0gMzkwNDE2MjY3MgoJaSA9IDAKCXVjb2Rl ID0gMAoJdHlwZSA9IDEyCgljb2RlID0gMgoJZXZhID0gNzIKIzggIDB4YzA2MmNmMGEgaW4gY2Fs bHRyYXAgKCkgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni9leGNlcHRpb24uczoxMzkKTm8gbG9j YWxzLgojOSAgMHgwMDAwMDAwOCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFi bGUuCiMxMCAweGU4YjQwMDI4IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJs ZS4KIzExIDB4YzA1MDAwMjggaW4gZXhlY19tYXBfZmlyc3RfcGFnZSAoaW1ncD0weGMyMDhkNjQw KSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4ZWMuYzo4MDMKCWkgPSAtMTA0MzIzNzMxMgoJ aW5pdGlhbF9wYWdlaW4gPSAtMTAzOTYxNTQ4OAoJbWEgPSB7MHgxODcyYywgMHgxLCAweDI0Niwg MHgwLCAweGMyMDhiNjAwLCAweDAsIDB4YzIwOGQ2YjgsIDB4ZThiNGNiZjAsIDB4YzA1Mjc2ZTcs IDB4YzA2ZGJjYzAsIDB4MiwgMHhjMDY3ZDFlMiwgCiAgMHgyNTcsIDB4YzIwOGQ2NDAsIDB4ZThi NGNiZmMsIDB4MjQ2fQoJb2JqZWN0ID0gMHgxMAojMTIgMHhjMDUzZTAxMiBpbiBwdHJhY2UgKHRk PTB4YzIwOGQ2NDAsIHVhcD0weGU4YjRjZDA0KSBhdCAvdXNyL3NyYy9zeXMva2Vybi9zeXNfcHJv Y2Vzcy5jOjMzOQoJciA9IHtwaW9kID0ge3Bpb2Rfb3AgPSAtMTA2NjUyNjU5MiwgcGlvZF9vZmZz ID0gMHgwLCBwaW9kX2FkZHIgPSAweGMwNjdmMmI0LCBwaW9kX2xlbiA9IDE3MDd9LCBwbCA9IHsK ICAgIHBsX2x3cGlkID0gLTEwNjY1MjY1OTIsIHBsX2V2ZW50ID0gMCwgcGxfZmxhZ3MgPSAtMTA2 NjkyOTQ4NH0sIGRicmVnID0ge2RyID0gezMyMjg0NDA3MDQsIDAsIDMyMjgwMzc4MTIsIDE3MDcs IAogICAgICAzMjI4NzI3MzgwLCAzOTA0MTYyOTAwLCAzMjI2Njk4MjE0LCAzMjI4NzI3Mzc2fX0s IGZwcmVnID0ge2Zwcl9lbnYgPSB7MzIyODQ0MDcwNCwgMCwgMzIyODAzNzgxMiwgMTcwNywgMzIy ODcyNzM4MCwgCiAgICAgIDM5MDQxNjI5MDAsIDMyMjY2OTgyMTR9LCBmcHJfYWNjID0geyJQeHLA RlwwMDJcMDAwXDAwMMg7IiwgImvAXDIwMKhWwUNcYlwwMDAiLCAiolwyMDdnwHjMtOjs3yIsIAog ICAgICAiUMBcMjAwqFbBXDAwMVwwMDBcMDAwIiwgIu2sZ8ArXDAwMVwwMDBcMDAw2CAiLCAifMFc MDA0zbToQNZcYsIiLCAiXDIzMMy06GyxT8BcMjAwqCIsICJWwVwwMDBcMDAwXDAwMFwwMDCiXDIw N2fAIn0sIAogICAgZnByX2V4X3N3ID0gMjExNSwgCiAgICBmcHJfcGFkID0gItggfMFcMDA0zbTo vMy06CixT8DYIHzBQNZcYsJcMjAwqFbBXDAwMFwwMDBcMDAwXDAwMKJcMjA3Z8AyXGJcMDAwXDAw MFwwMDBcMDAwXDAwMFwwMDBA1lxiwlwwMDC2XGLCMM206FwwMDBcMDAwXDAwMFwwMDBA1lxiwiJ9 LCByZWcgPSB7cl9mcyA9IDMyMjg0NDA3MDQsIHJfZXMgPSAwLCByX2RzID0gMzIyODAzNzgxMiwg cl9lZGkgPSAxNzA3LCByX2VzaSA9IDMyMjg3MjczODAsIHJfZWJwID0gMzkwNDE2MjkwMCwgCiAg ICByX2lzcCA9IDMyMjY2OTgyMTQsIHJfZWJ4ID0gMzIyODcyNzM3Niwgcl9lZHggPSA1ODIsIHJf ZWN4ID0gMzIyODI1MzEyOCwgcl9lYXggPSAzMjQzNjgxOTIwLCByX3RyYXBubyA9IDIxMTUsIAog ICAgcl9lcnIgPSAzMjI4MDEwNDAyLCByX2VpcCA9IDM5MDQxNjI5MzYsIHJfY3MgPSAzMjI2NTI1 Njc2LCByX2VmbGFncyA9IDMyNDM2ODE5MjAsIHJfZXNwID0gMSwgcl9zcyA9IDMyMjgwMTk5NDks IAogICAgcl9ncyA9IDI5OX19CglhZGRyID0gKHZvaWQgKikgMHgwCgllcnJvciA9IDAKIzEzIDB4 YzA2MzlhOWYgaW4gc3lzY2FsbCAoZnJhbWU9CiAgICAgIHt0Zl9mcyA9IDU5LCB0Zl9lcyA9IDU5 LCB0Zl9kcyA9IDU5LCB0Zl9lZGkgPSAtMTA3Nzk0MDc5NiwgdGZfZXNpID0gNjg3LCB0Zl9lYnAg PSAtMTA3Nzk0MjEzNiwgdGZfaXNwID0gLTM5MDgwNDEyNCwgdGZfZWJ4ID0gNjg3LCB0Zl9lZHgg PSA2NzQ5ODYwOTIsIHRmX2VjeCA9IDY3NDkwMzI2OCwgdGZfZWF4ID0gMjYsIHRmX3RyYXBubyA9 IDEyLCB0Zl9lcnIgPSAyLCB0Zl9laXAgPSA2NzQyNjAwMTEsIHRmX2NzID0gNTEsIHRmX2VmbGFn cyA9IDUxOCwgdGZfZXNwID0gLTEwNzc5NDIxNjQsIHRmX3NzID0gNTl9KSBhdCAvdXNyL3NyYy9z eXMvaTM4Ni9pMzg2L3RyYXAuYzo5NTkKCXBhcmFtcyA9IDB4YmZiZmU4NzAgPEFkZHJlc3MgMHhi ZmJmZTg3MCBvdXQgb2YgYm91bmRzPgoJY2FsbHAgPSAoc3RydWN0IHN5c2VudCAqKSAweGMwNmFm YWYwCgl0ZCA9IChzdHJ1Y3QgdGhyZWFkICopIDB4YzIwOGQ2NDAKCXAgPSAoc3RydWN0IHByb2Mg KikgMHhjMjA4YjYwMAoJb3JpZ190Zl9lZmxhZ3MgPSA1MTgKCXN0aWNrcyA9IDEKCWVycm9yID0g MAoJbmFyZyA9IDQKCWFyZ3MgPSB7MTAsIDY4NywgMCwgMCwgMCwgMCwgMSwgLTEwMzk2MTY1MTJ9 Cgljb2RlID0gMjYKIzE0IDB4YzA2MmNmNWYgaW4gWGludDB4ODBfc3lzY2FsbCAoKSBhdCAvdXNy L3NyYy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlvbi5zOjIwMApObyBsb2NhbHMuCiMxNSAweDAwMDAw MDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzE2IDB4MDAwMDAw M2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTcgMHgwMDAwMDAz YiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxOCAweGJmYmZlZGM0 IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzE5IDB4MDAwMDAyYWYg aW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjAgMHhiZmJmZTg4OCBp biA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyMSAweGU4YjRjZDY0IGlu ID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzIyIDB4MDAwMDAyYWYgaW4g Pz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjMgMHgyODNiNzg2YyBpbiA/ PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNCAweDI4M2EzNGU0IGluID8/ ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI1IDB4MDAwMDAwMWEgaW4gPz8g KCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjYgMHgwMDAwMDAwYyBpbiA/PyAo KQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNyAweDAwMDAwMDAyIGluID8/ICgp Ck5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI4IDB4MjgzMDY0MmIgaW4gPz8gKCkK Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjkgMHgwMDAwMDAzMyBpbiA/PyAoKQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMCAweDAwMDAwMjA2IGluID8/ICgpCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMxIDB4YmZiZmU4NmMgaW4gPz8gKCkKTm8g c3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzIgMHgwMDAwMDAzYiBpbiA/PyAoKQpObyBz eW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMyAweDAwMDAwMDAwIGluID8/ICgpCk5vIHN5 bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM0IDB4MDAwMDAwMDAgaW4gPz8gKCkKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzUgMHgwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1i b2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNiAweDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJv bCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM3IDB4MWY0YjkwMDAgaW4gPz8gKCkKTm8gc3ltYm9s IHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzggMHhjMjA4ZDc5NCBpbiA/PyAoKQpObyBzeW1ib2wg dGFibGUgaW5mbyBhdmFpbGFibGUuCiMzOSAweGMxNTgwZTEwIGluID8/ICgpCk5vIHN5bWJvbCB0 YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQwIDB4ZThiNGNjN2MgaW4gPz8gKCkKTm8gc3ltYm9sIHRh YmxlIGluZm8gYXZhaWxhYmxlLgojNDEgMHhlOGI0Y2M2NCBpbiA/PyAoKQpObyBzeW1ib2wgdGFi bGUgaW5mbyBhdmFpbGFibGUuCiM0MiAweGMyMDhkNjQwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJs ZSBpbmZvIGF2YWlsYWJsZS4KIzQzIDB4YzA1MjY4ZTcgaW4gc2NoZWRfc3dpdGNoICh0ZD0weDJh ZiwgbmV3dGQ9MHgyYWYsIGZsYWdzPTApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5j OjE0MDMKCWtlID0gKHN0cnVjdCB0ZF9zY2hlZCAqKSAweGJmYmZlZGM0CihrZ2RiKSAKIzAgIGRv YWR1bXAgKCkgYXQgcGNwdS5oOjE2NQpObyBsb2NhbHMuCiMxICAweGMwNDYwYzEyIGluIGRiX2Zu Y2FsbCAoZHVtbXkxPTAsIGR1bW15Mj0wLCBkdW1teTM9LTEwNjczMDQ4ODksIGR1bW15ND0weGU4 YjRjOWZjICIoyrToXDIzMFwwMzNiwFwwMjTKtOhcMDMwyrToXDIyMFwwMjciKQogICAgYXQgL3Vz ci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6NTMxCglmbl9hZGRyID0gLTEwNjg0MDk2ODQKCWFy Z3MgPSB7MCA8cmVwZWF0cyAxMSB0aW1lcz59CgluYXJncyA9IDExCglyZXR2YWwgPSAwCglmdW5j ID0gKGZjbl8xMGFyZ3NfdCAqKSAweGMwNTE1Y2FjIDxkb2FkdW1wPgoJdCA9IDAKIzIgIDB4YzA0 NjBhMjAgaW4gZGJfY29tbWFuZCAobGFzdF9jbWRwPTB4YzA2ZDI0YTQsIGNtZF90YWJsZT0weDAs IGF1eF9jbWRfdGFibGVwPTB4YzA2OWI2ZjAsIGF1eF9jbWRfdGFibGVwX2VuZD0weGMwNjliNmY0 KQogICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6MzQ5CgljbWQgPSAoc3RydWN0 IGNvbW1hbmQgKikgMHhjMDZhMTE2MAoJdCA9IDAKCW1vZGlmID0gIijKtOhcMjMwXDAzM2LAXDAy NMq06FwwMzDKtOhcMjIwXDAyN1wwMDBcMDAwXDIyMFwwMjdcMDAwXDAwMP9cMDI3XDAwMFwwMDBc MDAwXDAwMFwwMDBcMDAwXDAwMPZzwFxyXDAwMFwwMDBcMDAwXDAwMPZzwFwwMDD2c8BcclwwMDBc MDAwXDAwMFwwMDFcMDAwXDAwMFwwMDBUyrToy1wwMjRiwFTKtOjkXDAyNGLA4MJywMB7csB4XDAw MFwwMDBcMDAwoC1twFxmXDAwMFwwMDBcMDAwdMq06FwwMjAqRsAmvWfAXDAwMCdGwFxmXDAwMFww MDBcMDAwoC1twLJcMDM2RsAiCglhZGRyID0gMAoJY291bnQgPSAtMTA2NzMwNDg4OQoJaGF2ZV9h ZGRyID0gMAoJcmVzdWx0ID0gMAojMyAgMHhjMDQ2MGFlOCBpbiBkYl9jb21tYW5kX2xvb3AgKCkg YXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6NDU1Ck5vIGxvY2Fscy4KIzQgIDB4YzA0 NjI2NmQgaW4gZGJfdHJhcCAodHlwZT0xMiwgY29kZT0wKSBhdCAvdXNyL3NyYy9zeXMvZGRiL2Ri X21haW4uYzoyMjEKCWpiID0ge3tfamIgPSB7LTM5MDgwNDgxMiwgLTM5MDgwNDgzMiwgLTM5MDgw NDc2MCwgLTM5MDgwNDYzMiwgMTIsIC0xMDY5MTQ0NTcwLCAxMiwgLTM5MDgwNDczNiwgLTEwNjgz MDMxNDUsIAogICAgICAtMTA2NjgzOTEyNSwgLTEwNjgzMDMwMTIsIC0zOTA4MDQ3NTZ9fX0KCXBy ZXZfamIgPSAodm9pZCAqKSAweDAKCWJrcHQgPSAwCiM1ICAweGMwNTJlNGQzIGluIGtkYl90cmFw ICh0eXBlPTEyLCBjb2RlPTAsIHRmPTB4ZThiNGNiNjgpIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3N1 YnJfa2RiLmM6NDcxCgloYW5kbGVkID0gLTM5MDgwNDYzMgojNiAgMHhjMDYzOTdlNyBpbiB0cmFw X2ZhdGFsIChmcmFtZT0weGU4YjRjYjY4LCBldmE9NzIpIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kz ODYvdHJhcC5jOjgwOQoJY29kZSA9IDQwCgl0eXBlID0gMTIKCXNzID0gNDAKCWVzcCA9IDAKCXNv ZnRzZWcgPSB7c3NkX2Jhc2UgPSAwLCBzc2RfbGltaXQgPSAxMDQ4NTc1LCBzc2RfdHlwZSA9IDI3 LCBzc2RfZHBsID0gMCwgc3NkX3AgPSAxLCBzc2RfeHggPSAwLCBzc2RfeHgxID0gMCwgCiAgc3Nk X2RlZjMyID0gMSwgc3NkX2dyYW4gPSAxfQojNyAgMHhjMDYzOGY4NiBpbiB0cmFwIChmcmFtZT0K ICAgICAge3RmX2ZzID0gOCwgdGZfZXMgPSAtMzkwODU2NjY0LCB0Zl9kcyA9IC0xMDY4NDk4OTA0 LCB0Zl9lZGkgPSAtMTAzOTYxNTQ4OCwgdGZfZXNpID0gMTYsIHRmX2VicCA9IC0zOTA4MDQ0NzYs IHRmX2lzcCA9IC0zOTA4MDQ1ODgsIHRmX2VieCA9IC0xMDQzMjM3MzEyLCB0Zl9lZHggPSAtMTAz OTYwODI1NiwgdGZfZWN4ID0gMSwgdGZfZWF4ID0gMCwgdGZfdHJhcG5vID0gMTIsIHRmX2VyciA9 IDIsIHRmX2VpcCA9IC0xMDY4MjQyNjY2LCB0Zl9jcyA9IDMyLCB0Zl9lZmxhZ3MgPSA2NTY2Nywg dGZfZXNwID0gLTEwNjY5Mjk0ODQsIHRmX3NzID0gMTcwN30pIGF0IC91c3Ivc3JjL3N5cy9pMzg2 L2kzODYvdHJhcC5jOjI1MgoJdGQgPSAoc3RydWN0IHRocmVhZCAqKSAweGMyMDhkNjQwCglwID0g KHN0cnVjdCBwcm9jICopIDB4YzIwOGI2MDAKCXN0aWNrcyA9IDM5MDQxNjI2NzIKCWkgPSAwCgl1 Y29kZSA9IDAKCXR5cGUgPSAxMgoJY29kZSA9IDIKCWV2YSA9IDcyCiM4ICAweGMwNjJjZjBhIGlu IGNhbGx0cmFwICgpIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvZXhjZXB0aW9uLnM6MTM5Ck5v IGxvY2Fscy4KIzkgIDB4MDAwMDAwMDggaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLgojMTAgMHhlOGI0MDAyOCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFp bGFibGUuCiMxMSAweGMwNTAwMDI4IGluIGV4ZWNfbWFwX2ZpcnN0X3BhZ2UgKGltZ3A9MHhjMjA4 ZDY0MCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGVjLmM6ODAzCglpID0gLTEwNDMyMzcz MTIKCWluaXRpYWxfcGFnZWluID0gLTEwMzk2MTU0ODgKCW1hID0gezB4MTg3MmMsIDB4MSwgMHgy NDYsIDB4MCwgMHhjMjA4YjYwMCwgMHgwLCAweGMyMDhkNmI4LCAweGU4YjRjYmYwLCAweGMwNTI3 NmU3LCAweGMwNmRiY2MwLCAweDIsIDB4YzA2N2QxZTIsIAogIDB4MjU3LCAweGMyMDhkNjQwLCAw eGU4YjRjYmZjLCAweDI0Nn0KCW9iamVjdCA9IDB4MTAKIzEyIDB4YzA1M2UwMTIgaW4gcHRyYWNl ICh0ZD0weGMyMDhkNjQwLCB1YXA9MHhlOGI0Y2QwNCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4vc3lz X3Byb2Nlc3MuYzozMzkKCXIgPSB7cGlvZCA9IHtwaW9kX29wID0gLTEwNjY1MjY1OTIsIHBpb2Rf b2ZmcyA9IDB4MCwgcGlvZF9hZGRyID0gMHhjMDY3ZjJiNCwgcGlvZF9sZW4gPSAxNzA3fSwgcGwg PSB7CiAgICBwbF9sd3BpZCA9IC0xMDY2NTI2NTkyLCBwbF9ldmVudCA9IDAsIHBsX2ZsYWdzID0g LTEwNjY5Mjk0ODR9LCBkYnJlZyA9IHtkciA9IHszMjI4NDQwNzA0LCAwLCAzMjI4MDM3ODEyLCAx NzA3LCAKICAgICAgMzIyODcyNzM4MCwgMzkwNDE2MjkwMCwgMzIyNjY5ODIxNCwgMzIyODcyNzM3 Nn19LCBmcHJlZyA9IHtmcHJfZW52ID0gezMyMjg0NDA3MDQsIDAsIDMyMjgwMzc4MTIsIDE3MDcs IDMyMjg3MjczODAsIAogICAgICAzOTA0MTYyOTAwLCAzMjI2Njk4MjE0fSwgZnByX2FjYyA9IHsi UHhywEZcMDAyXDAwMFwwMDDIOyIsICJrwFwyMDCoVsFDXGJcMDAwIiwgIqJcMjA3Z8B4zLTo7N8i LCAKICAgICAgIlDAXDIwMKhWwVwwMDFcMDAwXDAwMCIsICLtrGfAK1wwMDFcMDAwXDAwMNggIiwg InzBXDAwNM206EDWXGLCIiwgIlwyMzDMtOhssU/AXDIwMKgiLCAiVsFcMDAwXDAwMFwwMDBcMDAw olwyMDdnwCJ9LCAKICAgIGZwcl9leF9zdyA9IDIxMTUsIAogICAgZnByX3BhZCA9ICLYIHzBXDAw NM206LzMtOgosU/A2CB8wUDWXGLCXDIwMKhWwVwwMDBcMDAwXDAwMFwwMDCiXDIwN2fAMlxiXDAw MFwwMDBcMDAwXDAwMFwwMDBcMDAwQNZcYsJcMDAwtlxiwjDNtOhcMDAwXDAwMFwwMDBcMDAwQNZc YsIifSwgcmVnID0ge3JfZnMgPSAzMjI4NDQwNzA0LCByX2VzID0gMCwgcl9kcyA9IDMyMjgwMzc4 MTIsIHJfZWRpID0gMTcwNywgcl9lc2kgPSAzMjI4NzI3MzgwLCByX2VicCA9IDM5MDQxNjI5MDAs IAogICAgcl9pc3AgPSAzMjI2Njk4MjE0LCByX2VieCA9IDMyMjg3MjczNzYsIHJfZWR4ID0gNTgy LCByX2VjeCA9IDMyMjgyNTMxMjgsIHJfZWF4ID0gMzI0MzY4MTkyMCwgcl90cmFwbm8gPSAyMTE1 LCAKICAgIHJfZXJyID0gMzIyODAxMDQwMiwgcl9laXAgPSAzOTA0MTYyOTM2LCByX2NzID0gMzIy NjUyNTY3Niwgcl9lZmxhZ3MgPSAzMjQzNjgxOTIwLCByX2VzcCA9IDEsIHJfc3MgPSAzMjI4MDE5 OTQ5LCAKICAgIHJfZ3MgPSAyOTl9fQoJYWRkciA9ICh2b2lkICopIDB4MAoJZXJyb3IgPSAwCiMx MyAweGMwNjM5YTlmIGluIHN5c2NhbGwgKGZyYW1lPQogICAgICB7dGZfZnMgPSA1OSwgdGZfZXMg PSA1OSwgdGZfZHMgPSA1OSwgdGZfZWRpID0gLTEwNzc5NDA3OTYsIHRmX2VzaSA9IDY4NywgdGZf ZWJwID0gLTEwNzc5NDIxMzYsIHRmX2lzcCA9IC0zOTA4MDQxMjQsIHRmX2VieCA9IDY4NywgdGZf ZWR4ID0gNjc0OTg2MDkyLCB0Zl9lY3ggPSA2NzQ5MDMyNjgsIHRmX2VheCA9IDI2LCB0Zl90cmFw bm8gPSAxMiwgdGZfZXJyID0gMiwgdGZfZWlwID0gNjc0MjYwMDExLCB0Zl9jcyA9IDUxLCB0Zl9l ZmxhZ3MgPSA1MTgsIHRmX2VzcCA9IC0xMDc3OTQyMTY0LCB0Zl9zcyA9IDU5fSkgYXQgL3Vzci9z cmMvc3lzL2kzODYvaTM4Ni90cmFwLmM6OTU5CglwYXJhbXMgPSAweGJmYmZlODcwIDxBZGRyZXNz IDB4YmZiZmU4NzAgb3V0IG9mIGJvdW5kcz4KCWNhbGxwID0gKHN0cnVjdCBzeXNlbnQgKikgMHhj MDZhZmFmMAoJdGQgPSAoc3RydWN0IHRocmVhZCAqKSAweGMyMDhkNjQwCglwID0gKHN0cnVjdCBw cm9jICopIDB4YzIwOGI2MDAKCW9yaWdfdGZfZWZsYWdzID0gNTE4CglzdGlja3MgPSAxCgllcnJv ciA9IDAKCW5hcmcgPSA0CglhcmdzID0gezEwLCA2ODcsIDAsIDAsIDAsIDAsIDEsIC0xMDM5NjE2 NTEyfQoJY29kZSA9IDI2CiMxNCAweGMwNjJjZjVmIGluIFhpbnQweDgwX3N5c2NhbGwgKCkgYXQg L3Vzci9zcmMvc3lzL2kzODYvaTM4Ni9leGNlcHRpb24uczoyMDAKTm8gbG9jYWxzLgojMTUgMHgw MDAwMDAzYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxNiAweDAw MDAwMDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzE3IDB4MDAw MDAwM2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTggMHhiZmJm ZWRjNCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxOSAweDAwMDAw MmFmIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzIwIDB4YmZiZmU4 ODggaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjEgMHhlOGI0Y2Q2 NCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyMiAweDAwMDAwMmFm IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzIzIDB4MjgzYjc4NmMg aW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjQgMHgyODNhMzRlNCBp biA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNSAweDAwMDAwMDFhIGlu ID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI2IDB4MDAwMDAwMGMgaW4g Pz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjcgMHgwMDAwMDAwMiBpbiA/ PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyOCAweDI4MzA2NDJiIGluID8/ ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI5IDB4MDAwMDAwMzMgaW4gPz8g KCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzAgMHgwMDAwMDIwNiBpbiA/PyAo KQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMSAweGJmYmZlODZjIGluID8/ICgp Ck5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMyIDB4MDAwMDAwM2IgaW4gPz8gKCkK Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzMgMHgwMDAwMDAwMCBpbiA/PyAoKQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNCAweDAwMDAwMDAwIGluID8/ICgpCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM1IDB4MDAwMDAwMDAgaW4gPz8gKCkKTm8g c3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzYgMHgwMDAwMDAwMCBpbiA/PyAoKQpObyBz eW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNyAweDFmNGI5MDAwIGluID8/ICgpCk5vIHN5 bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM4IDB4YzIwOGQ3OTQgaW4gPz8gKCkKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzkgMHhjMTU4MGUxMCBpbiA/PyAoKQpObyBzeW1i b2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MCAweGU4YjRjYzdjIGluID8/ICgpCk5vIHN5bWJv bCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQxIDB4ZThiNGNjNjQgaW4gPz8gKCkKTm8gc3ltYm9s IHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDIgMHhjMjA4ZDY0MCBpbiA/PyAoKQpObyBzeW1ib2wg dGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MyAweGMwNTI2OGU3IGluIHNjaGVkX3N3aXRjaCAodGQ9 MHgyYWYsIG5ld3RkPTB4MmFmLCBmbGFncz0wKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9zY2hlZF91 bGUuYzoxNDAzCglrZSA9IChzdHJ1Y3QgdGRfc2NoZWQgKikgMHhiZmJmZWRjNAooa2dkYikgCiMw ICBkb2FkdW1wICgpIGF0IHBjcHUuaDoxNjUKTm8gbG9jYWxzLgojMSAgMHhjMDQ2MGMxMiBpbiBk Yl9mbmNhbGwgKGR1bW15MT0wLCBkdW1teTI9MCwgZHVtbXkzPS0xMDY3MzA0ODg5LCBkdW1teTQ9 MHhlOGI0YzlmYyAiKMq06FwyMzBcMDMzYsBcMDI0yrToXDAzMMq06FwyMjBcMDI3IikKICAgIGF0 IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjUzMQoJZm5fYWRkciA9IC0xMDY4NDA5Njg0 CglhcmdzID0gezAgPHJlcGVhdHMgMTEgdGltZXM+fQoJbmFyZ3MgPSAxMQoJcmV0dmFsID0gMAoJ ZnVuYyA9IChmY25fMTBhcmdzX3QgKikgMHhjMDUxNWNhYyA8ZG9hZHVtcD4KCXQgPSAwCiMyICAw eGMwNDYwYTIwIGluIGRiX2NvbW1hbmQgKGxhc3RfY21kcD0weGMwNmQyNGE0LCBjbWRfdGFibGU9 MHgwLCBhdXhfY21kX3RhYmxlcD0weGMwNjliNmYwLCBhdXhfY21kX3RhYmxlcF9lbmQ9MHhjMDY5 YjZmNCkKICAgIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjM0OQoJY21kID0gKHN0 cnVjdCBjb21tYW5kICopIDB4YzA2YTExNjAKCXQgPSAwCgltb2RpZiA9ICIoyrToXDIzMFwwMzNi wFwwMjTKtOhcMDMwyrToXDIyMFwwMjdcMDAwXDAwMFwyMjBcMDI3XDAwMFwwMDD/XDAyN1wwMDBc MDAwXDAwMFwwMDBcMDAwXDAwMFwwMDD2c8BcclwwMDBcMDAwXDAwMFwwMDD2c8BcMDAw9nPAXHJc MDAwXDAwMFwwMDBcMDAxXDAwMFwwMDBcMDAwVMq06MtcMDI0YsBUyrTo5FwwMjRiwODCcsDAe3LA eFwwMDBcMDAwXDAwMKAtbcBcZlwwMDBcMDAwXDAwMHTKtOhcMDIwKkbAJr1nwFwwMDAnRsBcZlww MDBcMDAwXDAwMKAtbcCyXDAzNkbAIgoJYWRkciA9IDAKCWNvdW50ID0gLTEwNjczMDQ4ODkKCWhh dmVfYWRkciA9IDAKCXJlc3VsdCA9IDAKIzMgIDB4YzA0NjBhZTggaW4gZGJfY29tbWFuZF9sb29w ICgpIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjQ1NQpObyBsb2NhbHMuCiM0ICAw eGMwNDYyNjZkIGluIGRiX3RyYXAgKHR5cGU9MTIsIGNvZGU9MCkgYXQgL3Vzci9zcmMvc3lzL2Rk Yi9kYl9tYWluLmM6MjIxCglqYiA9IHt7X2piID0gey0zOTA4MDQ4MTIsIC0zOTA4MDQ4MzIsIC0z OTA4MDQ3NjAsIC0zOTA4MDQ2MzIsIDEyLCAtMTA2OTE0NDU3MCwgMTIsIC0zOTA4MDQ3MzYsIC0x MDY4MzAzMTQ1LCAKICAgICAgLTEwNjY4MzkxMjUsIC0xMDY4MzAzMDEyLCAtMzkwODA0NzU2fX19 CglwcmV2X2piID0gKHZvaWQgKikgMHgwCglia3B0ID0gMAojNSAgMHhjMDUyZTRkMyBpbiBrZGJf dHJhcCAodHlwZT0xMiwgY29kZT0wLCB0Zj0weGU4YjRjYjY4KSBhdCAvdXNyL3NyYy9zeXMva2Vy bi9zdWJyX2tkYi5jOjQ3MQoJaGFuZGxlZCA9IC0zOTA4MDQ2MzIKIzYgIDB4YzA2Mzk3ZTcgaW4g dHJhcF9mYXRhbCAoZnJhbWU9MHhlOGI0Y2I2OCwgZXZhPTcyKSBhdCAvdXNyL3NyYy9zeXMvaTM4 Ni9pMzg2L3RyYXAuYzo4MDkKCWNvZGUgPSA0MAoJdHlwZSA9IDEyCglzcyA9IDQwCgllc3AgPSAw Cglzb2Z0c2VnID0ge3NzZF9iYXNlID0gMCwgc3NkX2xpbWl0ID0gMTA0ODU3NSwgc3NkX3R5cGUg PSAyNywgc3NkX2RwbCA9IDAsIHNzZF9wID0gMSwgc3NkX3h4ID0gMCwgc3NkX3h4MSA9IDAsIAog IHNzZF9kZWYzMiA9IDEsIHNzZF9ncmFuID0gMX0KIzcgIDB4YzA2MzhmODYgaW4gdHJhcCAoZnJh bWU9CiAgICAgIHt0Zl9mcyA9IDgsIHRmX2VzID0gLTM5MDg1NjY2NCwgdGZfZHMgPSAtMTA2ODQ5 ODkwNCwgdGZfZWRpID0gLTEwMzk2MTU0ODgsIHRmX2VzaSA9IDE2LCB0Zl9lYnAgPSAtMzkwODA0 NDc2LCB0Zl9pc3AgPSAtMzkwODA0NTg4LCB0Zl9lYnggPSAtMTA0MzIzNzMxMiwgdGZfZWR4ID0g LTEwMzk2MDgyNTYsIHRmX2VjeCA9IDEsIHRmX2VheCA9IDAsIHRmX3RyYXBubyA9IDEyLCB0Zl9l cnIgPSAyLCB0Zl9laXAgPSAtMTA2ODI0MjY2NiwgdGZfY3MgPSAzMiwgdGZfZWZsYWdzID0gNjU2 NjcsIHRmX2VzcCA9IC0xMDY2OTI5NDg0LCB0Zl9zcyA9IDE3MDd9KSBhdCAvdXNyL3NyYy9zeXMv aTM4Ni9pMzg2L3RyYXAuYzoyNTIKCXRkID0gKHN0cnVjdCB0aHJlYWQgKikgMHhjMjA4ZDY0MAoJ cCA9IChzdHJ1Y3QgcHJvYyAqKSAweGMyMDhiNjAwCglzdGlja3MgPSAzOTA0MTYyNjcyCglpID0g MAoJdWNvZGUgPSAwCgl0eXBlID0gMTIKCWNvZGUgPSAyCglldmEgPSA3MgojOCAgMHhjMDYyY2Yw YSBpbiBjYWxsdHJhcCAoKSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlvbi5zOjEz OQpObyBsb2NhbHMuCiM5ICAweDAwMDAwMDA4IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZv IGF2YWlsYWJsZS4KIzEwIDB4ZThiNDAwMjggaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8g YXZhaWxhYmxlLgojMTEgMHhjMDUwMDAyOCBpbiBleGVjX21hcF9maXJzdF9wYWdlIChpbWdwPTB4 YzIwOGQ2NDApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhlYy5jOjgwMwoJaSA9IC0xMDQz MjM3MzEyCglpbml0aWFsX3BhZ2VpbiA9IC0xMDM5NjE1NDg4CgltYSA9IHsweDE4NzJjLCAweDEs IDB4MjQ2LCAweDAsIDB4YzIwOGI2MDAsIDB4MCwgMHhjMjA4ZDZiOCwgMHhlOGI0Y2JmMCwgMHhj MDUyNzZlNywgMHhjMDZkYmNjMCwgMHgyLCAweGMwNjdkMWUyLCAKICAweDI1NywgMHhjMjA4ZDY0 MCwgMHhlOGI0Y2JmYywgMHgyNDZ9CglvYmplY3QgPSAweDEwCiMxMiAweGMwNTNlMDEyIGluIHB0 cmFjZSAodGQ9MHhjMjA4ZDY0MCwgdWFwPTB4ZThiNGNkMDQpIGF0IC91c3Ivc3JjL3N5cy9rZXJu L3N5c19wcm9jZXNzLmM6MzM5CglyID0ge3Bpb2QgPSB7cGlvZF9vcCA9IC0xMDY2NTI2NTkyLCBw aW9kX29mZnMgPSAweDAsIHBpb2RfYWRkciA9IDB4YzA2N2YyYjQsIHBpb2RfbGVuID0gMTcwN30s IHBsID0gewogICAgcGxfbHdwaWQgPSAtMTA2NjUyNjU5MiwgcGxfZXZlbnQgPSAwLCBwbF9mbGFn cyA9IC0xMDY2OTI5NDg0fSwgZGJyZWcgPSB7ZHIgPSB7MzIyODQ0MDcwNCwgMCwgMzIyODAzNzgx MiwgMTcwNywgCiAgICAgIDMyMjg3MjczODAsIDM5MDQxNjI5MDAsIDMyMjY2OTgyMTQsIDMyMjg3 MjczNzZ9fSwgZnByZWcgPSB7ZnByX2VudiA9IHszMjI4NDQwNzA0LCAwLCAzMjI4MDM3ODEyLCAx NzA3LCAzMjI4NzI3MzgwLCAKICAgICAgMzkwNDE2MjkwMCwgMzIyNjY5ODIxNH0sIGZwcl9hY2Mg PSB7IlB4csBGXDAwMlwwMDBcMDAwyDsiLCAia8BcMjAwqFbBQ1xiXDAwMCIsICKiXDIwN2fAeMy0 6OzfIiwgCiAgICAgICJQwFwyMDCoVsFcMDAxXDAwMFwwMDAiLCAi7axnwCtcMDAxXDAwMFwwMDDY ICIsICJ8wVwwMDTNtOhA1lxiwiIsICJcMjMwzLTobLFPwFwyMDCoIiwgIlbBXDAwMFwwMDBcMDAw XDAwMKJcMjA3Z8AifSwgCiAgICBmcHJfZXhfc3cgPSAyMTE1LCAKICAgIGZwcl9wYWQgPSAi2CB8 wVwwMDTNtOi8zLToKLFPwNggfMFA1lxiwlwyMDCoVsFcMDAwXDAwMFwwMDBcMDAwolwyMDdnwDJc YlwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMEDWXGLCXDAwMLZcYsIwzbToXDAwMFwwMDBcMDAwXDAw MEDWXGLCIn0sIHJlZyA9IHtyX2ZzID0gMzIyODQ0MDcwNCwgcl9lcyA9IDAsIHJfZHMgPSAzMjI4 MDM3ODEyLCByX2VkaSA9IDE3MDcsIHJfZXNpID0gMzIyODcyNzM4MCwgcl9lYnAgPSAzOTA0MTYy OTAwLCAKICAgIHJfaXNwID0gMzIyNjY5ODIxNCwgcl9lYnggPSAzMjI4NzI3Mzc2LCByX2VkeCA9 IDU4Miwgcl9lY3ggPSAzMjI4MjUzMTI4LCByX2VheCA9IDMyNDM2ODE5MjAsIHJfdHJhcG5vID0g MjExNSwgCiAgICByX2VyciA9IDMyMjgwMTA0MDIsIHJfZWlwID0gMzkwNDE2MjkzNiwgcl9jcyA9 IDMyMjY1MjU2NzYsIHJfZWZsYWdzID0gMzI0MzY4MTkyMCwgcl9lc3AgPSAxLCByX3NzID0gMzIy ODAxOTk0OSwgCiAgICByX2dzID0gMjk5fX0KCWFkZHIgPSAodm9pZCAqKSAweDAKCWVycm9yID0g MAojMTMgMHhjMDYzOWE5ZiBpbiBzeXNjYWxsIChmcmFtZT0KICAgICAge3RmX2ZzID0gNTksIHRm X2VzID0gNTksIHRmX2RzID0gNTksIHRmX2VkaSA9IC0xMDc3OTQwNzk2LCB0Zl9lc2kgPSA2ODcs IHRmX2VicCA9IC0xMDc3OTQyMTM2LCB0Zl9pc3AgPSAtMzkwODA0MTI0LCB0Zl9lYnggPSA2ODcs IHRmX2VkeCA9IDY3NDk4NjA5MiwgdGZfZWN4ID0gNjc0OTAzMjY4LCB0Zl9lYXggPSAyNiwgdGZf dHJhcG5vID0gMTIsIHRmX2VyciA9IDIsIHRmX2VpcCA9IDY3NDI2MDAxMSwgdGZfY3MgPSA1MSwg dGZfZWZsYWdzID0gNTE4LCB0Zl9lc3AgPSAtMTA3Nzk0MjE2NCwgdGZfc3MgPSA1OX0pIGF0IC91 c3Ivc3JjL3N5cy9pMzg2L2kzODYvdHJhcC5jOjk1OQoJcGFyYW1zID0gMHhiZmJmZTg3MCA8QWRk cmVzcyAweGJmYmZlODcwIG91dCBvZiBib3VuZHM+CgljYWxscCA9IChzdHJ1Y3Qgc3lzZW50ICop IDB4YzA2YWZhZjAKCXRkID0gKHN0cnVjdCB0aHJlYWQgKikgMHhjMjA4ZDY0MAoJcCA9IChzdHJ1 Y3QgcHJvYyAqKSAweGMyMDhiNjAwCglvcmlnX3RmX2VmbGFncyA9IDUxOAoJc3RpY2tzID0gMQoJ ZXJyb3IgPSAwCgluYXJnID0gNAoJYXJncyA9IHsxMCwgNjg3LCAwLCAwLCAwLCAwLCAxLCAtMTAz OTYxNjUxMn0KCWNvZGUgPSAyNgojMTQgMHhjMDYyY2Y1ZiBpbiBYaW50MHg4MF9zeXNjYWxsICgp IGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvZXhjZXB0aW9uLnM6MjAwCk5vIGxvY2Fscy4KIzE1 IDB4MDAwMDAwM2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTYg MHgwMDAwMDAzYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxNyAw eDAwMDAwMDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzE4IDB4 YmZiZmVkYzQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTkgMHgw MDAwMDJhZiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyMCAweGJm YmZlODg4IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzIxIDB4ZThi NGNkNjQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjIgMHgwMDAw MDJhZiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyMyAweDI4M2I3 ODZjIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI0IDB4MjgzYTM0 ZTQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjUgMHgwMDAwMDAx YSBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNiAweDAwMDAwMDBj IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI3IDB4MDAwMDAwMDIg aW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjggMHgyODMwNjQyYiBp biA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyOSAweDAwMDAwMDMzIGlu ID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMwIDB4MDAwMDAyMDYgaW4g Pz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzEgMHhiZmJmZTg2YyBpbiA/ PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMiAweDAwMDAwMDNiIGluID8/ ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMzIDB4MDAwMDAwMDAgaW4gPz8g KCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzQgMHgwMDAwMDAwMCBpbiA/PyAo KQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNSAweDAwMDAwMDAwIGluID8/ICgp Ck5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM2IDB4MDAwMDAwMDAgaW4gPz8gKCkK Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzcgMHgxZjRiOTAwMCBpbiA/PyAoKQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzOCAweGMyMDhkNzk0IGluID8/ICgpCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM5IDB4YzE1ODBlMTAgaW4gPz8gKCkKTm8g c3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDAgMHhlOGI0Y2M3YyBpbiA/PyAoKQpObyBz eW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MSAweGU4YjRjYzY0IGluID8/ICgpCk5vIHN5 bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQyIDB4YzIwOGQ2NDAgaW4gPz8gKCkKTm8gc3lt Ym9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDMgMHhjMDUyNjhlNyBpbiBzY2hlZF9zd2l0Y2gg KHRkPTB4MmFmLCBuZXd0ZD0weDJhZiwgZmxhZ3M9MCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4vc2No ZWRfdWxlLmM6MTQwMwoJa2UgPSAoc3RydWN0IHRkX3NjaGVkICopIDB4YmZiZmVkYzQKKGtnZGIp IAojMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MTY1Ck5vIGxvY2Fscy4KIzEgIDB4YzA0NjBjMTIg aW4gZGJfZm5jYWxsIChkdW1teTE9MCwgZHVtbXkyPTAsIGR1bW15Mz0tMTA2NzMwNDg4OSwgZHVt bXk0PTB4ZThiNGM5ZmMgIijKtOhcMjMwXDAzM2LAXDAyNMq06FwwMzDKtOhcMjIwXDAyNyIpCiAg ICBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo1MzEKCWZuX2FkZHIgPSAtMTA2ODQw OTY4NAoJYXJncyA9IHswIDxyZXBlYXRzIDExIHRpbWVzPn0KCW5hcmdzID0gMTEKCXJldHZhbCA9 IDAKCWZ1bmMgPSAoZmNuXzEwYXJnc190ICopIDB4YzA1MTVjYWMgPGRvYWR1bXA+Cgl0ID0gMAoj MiAgMHhjMDQ2MGEyMCBpbiBkYl9jb21tYW5kIChsYXN0X2NtZHA9MHhjMDZkMjRhNCwgY21kX3Rh YmxlPTB4MCwgYXV4X2NtZF90YWJsZXA9MHhjMDY5YjZmMCwgYXV4X2NtZF90YWJsZXBfZW5kPTB4 YzA2OWI2ZjQpCiAgICBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQuYzozNDkKCWNtZCA9 IChzdHJ1Y3QgY29tbWFuZCAqKSAweGMwNmExMTYwCgl0ID0gMAoJbW9kaWYgPSAiKMq06FwyMzBc MDMzYsBcMDI0yrToXDAzMMq06FwyMjBcMDI3XDAwMFwwMDBcMjIwXDAyN1wwMDBcMDAw/1wwMjdc MDAwXDAwMFwwMDBcMDAwXDAwMFwwMDBcMDAw9nPAXHJcMDAwXDAwMFwwMDBcMDAw9nPAXDAwMPZz wFxyXDAwMFwwMDBcMDAwXDAwMVwwMDBcMDAwXDAwMFTKtOjLXDAyNGLAVMq06ORcMDI0YsDgwnLA wHtywHhcMDAwXDAwMFwwMDCgLW3AXGZcMDAwXDAwMFwwMDB0yrToXDAyMCpGwCa9Z8BcMDAwJ0bA XGZcMDAwXDAwMFwwMDCgLW3AslwwMzZGwCIKCWFkZHIgPSAwCgljb3VudCA9IC0xMDY3MzA0ODg5 CgloYXZlX2FkZHIgPSAwCglyZXN1bHQgPSAwCiMzICAweGMwNDYwYWU4IGluIGRiX2NvbW1hbmRf bG9vcCAoKSBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo0NTUKTm8gbG9jYWxzLgoj NCAgMHhjMDQ2MjY2ZCBpbiBkYl90cmFwICh0eXBlPTEyLCBjb2RlPTApIGF0IC91c3Ivc3JjL3N5 cy9kZGIvZGJfbWFpbi5jOjIyMQoJamIgPSB7e19qYiA9IHstMzkwODA0ODEyLCAtMzkwODA0ODMy LCAtMzkwODA0NzYwLCAtMzkwODA0NjMyLCAxMiwgLTEwNjkxNDQ1NzAsIDEyLCAtMzkwODA0NzM2 LCAtMTA2ODMwMzE0NSwgCiAgICAgIC0xMDY2ODM5MTI1LCAtMTA2ODMwMzAxMiwgLTM5MDgwNDc1 Nn19fQoJcHJldl9qYiA9ICh2b2lkICopIDB4MAoJYmtwdCA9IDAKIzUgIDB4YzA1MmU0ZDMgaW4g a2RiX3RyYXAgKHR5cGU9MTIsIGNvZGU9MCwgdGY9MHhlOGI0Y2I2OCkgYXQgL3Vzci9zcmMvc3lz L2tlcm4vc3Vicl9rZGIuYzo0NzEKCWhhbmRsZWQgPSAtMzkwODA0NjMyCiM2ICAweGMwNjM5N2U3 IGluIHRyYXBfZmF0YWwgKGZyYW1lPTB4ZThiNGNiNjgsIGV2YT03MikgYXQgL3Vzci9zcmMvc3lz L2kzODYvaTM4Ni90cmFwLmM6ODA5Cgljb2RlID0gNDAKCXR5cGUgPSAxMgoJc3MgPSA0MAoJZXNw ID0gMAoJc29mdHNlZyA9IHtzc2RfYmFzZSA9IDAsIHNzZF9saW1pdCA9IDEwNDg1NzUsIHNzZF90 eXBlID0gMjcsIHNzZF9kcGwgPSAwLCBzc2RfcCA9IDEsIHNzZF94eCA9IDAsIHNzZF94eDEgPSAw LCAKICBzc2RfZGVmMzIgPSAxLCBzc2RfZ3JhbiA9IDF9CiM3ICAweGMwNjM4Zjg2IGluIHRyYXAg KGZyYW1lPQogICAgICB7dGZfZnMgPSA4LCB0Zl9lcyA9IC0zOTA4NTY2NjQsIHRmX2RzID0gLTEw Njg0OTg5MDQsIHRmX2VkaSA9IC0xMDM5NjE1NDg4LCB0Zl9lc2kgPSAxNiwgdGZfZWJwID0gLTM5 MDgwNDQ3NiwgdGZfaXNwID0gLTM5MDgwNDU4OCwgdGZfZWJ4ID0gLTEwNDMyMzczMTIsIHRmX2Vk eCA9IC0xMDM5NjA4MjU2LCB0Zl9lY3ggPSAxLCB0Zl9lYXggPSAwLCB0Zl90cmFwbm8gPSAxMiwg dGZfZXJyID0gMiwgdGZfZWlwID0gLTEwNjgyNDI2NjYsIHRmX2NzID0gMzIsIHRmX2VmbGFncyA9 IDY1NjY3LCB0Zl9lc3AgPSAtMTA2NjkyOTQ4NCwgdGZfc3MgPSAxNzA3fSkgYXQgL3Vzci9zcmMv c3lzL2kzODYvaTM4Ni90cmFwLmM6MjUyCgl0ZCA9IChzdHJ1Y3QgdGhyZWFkICopIDB4YzIwOGQ2 NDAKCXAgPSAoc3RydWN0IHByb2MgKikgMHhjMjA4YjYwMAoJc3RpY2tzID0gMzkwNDE2MjY3MgoJ aSA9IDAKCXVjb2RlID0gMAoJdHlwZSA9IDEyCgljb2RlID0gMgoJZXZhID0gNzIKIzggIDB4YzA2 MmNmMGEgaW4gY2FsbHRyYXAgKCkgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni9leGNlcHRpb24u czoxMzkKTm8gbG9jYWxzLgojOSAgMHgwMDAwMDAwOCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUg aW5mbyBhdmFpbGFibGUuCiMxMCAweGU4YjQwMDI4IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBp bmZvIGF2YWlsYWJsZS4KIzExIDB4YzA1MDAwMjggaW4gZXhlY19tYXBfZmlyc3RfcGFnZSAoaW1n cD0weGMyMDhkNjQwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4ZWMuYzo4MDMKCWkgPSAt MTA0MzIzNzMxMgoJaW5pdGlhbF9wYWdlaW4gPSAtMTAzOTYxNTQ4OAoJbWEgPSB7MHgxODcyYywg MHgxLCAweDI0NiwgMHgwLCAweGMyMDhiNjAwLCAweDAsIDB4YzIwOGQ2YjgsIDB4ZThiNGNiZjAs IDB4YzA1Mjc2ZTcsIDB4YzA2ZGJjYzAsIDB4MiwgMHhjMDY3ZDFlMiwgCiAgMHgyNTcsIDB4YzIw OGQ2NDAsIDB4ZThiNGNiZmMsIDB4MjQ2fQoJb2JqZWN0ID0gMHgxMAojMTIgMHhjMDUzZTAxMiBp biBwdHJhY2UgKHRkPTB4YzIwOGQ2NDAsIHVhcD0weGU4YjRjZDA0KSBhdCAvdXNyL3NyYy9zeXMv a2Vybi9zeXNfcHJvY2Vzcy5jOjMzOQoJciA9IHtwaW9kID0ge3Bpb2Rfb3AgPSAtMTA2NjUyNjU5 MiwgcGlvZF9vZmZzID0gMHgwLCBwaW9kX2FkZHIgPSAweGMwNjdmMmI0LCBwaW9kX2xlbiA9IDE3 MDd9LCBwbCA9IHsKICAgIHBsX2x3cGlkID0gLTEwNjY1MjY1OTIsIHBsX2V2ZW50ID0gMCwgcGxf ZmxhZ3MgPSAtMTA2NjkyOTQ4NH0sIGRicmVnID0ge2RyID0gezMyMjg0NDA3MDQsIDAsIDMyMjgw Mzc4MTIsIDE3MDcsIAogICAgICAzMjI4NzI3MzgwLCAzOTA0MTYyOTAwLCAzMjI2Njk4MjE0LCAz MjI4NzI3Mzc2fX0sIGZwcmVnID0ge2Zwcl9lbnYgPSB7MzIyODQ0MDcwNCwgMCwgMzIyODAzNzgx MiwgMTcwNywgMzIyODcyNzM4MCwgCiAgICAgIDM5MDQxNjI5MDAsIDMyMjY2OTgyMTR9LCBmcHJf YWNjID0geyJQeHLARlwwMDJcMDAwXDAwMMg7IiwgImvAXDIwMKhWwUNcYlwwMDAiLCAiolwyMDdn wHjMtOjs3yIsIAogICAgICAiUMBcMjAwqFbBXDAwMVwwMDBcMDAwIiwgIu2sZ8ArXDAwMVwwMDBc MDAw2CAiLCAifMFcMDA0zbToQNZcYsIiLCAiXDIzMMy06GyxT8BcMjAwqCIsICJWwVwwMDBcMDAw XDAwMFwwMDCiXDIwN2fAIn0sIAogICAgZnByX2V4X3N3ID0gMjExNSwgCiAgICBmcHJfcGFkID0g ItggfMFcMDA0zbTovMy06CixT8DYIHzBQNZcYsJcMjAwqFbBXDAwMFwwMDBcMDAwXDAwMKJcMjA3 Z8AyXGJcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDBA1lxiwlwwMDC2XGLCMM206FwwMDBcMDAwXDAw MFwwMDBA1lxiwiJ9LCByZWcgPSB7cl9mcyA9IDMyMjg0NDA3MDQsIHJfZXMgPSAwLCByX2RzID0g MzIyODAzNzgxMiwgcl9lZGkgPSAxNzA3LCByX2VzaSA9IDMyMjg3MjczODAsIHJfZWJwID0gMzkw NDE2MjkwMCwgCiAgICByX2lzcCA9IDMyMjY2OTgyMTQsIHJfZWJ4ID0gMzIyODcyNzM3Niwgcl9l ZHggPSA1ODIsIHJfZWN4ID0gMzIyODI1MzEyOCwgcl9lYXggPSAzMjQzNjgxOTIwLCByX3RyYXBu byA9IDIxMTUsIAogICAgcl9lcnIgPSAzMjI4MDEwNDAyLCByX2VpcCA9IDM5MDQxNjI5MzYsIHJf Y3MgPSAzMjI2NTI1Njc2LCByX2VmbGFncyA9IDMyNDM2ODE5MjAsIHJfZXNwID0gMSwgcl9zcyA9 IDMyMjgwMTk5NDksIAogICAgcl9ncyA9IDI5OX19CglhZGRyID0gKHZvaWQgKikgMHgwCgllcnJv ciA9IDAKIzEzIDB4YzA2MzlhOWYgaW4gc3lzY2FsbCAoZnJhbWU9CiAgICAgIHt0Zl9mcyA9IDU5 LCB0Zl9lcyA9IDU5LCB0Zl9kcyA9IDU5LCB0Zl9lZGkgPSAtMTA3Nzk0MDc5NiwgdGZfZXNpID0g Njg3LCB0Zl9lYnAgPSAtMTA3Nzk0MjEzNiwgdGZfaXNwID0gLTM5MDgwNDEyNCwgdGZfZWJ4ID0g Njg3LCB0Zl9lZHggPSA2NzQ5ODYwOTIsIHRmX2VjeCA9IDY3NDkwMzI2OCwgdGZfZWF4ID0gMjYs IHRmX3RyYXBubyA9IDEyLCB0Zl9lcnIgPSAyLCB0Zl9laXAgPSA2NzQyNjAwMTEsIHRmX2NzID0g NTEsIHRmX2VmbGFncyA9IDUxOCwgdGZfZXNwID0gLTEwNzc5NDIxNjQsIHRmX3NzID0gNTl9KSBh dCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzo5NTkKCXBhcmFtcyA9IDB4YmZiZmU4NzAg PEFkZHJlc3MgMHhiZmJmZTg3MCBvdXQgb2YgYm91bmRzPgoJY2FsbHAgPSAoc3RydWN0IHN5c2Vu dCAqKSAweGMwNmFmYWYwCgl0ZCA9IChzdHJ1Y3QgdGhyZWFkICopIDB4YzIwOGQ2NDAKCXAgPSAo c3RydWN0IHByb2MgKikgMHhjMjA4YjYwMAoJb3JpZ190Zl9lZmxhZ3MgPSA1MTgKCXN0aWNrcyA9 IDEKCWVycm9yID0gMAoJbmFyZyA9IDQKCWFyZ3MgPSB7MTAsIDY4NywgMCwgMCwgMCwgMCwgMSwg LTEwMzk2MTY1MTJ9Cgljb2RlID0gMjYKIzE0IDB4YzA2MmNmNWYgaW4gWGludDB4ODBfc3lzY2Fs bCAoKSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlvbi5zOjIwMApObyBsb2NhbHMu CiMxNSAweDAwMDAwMDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4K IzE2IDB4MDAwMDAwM2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgoj MTcgMHgwMDAwMDAzYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMx OCAweGJmYmZlZGM0IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzE5 IDB4MDAwMDAyYWYgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjAg MHhiZmJmZTg4OCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyMSAw eGU4YjRjZDY0IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzIyIDB4 MDAwMDAyYWYgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjMgMHgy ODNiNzg2YyBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNCAweDI4 M2EzNGU0IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI1IDB4MDAw MDAwMWEgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjYgMHgwMDAw MDAwYyBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNyAweDAwMDAw MDAyIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI4IDB4MjgzMDY0 MmIgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjkgMHgwMDAwMDAz MyBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMCAweDAwMDAwMjA2 IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMxIDB4YmZiZmU4NmMg aW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzIgMHgwMDAwMDAzYiBp biA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMyAweDAwMDAwMDAwIGlu ID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM0IDB4MDAwMDAwMDAgaW4g Pz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzUgMHgwMDAwMDAwMCBpbiA/ PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNiAweDAwMDAwMDAwIGluID8/ ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM3IDB4MWY0YjkwMDAgaW4gPz8g KCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzggMHhjMjA4ZDc5NCBpbiA/PyAo KQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzOSAweGMxNTgwZTEwIGluID8/ICgp Ck5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQwIDB4ZThiNGNjN2MgaW4gPz8gKCkK Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDEgMHhlOGI0Y2M2NCBpbiA/PyAoKQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MiAweGMyMDhkNjQwIGluID8/ICgpCk5v IHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQzIDB4YzA1MjY4ZTcgaW4gc2NoZWRfc3dp dGNoICh0ZD0weDJhZiwgbmV3dGQ9MHgyYWYsIGZsYWdzPTApIGF0IC91c3Ivc3JjL3N5cy9rZXJu L3NjaGVkX3VsZS5jOjE0MDMKCWtlID0gKHN0cnVjdCB0ZF9zY2hlZCAqKSAweGJmYmZlZGM0Cihr Z2RiKSAKIzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjE2NQpObyBsb2NhbHMuCiMxICAweGMwNDYw YzEyIGluIGRiX2ZuY2FsbCAoZHVtbXkxPTAsIGR1bW15Mj0wLCBkdW1teTM9LTEwNjczMDQ4ODks IGR1bW15ND0weGU4YjRjOWZjICIoyrToXDIzMFwwMzNiwFwwMjTKtOhcMDMwyrToXDIyMFwwMjci KQogICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6NTMxCglmbl9hZGRyID0gLTEw Njg0MDk2ODQKCWFyZ3MgPSB7MCA8cmVwZWF0cyAxMSB0aW1lcz59CgluYXJncyA9IDExCglyZXR2 YWwgPSAwCglmdW5jID0gKGZjbl8xMGFyZ3NfdCAqKSAweGMwNTE1Y2FjIDxkb2FkdW1wPgoJdCA9 IDAKIzIgIDB4YzA0NjBhMjAgaW4gZGJfY29tbWFuZCAobGFzdF9jbWRwPTB4YzA2ZDI0YTQsIGNt ZF90YWJsZT0weDAsIGF1eF9jbWRfdGFibGVwPTB4YzA2OWI2ZjAsIGF1eF9jbWRfdGFibGVwX2Vu ZD0weGMwNjliNmY0KQogICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6MzQ5Cglj bWQgPSAoc3RydWN0IGNvbW1hbmQgKikgMHhjMDZhMTE2MAoJdCA9IDAKCW1vZGlmID0gIijKtOhc MjMwXDAzM2LAXDAyNMq06FwwMzDKtOhcMjIwXDAyN1wwMDBcMDAwXDIyMFwwMjdcMDAwXDAwMP9c MDI3XDAwMFwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMPZzwFxyXDAwMFwwMDBcMDAwXDAwMPZzwFww MDD2c8BcclwwMDBcMDAwXDAwMFwwMDFcMDAwXDAwMFwwMDBUyrToy1wwMjRiwFTKtOjkXDAyNGLA 4MJywMB7csB4XDAwMFwwMDBcMDAwoC1twFxmXDAwMFwwMDBcMDAwdMq06FwwMjAqRsAmvWfAXDAw MCdGwFxmXDAwMFwwMDBcMDAwoC1twLJcMDM2RsAiCglhZGRyID0gMAoJY291bnQgPSAtMTA2NzMw NDg4OQoJaGF2ZV9hZGRyID0gMAoJcmVzdWx0ID0gMAojMyAgMHhjMDQ2MGFlOCBpbiBkYl9jb21t YW5kX2xvb3AgKCkgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6NDU1Ck5vIGxvY2Fs cy4KIzQgIDB4YzA0NjI2NmQgaW4gZGJfdHJhcCAodHlwZT0xMiwgY29kZT0wKSBhdCAvdXNyL3Ny Yy9zeXMvZGRiL2RiX21haW4uYzoyMjEKCWpiID0ge3tfamIgPSB7LTM5MDgwNDgxMiwgLTM5MDgw NDgzMiwgLTM5MDgwNDc2MCwgLTM5MDgwNDYzMiwgMTIsIC0xMDY5MTQ0NTcwLCAxMiwgLTM5MDgw NDczNiwgLTEwNjgzMDMxNDUsIAogICAgICAtMTA2NjgzOTEyNSwgLTEwNjgzMDMwMTIsIC0zOTA4 MDQ3NTZ9fX0KCXByZXZfamIgPSAodm9pZCAqKSAweDAKCWJrcHQgPSAwCiM1ICAweGMwNTJlNGQz IGluIGtkYl90cmFwICh0eXBlPTEyLCBjb2RlPTAsIHRmPTB4ZThiNGNiNjgpIGF0IC91c3Ivc3Jj L3N5cy9rZXJuL3N1YnJfa2RiLmM6NDcxCgloYW5kbGVkID0gLTM5MDgwNDYzMgojNiAgMHhjMDYz OTdlNyBpbiB0cmFwX2ZhdGFsIChmcmFtZT0weGU4YjRjYjY4LCBldmE9NzIpIGF0IC91c3Ivc3Jj L3N5cy9pMzg2L2kzODYvdHJhcC5jOjgwOQoJY29kZSA9IDQwCgl0eXBlID0gMTIKCXNzID0gNDAK CWVzcCA9IDAKCXNvZnRzZWcgPSB7c3NkX2Jhc2UgPSAwLCBzc2RfbGltaXQgPSAxMDQ4NTc1LCBz c2RfdHlwZSA9IDI3LCBzc2RfZHBsID0gMCwgc3NkX3AgPSAxLCBzc2RfeHggPSAwLCBzc2RfeHgx ID0gMCwgCiAgc3NkX2RlZjMyID0gMSwgc3NkX2dyYW4gPSAxfQojNyAgMHhjMDYzOGY4NiBpbiB0 cmFwIChmcmFtZT0KICAgICAge3RmX2ZzID0gOCwgdGZfZXMgPSAtMzkwODU2NjY0LCB0Zl9kcyA9 IC0xMDY4NDk4OTA0LCB0Zl9lZGkgPSAtMTAzOTYxNTQ4OCwgdGZfZXNpID0gMTYsIHRmX2VicCA9 IC0zOTA4MDQ0NzYsIHRmX2lzcCA9IC0zOTA4MDQ1ODgsIHRmX2VieCA9IC0xMDQzMjM3MzEyLCB0 Zl9lZHggPSAtMTAzOTYwODI1NiwgdGZfZWN4ID0gMSwgdGZfZWF4ID0gMCwgdGZfdHJhcG5vID0g MTIsIHRmX2VyciA9IDIsIHRmX2VpcCA9IC0xMDY4MjQyNjY2LCB0Zl9jcyA9IDMyLCB0Zl9lZmxh Z3MgPSA2NTY2NywgdGZfZXNwID0gLTEwNjY5Mjk0ODQsIHRmX3NzID0gMTcwN30pIGF0IC91c3Iv c3JjL3N5cy9pMzg2L2kzODYvdHJhcC5jOjI1MgoJdGQgPSAoc3RydWN0IHRocmVhZCAqKSAweGMy MDhkNjQwCglwID0gKHN0cnVjdCBwcm9jICopIDB4YzIwOGI2MDAKCXN0aWNrcyA9IDM5MDQxNjI2 NzIKCWkgPSAwCgl1Y29kZSA9IDAKCXR5cGUgPSAxMgoJY29kZSA9IDIKCWV2YSA9IDcyCiM4ICAw eGMwNjJjZjBhIGluIGNhbGx0cmFwICgpIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvZXhjZXB0 aW9uLnM6MTM5Ck5vIGxvY2Fscy4KIzkgIDB4MDAwMDAwMDggaW4gPz8gKCkKTm8gc3ltYm9sIHRh YmxlIGluZm8gYXZhaWxhYmxlLgojMTAgMHhlOGI0MDAyOCBpbiA/PyAoKQpObyBzeW1ib2wgdGFi bGUgaW5mbyBhdmFpbGFibGUuCiMxMSAweGMwNTAwMDI4IGluIGV4ZWNfbWFwX2ZpcnN0X3BhZ2Ug KGltZ3A9MHhjMjA4ZDY0MCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9leGVjLmM6ODAzCglp ID0gLTEwNDMyMzczMTIKCWluaXRpYWxfcGFnZWluID0gLTEwMzk2MTU0ODgKCW1hID0gezB4MTg3 MmMsIDB4MSwgMHgyNDYsIDB4MCwgMHhjMjA4YjYwMCwgMHgwLCAweGMyMDhkNmI4LCAweGU4YjRj YmYwLCAweGMwNTI3NmU3LCAweGMwNmRiY2MwLCAweDIsIDB4YzA2N2QxZTIsIAogIDB4MjU3LCAw eGMyMDhkNjQwLCAweGU4YjRjYmZjLCAweDI0Nn0KCW9iamVjdCA9IDB4MTAKIzEyIDB4YzA1M2Uw MTIgaW4gcHRyYWNlICh0ZD0weGMyMDhkNjQwLCB1YXA9MHhlOGI0Y2QwNCkgYXQgL3Vzci9zcmMv c3lzL2tlcm4vc3lzX3Byb2Nlc3MuYzozMzkKCXIgPSB7cGlvZCA9IHtwaW9kX29wID0gLTEwNjY1 MjY1OTIsIHBpb2Rfb2ZmcyA9IDB4MCwgcGlvZF9hZGRyID0gMHhjMDY3ZjJiNCwgcGlvZF9sZW4g PSAxNzA3fSwgcGwgPSB7CiAgICBwbF9sd3BpZCA9IC0xMDY2NTI2NTkyLCBwbF9ldmVudCA9IDAs IHBsX2ZsYWdzID0gLTEwNjY5Mjk0ODR9LCBkYnJlZyA9IHtkciA9IHszMjI4NDQwNzA0LCAwLCAz MjI4MDM3ODEyLCAxNzA3LCAKICAgICAgMzIyODcyNzM4MCwgMzkwNDE2MjkwMCwgMzIyNjY5ODIx NCwgMzIyODcyNzM3Nn19LCBmcHJlZyA9IHtmcHJfZW52ID0gezMyMjg0NDA3MDQsIDAsIDMyMjgw Mzc4MTIsIDE3MDcsIDMyMjg3MjczODAsIAogICAgICAzOTA0MTYyOTAwLCAzMjI2Njk4MjE0fSwg ZnByX2FjYyA9IHsiUHhywEZcMDAyXDAwMFwwMDDIOyIsICJrwFwyMDCoVsFDXGJcMDAwIiwgIqJc MjA3Z8B4zLTo7N8iLCAKICAgICAgIlDAXDIwMKhWwVwwMDFcMDAwXDAwMCIsICLtrGfAK1wwMDFc MDAwXDAwMNggIiwgInzBXDAwNM206EDWXGLCIiwgIlwyMzDMtOhssU/AXDIwMKgiLCAiVsFcMDAw XDAwMFwwMDBcMDAwolwyMDdnwCJ9LCAKICAgIGZwcl9leF9zdyA9IDIxMTUsIAogICAgZnByX3Bh ZCA9ICLYIHzBXDAwNM206LzMtOgosU/A2CB8wUDWXGLCXDIwMKhWwVwwMDBcMDAwXDAwMFwwMDCi XDIwN2fAMlxiXDAwMFwwMDBcMDAwXDAwMFwwMDBcMDAwQNZcYsJcMDAwtlxiwjDNtOhcMDAwXDAw MFwwMDBcMDAwQNZcYsIifSwgcmVnID0ge3JfZnMgPSAzMjI4NDQwNzA0LCByX2VzID0gMCwgcl9k cyA9IDMyMjgwMzc4MTIsIHJfZWRpID0gMTcwNywgcl9lc2kgPSAzMjI4NzI3MzgwLCByX2VicCA9 IDM5MDQxNjI5MDAsIAogICAgcl9pc3AgPSAzMjI2Njk4MjE0LCByX2VieCA9IDMyMjg3MjczNzYs IHJfZWR4ID0gNTgyLCByX2VjeCA9IDMyMjgyNTMxMjgsIHJfZWF4ID0gMzI0MzY4MTkyMCwgcl90 cmFwbm8gPSAyMTE1LCAKICAgIHJfZXJyID0gMzIyODAxMDQwMiwgcl9laXAgPSAzOTA0MTYyOTM2 LCByX2NzID0gMzIyNjUyNTY3Niwgcl9lZmxhZ3MgPSAzMjQzNjgxOTIwLCByX2VzcCA9IDEsIHJf c3MgPSAzMjI4MDE5OTQ5LCAKICAgIHJfZ3MgPSAyOTl9fQoJYWRkciA9ICh2b2lkICopIDB4MAoJ ZXJyb3IgPSAwCiMxMyAweGMwNjM5YTlmIGluIHN5c2NhbGwgKGZyYW1lPQogICAgICB7dGZfZnMg PSA1OSwgdGZfZXMgPSA1OSwgdGZfZHMgPSA1OSwgdGZfZWRpID0gLTEwNzc5NDA3OTYsIHRmX2Vz aSA9IDY4NywgdGZfZWJwID0gLTEwNzc5NDIxMzYsIHRmX2lzcCA9IC0zOTA4MDQxMjQsIHRmX2Vi eCA9IDY4NywgdGZfZWR4ID0gNjc0OTg2MDkyLCB0Zl9lY3ggPSA2NzQ5MDMyNjgsIHRmX2VheCA9 IDI2LCB0Zl90cmFwbm8gPSAxMiwgdGZfZXJyID0gMiwgdGZfZWlwID0gNjc0MjYwMDExLCB0Zl9j cyA9IDUxLCB0Zl9lZmxhZ3MgPSA1MTgsIHRmX2VzcCA9IC0xMDc3OTQyMTY0LCB0Zl9zcyA9IDU5 fSkgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni90cmFwLmM6OTU5CglwYXJhbXMgPSAweGJmYmZl ODcwIDxBZGRyZXNzIDB4YmZiZmU4NzAgb3V0IG9mIGJvdW5kcz4KCWNhbGxwID0gKHN0cnVjdCBz eXNlbnQgKikgMHhjMDZhZmFmMAoJdGQgPSAoc3RydWN0IHRocmVhZCAqKSAweGMyMDhkNjQwCglw ID0gKHN0cnVjdCBwcm9jICopIDB4YzIwOGI2MDAKCW9yaWdfdGZfZWZsYWdzID0gNTE4CglzdGlj a3MgPSAxCgllcnJvciA9IDAKCW5hcmcgPSA0CglhcmdzID0gezEwLCA2ODcsIDAsIDAsIDAsIDAs IDEsIC0xMDM5NjE2NTEyfQoJY29kZSA9IDI2CiMxNCAweGMwNjJjZjVmIGluIFhpbnQweDgwX3N5 c2NhbGwgKCkgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni9leGNlcHRpb24uczoyMDAKTm8gbG9j YWxzLgojMTUgMHgwMDAwMDAzYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFi bGUuCiMxNiAweDAwMDAwMDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJs ZS4KIzE3IDB4MDAwMDAwM2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxl LgojMTggMHhiZmJmZWRjNCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUu CiMxOSAweDAwMDAwMmFmIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4K IzIwIDB4YmZiZmU4ODggaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgoj MjEgMHhlOGI0Y2Q2NCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMy MiAweDAwMDAwMmFmIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzIz IDB4MjgzYjc4NmMgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjQg MHgyODNhMzRlNCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyNSAw eDAwMDAwMDFhIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI2IDB4 MDAwMDAwMGMgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjcgMHgw MDAwMDAwMiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyOCAweDI4 MzA2NDJiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI5IDB4MDAw MDAwMzMgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzAgMHgwMDAw MDIwNiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMSAweGJmYmZl ODZjIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMyIDB4MDAwMDAw M2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzMgMHgwMDAwMDAw MCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNCAweDAwMDAwMDAw IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM1IDB4MDAwMDAwMDAg aW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzYgMHgwMDAwMDAwMCBp biA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNyAweDFmNGI5MDAwIGlu ID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM4IDB4YzIwOGQ3OTQgaW4g Pz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzkgMHhjMTU4MGUxMCBpbiA/ PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MCAweGU4YjRjYzdjIGluID8/ ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQxIDB4ZThiNGNjNjQgaW4gPz8g KCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDIgMHhjMjA4ZDY0MCBpbiA/PyAo KQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MyAweGMwNTI2OGU3IGluIHNjaGVk X3N3aXRjaCAodGQ9MHgyYWYsIG5ld3RkPTB4MmFmLCBmbGFncz0wKSBhdCAvdXNyL3NyYy9zeXMv a2Vybi9zY2hlZF91bGUuYzoxNDAzCglrZSA9IChzdHJ1Y3QgdGRfc2NoZWQgKikgMHhiZmJmZWRj NAooa2dkYikgCiMwICBkb2FkdW1wICgpIGF0IHBjcHUuaDoxNjUKTm8gbG9jYWxzLgojMSAgMHhj MDQ2MGMxMiBpbiBkYl9mbmNhbGwgKGR1bW15MT0wLCBkdW1teTI9MCwgZHVtbXkzPS0xMDY3MzA0 ODg5LCBkdW1teTQ9MHhlOGI0YzlmYyAiKMq06FwyMzBcMDMzYsBcMDI0yrToXDAzMMq06FwyMjBc MDI3IikKICAgIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjUzMQoJZm5fYWRkciA9 IC0xMDY4NDA5Njg0CglhcmdzID0gezAgPHJlcGVhdHMgMTEgdGltZXM+fQoJbmFyZ3MgPSAxMQoJ cmV0dmFsID0gMAoJZnVuYyA9IChmY25fMTBhcmdzX3QgKikgMHhjMDUxNWNhYyA8ZG9hZHVtcD4K CXQgPSAwCiMyICAweGMwNDYwYTIwIGluIGRiX2NvbW1hbmQgKGxhc3RfY21kcD0weGMwNmQyNGE0 LCBjbWRfdGFibGU9MHgwLCBhdXhfY21kX3RhYmxlcD0weGMwNjliNmYwLCBhdXhfY21kX3RhYmxl cF9lbmQ9MHhjMDY5YjZmNCkKICAgIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjM0 OQoJY21kID0gKHN0cnVjdCBjb21tYW5kICopIDB4YzA2YTExNjAKCXQgPSAwCgltb2RpZiA9ICIo yrToXDIzMFwwMzNiwFwwMjTKtOhcMDMwyrToXDIyMFwwMjdcMDAwXDAwMFwyMjBcMDI3XDAwMFww MDD/XDAyN1wwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDD2c8BcclwwMDBcMDAwXDAwMFwwMDD2 c8BcMDAw9nPAXHJcMDAwXDAwMFwwMDBcMDAxXDAwMFwwMDBcMDAwVMq06MtcMDI0YsBUyrTo5Fww MjRiwODCcsDAe3LAeFwwMDBcMDAwXDAwMKAtbcBcZlwwMDBcMDAwXDAwMHTKtOhcMDIwKkbAJr1n wFwwMDAnRsBcZlwwMDBcMDAwXDAwMKAtbcCyXDAzNkbAIgoJYWRkciA9IDAKCWNvdW50ID0gLTEw NjczMDQ4ODkKCWhhdmVfYWRkciA9IDAKCXJlc3VsdCA9IDAKIzMgIDB4YzA0NjBhZTggaW4gZGJf Y29tbWFuZF9sb29wICgpIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjQ1NQpObyBs b2NhbHMuCiM0ICAweGMwNDYyNjZkIGluIGRiX3RyYXAgKHR5cGU9MTIsIGNvZGU9MCkgYXQgL3Vz ci9zcmMvc3lzL2RkYi9kYl9tYWluLmM6MjIxCglqYiA9IHt7X2piID0gey0zOTA4MDQ4MTIsIC0z OTA4MDQ4MzIsIC0zOTA4MDQ3NjAsIC0zOTA4MDQ2MzIsIDEyLCAtMTA2OTE0NDU3MCwgMTIsIC0z OTA4MDQ3MzYsIC0xMDY4MzAzMTQ1LCAKICAgICAgLTEwNjY4MzkxMjUsIC0xMDY4MzAzMDEyLCAt MzkwODA0NzU2fX19CglwcmV2X2piID0gKHZvaWQgKikgMHgwCglia3B0ID0gMAojNSAgMHhjMDUy ZTRkMyBpbiBrZGJfdHJhcCAodHlwZT0xMiwgY29kZT0wLCB0Zj0weGU4YjRjYjY4KSBhdCAvdXNy L3NyYy9zeXMva2Vybi9zdWJyX2tkYi5jOjQ3MQoJaGFuZGxlZCA9IC0zOTA4MDQ2MzIKIzYgIDB4 YzA2Mzk3ZTcgaW4gdHJhcF9mYXRhbCAoZnJhbWU9MHhlOGI0Y2I2OCwgZXZhPTcyKSBhdCAvdXNy L3NyYy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzo4MDkKCWNvZGUgPSA0MAoJdHlwZSA9IDEyCglzcyA9 IDQwCgllc3AgPSAwCglzb2Z0c2VnID0ge3NzZF9iYXNlID0gMCwgc3NkX2xpbWl0ID0gMTA0ODU3 NSwgc3NkX3R5cGUgPSAyNywgc3NkX2RwbCA9IDAsIHNzZF9wID0gMSwgc3NkX3h4ID0gMCwgc3Nk X3h4MSA9IDAsIAogIHNzZF9kZWYzMiA9IDEsIHNzZF9ncmFuID0gMX0KIzcgIDB4YzA2MzhmODYg aW4gdHJhcCAoZnJhbWU9CiAgICAgIHt0Zl9mcyA9IDgsIHRmX2VzID0gLTM5MDg1NjY2NCwgdGZf ZHMgPSAtMTA2ODQ5ODkwNCwgdGZfZWRpID0gLTEwMzk2MTU0ODgsIHRmX2VzaSA9IDE2LCB0Zl9l YnAgPSAtMzkwODA0NDc2LCB0Zl9pc3AgPSAtMzkwODA0NTg4LCB0Zl9lYnggPSAtMTA0MzIzNzMx MiwgdGZfZWR4ID0gLTEwMzk2MDgyNTYsIHRmX2VjeCA9IDEsIHRmX2VheCA9IDAsIHRmX3RyYXBu byA9IDEyLCB0Zl9lcnIgPSAyLCB0Zl9laXAgPSAtMTA2ODI0MjY2NiwgdGZfY3MgPSAzMiwgdGZf ZWZsYWdzID0gNjU2NjcsIHRmX2VzcCA9IC0xMDY2OTI5NDg0LCB0Zl9zcyA9IDE3MDd9KSBhdCAv dXNyL3NyYy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzoyNTIKCXRkID0gKHN0cnVjdCB0aHJlYWQgKikg MHhjMjA4ZDY0MAoJcCA9IChzdHJ1Y3QgcHJvYyAqKSAweGMyMDhiNjAwCglzdGlja3MgPSAzOTA0 MTYyNjcyCglpID0gMAoJdWNvZGUgPSAwCgl0eXBlID0gMTIKCWNvZGUgPSAyCglldmEgPSA3Mgoj OCAgMHhjMDYyY2YwYSBpbiBjYWxsdHJhcCAoKSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4 Y2VwdGlvbi5zOjEzOQpObyBsb2NhbHMuCiM5ICAweDAwMDAwMDA4IGluID8/ICgpCk5vIHN5bWJv bCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzEwIDB4ZThiNDAwMjggaW4gPz8gKCkKTm8gc3ltYm9s IHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTEgMHhjMDUwMDAyOCBpbiBleGVjX21hcF9maXJzdF9w YWdlIChpbWdwPTB4YzIwOGQ2NDApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tlcm5fZXhlYy5jOjgw MwoJaSA9IC0xMDQzMjM3MzEyCglpbml0aWFsX3BhZ2VpbiA9IC0xMDM5NjE1NDg4CgltYSA9IHsw eDE4NzJjLCAweDEsIDB4MjQ2LCAweDAsIDB4YzIwOGI2MDAsIDB4MCwgMHhjMjA4ZDZiOCwgMHhl OGI0Y2JmMCwgMHhjMDUyNzZlNywgMHhjMDZkYmNjMCwgMHgyLCAweGMwNjdkMWUyLCAKICAweDI1 NywgMHhjMjA4ZDY0MCwgMHhlOGI0Y2JmYywgMHgyNDZ9CglvYmplY3QgPSAweDEwCiMxMiAweGMw NTNlMDEyIGluIHB0cmFjZSAodGQ9MHhjMjA4ZDY0MCwgdWFwPTB4ZThiNGNkMDQpIGF0IC91c3Iv c3JjL3N5cy9rZXJuL3N5c19wcm9jZXNzLmM6MzM5CglyID0ge3Bpb2QgPSB7cGlvZF9vcCA9IC0x MDY2NTI2NTkyLCBwaW9kX29mZnMgPSAweDAsIHBpb2RfYWRkciA9IDB4YzA2N2YyYjQsIHBpb2Rf bGVuID0gMTcwN30sIHBsID0gewogICAgcGxfbHdwaWQgPSAtMTA2NjUyNjU5MiwgcGxfZXZlbnQg PSAwLCBwbF9mbGFncyA9IC0xMDY2OTI5NDg0fSwgZGJyZWcgPSB7ZHIgPSB7MzIyODQ0MDcwNCwg MCwgMzIyODAzNzgxMiwgMTcwNywgCiAgICAgIDMyMjg3MjczODAsIDM5MDQxNjI5MDAsIDMyMjY2 OTgyMTQsIDMyMjg3MjczNzZ9fSwgZnByZWcgPSB7ZnByX2VudiA9IHszMjI4NDQwNzA0LCAwLCAz MjI4MDM3ODEyLCAxNzA3LCAzMjI4NzI3MzgwLCAKICAgICAgMzkwNDE2MjkwMCwgMzIyNjY5ODIx NH0sIGZwcl9hY2MgPSB7IlB4csBGXDAwMlwwMDBcMDAwyDsiLCAia8BcMjAwqFbBQ1xiXDAwMCIs ICKiXDIwN2fAeMy06OzfIiwgCiAgICAgICJQwFwyMDCoVsFcMDAxXDAwMFwwMDAiLCAi7axnwCtc MDAxXDAwMFwwMDDYICIsICJ8wVwwMDTNtOhA1lxiwiIsICJcMjMwzLTobLFPwFwyMDCoIiwgIlbB XDAwMFwwMDBcMDAwXDAwMKJcMjA3Z8AifSwgCiAgICBmcHJfZXhfc3cgPSAyMTE1LCAKICAgIGZw cl9wYWQgPSAi2CB8wVwwMDTNtOi8zLToKLFPwNggfMFA1lxiwlwyMDCoVsFcMDAwXDAwMFwwMDBc MDAwolwyMDdnwDJcYlwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMEDWXGLCXDAwMLZcYsIwzbToXDAw MFwwMDBcMDAwXDAwMEDWXGLCIn0sIHJlZyA9IHtyX2ZzID0gMzIyODQ0MDcwNCwgcl9lcyA9IDAs IHJfZHMgPSAzMjI4MDM3ODEyLCByX2VkaSA9IDE3MDcsIHJfZXNpID0gMzIyODcyNzM4MCwgcl9l YnAgPSAzOTA0MTYyOTAwLCAKICAgIHJfaXNwID0gMzIyNjY5ODIxNCwgcl9lYnggPSAzMjI4NzI3 Mzc2LCByX2VkeCA9IDU4Miwgcl9lY3ggPSAzMjI4MjUzMTI4LCByX2VheCA9IDMyNDM2ODE5MjAs IHJfdHJhcG5vID0gMjExNSwgCiAgICByX2VyciA9IDMyMjgwMTA0MDIsIHJfZWlwID0gMzkwNDE2 MjkzNiwgcl9jcyA9IDMyMjY1MjU2NzYsIHJfZWZsYWdzID0gMzI0MzY4MTkyMCwgcl9lc3AgPSAx LCByX3NzID0gMzIyODAxOTk0OSwgCiAgICByX2dzID0gMjk5fX0KCWFkZHIgPSAodm9pZCAqKSAw eDAKCWVycm9yID0gMAojMTMgMHhjMDYzOWE5ZiBpbiBzeXNjYWxsIChmcmFtZT0KICAgICAge3Rm X2ZzID0gNTksIHRmX2VzID0gNTksIHRmX2RzID0gNTksIHRmX2VkaSA9IC0xMDc3OTQwNzk2LCB0 Zl9lc2kgPSA2ODcsIHRmX2VicCA9IC0xMDc3OTQyMTM2LCB0Zl9pc3AgPSAtMzkwODA0MTI0LCB0 Zl9lYnggPSA2ODcsIHRmX2VkeCA9IDY3NDk4NjA5MiwgdGZfZWN4ID0gNjc0OTAzMjY4LCB0Zl9l YXggPSAyNiwgdGZfdHJhcG5vID0gMTIsIHRmX2VyciA9IDIsIHRmX2VpcCA9IDY3NDI2MDAxMSwg dGZfY3MgPSA1MSwgdGZfZWZsYWdzID0gNTE4LCB0Zl9lc3AgPSAtMTA3Nzk0MjE2NCwgdGZfc3Mg PSA1OX0pIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvdHJhcC5jOjk1OQoJcGFyYW1zID0gMHhi ZmJmZTg3MCA8QWRkcmVzcyAweGJmYmZlODcwIG91dCBvZiBib3VuZHM+CgljYWxscCA9IChzdHJ1 Y3Qgc3lzZW50ICopIDB4YzA2YWZhZjAKCXRkID0gKHN0cnVjdCB0aHJlYWQgKikgMHhjMjA4ZDY0 MAoJcCA9IChzdHJ1Y3QgcHJvYyAqKSAweGMyMDhiNjAwCglvcmlnX3RmX2VmbGFncyA9IDUxOAoJ c3RpY2tzID0gMQoJZXJyb3IgPSAwCgluYXJnID0gNAoJYXJncyA9IHsxMCwgNjg3LCAwLCAwLCAw LCAwLCAxLCAtMTAzOTYxNjUxMn0KCWNvZGUgPSAyNgojMTQgMHhjMDYyY2Y1ZiBpbiBYaW50MHg4 MF9zeXNjYWxsICgpIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvZXhjZXB0aW9uLnM6MjAwCk5v IGxvY2Fscy4KIzE1IDB4MDAwMDAwM2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLgojMTYgMHgwMDAwMDAzYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFp bGFibGUuCiMxNyAweDAwMDAwMDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWls YWJsZS4KIzE4IDB4YmZiZmVkYzQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxh YmxlLgojMTkgMHgwMDAwMDJhZiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFi bGUuCiMyMCAweGJmYmZlODg4IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJs ZS4KIzIxIDB4ZThiNGNkNjQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxl LgojMjIgMHgwMDAwMDJhZiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUu CiMyMyAweDI4M2I3ODZjIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4K IzI0IDB4MjgzYTM0ZTQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgoj MjUgMHgwMDAwMDAxYSBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMy NiAweDAwMDAwMDBjIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzI3 IDB4MDAwMDAwMDIgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMjgg MHgyODMwNjQyYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMyOSAw eDAwMDAwMDMzIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMwIDB4 MDAwMDAyMDYgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzEgMHhi ZmJmZTg2YyBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMiAweDAw MDAwMDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMzIDB4MDAw MDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzQgMHgwMDAw MDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNSAweDAwMDAw MDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM2IDB4MDAwMDAw MDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzcgMHgxZjRiOTAw MCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzOCAweGMyMDhkNzk0 IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM5IDB4YzE1ODBlMTAg aW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDAgMHhlOGI0Y2M3YyBp biA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MSAweGU4YjRjYzY0IGlu ID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQyIDB4YzIwOGQ2NDAgaW4g Pz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDMgMHhjMDUyNjhlNyBpbiBz Y2hlZF9zd2l0Y2ggKHRkPTB4MmFmLCBuZXd0ZD0weDJhZiwgZmxhZ3M9MCkgYXQgL3Vzci9zcmMv c3lzL2tlcm4vc2NoZWRfdWxlLmM6MTQwMwoJa2UgPSAoc3RydWN0IHRkX3NjaGVkICopIDB4YmZi ZmVkYzQKKGtnZGIpIAojMCAgZG9hZHVtcCAoKSBhdCBwY3B1Lmg6MTY1Ck5vIGxvY2Fscy4KIzEg IDB4YzA0NjBjMTIgaW4gZGJfZm5jYWxsIChkdW1teTE9MCwgZHVtbXkyPTAsIGR1bW15Mz0tMTA2 NzMwNDg4OSwgZHVtbXk0PTB4ZThiNGM5ZmMgIijKtOhcMjMwXDAzM2LAXDAyNMq06FwwMzDKtOhc MjIwXDAyNyIpCiAgICBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo1MzEKCWZuX2Fk ZHIgPSAtMTA2ODQwOTY4NAoJYXJncyA9IHswIDxyZXBlYXRzIDExIHRpbWVzPn0KCW5hcmdzID0g MTEKCXJldHZhbCA9IDAKCWZ1bmMgPSAoZmNuXzEwYXJnc190ICopIDB4YzA1MTVjYWMgPGRvYWR1 bXA+Cgl0ID0gMAojMiAgMHhjMDQ2MGEyMCBpbiBkYl9jb21tYW5kIChsYXN0X2NtZHA9MHhjMDZk MjRhNCwgY21kX3RhYmxlPTB4MCwgYXV4X2NtZF90YWJsZXA9MHhjMDY5YjZmMCwgYXV4X2NtZF90 YWJsZXBfZW5kPTB4YzA2OWI2ZjQpCiAgICBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQu YzozNDkKCWNtZCA9IChzdHJ1Y3QgY29tbWFuZCAqKSAweGMwNmExMTYwCgl0ID0gMAoJbW9kaWYg PSAiKMq06FwyMzBcMDMzYsBcMDI0yrToXDAzMMq06FwyMjBcMDI3XDAwMFwwMDBcMjIwXDAyN1ww MDBcMDAw/1wwMjdcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDBcMDAw9nPAXHJcMDAwXDAwMFwwMDBc MDAw9nPAXDAwMPZzwFxyXDAwMFwwMDBcMDAwXDAwMVwwMDBcMDAwXDAwMFTKtOjLXDAyNGLAVMq0 6ORcMDI0YsDgwnLAwHtywHhcMDAwXDAwMFwwMDCgLW3AXGZcMDAwXDAwMFwwMDB0yrToXDAyMCpG wCa9Z8BcMDAwJ0bAXGZcMDAwXDAwMFwwMDCgLW3AslwwMzZGwCIKCWFkZHIgPSAwCgljb3VudCA9 IC0xMDY3MzA0ODg5CgloYXZlX2FkZHIgPSAwCglyZXN1bHQgPSAwCiMzICAweGMwNDYwYWU4IGlu IGRiX2NvbW1hbmRfbG9vcCAoKSBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX2NvbW1hbmQuYzo0NTUK Tm8gbG9jYWxzLgojNCAgMHhjMDQ2MjY2ZCBpbiBkYl90cmFwICh0eXBlPTEyLCBjb2RlPTApIGF0 IC91c3Ivc3JjL3N5cy9kZGIvZGJfbWFpbi5jOjIyMQoJamIgPSB7e19qYiA9IHstMzkwODA0ODEy LCAtMzkwODA0ODMyLCAtMzkwODA0NzYwLCAtMzkwODA0NjMyLCAxMiwgLTEwNjkxNDQ1NzAsIDEy LCAtMzkwODA0NzM2LCAtMTA2ODMwMzE0NSwgCiAgICAgIC0xMDY2ODM5MTI1LCAtMTA2ODMwMzAx MiwgLTM5MDgwNDc1Nn19fQoJcHJldl9qYiA9ICh2b2lkICopIDB4MAoJYmtwdCA9IDAKIzUgIDB4 YzA1MmU0ZDMgaW4ga2RiX3RyYXAgKHR5cGU9MTIsIGNvZGU9MCwgdGY9MHhlOGI0Y2I2OCkgYXQg L3Vzci9zcmMvc3lzL2tlcm4vc3Vicl9rZGIuYzo0NzEKCWhhbmRsZWQgPSAtMzkwODA0NjMyCiM2 ICAweGMwNjM5N2U3IGluIHRyYXBfZmF0YWwgKGZyYW1lPTB4ZThiNGNiNjgsIGV2YT03MikgYXQg L3Vzci9zcmMvc3lzL2kzODYvaTM4Ni90cmFwLmM6ODA5Cgljb2RlID0gNDAKCXR5cGUgPSAxMgoJ c3MgPSA0MAoJZXNwID0gMAoJc29mdHNlZyA9IHtzc2RfYmFzZSA9IDAsIHNzZF9saW1pdCA9IDEw NDg1NzUsIHNzZF90eXBlID0gMjcsIHNzZF9kcGwgPSAwLCBzc2RfcCA9IDEsIHNzZF94eCA9IDAs IHNzZF94eDEgPSAwLCAKICBzc2RfZGVmMzIgPSAxLCBzc2RfZ3JhbiA9IDF9CiM3ICAweGMwNjM4 Zjg2IGluIHRyYXAgKGZyYW1lPQogICAgICB7dGZfZnMgPSA4LCB0Zl9lcyA9IC0zOTA4NTY2NjQs IHRmX2RzID0gLTEwNjg0OTg5MDQsIHRmX2VkaSA9IC0xMDM5NjE1NDg4LCB0Zl9lc2kgPSAxNiwg dGZfZWJwID0gLTM5MDgwNDQ3NiwgdGZfaXNwID0gLTM5MDgwNDU4OCwgdGZfZWJ4ID0gLTEwNDMy MzczMTIsIHRmX2VkeCA9IC0xMDM5NjA4MjU2LCB0Zl9lY3ggPSAxLCB0Zl9lYXggPSAwLCB0Zl90 cmFwbm8gPSAxMiwgdGZfZXJyID0gMiwgdGZfZWlwID0gLTEwNjgyNDI2NjYsIHRmX2NzID0gMzIs IHRmX2VmbGFncyA9IDY1NjY3LCB0Zl9lc3AgPSAtMTA2NjkyOTQ4NCwgdGZfc3MgPSAxNzA3fSkg YXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni90cmFwLmM6MjUyCgl0ZCA9IChzdHJ1Y3QgdGhyZWFk ICopIDB4YzIwOGQ2NDAKCXAgPSAoc3RydWN0IHByb2MgKikgMHhjMjA4YjYwMAoJc3RpY2tzID0g MzkwNDE2MjY3MgoJaSA9IDAKCXVjb2RlID0gMAoJdHlwZSA9IDEyCgljb2RlID0gMgoJZXZhID0g NzIKIzggIDB4YzA2MmNmMGEgaW4gY2FsbHRyYXAgKCkgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4 Ni9leGNlcHRpb24uczoxMzkKTm8gbG9jYWxzLgojOSAgMHgwMDAwMDAwOCBpbiA/PyAoKQpObyBz eW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxMCAweGU4YjQwMDI4IGluID8/ICgpCk5vIHN5 bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzExIDB4YzA1MDAwMjggaW4gZXhlY19tYXBfZmly c3RfcGFnZSAoaW1ncD0weGMyMDhkNjQwKSBhdCAvdXNyL3NyYy9zeXMva2Vybi9rZXJuX2V4ZWMu Yzo4MDMKCWkgPSAtMTA0MzIzNzMxMgoJaW5pdGlhbF9wYWdlaW4gPSAtMTAzOTYxNTQ4OAoJbWEg PSB7MHgxODcyYywgMHgxLCAweDI0NiwgMHgwLCAweGMyMDhiNjAwLCAweDAsIDB4YzIwOGQ2Yjgs IDB4ZThiNGNiZjAsIDB4YzA1Mjc2ZTcsIDB4YzA2ZGJjYzAsIDB4MiwgMHhjMDY3ZDFlMiwgCiAg MHgyNTcsIDB4YzIwOGQ2NDAsIDB4ZThiNGNiZmMsIDB4MjQ2fQoJb2JqZWN0ID0gMHgxMAojMTIg MHhjMDUzZTAxMiBpbiBwdHJhY2UgKHRkPTB4YzIwOGQ2NDAsIHVhcD0weGU4YjRjZDA0KSBhdCAv dXNyL3NyYy9zeXMva2Vybi9zeXNfcHJvY2Vzcy5jOjMzOQoJciA9IHtwaW9kID0ge3Bpb2Rfb3Ag PSAtMTA2NjUyNjU5MiwgcGlvZF9vZmZzID0gMHgwLCBwaW9kX2FkZHIgPSAweGMwNjdmMmI0LCBw aW9kX2xlbiA9IDE3MDd9LCBwbCA9IHsKICAgIHBsX2x3cGlkID0gLTEwNjY1MjY1OTIsIHBsX2V2 ZW50ID0gMCwgcGxfZmxhZ3MgPSAtMTA2NjkyOTQ4NH0sIGRicmVnID0ge2RyID0gezMyMjg0NDA3 MDQsIDAsIDMyMjgwMzc4MTIsIDE3MDcsIAogICAgICAzMjI4NzI3MzgwLCAzOTA0MTYyOTAwLCAz MjI2Njk4MjE0LCAzMjI4NzI3Mzc2fX0sIGZwcmVnID0ge2Zwcl9lbnYgPSB7MzIyODQ0MDcwNCwg MCwgMzIyODAzNzgxMiwgMTcwNywgMzIyODcyNzM4MCwgCiAgICAgIDM5MDQxNjI5MDAsIDMyMjY2 OTgyMTR9LCBmcHJfYWNjID0geyJQeHLARlwwMDJcMDAwXDAwMMg7IiwgImvAXDIwMKhWwUNcYlww MDAiLCAiolwyMDdnwHjMtOjs3yIsIAogICAgICAiUMBcMjAwqFbBXDAwMVwwMDBcMDAwIiwgIu2s Z8ArXDAwMVwwMDBcMDAw2CAiLCAifMFcMDA0zbToQNZcYsIiLCAiXDIzMMy06GyxT8BcMjAwqCIs ICJWwVwwMDBcMDAwXDAwMFwwMDCiXDIwN2fAIn0sIAogICAgZnByX2V4X3N3ID0gMjExNSwgCiAg ICBmcHJfcGFkID0gItggfMFcMDA0zbTovMy06CixT8DYIHzBQNZcYsJcMjAwqFbBXDAwMFwwMDBc MDAwXDAwMKJcMjA3Z8AyXGJcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDBA1lxiwlwwMDC2XGLCMM20 6FwwMDBcMDAwXDAwMFwwMDBA1lxiwiJ9LCByZWcgPSB7cl9mcyA9IDMyMjg0NDA3MDQsIHJfZXMg PSAwLCByX2RzID0gMzIyODAzNzgxMiwgcl9lZGkgPSAxNzA3LCByX2VzaSA9IDMyMjg3MjczODAs IHJfZWJwID0gMzkwNDE2MjkwMCwgCiAgICByX2lzcCA9IDMyMjY2OTgyMTQsIHJfZWJ4ID0gMzIy ODcyNzM3Niwgcl9lZHggPSA1ODIsIHJfZWN4ID0gMzIyODI1MzEyOCwgcl9lYXggPSAzMjQzNjgx OTIwLCByX3RyYXBubyA9IDIxMTUsIAogICAgcl9lcnIgPSAzMjI4MDEwNDAyLCByX2VpcCA9IDM5 MDQxNjI5MzYsIHJfY3MgPSAzMjI2NTI1Njc2LCByX2VmbGFncyA9IDMyNDM2ODE5MjAsIHJfZXNw ID0gMSwgcl9zcyA9IDMyMjgwMTk5NDksIAogICAgcl9ncyA9IDI5OX19CglhZGRyID0gKHZvaWQg KikgMHgwCgllcnJvciA9IDAKIzEzIDB4YzA2MzlhOWYgaW4gc3lzY2FsbCAoZnJhbWU9CiAgICAg IHt0Zl9mcyA9IDU5LCB0Zl9lcyA9IDU5LCB0Zl9kcyA9IDU5LCB0Zl9lZGkgPSAtMTA3Nzk0MDc5 NiwgdGZfZXNpID0gNjg3LCB0Zl9lYnAgPSAtMTA3Nzk0MjEzNiwgdGZfaXNwID0gLTM5MDgwNDEy NCwgdGZfZWJ4ID0gNjg3LCB0Zl9lZHggPSA2NzQ5ODYwOTIsIHRmX2VjeCA9IDY3NDkwMzI2OCwg dGZfZWF4ID0gMjYsIHRmX3RyYXBubyA9IDEyLCB0Zl9lcnIgPSAyLCB0Zl9laXAgPSA2NzQyNjAw MTEsIHRmX2NzID0gNTEsIHRmX2VmbGFncyA9IDUxOCwgdGZfZXNwID0gLTEwNzc5NDIxNjQsIHRm X3NzID0gNTl9KSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzo5NTkKCXBhcmFtcyA9 IDB4YmZiZmU4NzAgPEFkZHJlc3MgMHhiZmJmZTg3MCBvdXQgb2YgYm91bmRzPgoJY2FsbHAgPSAo c3RydWN0IHN5c2VudCAqKSAweGMwNmFmYWYwCgl0ZCA9IChzdHJ1Y3QgdGhyZWFkICopIDB4YzIw OGQ2NDAKCXAgPSAoc3RydWN0IHByb2MgKikgMHhjMjA4YjYwMAoJb3JpZ190Zl9lZmxhZ3MgPSA1 MTgKCXN0aWNrcyA9IDEKCWVycm9yID0gMAoJbmFyZyA9IDQKCWFyZ3MgPSB7MTAsIDY4NywgMCwg MCwgMCwgMCwgMSwgLTEwMzk2MTY1MTJ9Cgljb2RlID0gMjYKIzE0IDB4YzA2MmNmNWYgaW4gWGlu dDB4ODBfc3lzY2FsbCAoKSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L2V4Y2VwdGlvbi5zOjIw MApObyBsb2NhbHMuCiMxNSAweDAwMDAwMDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZv IGF2YWlsYWJsZS4KIzE2IDB4MDAwMDAwM2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8g YXZhaWxhYmxlLgojMTcgMHgwMDAwMDAzYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBh dmFpbGFibGUuCiMxOCAweGJmYmZlZGM0IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2 YWlsYWJsZS4KIzE5IDB4MDAwMDAyYWYgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLgojMjAgMHhiZmJmZTg4OCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFp bGFibGUuCiMyMSAweGU4YjRjZDY0IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWls YWJsZS4KIzIyIDB4MDAwMDAyYWYgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxh YmxlLgojMjMgMHgyODNiNzg2YyBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFi bGUuCiMyNCAweDI4M2EzNGU0IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJs ZS4KIzI1IDB4MDAwMDAwMWEgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxl LgojMjYgMHgwMDAwMDAwYyBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUu CiMyNyAweDAwMDAwMDAyIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4K IzI4IDB4MjgzMDY0MmIgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgoj MjkgMHgwMDAwMDAzMyBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMz MCAweDAwMDAwMjA2IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzMx IDB4YmZiZmU4NmMgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzIg MHgwMDAwMDAzYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzMyAw eDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM0IDB4 MDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzUgMHgw MDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNiAweDAw MDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM3IDB4MWY0 YjkwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzggMHhjMjA4 ZDc5NCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzOSAweGMxNTgw ZTEwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQwIDB4ZThiNGNj N2MgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDEgMHhlOGI0Y2M2 NCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MiAweGMyMDhkNjQw IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQzIDB4YzA1MjY4ZTcg aW4gc2NoZWRfc3dpdGNoICh0ZD0weDJhZiwgbmV3dGQ9MHgyYWYsIGZsYWdzPTApIGF0IC91c3Iv c3JjL3N5cy9rZXJuL3NjaGVkX3VsZS5jOjE0MDMKCWtlID0gKHN0cnVjdCB0ZF9zY2hlZCAqKSAw eGJmYmZlZGM0CihrZ2RiKSAKIzAgIGRvYWR1bXAgKCkgYXQgcGNwdS5oOjE2NQpObyBsb2NhbHMu CiMxICAweGMwNDYwYzEyIGluIGRiX2ZuY2FsbCAoZHVtbXkxPTAsIGR1bW15Mj0wLCBkdW1teTM9 LTEwNjczMDQ4ODksIGR1bW15ND0weGU4YjRjOWZjICIoyrToXDIzMFwwMzNiwFwwMjTKtOhcMDMw yrToXDIyMFwwMjciKQogICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6NTMxCglm bl9hZGRyID0gLTEwNjg0MDk2ODQKCWFyZ3MgPSB7MCA8cmVwZWF0cyAxMSB0aW1lcz59CgluYXJn cyA9IDExCglyZXR2YWwgPSAwCglmdW5jID0gKGZjbl8xMGFyZ3NfdCAqKSAweGMwNTE1Y2FjIDxk b2FkdW1wPgoJdCA9IDAKIzIgIDB4YzA0NjBhMjAgaW4gZGJfY29tbWFuZCAobGFzdF9jbWRwPTB4 YzA2ZDI0YTQsIGNtZF90YWJsZT0weDAsIGF1eF9jbWRfdGFibGVwPTB4YzA2OWI2ZjAsIGF1eF9j bWRfdGFibGVwX2VuZD0weGMwNjliNmY0KQogICAgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21t YW5kLmM6MzQ5CgljbWQgPSAoc3RydWN0IGNvbW1hbmQgKikgMHhjMDZhMTE2MAoJdCA9IDAKCW1v ZGlmID0gIijKtOhcMjMwXDAzM2LAXDAyNMq06FwwMzDKtOhcMjIwXDAyN1wwMDBcMDAwXDIyMFww MjdcMDAwXDAwMP9cMDI3XDAwMFwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMPZzwFxyXDAwMFwwMDBc MDAwXDAwMPZzwFwwMDD2c8BcclwwMDBcMDAwXDAwMFwwMDFcMDAwXDAwMFwwMDBUyrToy1wwMjRi wFTKtOjkXDAyNGLA4MJywMB7csB4XDAwMFwwMDBcMDAwoC1twFxmXDAwMFwwMDBcMDAwdMq06Fww MjAqRsAmvWfAXDAwMCdGwFxmXDAwMFwwMDBcMDAwoC1twLJcMDM2RsAiCglhZGRyID0gMAoJY291 bnQgPSAtMTA2NzMwNDg4OQoJaGF2ZV9hZGRyID0gMAoJcmVzdWx0ID0gMAojMyAgMHhjMDQ2MGFl OCBpbiBkYl9jb21tYW5kX2xvb3AgKCkgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9jb21tYW5kLmM6 NDU1Ck5vIGxvY2Fscy4KIzQgIDB4YzA0NjI2NmQgaW4gZGJfdHJhcCAodHlwZT0xMiwgY29kZT0w KSBhdCAvdXNyL3NyYy9zeXMvZGRiL2RiX21haW4uYzoyMjEKCWpiID0ge3tfamIgPSB7LTM5MDgw NDgxMiwgLTM5MDgwNDgzMiwgLTM5MDgwNDc2MCwgLTM5MDgwNDYzMiwgMTIsIC0xMDY5MTQ0NTcw LCAxMiwgLTM5MDgwNDczNiwgLTEwNjgzMDMxNDUsIAogICAgICAtMTA2NjgzOTEyNSwgLTEwNjgz MDMwMTIsIC0zOTA4MDQ3NTZ9fX0KCXByZXZfamIgPSAodm9pZCAqKSAweDAKCWJrcHQgPSAwCiM1 ICAweGMwNTJlNGQzIGluIGtkYl90cmFwICh0eXBlPTEyLCBjb2RlPTAsIHRmPTB4ZThiNGNiNjgp IGF0IC91c3Ivc3JjL3N5cy9rZXJuL3N1YnJfa2RiLmM6NDcxCgloYW5kbGVkID0gLTM5MDgwNDYz MgojNiAgMHhjMDYzOTdlNyBpbiB0cmFwX2ZhdGFsIChmcmFtZT0weGU4YjRjYjY4LCBldmE9NzIp IGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvdHJhcC5jOjgwOQoJY29kZSA9IDQwCgl0eXBlID0g MTIKCXNzID0gNDAKCWVzcCA9IDAKCXNvZnRzZWcgPSB7c3NkX2Jhc2UgPSAwLCBzc2RfbGltaXQg PSAxMDQ4NTc1LCBzc2RfdHlwZSA9IDI3LCBzc2RfZHBsID0gMCwgc3NkX3AgPSAxLCBzc2RfeHgg PSAwLCBzc2RfeHgxID0gMCwgCiAgc3NkX2RlZjMyID0gMSwgc3NkX2dyYW4gPSAxfQojNyAgMHhj MDYzOGY4NiBpbiB0cmFwIChmcmFtZT0KICAgICAge3RmX2ZzID0gOCwgdGZfZXMgPSAtMzkwODU2 NjY0LCB0Zl9kcyA9IC0xMDY4NDk4OTA0LCB0Zl9lZGkgPSAtMTAzOTYxNTQ4OCwgdGZfZXNpID0g MTYsIHRmX2VicCA9IC0zOTA4MDQ0NzYsIHRmX2lzcCA9IC0zOTA4MDQ1ODgsIHRmX2VieCA9IC0x MDQzMjM3MzEyLCB0Zl9lZHggPSAtMTAzOTYwODI1NiwgdGZfZWN4ID0gMSwgdGZfZWF4ID0gMCwg dGZfdHJhcG5vID0gMTIsIHRmX2VyciA9IDIsIHRmX2VpcCA9IC0xMDY4MjQyNjY2LCB0Zl9jcyA9 IDMyLCB0Zl9lZmxhZ3MgPSA2NTY2NywgdGZfZXNwID0gLTEwNjY5Mjk0ODQsIHRmX3NzID0gMTcw N30pIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvdHJhcC5jOjI1MgoJdGQgPSAoc3RydWN0IHRo cmVhZCAqKSAweGMyMDhkNjQwCglwID0gKHN0cnVjdCBwcm9jICopIDB4YzIwOGI2MDAKCXN0aWNr cyA9IDM5MDQxNjI2NzIKCWkgPSAwCgl1Y29kZSA9IDAKCXR5cGUgPSAxMgoJY29kZSA9IDIKCWV2 YSA9IDcyCiM4ICAweGMwNjJjZjBhIGluIGNhbGx0cmFwICgpIGF0IC91c3Ivc3JjL3N5cy9pMzg2 L2kzODYvZXhjZXB0aW9uLnM6MTM5Ck5vIGxvY2Fscy4KIzkgIDB4MDAwMDAwMDggaW4gPz8gKCkK Tm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTAgMHhlOGI0MDAyOCBpbiA/PyAoKQpO byBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMxMSAweGMwNTAwMDI4IGluIGV4ZWNfbWFw X2ZpcnN0X3BhZ2UgKGltZ3A9MHhjMjA4ZDY0MCkgYXQgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9l eGVjLmM6ODAzCglpID0gLTEwNDMyMzczMTIKCWluaXRpYWxfcGFnZWluID0gLTEwMzk2MTU0ODgK CW1hID0gezB4MTg3MmMsIDB4MSwgMHgyNDYsIDB4MCwgMHhjMjA4YjYwMCwgMHgwLCAweGMyMDhk NmI4LCAweGU4YjRjYmYwLCAweGMwNTI3NmU3LCAweGMwNmRiY2MwLCAweDIsIDB4YzA2N2QxZTIs IAogIDB4MjU3LCAweGMyMDhkNjQwLCAweGU4YjRjYmZjLCAweDI0Nn0KCW9iamVjdCA9IDB4MTAK IzEyIDB4YzA1M2UwMTIgaW4gcHRyYWNlICh0ZD0weGMyMDhkNjQwLCB1YXA9MHhlOGI0Y2QwNCkg YXQgL3Vzci9zcmMvc3lzL2tlcm4vc3lzX3Byb2Nlc3MuYzozMzkKCXIgPSB7cGlvZCA9IHtwaW9k X29wID0gLTEwNjY1MjY1OTIsIHBpb2Rfb2ZmcyA9IDB4MCwgcGlvZF9hZGRyID0gMHhjMDY3ZjJi NCwgcGlvZF9sZW4gPSAxNzA3fSwgcGwgPSB7CiAgICBwbF9sd3BpZCA9IC0xMDY2NTI2NTkyLCBw bF9ldmVudCA9IDAsIHBsX2ZsYWdzID0gLTEwNjY5Mjk0ODR9LCBkYnJlZyA9IHtkciA9IHszMjI4 NDQwNzA0LCAwLCAzMjI4MDM3ODEyLCAxNzA3LCAKICAgICAgMzIyODcyNzM4MCwgMzkwNDE2Mjkw MCwgMzIyNjY5ODIxNCwgMzIyODcyNzM3Nn19LCBmcHJlZyA9IHtmcHJfZW52ID0gezMyMjg0NDA3 MDQsIDAsIDMyMjgwMzc4MTIsIDE3MDcsIDMyMjg3MjczODAsIAogICAgICAzOTA0MTYyOTAwLCAz MjI2Njk4MjE0fSwgZnByX2FjYyA9IHsiUHhywEZcMDAyXDAwMFwwMDDIOyIsICJrwFwyMDCoVsFD XGJcMDAwIiwgIqJcMjA3Z8B4zLTo7N8iLCAKICAgICAgIlDAXDIwMKhWwVwwMDFcMDAwXDAwMCIs ICLtrGfAK1wwMDFcMDAwXDAwMNggIiwgInzBXDAwNM206EDWXGLCIiwgIlwyMzDMtOhssU/AXDIw MKgiLCAiVsFcMDAwXDAwMFwwMDBcMDAwolwyMDdnwCJ9LCAKICAgIGZwcl9leF9zdyA9IDIxMTUs IAogICAgZnByX3BhZCA9ICLYIHzBXDAwNM206LzMtOgosU/A2CB8wUDWXGLCXDIwMKhWwVwwMDBc MDAwXDAwMFwwMDCiXDIwN2fAMlxiXDAwMFwwMDBcMDAwXDAwMFwwMDBcMDAwQNZcYsJcMDAwtlxi wjDNtOhcMDAwXDAwMFwwMDBcMDAwQNZcYsIifSwgcmVnID0ge3JfZnMgPSAzMjI4NDQwNzA0LCBy X2VzID0gMCwgcl9kcyA9IDMyMjgwMzc4MTIsIHJfZWRpID0gMTcwNywgcl9lc2kgPSAzMjI4NzI3 MzgwLCByX2VicCA9IDM5MDQxNjI5MDAsIAogICAgcl9pc3AgPSAzMjI2Njk4MjE0LCByX2VieCA9 IDMyMjg3MjczNzYsIHJfZWR4ID0gNTgyLCByX2VjeCA9IDMyMjgyNTMxMjgsIHJfZWF4ID0gMzI0 MzY4MTkyMCwgcl90cmFwbm8gPSAyMTE1LCAKICAgIHJfZXJyID0gMzIyODAxMDQwMiwgcl9laXAg PSAzOTA0MTYyOTM2LCByX2NzID0gMzIyNjUyNTY3Niwgcl9lZmxhZ3MgPSAzMjQzNjgxOTIwLCBy X2VzcCA9IDEsIHJfc3MgPSAzMjI4MDE5OTQ5LCAKICAgIHJfZ3MgPSAyOTl9fQoJYWRkciA9ICh2 b2lkICopIDB4MAoJZXJyb3IgPSAwCiMxMyAweGMwNjM5YTlmIGluIHN5c2NhbGwgKGZyYW1lPQog ICAgICB7dGZfZnMgPSA1OSwgdGZfZXMgPSA1OSwgdGZfZHMgPSA1OSwgdGZfZWRpID0gLTEwNzc5 NDA3OTYsIHRmX2VzaSA9IDY4NywgdGZfZWJwID0gLTEwNzc5NDIxMzYsIHRmX2lzcCA9IC0zOTA4 MDQxMjQsIHRmX2VieCA9IDY4NywgdGZfZWR4ID0gNjc0OTg2MDkyLCB0Zl9lY3ggPSA2NzQ5MDMy NjgsIHRmX2VheCA9IDI2LCB0Zl90cmFwbm8gPSAxMiwgdGZfZXJyID0gMiwgdGZfZWlwID0gNjc0 MjYwMDExLCB0Zl9jcyA9IDUxLCB0Zl9lZmxhZ3MgPSA1MTgsIHRmX2VzcCA9IC0xMDc3OTQyMTY0 LCB0Zl9zcyA9IDU5fSkgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni90cmFwLmM6OTU5CglwYXJh bXMgPSAweGJmYmZlODcwIDxBZGRyZXNzIDB4YmZiZmU4NzAgb3V0IG9mIGJvdW5kcz4KCWNhbGxw ID0gKHN0cnVjdCBzeXNlbnQgKikgMHhjMDZhZmFmMAoJdGQgPSAoc3RydWN0IHRocmVhZCAqKSAw eGMyMDhkNjQwCglwID0gKHN0cnVjdCBwcm9jICopIDB4YzIwOGI2MDAKCW9yaWdfdGZfZWZsYWdz ID0gNTE4CglzdGlja3MgPSAxCgllcnJvciA9IDAKCW5hcmcgPSA0CglhcmdzID0gezEwLCA2ODcs IDAsIDAsIDAsIDAsIDEsIC0xMDM5NjE2NTEyfQoJY29kZSA9IDI2CiMxNCAweGMwNjJjZjVmIGlu IFhpbnQweDgwX3N5c2NhbGwgKCkgYXQgL3Vzci9zcmMvc3lzL2kzODYvaTM4Ni9leGNlcHRpb24u czoyMDAKTm8gbG9jYWxzLgojMTUgMHgwMDAwMDAzYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUg aW5mbyBhdmFpbGFibGUuCiMxNiAweDAwMDAwMDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBp bmZvIGF2YWlsYWJsZS4KIzE3IDB4MDAwMDAwM2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGlu Zm8gYXZhaWxhYmxlLgojMTggMHhiZmJmZWRjNCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5m byBhdmFpbGFibGUuCiMxOSAweDAwMDAwMmFmIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZv IGF2YWlsYWJsZS4KIzIwIDB4YmZiZmU4ODggaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8g YXZhaWxhYmxlLgojMjEgMHhlOGI0Y2Q2NCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBh dmFpbGFibGUuCiMyMiAweDAwMDAwMmFmIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2 YWlsYWJsZS4KIzIzIDB4MjgzYjc4NmMgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLgojMjQgMHgyODNhMzRlNCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFp bGFibGUuCiMyNSAweDAwMDAwMDFhIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWls YWJsZS4KIzI2IDB4MDAwMDAwMGMgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxh YmxlLgojMjcgMHgwMDAwMDAwMiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFi bGUuCiMyOCAweDI4MzA2NDJiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJs ZS4KIzI5IDB4MDAwMDAwMzMgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxl LgojMzAgMHgwMDAwMDIwNiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUu CiMzMSAweGJmYmZlODZjIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4K IzMyIDB4MDAwMDAwM2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgoj MzMgMHgwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMz NCAweDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM1 IDB4MDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzYg MHgwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMzNyAw eDFmNGI5MDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM4IDB4 YzIwOGQ3OTQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMzkgMHhj MTU4MGUxMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MCAweGU4 YjRjYzdjIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQxIDB4ZThi NGNjNjQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDIgMHhjMjA4 ZDY0MCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MyAweGMwNTI2 OGU3IGluIHNjaGVkX3N3aXRjaCAodGQ9MHgyYWYsIG5ld3RkPTB4MmFmLCBmbGFncz0wKSBhdCAv dXNyL3NyYy9zeXMva2Vybi9zY2hlZF91bGUuYzoxNDAzCglrZSA9IChzdHJ1Y3QgdGRfc2NoZWQg KikgMHhiZmJmZWRjNAooa2dkYikgCiMwICBkb2FkdW1wICgpIGF0IHBjcHUuaDoxNjUKTm8gbG9j YWxzLgojMSAgMHhjMDQ2MGMxMiBpbiBkYl9mbmNhbGwgKGR1bW15MT0wLCBkdW1teTI9MCwgZHVt bXkzPS0xMDY3MzA0ODg5LCBkdW1teTQ9MHhlOGI0YzlmYyAiKMq06FwyMzBcMDMzYsBcMDI0yrTo XDAzMMq06FwyMjBcMDI3IikKICAgIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFuZC5jOjUz MQoJZm5fYWRkciA9IC0xMDY4NDA5Njg0CglhcmdzID0gezAgPHJlcGVhdHMgMTEgdGltZXM+fQoJ bmFyZ3MgPSAxMQoJcmV0dmFsID0gMAoJZnVuYyA9IChmY25fMTBhcmdzX3QgKikgMHhjMDUxNWNh YyA8ZG9hZHVtcD4KCXQgPSAwCiMyICAweGMwNDYwYTIwIGluIGRiX2NvbW1hbmQgKGxhc3RfY21k cD0weGMwNmQyNGE0LCBjbWRfdGFibGU9MHgwLCBhdXhfY21kX3RhYmxlcD0weGMwNjliNmYwLCBh dXhfY21kX3RhYmxlcF9lbmQ9MHhjMDY5YjZmNCkKICAgIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJf Y29tbWFuZC5jOjM0OQoJY21kID0gKHN0cnVjdCBjb21tYW5kICopIDB4YzA2YTExNjAKCXQgPSAw Cgltb2RpZiA9ICIoyrToXDIzMFwwMzNiwFwwMjTKtOhcMDMwyrToXDIyMFwwMjdcMDAwXDAwMFwy MjBcMDI3XDAwMFwwMDD/XDAyN1wwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMFwwMDD2c8BcclwwMDBc MDAwXDAwMFwwMDD2c8BcMDAw9nPAXHJcMDAwXDAwMFwwMDBcMDAxXDAwMFwwMDBcMDAwVMq06Mtc MDI0YsBUyrTo5FwwMjRiwODCcsDAe3LAeFwwMDBcMDAwXDAwMKAtbcBcZlwwMDBcMDAwXDAwMHTK tOhcMDIwKkbAJr1nwFwwMDAnRsBcZlwwMDBcMDAwXDAwMKAtbcCyXDAzNkbAIgoJYWRkciA9IDAK CWNvdW50ID0gLTEwNjczMDQ4ODkKCWhhdmVfYWRkciA9IDAKCXJlc3VsdCA9IDAKIzMgIDB4YzA0 NjBhZTggaW4gZGJfY29tbWFuZF9sb29wICgpIGF0IC91c3Ivc3JjL3N5cy9kZGIvZGJfY29tbWFu ZC5jOjQ1NQpObyBsb2NhbHMuCiM0ICAweGMwNDYyNjZkIGluIGRiX3RyYXAgKHR5cGU9MTIsIGNv ZGU9MCkgYXQgL3Vzci9zcmMvc3lzL2RkYi9kYl9tYWluLmM6MjIxCglqYiA9IHt7X2piID0gey0z OTA4MDQ4MTIsIC0zOTA4MDQ4MzIsIC0zOTA4MDQ3NjAsIC0zOTA4MDQ2MzIsIDEyLCAtMTA2OTE0 NDU3MCwgMTIsIC0zOTA4MDQ3MzYsIC0xMDY4MzAzMTQ1LCAKICAgICAgLTEwNjY4MzkxMjUsIC0x MDY4MzAzMDEyLCAtMzkwODA0NzU2fX19CglwcmV2X2piID0gKHZvaWQgKikgMHgwCglia3B0ID0g MAojNSAgMHhjMDUyZTRkMyBpbiBrZGJfdHJhcCAodHlwZT0xMiwgY29kZT0wLCB0Zj0weGU4YjRj YjY4KSBhdCAvdXNyL3NyYy9zeXMva2Vybi9zdWJyX2tkYi5jOjQ3MQoJaGFuZGxlZCA9IC0zOTA4 MDQ2MzIKIzYgIDB4YzA2Mzk3ZTcgaW4gdHJhcF9mYXRhbCAoZnJhbWU9MHhlOGI0Y2I2OCwgZXZh PTcyKSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzo4MDkKCWNvZGUgPSA0MAoJdHlw ZSA9IDEyCglzcyA9IDQwCgllc3AgPSAwCglzb2Z0c2VnID0ge3NzZF9iYXNlID0gMCwgc3NkX2xp bWl0ID0gMTA0ODU3NSwgc3NkX3R5cGUgPSAyNywgc3NkX2RwbCA9IDAsIHNzZF9wID0gMSwgc3Nk X3h4ID0gMCwgc3NkX3h4MSA9IDAsIAogIHNzZF9kZWYzMiA9IDEsIHNzZF9ncmFuID0gMX0KIzcg IDB4YzA2MzhmODYgaW4gdHJhcCAoZnJhbWU9CiAgICAgIHt0Zl9mcyA9IDgsIHRmX2VzID0gLTM5 MDg1NjY2NCwgdGZfZHMgPSAtMTA2ODQ5ODkwNCwgdGZfZWRpID0gLTEwMzk2MTU0ODgsIHRmX2Vz aSA9IDE2LCB0Zl9lYnAgPSAtMzkwODA0NDc2LCB0Zl9pc3AgPSAtMzkwODA0NTg4LCB0Zl9lYngg PSAtMTA0MzIzNzMxMiwgdGZfZWR4ID0gLTEwMzk2MDgyNTYsIHRmX2VjeCA9IDEsIHRmX2VheCA9 IDAsIHRmX3RyYXBubyA9IDEyLCB0Zl9lcnIgPSAyLCB0Zl9laXAgPSAtMTA2ODI0MjY2NiwgdGZf Y3MgPSAzMiwgdGZfZWZsYWdzID0gNjU2NjcsIHRmX2VzcCA9IC0xMDY2OTI5NDg0LCB0Zl9zcyA9 IDE3MDd9KSBhdCAvdXNyL3NyYy9zeXMvaTM4Ni9pMzg2L3RyYXAuYzoyNTIKCXRkID0gKHN0cnVj dCB0aHJlYWQgKikgMHhjMjA4ZDY0MAoJcCA9IChzdHJ1Y3QgcHJvYyAqKSAweGMyMDhiNjAwCglz dGlja3MgPSAzOTA0MTYyNjcyCglpID0gMAoJdWNvZGUgPSAwCgl0eXBlID0gMTIKCWNvZGUgPSAy CglldmEgPSA3MgojOCAgMHhjMDYyY2YwYSBpbiBjYWxsdHJhcCAoKSBhdCAvdXNyL3NyYy9zeXMv aTM4Ni9pMzg2L2V4Y2VwdGlvbi5zOjEzOQpObyBsb2NhbHMuCiM5ICAweDAwMDAwMDA4IGluID8/ ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzEwIDB4ZThiNDAwMjggaW4gPz8g KCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojMTEgMHhjMDUwMDAyOCBpbiBleGVj X21hcF9maXJzdF9wYWdlIChpbWdwPTB4YzIwOGQ2NDApIGF0IC91c3Ivc3JjL3N5cy9rZXJuL2tl cm5fZXhlYy5jOjgwMwoJaSA9IC0xMDQzMjM3MzEyCglpbml0aWFsX3BhZ2VpbiA9IC0xMDM5NjE1 NDg4CgltYSA9IHsweDE4NzJjLCAweDEsIDB4MjQ2LCAweDAsIDB4YzIwOGI2MDAsIDB4MCwgMHhj MjA4ZDZiOCwgMHhlOGI0Y2JmMCwgMHhjMDUyNzZlNywgMHhjMDZkYmNjMCwgMHgyLCAweGMwNjdk MWUyLCAKICAweDI1NywgMHhjMjA4ZDY0MCwgMHhlOGI0Y2JmYywgMHgyNDZ9CglvYmplY3QgPSAw eDEwCiMxMiAweGMwNTNlMDEyIGluIHB0cmFjZSAodGQ9MHhjMjA4ZDY0MCwgdWFwPTB4ZThiNGNk MDQpIGF0IC91c3Ivc3JjL3N5cy9rZXJuL3N5c19wcm9jZXNzLmM6MzM5CglyID0ge3Bpb2QgPSB7 cGlvZF9vcCA9IC0xMDY2NTI2NTkyLCBwaW9kX29mZnMgPSAweDAsIHBpb2RfYWRkciA9IDB4YzA2 N2YyYjQsIHBpb2RfbGVuID0gMTcwN30sIHBsID0gewogICAgcGxfbHdwaWQgPSAtMTA2NjUyNjU5 MiwgcGxfZXZlbnQgPSAwLCBwbF9mbGFncyA9IC0xMDY2OTI5NDg0fSwgZGJyZWcgPSB7ZHIgPSB7 MzIyODQ0MDcwNCwgMCwgMzIyODAzNzgxMiwgMTcwNywgCiAgICAgIDMyMjg3MjczODAsIDM5MDQx NjI5MDAsIDMyMjY2OTgyMTQsIDMyMjg3MjczNzZ9fSwgZnByZWcgPSB7ZnByX2VudiA9IHszMjI4 NDQwNzA0LCAwLCAzMjI4MDM3ODEyLCAxNzA3LCAzMjI4NzI3MzgwLCAKICAgICAgMzkwNDE2Mjkw MCwgMzIyNjY5ODIxNH0sIGZwcl9hY2MgPSB7IlB4csBGXDAwMlwwMDBcMDAwyDsiLCAia8BcMjAw qFbBQ1xiXDAwMCIsICKiXDIwN2fAeMy06OzfIiwgCiAgICAgICJQwFwyMDCoVsFcMDAxXDAwMFww MDAiLCAi7axnwCtcMDAxXDAwMFwwMDDYICIsICJ8wVwwMDTNtOhA1lxiwiIsICJcMjMwzLTobLFP wFwyMDCoIiwgIlbBXDAwMFwwMDBcMDAwXDAwMKJcMjA3Z8AifSwgCiAgICBmcHJfZXhfc3cgPSAy MTE1LCAKICAgIGZwcl9wYWQgPSAi2CB8wVwwMDTNtOi8zLToKLFPwNggfMFA1lxiwlwyMDCoVsFc MDAwXDAwMFwwMDBcMDAwolwyMDdnwDJcYlwwMDBcMDAwXDAwMFwwMDBcMDAwXDAwMEDWXGLCXDAw MLZcYsIwzbToXDAwMFwwMDBcMDAwXDAwMEDWXGLCIn0sIHJlZyA9IHtyX2ZzID0gMzIyODQ0MDcw NCwgcl9lcyA9IDAsIHJfZHMgPSAzMjI4MDM3ODEyLCByX2VkaSA9IDE3MDcsIHJfZXNpID0gMzIy ODcyNzM4MCwgcl9lYnAgPSAzOTA0MTYyOTAwLCAKICAgIHJfaXNwID0gMzIyNjY5ODIxNCwgcl9l YnggPSAzMjI4NzI3Mzc2LCByX2VkeCA9IDU4Miwgcl9lY3ggPSAzMjI4MjUzMTI4LCByX2VheCA9 IDMyNDM2ODE5MjAsIHJfdHJhcG5vID0gMjExNSwgCiAgICByX2VyciA9IDMyMjgwMTA0MDIsIHJf ZWlwID0gMzkwNDE2MjkzNiwgcl9jcyA9IDMyMjY1MjU2NzYsIHJfZWZsYWdzID0gMzI0MzY4MTky MCwgcl9lc3AgPSAxLCByX3NzID0gMzIyODAxOTk0OSwgCiAgICByX2dzID0gMjk5fX0KCWFkZHIg PSAodm9pZCAqKSAweDAKCWVycm9yID0gMAojMTMgMHhjMDYzOWE5ZiBpbiBzeXNjYWxsIChmcmFt ZT0KICAgICAge3RmX2ZzID0gNTksIHRmX2VzID0gNTksIHRmX2RzID0gNTksIHRmX2VkaSA9IC0x MDc3OTQwNzk2LCB0Zl9lc2kgPSA2ODcsIHRmX2VicCA9IC0xMDc3OTQyMTM2LCB0Zl9pc3AgPSAt MzkwODA0MTI0LCB0Zl9lYnggPSA2ODcsIHRmX2VkeCA9IDY3NDk4NjA5MiwgdGZfZWN4ID0gNjc0 OTAzMjY4LCB0Zl9lYXggPSAyNiwgdGZfdHJhcG5vID0gMTIsIHRmX2VyciA9IDIsIHRmX2VpcCA9 IDY3NDI2MDAxMSwgdGZfY3MgPSA1MSwgdGZfZWZsYWdzID0gNTE4LCB0Zl9lc3AgPSAtMTA3Nzk0 MjE2NCwgdGZfc3MgPSA1OX0pIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvdHJhcC5jOjk1OQoJ cGFyYW1zID0gMHhiZmJmZTg3MCA8QWRkcmVzcyAweGJmYmZlODcwIG91dCBvZiBib3VuZHM+Cglj YWxscCA9IChzdHJ1Y3Qgc3lzZW50ICopIDB4YzA2YWZhZjAKCXRkID0gKHN0cnVjdCB0aHJlYWQg KikgMHhjMjA4ZDY0MAoJcCA9IChzdHJ1Y3QgcHJvYyAqKSAweGMyMDhiNjAwCglvcmlnX3RmX2Vm bGFncyA9IDUxOAoJc3RpY2tzID0gMQoJZXJyb3IgPSAwCgluYXJnID0gNAoJYXJncyA9IHsxMCwg Njg3LCAwLCAwLCAwLCAwLCAxLCAtMTAzOTYxNjUxMn0KCWNvZGUgPSAyNgojMTQgMHhjMDYyY2Y1 ZiBpbiBYaW50MHg4MF9zeXNjYWxsICgpIGF0IC91c3Ivc3JjL3N5cy9pMzg2L2kzODYvZXhjZXB0 aW9uLnM6MjAwCk5vIGxvY2Fscy4KIzE1IDB4MDAwMDAwM2IgaW4gPz8gKCkKTm8gc3ltYm9sIHRh YmxlIGluZm8gYXZhaWxhYmxlLgojMTYgMHgwMDAwMDAzYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFi bGUgaW5mbyBhdmFpbGFibGUuCiMxNyAweDAwMDAwMDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJs ZSBpbmZvIGF2YWlsYWJsZS4KIzE4IDB4YmZiZmVkYzQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxl IGluZm8gYXZhaWxhYmxlLgojMTkgMHgwMDAwMDJhZiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUg aW5mbyBhdmFpbGFibGUuCiMyMCAweGJmYmZlODg4IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBp bmZvIGF2YWlsYWJsZS4KIzIxIDB4ZThiNGNkNjQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGlu Zm8gYXZhaWxhYmxlLgojMjIgMHgwMDAwMDJhZiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5m byBhdmFpbGFibGUuCiMyMyAweDI4M2I3ODZjIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZv IGF2YWlsYWJsZS4KIzI0IDB4MjgzYTM0ZTQgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8g YXZhaWxhYmxlLgojMjUgMHgwMDAwMDAxYSBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBh dmFpbGFibGUuCiMyNiAweDAwMDAwMDBjIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2 YWlsYWJsZS4KIzI3IDB4MDAwMDAwMDIgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZh aWxhYmxlLgojMjggMHgyODMwNjQyYiBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFp bGFibGUuCiMyOSAweDAwMDAwMDMzIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWls YWJsZS4KIzMwIDB4MDAwMDAyMDYgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxh YmxlLgojMzEgMHhiZmJmZTg2YyBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFi bGUuCiMzMiAweDAwMDAwMDNiIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJs ZS4KIzMzIDB4MDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxl LgojMzQgMHgwMDAwMDAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUu CiMzNSAweDAwMDAwMDAwIGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4K IzM2IDB4MDAwMDAwMDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgoj MzcgMHgxZjRiOTAwMCBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiMz OCAweGMyMDhkNzk0IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzM5 IDB4YzE1ODBlMTAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDAg MHhlOGI0Y2M3YyBpbiA/PyAoKQpObyBzeW1ib2wgdGFibGUgaW5mbyBhdmFpbGFibGUuCiM0MSAw eGU4YjRjYzY0IGluID8/ICgpCk5vIHN5bWJvbCB0YWJsZSBpbmZvIGF2YWlsYWJsZS4KIzQyIDB4 YzIwOGQ2NDAgaW4gPz8gKCkKTm8gc3ltYm9sIHRhYmxlIGluZm8gYXZhaWxhYmxlLgojNDMgMHhj MDUyNjhlNyBpbiBzY2hlZF9zd2l0Y2ggKHRkPTB4MmFmLCBuZXd0ZD0weDJhZiwgZmxhZ3M9MCkg YXQgL3Vzci9zcmMvc3lzL2tlcm4vc2NoZWRfdWxlLmM6MTQwMwoJa2UgPSAoc3RydWN0IHRkX3Nj aGVkICopIDB4YmZiZmVkYzQK --=-laGMJx4+yahJXgie/sBx-- --=-hG/iNLbwITDw0rfTDxFL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBClxw//cVsHxFZiIoRAtxmAJ9b3Fgz0Jf0tAv8uWZu4obm4QJS/gCfUTDH 8Wv0vRIZvoyjEkKvAmuNQK0= =b3nV -----END PGP SIGNATURE----- --=-hG/iNLbwITDw0rfTDxFL-- From owner-freebsd-current@FreeBSD.ORG Fri May 27 13:19:21 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 494DD16A41C for ; Fri, 27 May 2005 13:19:21 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4F6043D1F for ; Fri, 27 May 2005 13:19:20 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j4RDJJ4h063903; Fri, 27 May 2005 08:19:19 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42971E48.7040806@centtech.com> Date: Fri, 27 May 2005 08:19:04 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050504 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> <4296997C.9030700@samsco.org> <20050527000105.E54386@lexi.siliconlandmark.com> <42969DD8.4060701@samsco.org> In-Reply-To: <42969DD8.4060701@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 13:19:21 -0000 Scott Long wrote: > Andre Guibert de Bruet wrote: > >> >> On Thu, 26 May 2005, Chad Leigh -- Shire.Net LLC wrote: >> >>> Agreed, but as you say, FreeBSD is not there yet, and since the OP is >>> on FreeBSD, and wants to have multiple computers attached, NFS would >>> be one way of making that happen. And if you leave the other >>> computers attached by the FC but not mounted, if on goes down, you >>> can replace it with another, and switch your nfs server over. Not as >>> ideal but doable on FreeBSD. >> >> >> >> This hack would not be suitable in an HA environment -- It requires >> human intervention or some really fugly scripts not just for the NFS >> server, but also for the clients. These scripts would have to figure >> out how to recover NFS file locking state and consistency when the >> backup machine fails over. >> >> It seems as if NFS in this type of setup introduces more problems than >> it solves. >> >> Andy >> > > So what we need is some manpower. I estimate that a proof-of-concept > port of GFS would take about 4-6 solid months. There is also a volume > management aspect to GFS, but that is less important and the existing > GEOM classes can largely fill the role already. Anyone interested in > taking a serious look at it? I'm not much of a coder, so I'd like to support anyone who would like to work on this. I'll provide anything I can to help make this work. As a datapoint, I currently have a 5 node cluster running suse linux (enterprise) with Polyserve's cluster filesystem and distributed lock manager. They have two software components (well, more, but two bundles) - a distributed filesystem is the core of their software (with a distributed lock manager), and they also have an NFS bundle that allows multiple NFS servers to access and share the same data via shared storage. This is very useful to us (and many other companies much larger), and we pay a premium for it. I'm not sure what I could do, but I'm certain I could provide at minimum an environment to build/test all of this. Just curious - what are the pros/cons of porting GFS vs mangling UFS? I know GFS already has a base architected, but in the long run, what would be best? A BSD licensed fs would be completely awesome. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------ From owner-freebsd-current@FreeBSD.ORG Fri May 27 13:58:49 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97B2616A41F for ; Fri, 27 May 2005 13:58:49 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (lexi.siliconlandmark.com [209.69.98.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F7C543D4C for ; Fri, 27 May 2005 13:58:49 +0000 (GMT) (envelope-from andy@siliconlandmark.com) Received: from lexi.siliconlandmark.com (localhost [127.0.0.1]) by lexi.siliconlandmark.com (8.13.3/8.13.3) with ESMTP id j4RDwVI6076716; Fri, 27 May 2005 09:58:31 -0400 (EDT) (envelope-from andy@siliconlandmark.com) Received: from localhost (andy@localhost) by lexi.siliconlandmark.com (8.13.3/8.13.3/Submit) with ESMTP id j4RDwV2Z076713; Fri, 27 May 2005 09:58:31 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Fri, 27 May 2005 09:58:31 -0400 (EDT) From: Andre Guibert de Bruet To: "Conrad J. Sabatier" In-Reply-To: <20050526070757.7df71fad@dolphin.local.net> Message-ID: <20050527095351.S69811@lexi.siliconlandmark.com> References: <17042.43345.594850.534649@canoe.dclg.ca> <20050524002925.2f05fc55@dolphin.local.net> <1FA05BA9-15DF-496B-95AE-664815096717@FreeBSD.org> <20050524190311.711870aa@dolphin.local.net> <07005604-836F-48E0-AC46-9CC80BF19BD5@freebsd.org> <20050526070757.7df71fad@dolphin.local.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Information: Please contact the ISP for more information X-SL-MailScanner: Found to be clean X-SL-SpamCheck: not spam, SpamAssassin (score=-2.544, required 6, autolearn=not spam, AWL 0.06, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: freebsd-current@freebsd.org Subject: MIDI (Was: Re: 3 things working in -STABLE and not in -CURRENT) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 13:58:49 -0000 On Thu, 26 May 2005, Conrad J. Sabatier wrote: > In fact, adding this to the long-standing non-existent MIDI > support only increases the likelihood of my being forced to seek out > some other alternative. Have you tried the MIDI patchset? What sound card are you currently using? Andy /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */ /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */ /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */ /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */ From owner-freebsd-current@FreeBSD.ORG Fri May 27 15:27:53 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1075116A41C for ; Fri, 27 May 2005 15:27:53 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id C722043D1D for ; Fri, 27 May 2005 15:27:52 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j4RFRqda010305; Fri, 27 May 2005 08:27:52 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j4RFRqww010304; Fri, 27 May 2005 08:27:52 -0700 (PDT) (envelope-from faber) Date: Fri, 27 May 2005 08:27:52 -0700 From: Ted Faber To: Peter Jeremy Message-ID: <20050527152752.GA10069@pun.isi.edu> References: <20050526001806.GA1008@pun.isi.edu> <20050526080928.GE12640@cirb503493.alcatel.com.au> <20050526160846.GA6851@pun.isi.edu> <20050526203243.GB1055@pun.isi.edu> <20050527083734.GA18696@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Q68bSM7Ycu6FN28Q" Content-Disposition: inline In-Reply-To: <20050527083734.GA18696@cirb503493.alcatel.com.au> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Cc: freebsd-current@freebsd.org Subject: Re: hard deadlock(?) on -current; some debugging info, need help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 15:27:53 -0000 --Q68bSM7Ycu6FN28Q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 27, 2005 at 06:37:34PM +1000, Peter Jeremy wrote: > On Thu, 2005-May-26 13:32:43 -0700, Ted Faber wrote: > >On Thu, May 26, 2005 at 09:08:46AM -0700, Ted Faber wrote: > >Next lock up is now. Same kernel, pics are at > > > >http://www.isi.edu/~faber/tmp/deadlock/DSCN048{83,84,85,86,87,88,89,90,9= 1}.JPG >=20 > After comparing it with the last URL, I worked out it was actually > http://www.isi.edu/~faber/tmp/deadlock/DSCN04{83,84,85,86,87,88,89,90,91}= .JPG Sorry. Typo. >=20 > >My inexpert reading is that one of the threads of the psi jabber client > >is locked on something. "Something" why I need help. :-) >=20 > There are two filesystem locks: > - The psi process (pid 6936) is holding a lock on ad0s1a (probably /) > The thread in question is waiting on a nfs lock. > - A bash process (pid 6598) is holding an NFS lock and waiting on nfsreq >=20 > According to the vnode locks, there's one process waiting on the NFS > lock held by bash and 7 processes waiting on the ufs lock held by psi. > Without access to the actual process and lock structures, I can't be > certain but it looks very much like psi is waiting on the NFS lock held > by bash (there are no other processes waiting on nfs). >=20 > It's looking more like an NFS problem. I'm not sure where to go next > but I'd more strongly suggest that you try to get the system running > without NFS. For debugging or for my own sanity? :-) It's going to be fairly problematic to move from NFS and keep things going reasonably here. If it's a step we need to take to debug I can work something out, bit I do have a laptop running in the same environment (and with a kernel from the same source) that does not exhibit this problem. >=20 > It might be useful to know some more details about that NFS mount > (fsid 0x0600ff07). Can you tell us the mount parameters and what the > server is (OS type). Most o fthe nfs filesystems are automounted. I'm on the machine now, so I can't look at debugger output, but I can tell you that most of the NFS mounts that I can imagine either psi or bash looking at are automounted. The mount parameters are: timeo=3D8,retrans=3D9,intr Ummmmm. As I look this up, I realize that the amd config file in which this stuff resides is itself on an NFS file system. Not an automounted one, but an NFS filesystem nonetheless. I've got a very bad feeling about that all of a sudden. Visions of the automounter being asked to mount a filesystem that it has to look up in this config file that is temporarily unavailable due to network glitch (or some NFS race, or someone locking the file to edit it) seem bad. I'm going to move that configuration file. How does that possibility sound to you? For completeness, the server is a Solaris box. Don't laugh: boreas:~$ uname -a SunOS boreas.isi.edu 5.9 Generic_117171-12 sun4u sparc I'll move that configuration. With any luck this will solve my problem, though if you see somthing else more promising, don't hesitate to speak up. If moving the config does not solve it, is there some output from teh debugger I should get about the file system? Thanks again for all your help. It really helps to talk these things out with someone knowledgable. I hope it does turn out to be this NFS double jeopardy/pilot error, but if not I'll speak up again. =20 --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --Q68bSM7Ycu6FN28Q Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFClzx3aUz3f+Zf+XsRAnx8AJ4urocgW3+EplSUavnlsY7brtM49wCeITpw b8mCwZMphppeesScK1qMpaw= =rm+5 -----END PGP SIGNATURE----- --Q68bSM7Ycu6FN28Q-- From owner-freebsd-current@FreeBSD.ORG Fri May 27 16:18:11 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C5D0516A41C for ; Fri, 27 May 2005 16:18:11 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AF6643D1D for ; Fri, 27 May 2005 16:18:11 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j4RGIB9B001621; Fri, 27 May 2005 09:18:11 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j4RGIAUU001620; Fri, 27 May 2005 09:18:10 -0700 (PDT) (envelope-from faber) Date: Fri, 27 May 2005 09:18:10 -0700 From: Ted Faber To: Peter Jeremy Message-ID: <20050527161810.GA1142@pun.isi.edu> References: <20050526001806.GA1008@pun.isi.edu> <20050526080928.GE12640@cirb503493.alcatel.com.au> <20050526160846.GA6851@pun.isi.edu> <20050526203243.GB1055@pun.isi.edu> <20050527083734.GA18696@cirb503493.alcatel.com.au> <20050527152752.GA10069@pun.isi.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="OXfL5xGRrasGEqWY" Content-Disposition: inline In-Reply-To: <20050527152752.GA10069@pun.isi.edu> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Cc: freebsd-current@freebsd.org Subject: Re: hard deadlock(?) on -current; some debugging info, need help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 16:18:11 -0000 --OXfL5xGRrasGEqWY Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, May 27, 2005 at 08:27:52AM -0700, Ted Faber wrote: > As I look this up, I realize that the amd config file in which this > stuff resides is itself on an NFS file system. Not an automounted one, > but an NFS filesystem nonetheless. I've got a very bad feeling about > that all of a sudden. Visions of the automounter being asked to mount a > filesystem that it has to look up in this config file that is > temporarily unavailable due to network glitch (or some NFS race, or > someone locking the file to edit it) seem bad. >=20 > I'm going to move that configuration file. >=20 > How does that possibility sound to you? The config is not it. I moved to all local configuration files and still locked up. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --OXfL5xGRrasGEqWY Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCl0hCaUz3f+Zf+XsRAl6vAJ4yarJ88Z159EDW0aDUpq7/A4X5RACgzGc6 5IPQe9rUcjowcBiPh4PrvS4= =SoSh -----END PGP SIGNATURE----- --OXfL5xGRrasGEqWY-- From owner-freebsd-current@FreeBSD.ORG Fri May 27 17:08:10 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 380E016A41C for ; Fri, 27 May 2005 17:08:10 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id F11BD43D1F for ; Fri, 27 May 2005 17:08:09 +0000 (GMT) (envelope-from nb_root@videotron.ca) Received: from clk01a ([66.130.198.54]) by VL-MO-MR010.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0IH500M75RLFJY@VL-MO-MR010.ip.videotron.ca> for freebsd-current@freebsd.org; Fri, 27 May 2005 13:08:03 -0400 (EDT) Date: Fri, 27 May 2005 13:07:32 -0400 From: Nicolas Blais To: freebsd-current@freebsd.org Message-id: <200505271308.03371.nb_root@videotron.ca> MIME-version: 1.0 Content-type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary=nextPart6428052.O0RlcpO57L Content-transfer-encoding: 7bit User-Agent: KMail/1.8 Subject: Mouse not detected at boot without ehci X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 17:08:10 -0000 --nextPart6428052.O0RlcpO57L Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Since my memory card reader causes a 5 minute delay at boot with ehci enabl= ed=20 in my kernel, I removed ehci.=20 Now, whenever I boot, my mouse (standard Logitech optical ums) is not=20 detected. I have to unplug it and replug it, then it will attach and work=20 fine. This behavior did not happen when ehci was in my kernel. Obviously I= =20 can't put it back until it no longer causes the delay at boot. Any other solutions? Nicolas. =2D-=20 =46reeBSD 6.0-CURRENT #0: Fri May 27 12:20:45 EDT 2005 =20 root@clk01a:/usr/obj/usr/src/sys/CLK01A=20 PGP? : http://66.130.198.54:8081/security/nb_root.asc --nextPart6428052.O0RlcpO57L Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCl1Pzz38ton5LGeIRAijbAJ9qRdFA/mUoV186Snc4Y2ueC5dsfwCePnFX 8j4R+p4rwNt02tG19yq+xI0= =0LXH -----END PGP SIGNATURE----- --nextPart6428052.O0RlcpO57L-- From owner-freebsd-current@FreeBSD.ORG Fri May 27 17:09:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4D0BE16A41C for ; Fri, 27 May 2005 17:09:22 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.46]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1681643D1D for ; Fri, 27 May 2005 17:09:22 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin01-en2 [10.13.10.146]) by smtpout.mac.com (Xserve/8.12.11/smtpout10/MantshX 4.0) with ESMTP id j4RH9KXI013154; Fri, 27 May 2005 10:09:20 -0700 (PDT) Received: from [192.168.1.6] (pool-68-161-53-96.ny325.east.verizon.net [68.161.53.96]) (authenticated bits=0) by mac.com (Xserve/smtpin01/MantshX 4.0) with ESMTP id j4RH9GWe000783; Fri, 27 May 2005 10:09:17 -0700 (PDT) In-Reply-To: <20050527092544.GB18696@cirb503493.alcatel.com.au> References: <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> <4296997C.9030700@samsco.org> <20050526235852.M54386@lexi.siliconlandmark.com> <42969C1B.5010301@samsco.org> <20050527092544.GB18696@cirb503493.alcatel.com.au> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4C7F0B94-4D12-41A3-9A61-C3B620804671@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Fri, 27 May 2005 13:09:11 -0400 To: Peter Jeremy X-Mailer: Apple Mail (2.730) Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 17:09:22 -0000 On May 27, 2005, at 5:25 AM, Peter Jeremy wrote: > On Thu, 2005-May-26 22:03:39 -0600, Scott Long wrote: >> A few people have suggested modifying UFS to fill this role. It >> probably >> is just as much work as porting GFS, if not more, since UFS/FFS is >> closely tied to the buffer cache and block layers on BSD, and >> divorcing >> probably would be quite difficult. >> > > It's probably worth noting that (AFAIK) none of the commercial vendors > have managed to build a multi-master shared UFS filesystem. This > suggests that the effort is considerable. I would agree with this observation. :-) > Solaris clustering routes all I/O to a shared filesystem to a single > 'master' node, which is responsible for all physical I/O to the disk. > This would significantly simplify cache coherency management. Apple's Xsan clustering solution relies on a so-called "metadata controller", which keeps track of locking and provides syncronization and invalidation notification when the filesystem metadata changes. SAN clients still read the actual file data directly via fibre channel, but they also need IP-level connectivity via ethernet (an unroutable LAN is fine) to the MDC. The MDC is not a single-point-of-failure since redundant MDC's can be set up, but I believe if all MDCs go down, the clients are restricted to read & modify operations only to open files they'd already been using. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri May 27 18:16:35 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.ORG Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D1B4416A41C for ; Fri, 27 May 2005 18:16: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 6B77243D49 for ; Fri, 27 May 2005 18:16:32 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [192.168.254.14] (imini.samsco.home [192.168.254.14]) (authenticated bits=0) by pooker.samsco.org (8.13.3/8.13.3) with ESMTP id j4RIIKjg050670; Fri, 27 May 2005 12:18:20 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <429763B0.2060705@samsco.org> Date: Fri, 27 May 2005 12:15:12 -0600 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050416 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Garrett Wollman References: <4295D51F.50106@centtech.com> <429606D9.6080602@cs.tu-berlin.de> <42960ACB.7090801@cs.tu-berlin.de> <42960CFE.4060307@centtech.com> <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> <4296997C.9030700@samsco.org> <20050526235852.M54386@lexi.siliconlandmark.com> <42969C1B.5010301@samsco.org> <17047.25282.72131.519040@khavrinen.csail.mit.edu> In-Reply-To: <17047.25282.72131.519040@khavrinen.csail.mit.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.8 required=3.8 tests=ALL_TRUSTED autolearn=failed version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on pooker.samsco.org Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 18:16:36 -0000 Garrett Wollman wrote: > < said: > > >>is just as much work as porting GFS, if not more, since UFS/FFS is >>closely tied to the buffer cache and block layers on BSD, and divorcing >>probably would be quite difficult. > > > For multiple writers, probably so. For the single-writer case, I > don't think so, since the readers can mount a snapshot while the > writer mounts the read-write view. Well, having a writer is pointless if the readers are stuck on a snapshot. Also, I'm not exactly sure how dirty buffers get flushed to disk in the case of a snapshot. Recall that the snapshot file only save the deltas of the old data, and flushing those deltas to disk is still under the control of the VM/buffer/cache system. You'd probably still have to have some sort of inter-computer synchronization system in place. > > All this would be a lot easier if we had a storage manager more like > ZFS's. > Well, ZFS doesn't really exist yet, so it's hard to draw a comparison ;-) Scott From owner-freebsd-current@FreeBSD.ORG Fri May 27 18:31:46 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D0DC16A41C; Fri, 27 May 2005 18:31:46 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id B22F343D1F; Fri, 27 May 2005 18:31:42 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j4RIU3E9014448 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 May 2005 03:30:07 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 28 May 2005 03:30:02 +0900 Message-ID: From: Hajimu UMEMOTO To: Warner Losh , nectar@FreeBSD.org, des@FreeBSD.org In-Reply-To: <20050509.104234.71141880.imp@bsdimp.com> References: <200505041529.36826.peter@wemm.org> <20050509.104234.71141880.imp@bsdimp.com> User-Agent: xcite1.38> Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE 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_May_28_03:30:02_2005-1" X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sat, 28 May 2005 03:30:07 +0900 (JST) X-Virus-Scanned: by amavisd-new 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.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: standards@FreeBSD.org, current@FreeBSD.org, freebsd-arch@FreeBSD.org Subject: Re: [CFR] correct type of addrinfo.ai_addrlen and netent.n_net X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 18:31:46 -0000 --Multipart_Sat_May_28_03:30:02_2005-1 Content-Type: text/plain; charset=US-ASCII Hi, >>>>> On Mon, 09 May 2005 10:42:34 -0600 (MDT) >>>>> Warner Losh said: > Are you suggest when to remove padding? Since the major of libc was > bumped already in 6-CURRENT, it may better to wait 7-CURRENT. imp> We've generally not worried compatibility in the 'rough and tumble' imp> world of FreeBSD current. So unless there's a problem in the upgrade imp> path, I think that we safely omit them. I'll commit the attached change to nuke padding. It will break ABI compatibility on 64 bit arch. So, I'm planning bumping major of affected shlibs. Please review it. Sincerely, --Multipart_Sat_May_28_03:30:02_2005-1 Content-Type: text/x-patch; charset=US-ASCII Content-Disposition: attachment; filename="netdb.h-padding-nuke.diff" Content-Transfer-Encoding: 7bit Index: include/netdb.h diff -u include/netdb.h.orig include/netdb.h --- include/netdb.h.orig Sat May 28 01:20:40 2005 +++ include/netdb.h Sat May 28 01:31:52 2005 @@ -63,8 +63,6 @@ #include #include -#include -#include #ifndef _SIZE_T_DECLARED typedef __size_t size_t; @@ -105,28 +103,11 @@ #define h_addr h_addr_list[0] /* address, for backward compatibility */ }; -/* - * Note: n_net used to be an unsigned long integer. - * In XNS5, and subsequently in POSIX-2001 it was changed to an - * uint32_t. - * To accomodate for this while preserving binary compatibility with - * the old interface, we prepend or append 32 bits of padding, - * depending on the (LP64) architecture's endianness. - * - * This should be deleted the next time the libc major number is - * incremented. - */ struct netent { char *n_name; /* official name of net */ char **n_aliases; /* alias list */ int n_addrtype; /* net address type */ -#if __LONG_BIT == 64 && _BYTE_ORDER == _BIG_ENDIAN - uint32_t __n_pad0; /* ABI compatibility */ -#endif uint32_t n_net; /* network # */ -#if __LONG_BIT == 64 && _BYTE_ORDER == _LITTLE_ENDIAN - uint32_t __n_pad0; /* ABI compatibility */ -#endif }; struct servent { @@ -142,29 +123,12 @@ int p_proto; /* protocol # */ }; -/* - * Note: ai_addrlen used to be a size_t, per RFC 2553. - * In XNS5.2, and subsequently in POSIX-2001 and RFC 3493 it was - * changed to a socklen_t. - * To accomodate for this while preserving binary compatibility with the - * old interface, we prepend or append 32 bits of padding, depending on - * the (LP64) architecture's endianness. - * - * This should be deleted the next time the libc major number is - * incremented. - */ struct addrinfo { int ai_flags; /* AI_PASSIVE, AI_CANONNAME, AI_NUMERICHOST */ int ai_family; /* PF_xxx */ int ai_socktype; /* SOCK_xxx */ int ai_protocol; /* 0 or IPPROTO_xxx for IPv4 and IPv6 */ -#if __LONG_BIT == 64 && _BYTE_ORDER == _BIG_ENDIAN - uint32_t __ai_pad0; /* ABI compatibility */ -#endif socklen_t ai_addrlen; /* length of ai_addr */ -#if __LONG_BIT == 64 && _BYTE_ORDER == _LITTLE_ENDIAN - uint32_t __ai_pad0; /* ABI compatibility */ -#endif char *ai_canonname; /* canonical name for hostname */ struct sockaddr *ai_addr; /* binary address */ struct addrinfo *ai_next; /* next structure in linked list */ @@ -262,11 +226,7 @@ struct hostent *gethostent(void); struct hostent *getipnodebyaddr(const void *, size_t, int, int *); struct hostent *getipnodebyname(const char *, int, int, int *); -#if __LONG_BIT == 64 -struct netent *getnetbyaddr(unsigned long, int); /* ABI compatibility */ -#else struct netent *getnetbyaddr(uint32_t, int); -#endif struct netent *getnetbyname(const char *); struct netent *getnetent(void); int getnetgrent(char **, char **, char **); Index: kerberos5/lib/Makefile.inc diff -u kerberos5/lib/Makefile.inc.orig kerberos5/lib/Makefile.inc --- kerberos5/lib/Makefile.inc.orig Sat Oct 25 18:24:54 2003 +++ kerberos5/lib/Makefile.inc Sat May 28 01:49:00 2005 @@ -1,5 +1,5 @@ # $FreeBSD: src/kerberos5/lib/Makefile.inc,v 1.6 2003/10/09 19:48:45 nectar Exp $ -SHLIB_MAJOR?= 7 +SHLIB_MAJOR?= 8 .include "../Makefile.inc" Index: lib/libbsnmp/Makefile.inc diff -u lib/libbsnmp/Makefile.inc.orig lib/libbsnmp/Makefile.inc --- lib/libbsnmp/Makefile.inc.orig Mon Oct 25 00:32:30 2004 +++ lib/libbsnmp/Makefile.inc Sat May 28 01:39:39 2005 @@ -1,6 +1,6 @@ # $FreeBSD: src/lib/libbsnmp/Makefile.inc,v 1.5 2004/10/24 15:32:30 ru Exp $ -SHLIB_MAJOR= 2 +SHLIB_MAJOR= 3 WARNS?= 6 NO_WERROR= INCSDIR= ${INCLUDEDIR}/bsnmp Index: lib/libc/net/getaddrinfo.c diff -u -p lib/libc/net/getaddrinfo.c.orig lib/libc/net/getaddrinfo.c --- lib/libc/net/getaddrinfo.c.orig Sat May 28 01:38:16 2005 +++ lib/libc/net/getaddrinfo.c Sat May 28 01:33:09 2005 @@ -1352,9 +1352,6 @@ get_ai(pai, afd, addr) memset(ai->ai_addr, 0, (size_t)afd->a_socklen); ai->ai_addr->sa_len = afd->a_socklen; ai->ai_addrlen = afd->a_socklen; -#if __LONG_BIT == 64 - ai->__ai_pad0 = 0; /* ABI compatibility */ -#endif ai->ai_addr->sa_family = ai->ai_family = afd->a_af; p = (char *)(void *)(ai->ai_addr); #ifdef FAITH Index: lib/libc/net/getnetbydns.c diff -u -p lib/libc/net/getnetbydns.c.orig lib/libc/net/getnetbydns.c --- lib/libc/net/getnetbydns.c.orig Sat May 28 01:24:33 2005 +++ lib/libc/net/getnetbydns.c Sat May 28 01:36:52 2005 @@ -259,9 +259,6 @@ getnetanswer(querybuf *answer, int ansle break; } ne->n_aliases++; -#if __LONG_BIT == 64 - ne->__n_pad0 = 0; /* ABI compatibility */ -#endif return 0; } h_errno = TRY_AGAIN; @@ -334,9 +331,6 @@ _dns_getnetbyaddr(void *rval, void *cb_d while ((net & 0xff) == 0 && net != 0) net >>= 8; ne->n_net = net; -#if __LONG_BIT == 64 - ne->__n_pad0 = 0; /* ABI compatibility */ -#endif return NS_SUCCESS; } return NS_NOTFOUND; Index: lib/libc/net/getnetbyht.c diff -u -p lib/libc/net/getnetbyht.c.orig lib/libc/net/getnetbyht.c --- lib/libc/net/getnetbyht.c.orig Sat May 28 01:24:33 2005 +++ lib/libc/net/getnetbyht.c Sat May 28 01:37:13 2005 @@ -122,9 +122,6 @@ again: if (p != NULL) *p++ = '\0'; ne->n_net = inet_network(cp); -#if __LONG_BIT == 64 - ne->__n_pad0 = 0; /* ABI compatibility */ -#endif ne->n_addrtype = AF_INET; q = ne->n_aliases = ned->net_aliases; if (p != NULL) { Index: lib/libc/net/getnetbynis.c diff -u -p lib/libc/net/getnetbynis.c.orig lib/libc/net/getnetbynis.c --- lib/libc/net/getnetbynis.c.orig Sat May 28 01:24:33 2005 +++ lib/libc/net/getnetbynis.c Sat May 28 01:37:35 2005 @@ -99,9 +99,6 @@ _getnetbynis(const char *name, char *map cp++; ne->n_net = inet_network(cp); -#if __LONG_BIT == 64 - ne->__n_pad0 = 0; /* ABI compatibility */ -#endif ne->n_addrtype = AF_INET; q = ne->n_aliases = ned->net_aliases; Index: lib/libc/net/getnetnamadr.c diff -u -p lib/libc/net/getnetnamadr.c.orig lib/libc/net/getnetnamadr.c --- lib/libc/net/getnetnamadr.c.orig Sat May 28 01:35:00 2005 +++ lib/libc/net/getnetnamadr.c Sat May 28 01:35:32 2005 @@ -165,17 +165,13 @@ getnetbyname(const char *name) } struct netent * -#if __LONG_BIT == 64 -getnetbyaddr(u_long addr, int af) /* ABI compatibility */ -#else getnetbyaddr(uint32_t addr, int af) -#endif { struct netdata *nd; if ((nd = __netdata_init()) == NULL) return NULL; - if (getnetbyaddr_r((uint32_t)addr, af, &nd->net, &nd->data) != 0) + if (getnetbyaddr_r(addr, af, &nd->net, &nd->data) != 0) return NULL; return &nd->net; } Index: lib/libfetch/Makefile diff -u lib/libfetch/Makefile.orig lib/libfetch/Makefile --- lib/libfetch/Makefile.orig Thu Jan 27 16:57:04 2005 +++ lib/libfetch/Makefile Sat May 28 01:41:14 2005 @@ -18,7 +18,7 @@ CSTD?= c99 WARNS?= 2 -SHLIB_MAJOR= 3 +SHLIB_MAJOR= 4 ftperr.h: ftp.errors @echo "static struct fetcherr _ftp_errlist[] = {" > ${.TARGET} Index: lib/libftpio/Makefile diff -u lib/libftpio/Makefile.orig lib/libftpio/Makefile --- lib/libftpio/Makefile.orig Sat Oct 25 18:25:46 2003 +++ lib/libftpio/Makefile Sat May 28 01:42:31 2005 @@ -1,7 +1,7 @@ # $FreeBSD: src/lib/libftpio/Makefile,v 1.13 2002/09/28 00:25:29 peter Exp $ LIB= ftpio -SHLIB_MAJOR= 5 +SHLIB_MAJOR= 6 SRCS= ftpio.c ftperr.c INCS= ftpio.h Index: lib/libipsec/Makefile diff -u lib/libipsec/Makefile.orig lib/libipsec/Makefile --- lib/libipsec/Makefile.orig Thu Jan 27 16:57:05 2005 +++ lib/libipsec/Makefile Sat May 28 01:42:52 2005 @@ -29,7 +29,7 @@ LIB= ipsec SHLIBDIR?= /lib -SHLIB_MAJOR= 1 +SHLIB_MAJOR= 2 CFLAGS+=-I. -I${.CURDIR} CFLAGS+=-DIPSEC_DEBUG -DIPSEC .if !defined(NO_INET6) Index: lib/libpam/Makefile.inc diff -u lib/libpam/Makefile.inc.orig lib/libpam/Makefile.inc --- lib/libpam/Makefile.inc.orig Sat May 28 01:45:39 2005 +++ lib/libpam/Makefile.inc Sat May 28 01:45:57 2005 @@ -28,4 +28,4 @@ DEBUG_FLAGS+= -DDEBUG .endif -SHLIB_MAJOR= 2 +SHLIB_MAJOR= 3 Index: lib/libpcap/Makefile diff -u lib/libpcap/Makefile.orig lib/libpcap/Makefile --- lib/libpcap/Makefile.orig Thu Jan 27 16:57:08 2005 +++ lib/libpcap/Makefile Sat May 28 01:43:25 2005 @@ -19,7 +19,7 @@ CFLAGS+=-DINET6 .endif -SHLIB_MAJOR=3 +SHLIB_MAJOR=4 # # Magic to grab sources out of src/contrib Index: lib/libutil/Makefile diff -u lib/libutil/Makefile.orig lib/libutil/Makefile --- lib/libutil/Makefile.orig Thu Jan 27 16:57:16 2005 +++ lib/libutil/Makefile Sat May 28 01:44:45 2005 @@ -2,7 +2,7 @@ # $FreeBSD: src/lib/libutil/Makefile,v 1.56 2004/05/24 22:19:27 pjd Exp $ LIB= util -SHLIB_MAJOR= 4 +SHLIB_MAJOR= 5 SHLIBDIR?= /lib CFLAGS+=-DLIBC_SCCS -I${.CURDIR} -I${.CURDIR}/../libc/gen/ CFLAGS+=-DINET6 Index: lib/libwrap/Makefile diff -u lib/libwrap/Makefile.orig lib/libwrap/Makefile --- lib/libwrap/Makefile.orig Thu Jan 27 16:57:16 2005 +++ lib/libwrap/Makefile Sat May 28 01:45:00 2005 @@ -3,7 +3,7 @@ # LIB= wrap -SHLIB_MAJOR= 3 +SHLIB_MAJOR= 4 INCS= tcpd.h MAN= hosts_access.3 MAN+= hosts_access.5 hosts_options.5 Index: secure/lib/libssh/Makefile diff -u secure/lib/libssh/Makefile.orig secure/lib/libssh/Makefile --- secure/lib/libssh/Makefile.orig Sat May 28 01:47:38 2005 +++ secure/lib/libssh/Makefile Sat May 28 01:47:52 2005 @@ -1,6 +1,8 @@ # $FreeBSD: src/secure/lib/libssh/Makefile,v 1.31 2004/12/21 09:33:45 ru Exp $ LIB= ssh +SHLIB_MAJOR= 3 + SRCS= acss.c authfd.c authfile.c bufaux.c buffer.c \ canohost.c channels.c cipher.c cipher-acss.c cipher-aes.c \ cipher-bf1.c cipher-ctr.c cipher-3des1.c cleanup.c \ --Multipart_Sat_May_28_03:30:02_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_May_28_03:30:02_2005-1-- From owner-freebsd-current@FreeBSD.ORG Fri May 27 19:12:00 2005 Return-Path: X-Original-To: current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 69A5C16A41C; Fri, 27 May 2005 19:12:00 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from cheer.mahoroba.org (gw4.mahoroba.org [218.45.22.175]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8AF9B43D1D; Fri, 27 May 2005 19:11:59 +0000 (GMT) (envelope-from ume@mahoroba.org) Received: from lyrics.mahoroba.org (ume@lyrics.mahoroba.org [IPv6:3ffe:501:185b:8010:280:88ff:fe03:4841]) (user=ume mech=CRAM-MD5 bits=0) by cheer.mahoroba.org (8.13.3/8.13.3) with ESMTP/inet6 id j4RJBp77032013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 May 2005 04:11:51 +0900 (JST) (envelope-from ume@mahoroba.org) Date: Sat, 28 May 2005 04:11:51 +0900 Message-ID: From: Hajimu UMEMOTO To: current@FreeBSD.org, ports@FreeBSD.org References: <200505271902.j4RJ2C99016300@repoman.freebsd.org> User-Agent: Wanderlust/2.15.1 (Almost Unreal) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/22.0.50 (i386-unknown-freebsd5.4) MULE/5.0 (SAKAKI) X-Operating-System: FreeBSD 5.4-STABLE 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_May_28_04:11:51_2005-1" X-Greylist: Sender succeded SMTP AUTH authentication, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [IPv6:3ffe:501:185b:8010::1]); Sat, 28 May 2005 04:11:51 +0900 (JST) X-Virus-Scanned: by amavisd-new 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.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org Cc: Subject: HEADS UP: NI_WITHSCOPEID is not defined anymore. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 19:12:00 -0000 --Multipart_Sat_May_28_04:11:51_2005-1 Content-Type: text/plain; charset=US-ASCII Hi, I've committed to disable defining NI_WITHSCOPEID. It was exists only for backward compatibility, and getnameinfo(3) did nothing against NI_WITHSCOPEID since 5.2-RELEASE. I hope this commit breaks nothing. Sincerely, --Multipart_Sat_May_28_04:11:51_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: <200505271902.j4RJ2C99016300@repoman.freebsd.org> From: Hajimu UMEMOTO Date: Fri, 27 May 2005 19:02:12 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/include netdb.h X-FreeBSD-CVS-Branch: HEAD Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0b5 (cheer.mahoroba.org [218.45.22.175]); Sat, 28 May 2005 04:02:24 +0900 (JST) X-Virus-Scanned: by amavisd-new X-Virus-Status: Clean X-Spam-Status: No, score=-5.7 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.0.3 X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on cheer.mahoroba.org ume 2005-05-27 19:02:12 UTC FreeBSD src repository Modified files: include netdb.h Log: disable defining NI_WITHSCOPEID. It was obsoleted, and was exist only for backward compatibility since 5.2-RELEASE. Revision Changes Path 1.37 +1 -1 src/include/netdb.h --Multipart_Sat_May_28_04:11:51_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_May_28_04:11:51_2005-1-- From owner-freebsd-current@FreeBSD.ORG Fri May 27 19:41:22 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id BD6E716A41C for ; Fri, 27 May 2005 19:41:22 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail01.syd.optusnet.com.au (mail01.syd.optusnet.com.au [211.29.132.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3287C43D1F for ; Fri, 27 May 2005 19:41:21 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mail01.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j4RJfKqK013473 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 28 May 2005 05:41:20 +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 j4RJfKRx022412; Sat, 28 May 2005 05:41:20 +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 j4RJfJ3j022411; Sat, 28 May 2005 05:41:19 +1000 (EST) (envelope-from pjeremy) Date: Sat, 28 May 2005 05:41:19 +1000 From: Peter Jeremy To: Charles Swiger Message-ID: <20050527194119.GB18914@cirb503493.alcatel.com.au> References: <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> <4296997C.9030700@samsco.org> <20050526235852.M54386@lexi.siliconlandmark.com> <42969C1B.5010301@samsco.org> <20050527092544.GB18696@cirb503493.alcatel.com.au> <4C7F0B94-4D12-41A3-9A61-C3B620804671@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4C7F0B94-4D12-41A3-9A61-C3B620804671@mac.com> User-Agent: Mutt/1.4.2i Cc: FreeBSD Current Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 19:41:22 -0000 On Fri, 2005-May-27 13:09:11 -0400, Charles Swiger wrote: >Apple's Xsan clustering solution relies on a so-called "metadata >controller", which keeps track of locking and provides syncronization >and invalidation notification when the filesystem metadata changes. >SAN clients still read the actual file data directly via fibre >channel, but they also need IP-level connectivity via ethernet (an >unroutable LAN is fine) to the MDC. This is roughly the same as AdvFS on the la[te]st version of Tru64 clustering. Both Tru64 and Solaris _require_ a cluster-private LAN (or equivalent - there's a PCI memory-to-memory card that can be used as an alternative). I suspect a master metadata manager and coherency controller with all the other systems as clients is probably the optimal solution. A distributed MESI-style approach would look cleaner but be much more effort to implement and I suspect the inter-node traffic requirements would kill scalability. >The MDC is not a single-point-of-failure since redundant MDC's can be >set up, but I believe if all MDCs go down, Presumably there's MDC failover as part of the cluster management. (At least that's the way that Solaris and Tru64 work). Any UFS guru's want to comment on the [im]practicality of clustering UFS? -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Fri May 27 20:43:06 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A12AC16A41C for ; Fri, 27 May 2005 20:43:06 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail21.syd.optusnet.com.au (mail21.syd.optusnet.com.au [211.29.133.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1653043D1D for ; Fri, 27 May 2005 20:43:05 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c211-30-75-229.belrs2.nsw.optusnet.com.au [211.30.75.229]) by mail21.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j4RKh3we005533 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 28 May 2005 06:43:03 +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 j4RKh2Rx022491; Sat, 28 May 2005 06:43:02 +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 j4RKh2vu022490; Sat, 28 May 2005 06:43:02 +1000 (EST) (envelope-from pjeremy) Date: Sat, 28 May 2005 06:43:02 +1000 From: Peter Jeremy To: Ted Faber Message-ID: <20050527204302.GC18914@cirb503493.alcatel.com.au> References: <20050526001806.GA1008@pun.isi.edu> <20050526080928.GE12640@cirb503493.alcatel.com.au> <20050526160846.GA6851@pun.isi.edu> <20050526203243.GB1055@pun.isi.edu> <20050527083734.GA18696@cirb503493.alcatel.com.au> <20050527152752.GA10069@pun.isi.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050527152752.GA10069@pun.isi.edu> User-Agent: Mutt/1.4.2i Cc: freebsd-current@freebsd.org Subject: Re: hard deadlock(?) on -current; some debugging info, need help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 20:43:06 -0000 On Fri, 2005-May-27 08:27:52 -0700, Ted Faber wrote: >work something out, bit I do have a laptop running in the same >environment (and with a kernel from the same source) that does not >exhibit this problem. That's a useful snippet. I missed the bit about same source before. What are the differences between the systems (including kernel compilation options)? That might provide a clue as to the underlying problem. Have you tried running the same sort of workload on your laptop? Is is feasible to run one of the kernels on both systems? >> It might be useful to know some more details about that NFS mount >> (fsid 0x0600ff07). Can you tell us the mount parameters and what the >> server is (OS type). > >Most o fthe nfs filesystems are automounted. I'm on the machine now, so >I can't look at debugger output, but I can tell you that most of the NFS >mounts that I can imagine either psi or bash looking at are automounted. >The mount parameters are: timeo=8,retrans=9,intr I didn't notice amd before. If you can't avoid NFS, any chance of (at least temporarily) hard-mounting all the relevant filesystems and disabling amd? amd acts as an NFS server to detect activity on the automount filesystems. Both the backtraces you posted show that one process is blocked on an NFS request and amd is blocked on ufs. The locks on the second backtrace show that the bash waiting on an NFS request is a root of the deadlock tree. If that NFS request is supposed to be handled by amd, you close the deadlock cycle. Also, if your mounts are interruptable, that nfsreq sleep is interruptable - you could try dropping into DDB, finding the process sleeping on nfsreq and killing it ("kill signal_number pid" in ddb, no '-' on the signal number), then using "cont" to recover. That might break the deadlock. >For completeness, the server is a Solaris box. Don't laugh: >boreas:~$ uname -a >SunOS boreas.isi.edu 5.9 Generic_117171-12 sun4u sparc Sun's NFS implementations should be trustable :-). > If moving the config does not solve it, is there some output from >teh debugger I should get about the file system? I can't see any DDB command to dump the mount table and doing it manually would be painful. Have you managed to get a crash dump? (If not, what does "call doadump" do?) Alternatively, have you ever tried running remote GDB? > It really helps to talk these things >out with someone knowledgable. Unfortunately, no-one knowledgable has showed up :-). -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Fri May 27 21:01:40 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9468B16A41C for ; Fri, 27 May 2005 21:01:40 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3F6A943D1D for ; Fri, 27 May 2005 21:01:40 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j4RL1dQo001311; Fri, 27 May 2005 14:01:39 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j4RL1dSA001310; Fri, 27 May 2005 14:01:39 -0700 (PDT) (envelope-from faber) Date: Fri, 27 May 2005 14:01:39 -0700 From: Ted Faber To: Peter Jeremy Message-ID: <20050527210139.GA1213@pun.isi.edu> References: <20050526001806.GA1008@pun.isi.edu> <20050526080928.GE12640@cirb503493.alcatel.com.au> <20050526160846.GA6851@pun.isi.edu> <20050526203243.GB1055@pun.isi.edu> <20050527083734.GA18696@cirb503493.alcatel.com.au> <20050527152752.GA10069@pun.isi.edu> <20050527204302.GC18914@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline In-Reply-To: <20050527204302.GC18914@cirb503493.alcatel.com.au> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber Cc: freebsd-current@freebsd.org Subject: Re: hard deadlock(?) on -current; some debugging info, need help X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 21:01:40 -0000 --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, May 28, 2005 at 06:43:02AM +1000, Peter Jeremy wrote: > On Fri, 2005-May-27 08:27:52 -0700, Ted Faber wrote: > >> It might be useful to know some more details about that NFS mount > >> (fsid 0x0600ff07). Can you tell us the mount parameters and what the > >> server is (OS type). > > > >Most o fthe nfs filesystems are automounted. I'm on the machine now, so > >I can't look at debugger output, but I can tell you that most of the NFS > >mounts that I can imagine either psi or bash looking at are automounted. > >The mount parameters are: timeo=3D8,retrans=3D9,intr >=20 > I didn't notice amd before. If you can't avoid NFS, any chance of (at > least temporarily) hard-mounting all the relevant filesystems and > disabling amd? amd acts as an NFS server to detect activity on the > automount filesystems. Both the backtraces you posted show that one > process is blocked on an NFS request and amd is blocked on ufs. The > locks on the second backtrace show that the bash waiting on an NFS > request is a root of the deadlock tree. If that NFS request is > supposed to be handled by amd, you close the deadlock cycle. I think I've got it to the point where it's reproducible, and therefore killable. :-) It does seem to be an amd interaction, which gives me a way to avoid it until it is killed. Details within the hour. Thanks again for your suggestions. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCl4qzaUz3f+Zf+XsRAq8EAKCwGEHEFXOLxsb/7MzYfSOl0MwAEwCgxEql Eh8PNZa6wOFdV8U7eGSxHiQ= =r6YJ -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N-- From owner-freebsd-current@FreeBSD.ORG Fri May 27 21:49:09 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D564C16A41C for ; Fri, 27 May 2005 21:49:09 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (pun.isi.edu [128.9.160.150]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7884243D1D for ; Fri, 27 May 2005 21:49:09 +0000 (GMT) (envelope-from faber@pun.isi.edu) Received: from pun.isi.edu (localhost [127.0.0.1]) by pun.isi.edu (8.13.3/8.13.1) with ESMTP id j4RLn9Jc001507; Fri, 27 May 2005 14:49:09 -0700 (PDT) (envelope-from faber@pun.isi.edu) Received: (from faber@localhost) by pun.isi.edu (8.13.3/8.13.1/Submit) id j4RLn9mL001506; Fri, 27 May 2005 14:49:09 -0700 (PDT) (envelope-from faber) Date: Fri, 27 May 2005 14:49:08 -0700 From: Ted Faber To: freebsd-current@freebsd.org Message-ID: <20050527214908.GA1031@pun.isi.edu> References: <20050526001806.GA1008@pun.isi.edu> <20050526080928.GE12640@cirb503493.alcatel.com.au> <20050526160846.GA6851@pun.isi.edu> <20050526203243.GB1055@pun.isi.edu> <20050527083734.GA18696@cirb503493.alcatel.com.au> <20050527152752.GA10069@pun.isi.edu> <20050527204302.GC18914@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="4jXrM3lyYWu4nBt5" Content-Disposition: inline In-Reply-To: <20050527204302.GC18914@cirb503493.alcatel.com.au> User-Agent: Mutt/1.4.2.1i X-url: http://www.isi.edu/~faber X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Peter Jeremy Subject: amd/nfs deadlock on -current w/example code (was Re: hard deadlock(?) on -current; some debugging info, need help) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 21:49:10 -0000 --4jXrM3lyYWu4nBt5 Content-Type: multipart/mixed; boundary="gj572EiMnwbLXET9" Content-Disposition: inline --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable With a bunch of help from Peter Jeremy, I've been able to narrow my deadlock problem down to a repeatable case. If you're just tuning in, -current running amd and nfs deadlocks to the point where panic or call doadump from the debugger fails to generate a crash dump. I think that the included code and configs will let you cause this on your own machine. The scenario is this: amd mounted NFS directory reasonable read/write load from different processes eventually the machine deadlocks Amd configuration files and test code are attached. On my machines, compiling loadit and running loadit 35 /nfs/jade/faber (which just happens to be an nfs directory I use) locks up the system repeatably. loadit just forks n processes (arg1) to create files called lock${n} in the given directory (arg2). There's no locking done, but I named the files when I thought locking might be at issue. Each process accesses only its own lock file and makes some small writes/reads to it 10000 times. It seems to matter that the amd is managing multiple maps, though I only touch the /nfs one. I couldn't get it to lock only loading the nfs map. The amd configurations and code are attached. in etc/rc.conf I do: amd_enable=3D"YES" amd_flags=3D"-F /usr/local/etc/amd.conf" I'm happy to supply more data, file a pr, test patches or anything. I'm also working around by statically mounting the most common filesystems I use. Thanks again to Peter for holding my hand until I could get a repeatable case. --=20 Ted Faber http://www.isi.edu/~faber PGP: http://www.isi.edu/~faber/pubkeys.= asc Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#= SIG --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="amd.conf" [global] nfs_proto = udp auto_dir = /auto log_file = syslog restart_mounts = yes [/nfs] map_name = /usr/local/etc/amd.test [/isi] map_name = /usr/local/etc/amd.isi [/home] map_name = /usr/local/etc/amd.home [/removable] map_name = /usr/local/etc/amd.removable --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="amd.test" Content-Transfer-Encoding: quoted-printable # -- IMPORTANT NOTICE -- # # The master version of this file is kept on VENERA.ISI.EDU # You *must* make all modifications to this file on that host. # It will automatically update the other servers overnight. # You may then have to run "amq -f" to reset AMD. # =20 # Your cooperation in this matter is greatly appreciated!!! # /defaults type:=3Dnfs;fs:=3D${autodir}/${rhost}/${key};rfs:=3D${autodir}/${= rhost}/${key};opts:=3Dtimeo=3D8,retrans=3D9,intr jade rhost:=3Dboreas --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="amd.home" ravichan type:=link;fs:="/nfs/isd3/ravichan" mlievens type:=link;fs:="/nfs/ivory/mlievens" fukumoto type:=link;fs:="/nfs/isd2/fukumoto" carolina type:=link;fs:="/nfs/div2/carolina" scoyazo type:=link;fs:="/nfs/ipc/scoyazo" jwhalen type:=link;fs:="/nfs/neon/jwhalen" insley type:=link;fs:="/nfs/guest/insley" bsmith type:=link;fs:="/nfs/m_usr/bsmith" blythe type:=link;fs:="/nfs/isd/blythe" apache type:=link;fs:="/var/www" melz type:=link;fs:="/nfs/topaz/melz" workshop type:=link;fs:="/nfs/gren/workshop" spundun type:=link;fs:="/nfs/div1/spundun" smartin type:=link;fs:="/nfs/guest/smartin" oracle7 type:=link;fs:="/nfs/div2/oracle7" koranda type:=link;fs:="/nfs/guest/koranda" mwilde type:=link;fs:="/nfs/guest/mwilde" umdom type:=link;fs:="/nfs/ruby/umdom" puid2 type:=link;fs:="/none" faber type:=link;fs:="/usr/home/faber" thussain type:=link;fs:="/nfs/ivory/thussain" cmerchan type:=link;fs:="/nfs/isd2/cmerchan" christos type:=link;fs:="/nfs/gren/christos" melissa type:=link;fs:="/nfs/ivory/melissa" bhavsar type:=link;fs:="/nfs/guest/bhavsar" postel type:=link;fs:="/nfs/div7/postel" knight type:=link;fs:="/nfs/isd3/knight" kathyt type:=link;fs:="/nfs/asd2/kathyt" pipet type:=link;fs:="/nfs/topaz/pipet" ryankash type:=link;fs:="/nfs/isd/ryankash" kjohnson type:=link;fs:="/nfs/guest/kjohnson" alqahtan type:=link;fs:="/nfs/isd2/alqahtan" ziegler type:=link;fs:="/nfs/div1/ziegler" joechiu type:=link;fs:="/nfs/isd3/joechiu" jinbo type:=link;fs:="/nfs/div2/jinbo" juan type:=link;fs:="/nfs/guest/juan" bud_bkup type:=link;fs:="/" terrell type:=link;fs:="/nfs/v5/terrell" tania type:=link;fs:="/nfs/isd2/tania" yuri type:=link;fs:="/nfs/jade/yuri" wong type:=link;fs:="/nfs/guest/wong" shen type:=link;fs:="/nfs/isd3/shen" youngkan type:=link;fs:="/nfs/guest/youngkan" personne type:=link;fs:="/nfs/ivory/personne" jonesej type:=link;fs:="/nfs/ipc/jonesej" trang type:=link;fs:="/nfs/m_usr/trang" alanr type:=link;fs:="/nfs/ivory/alanr" web-ican type:=link;fs:="/" tshaulis type:=link;fs:="/nfs/guest/tshaulis" sridhar type:=link;fs:="/nfs/asd/sridhar" fleisch type:=link;fs:="/nfs/guest/fleisch" vsrini type:=link;fs:="/nfs/asd/vsrini" kakani type:=link;fs:="/nfs/isd2/kakani" mubin type:=link;fs:="/nfs/ivory/mubin" marcs type:=link;fs:="/nfs/topaz/marcs" arens type:=link;fs:="/nfs/topaz/arens" vay type:=link;fs:="/nfs/div1/vay" ulf type:=link;fs:="/nfs/isd/ulf" amarshal type:=link;fs:="/nfs/topaz/amarshal" web-rfc type:=link;fs:="/" pkamath type:=link;fs:="/nfs/jade/pkamath" gurmeet type:=link;fs:="/nfs/v6/gurmeet" eandre type:=link;fs:="/nfs/guest/eandre" arcada type:=link;fs:="/nfs/m_app1/arcada" amosis type:=link;fs:="/nfs/m_usr/amosis" weiye type:=link;fs:="/nfs/ruby/weiye" lane type:=link;fs:="/nfs/guest/lane" efab type:=link;fs:="/nfs/eisd/efab" bcn type:=link;fs:="/nfs/ruby/bcn" ohlander type:=link;fs:="/nfs/neon/ohlander" mwebster type:=link;fs:="/nfs/m_usr/mwebster" bmanning type:=link;fs:="/nfs/jade/bmanning" sfranke type:=link;fs:="/nfs/isd2/sfranke" pcadmin type:=link;fs:="/nfs/ipc/pcadmin" tjkwon type:=link;fs:="/nfs/div1/tjkwon" ndss00 type:=link;fs:="/nfs/jade/ndss00" iscapc type:=link;fs:="/nfs/v5/iscapc" mhall type:=link;fs:="/nfs/div1/mhall" jihie type:=link;fs:="/nfs/isd3/jihie" apachmos type:=link;fs:="/nfs/m_app1/apachmos" ars_adm type:=link;fs:="/usr/ar" maggon type:=link;fs:="/nfs/div2/maggon" koenig type:=link;fs:="/nfs/guest/koenig" nkwon type:=link;fs:="/nfs/topaz/nkwon" glenn type:=link;fs:="/nfs/m_usr/glenn" dhawe type:=link;fs:="/nfs/ipc/dhawe" cey type:=link;fs:="/nfs/jade/cey" informix type:=link;fs:="/nfs/isd/informix" ims_test type:=link;fs:="/nfs/m_prb1/probing/ims" gonzalez type:=link;fs:="/nfs/ipc/gonzalez" versant type:=link;fs:="/nfs/sevak-data/versant" hylafax type:=link;fs:="/var/spool/hylafax" rajeev type:=link;fs:="/nfs/guest/rajeev" soar-doc type:=link;fs:="/nfs/soar2/soar-doc" rstoker type:=link;fs:="/nfs/ivory/rstoker" diaz type:=link;fs:="/nfs/div7/diaz" touch-mm type:=link;fs:="/nfs/ruby/touch-mm" suifspec type:=link;fs:="/nfs/v5/suifspec" granacki type:=link;fs:="/nfs/v6/granacki" devmosis type:=link;fs:="/nfs/m_app1/devmosis" cacuser type:=link;fs:="/nfs/share/cacuser" xmosis type:=link;fs:="/nfs/m_app1/xmosis" ginoza type:=link;fs:="/nfs/gren/ginoza" timc type:=link;fs:="/nfs/isd/timc" xiw type:=link;fs:="/nfs/jade/xiw" iko type:=link;fs:="/nfs/guest/iko" cox type:=link;fs:="/nfs/m_usr/cox" web-usrx type:=link;fs:="/" prmsrv type:=link;fs:="/nfs/gost/products/prm" tyree type:=link;fs:="/nfs/m_usr/tyree" saltz type:=link;fs:="/nfs/neon/saltz" abocc type:=link;fs:="/nfs/jade/abocc" blau type:=link;fs:="/nfs/guest/blau" bgs type:=link;fs:="/nfs/guest/bgs" wdelorie type:=link;fs:="/nfs/m_usr/wdelorie" div10rpt type:=link;fs:="/nfs/neon/div10rpt" laura type:=link;fs:="/nfs/asd/laura" soar type:=link;fs:="/nfs/soar2/soar" delacruz type:=link;fs:="/nfs/gren/delacruz" web-bor type:=link;fs:="/" techlib type:=link;fs:="/nfs/ivory/techlib" cporter type:=link;fs:="/nfs/ivory/cporter" rwhois type:=link;fs:="/nfs/coms/rwhois" gmehta type:=link;fs:="/nfs/asd2/gmehta" dasher type:=link;fs:="/nfs/div2/dasher" kagy type:=link;fs:="/nfs/ipc/kagy" lwinston type:=link;fs:="/nfs/ivory/lwinston" chunchen type:=link;fs:="/nfs/div1/chunchen" germann type:=link;fs:="/nfs/guest/germann" web-bb type:=link;fs:="/" shetty type:=link;fs:="/nfs/v6/shetty" fstann type:=link;fs:="/nfs/jade/fstann" amyers type:=link;fs:="/nfs/isd2/amyers" noori type:=link;fs:="/nfs/guest/noori" alain type:=link;fs:="/nfs/v5/alain" mei type:=link;fs:="/nfs/asd/mei" penguest type:=link;fs:="/nfs/isd/penguest" sondeen type:=link;fs:="/nfs/div1/sondeen" hzhang3 type:=link;fs:="/nfs/guest/hzhang3" popadm type:=link;fs:="/tmp" draper type:=link;fs:="/nfs/div1/draper" d7east type:=link;fs:="/nfs/ruby/d7east" keith type:=link;fs:="/nfs/ivory/keith" och type:=link;fs:="/nfs/guest/och" web-clr2 type:=link;fs:="/" ruiwang type:=link;fs:="/nfs/ipc/ruiwang" muslea type:=link;fs:="/nfs/guest/muslea" action type:=link;fs:="/nfs/u2/action" marcu type:=link;fs:="/nfs/isd/marcu" brian type:=link;fs:="/nfs/gren/brian" webadmin type:=link;fs:="/tmp" rnelson type:=link;fs:="/nfs/ipc/rnelson" default type:=link;fs:="/nfs/u2/action" d7lists type:=link;fs:="/nfs/div7/d7lists" robots type:=link;fs:="/nfs/isd2/robots" craig type:=link;fs:="/nfs/ipc/craig" hlee type:=link;fs:="/nfs/topaz/hlee" sdr type:=link;fs:="/nfs/m_usr/sdr" asd type:=link;fs:="/nfs/asd/asd" mmguest type:=link;fs:="/nfs/conf/mmguest" div3rpt type:=link;fs:="/nfs/neon/div3rpt" rbates type:=link;fs:="/nfs/ipc/rbates" melody type:=link;fs:="/nfs/guest/melody" mieke type:=link;fs:="/nfs/div7/mieke" terrawor type:=link;fs:="/nfs/isd3/terrawor" smchenry type:=link;fs:="/nfs/div7/smchenry" in-notes type:=link;fs:="/nfs/ftp/in-notes" rapteam type:=link;fs:="/nfs/isd2/rapteam" erikabn type:=link;fs:="/nfs/topaz/erikabn" daemon type:=link;fs:="/" guillory type:=link;fs:="/nfs/isd2/guillory" facility type:=link;fs:="/nfs/ivory/facility" resumes type:=link;fs:="/nfs/ivory/resumes" dhollen type:=link;fs:="/nfs/m_usr/dhollen" web-ln type:=link;fs:="/" dlhawe type:=link;fs:="/nfs/ipc/dlhawe" boapps type:=link;fs:="/nfs/ivory/boapps" mason type:=link;fs:="/nfs/ipc/mason" carte type:=link;fs:="/nfs/amber/carte" preetham type:=link;fs:="/nfs/isd3/preetham" jamesrey type:=link;fs:="/nfs/ipc/jamesrey" ambastha type:=link;fs:="/nfs/guest/ambastha" oramos8 type:=link;fs:="/nfs/m_app1/oramos8" jonmay type:=link;fs:="/nfs/isd/jonmay" eiffel type:=link;fs:="/nfs/m_app1/eiffel" abebeh type:=link;fs:="/nfs/m_usr/abebeh" rfccp type:=link;fs:="/nfs/ruby/rfccp" difac type:=link;fs:="/nfs/ruby/difac" yuki type:=link;fs:="/nfs/isd2/yuki" hutchins type:=link;fs:="/nfs/guest/hutchins" schuler type:=link;fs:="/nfs/v5/schuler" probing type:=link;fs:="/nfs/m_prb1/probing" web-ntro type:=link;fs:="/" web-mman type:=link;fs:="/" vitanshu type:=link;fs:="/nfs/v6/vitanshu" nlsummer type:=link;fs:="/nfs/topaz/nlsummer" mmanpcen type:=link;fs:="/nfs/ruby/mmanpcen" omega type:=link;fs:="/nfs/isd2/omega" govindan type:=link;fs:="/nfs/div7/govindan" web-mon type:=link;fs:="/" valente type:=link;fs:="/nfs/topaz/valente" tmurray type:=link;fs:="/nfs/isd/tmurray" shahabi type:=link;fs:="/nfs/guest/shahabi" linnett type:=link;fs:="/nfs/neon/linnett" datatag type:=link;fs:="/nfs/asd/datatag" cpina type:=link;fs:="/nfs/m_usr/cpina" sims type:=link;fs:="/nfs/isd3/sims" ipc type:=link;fs:="/nfs/ipc/ipc" oramosis type:=link;fs:="/nfs/m_app1/oramosis" mhopkins type:=link;fs:="/nfs/isd/mhopkins" jdamoula type:=link;fs:="/nfs/guest/jdamoula" hfaxmail type:=link;fs:="/nfs/m_app1/hfaxmail" fhouston type:=link;fs:="/nfs/guest/fhouston" sharmaa type:=link;fs:="/nfs/div1/sharmaa" bschott type:=link;fs:="/nfs/guest/bschott" rzhou type:=link;fs:="/nfs/div7/rzhou" isl type:=link;fs:="/nfs/asd/asd" cad type:=link;fs:="/nfs/m_cad/cad" mboseman type:=link;fs:="/nfs/ivory/mboseman" jasapara type:=link;fs:="/nfs/guest/jasapara" hongsuda type:=link;fs:="/nfs/guest/hongsuda" imudom type:=link;fs:="/nfs/guest/imudom" hannes type:=link;fs:="/nfs/isd/hannes" barish type:=link;fs:="/nfs/guest/barish" jkrey type:=link;fs:="/nfs/jade/jkrey" teamhost type:=link;fs:="/nfs/amber/teamhost" isdguest type:=link;fs:="/nfs/isd/isdguest" mailman type:=link;fs:="/nfs/neon/mailman" mmconf type:=link;fs:="/nfs/conf/diamond/mmconf" ramya type:=link;fs:="/nfs/v6/ramya" mosis type:=link;fs:="/nfs/m_app1/mosis" hobbs type:=link;fs:="/nfs/topaz/hobbs" veda type:=link;fs:="/nfs/ivory/veda" mta type:=link;fs:="/" staruser type:=link;fs:="/nfs/ivory/staruser" maechlin type:=link;fs:="/nfs/asd2/maechlin" contract type:=link;fs:="/nfs/neon/contract" benbrown type:=link;fs:="/nfs/m_usr/benbrown" rneches type:=link;fs:="/nfs/div2/rneches" lindell type:=link;fs:="/nfs/guest/lindell" root type:=link;fs:="/" ragy type:=link;fs:="/nfs/guest/ragy" jair-ed type:=link;fs:="/nfs/isd2/jair-ed" lapin type:=link;fs:="/nfs/ivory/lapin" koehn type:=link;fs:="/nfs/guest/koehn" ih-mm type:=link;fs:="/nfs/ruby/ih-mm" zach type:=link;fs:="/nfs/m_usr/zach" gost type:=link;fs:="/nfs/gost" dkauchak type:=link;fs:="/nfs/guest/dkauchak" thakkar type:=link;fs:="/nfs/amber/thakkar" stefan type:=link;fs:="/nfs/topaz/stefan" frank type:=link;fs:="/nfs/guest/frank" dmkrx type:=link;fs:="/nfs/div2/dmkrx" acmos type:=link;fs:="/nfs/div2/acmos" gose type:=link;fs:="/nfs/guest/gose" wdb type:=link;fs:="/nfs/neon/wdb" ito type:=link;fs:="/nfs/isd2/ito" pynadath type:=link;fs:="/nfs/isd3/pynadath" whitney type:=link;fs:="/nfs/isd3/whitney" faxmail type:=link;fs:="/var/spool/faxmail" dartisi type:=link;fs:="/nfs/dart/dartisi" jbaker type:=link;fs:="/nfs/ipc/jbaker" fraser type:=link;fs:="/nfs/isd/fraser" div7ew type:=link;fs:="/nfs/ruby/div7ew" berger type:=link;fs:="/nfs/guest/berger" ning type:=link;fs:="/nfs/topaz/ning" carl type:=link;fs:="/nfs/v6/carl" lac type:=link;fs:="/nfs/isd/lac" comments type:=link;fs:="/nfs/jade/comments" ahonka type:=link;fs:="/nfs/m_usr/ahonka" falk type:=link;fs:="/nfs/jade/falk" gil type:=link;fs:="/nfs/isd/gil" shutdown type:=link;fs:="/tmp" web-iab type:=link;fs:="/" nobody type:=link;fs:="/" mariam type:=link;fs:="/nfs/isd3/mariam" leana type:=link;fs:="/nfs/gren/leana" astt type:=link;fs:="/nfs/soar2/astt" www type:=link;fs:="/nfs/web/htdocs" loomlist type:=link;fs:="/nfs/topaz/loomlist" rutland type:=link;fs:="/nfs/isd/rutland" lerman type:=link;fs:="/nfs/isd3/lerman" cjansa type:=link;fs:="/nfs/neon/cjansa" bbuser type:=link;fs:="/nfs/ipc/bbuser" d2adm type:=link;fs:="/nfs/eisd/d2adm" elai type:=link;fs:="/nfs/isd2/elai" mman-rfc type:=link;fs:="/nfs/ruby/mman-rfc" salemi type:=link;fs:="/nfs/div2/salemi" pantel type:=link;fs:="/nfs/isd3/pantel" puid4 type:=link;fs:="/none" cohen type:=link;fs:="/nfs/topaz/cohen" geoworld type:=link;fs:="/nfs/eisd/geoworld" pegasus type:=link;fs:="/nfs/asd2/pegasus" gganger type:=link;fs:="/nfs/m_usr/gganger" dolbear type:=link;fs:="/nfs/guest/dolbear" div2rpt type:=link;fs:="/nfs/neon/div2rpt" d7admin type:=link;fs:="/nfs/ruby/d7admin" yoonju type:=link;fs:="/nfs/asd2/yoonju" thiago type:=link;fs:="/nfs/topaz/thiago" thayer type:=link;fs:="/nfs/topaz/thayer" npckge type:=link;fs:="/nfs/v6/npckge" oasmosis type:=link;fs:="/nfs/m_app1/oasmosis" ns-users type:=link;fs:="/nfs/neon/ns-users" dceg_cvs type:=link;fs:="/nfs/div2/dceg_cvs" bbarrett type:=link;fs:="/nfs/guest/bbarrett" soluser type:=link;fs:="/nfs/ivory/soluser" matthew type:=link;fs:="/nfs/ivory/matthew" whiten type:=link;fs:="/nfs/isd2/whiten" girish type:=link;fs:="/nfs/isd2/girish" pedro type:=link;fs:="/nfs/div1/pedro" oard type:=link;fs:="/nfs/guest/oard" itf type:=link;fs:="/nfs/guest/itf" tstmosis type:=link;fs:="/nfs/m_app1/tstmosis" rosenblo type:=link;fs:="/nfs/neon/rosenblo" majordom type:=link;fs:="/nfs/infr/majordom" aserrano type:=link;fs:="/nfs/jade/aserrano" jlacoss type:=link;fs:="/nfs/v6/jlacoss" ariadne type:=link;fs:="/nfs/isd2/ariadne" qcao type:=link;fs:="/nfs/guest/qcao" esam type:=link;fs:="/nfs/isd2/esam" rfc-onli type:=link;fs:="/nfs/infr/rfc-onli" rramani type:=link;fs:="/nfs/div7/rramani" kintali type:=link;fs:="/nfs/div1/kintali" mdarcy type:=link;fs:="/nfs/v6/mdarcy" alau type:=link;fs:="/nfs/ivory/alau" usatlas1 type:=link;fs:="/nfs/asd/usatlas1" list-mgr type:=link;fs:="/nfs/infr/list-mgr" apopescu type:=link;fs:="/nfs/guest/apopescu" stellac type:=link;fs:="/nfs/topaz/stellac" steele type:=link;fs:="/nfs/asd/steele" nadim type:=link;fs:="/nfs/isd3/nadim" brad type:=link;fs:="/nfs/m_usr/brad" annc type:=link;fs:="/nfs/asd/annc" tex type:=link;fs:="/local/tex/lib/tex/macros" weathers type:=link;fs:="/nfs/isd2/weathers" nabbasi type:=link;fs:="/nfs/isd2/nabbasi" lsam type:=link;fs:="/nfs/conf/lsam" hans type:=link;fs:="/nfs/topaz/hans" knoblock type:=link;fs:="/nfs/isd3/knoblock" khoshnev type:=link;fs:="/nfs/neon/khoshnev" rbakshi type:=link;fs:="/nfs/guest/rbakshi" oraboff type:=link;fs:="/oracle/oraboff" johnson type:=link;fs:="/nfs/amber/johnson" isisrb type:=link;fs:="/nfs/asd2/isisrb" wygr type:=link;fs:="/nfs/ivory/wygr" will type:=link;fs:="/nfs/eisd/will" bso type:=link;fs:="/nfs/guest/bso" marsella type:=link;fs:="/nfs/amber/marsella" cescobar type:=link;fs:="/nfs/ivory/cescobar" isiconf type:=link;fs:="/nfs/conf/isiconf" ecannon type:=link;fs:="/nfs/isd2/ecannon" jerryc type:=link;fs:="/nfs/v5/jerryc" jcole type:=link;fs:="/nfs/guest/jcole" ivdgl type:=link;fs:="/nfs/asd/ivdgl" ldap-usrn type:=link;fs:="/" web-usrn type:=link;fs:="/" web-smos type:=link;fs:="/" nsnamsim type:=link;fs:="/nfs/ruby/nsnamsim" bosybase type:=link;fs:="/nfs/ivory/bosybase" icarmi type:=link;fs:="/nfs/div1/icarmi" cmah type:=link;fs:="/nfs/ivory/cmah" web-usrs type:=link;fs:="/" par_serv type:=link;fs:="/nfs/cad10/par_serv" mbrasser type:=link;fs:="/nfs/guest/mbrasser" lorraine type:=link;fs:="/nfs/ivory/lorraine" kkmercha type:=link;fs:="/nfs/guest/kkmercha" mcurry type:=link;fs:="/nfs/m_usr/mcurry" fujita type:=link;fs:="/nfs/jade/fujita" raghu type:=link;fs:="/nfs/ruby/raghu" kolahdoz type:=link;fs:="/nfs/isd2/kolahdoz" rparker type:=link;fs:="/nfs/guest/rparker" skrimm type:=link;fs:="/nfs/ivory/skrimm" agents type:=link;fs:="/nfs/isd2/agents" traum type:=link;fs:="/nfs/guest/traum" leiqu type:=link;fs:="/nfs/amber/leiqu" jackw type:=link;fs:="/nfs/asd/jackw" anava type:=link;fs:="/nfs/topaz/anava" http type:=link;fs:="/nfs/web/htdocs" stergiou type:=link;fs:="/nfs/ivory/stergiou" stamant type:=link;fs:="/nfs/topaz/stamant" nrathod type:=link;fs:="/nfs/isd/nrathod" madduri type:=link;fs:="/nfs/guest/madduri" d7share type:=link;fs:="/nfs/gren/d7share" klink type:=link;fs:="/nfs/isd2/klink" vlsi type:=link;fs:="/nfs/m_app1/vlsi" shaw type:=link;fs:="/nfs/amber/shaw" news type:=link;fs:="/usr/spool/news" gdt type:=link;fs:="/nfs/v6/gdt" fry type:=link;fs:="/nfs/m_usr/fry" pdox-adm type:=link;fs:="/nfs/ivory/pdox-adm" shishir type:=link;fs:="/nfs/v5/shishir" touch2 type:=link;fs:="/nfs/ruby/touch2" bhuang type:=link;fs:="/nfs/isd3/bhuang" opr type:=link;fs:="/nfs/u2/opr" galstyan type:=link;fs:="/nfs/isd3/galstyan" alfredau type:=link;fs:="/nfs/isd2/alfredau" shalini type:=link;fs:="/nfs/neon/shalini" onruser type:=link;fs:="/nfs/share/onruser" div9rpt type:=link;fs:="/nfs/neon/div9rpt" kokje type:=link;fs:="/nfs/jade/kokje" cbeal type:=link;fs:="/nfs/isd/cbeal" bbean type:=link;fs:="/nfs/ivory/bbean" bagga type:=link;fs:="/nfs/ruby/bagga" zhou type:=link;fs:="/nfs/jade/zhou" alba type:=link;fs:="/nfs/jade/alba" web-omos type:=link;fs:="/web-omos" div5rpt type:=link;fs:="/nfs/neon/div5rpt" liangz type:=link;fs:="/nfs/isd2/liangz" cmcdir type:=link;fs:="/nfs/m_cad/cmcdir" aharth type:=link;fs:="/nfs/guest/aharth" yasin type:=link;fs:="/nfs/guest/yasin" bacon type:=link;fs:="/nfs/guest/bacon" iana type:=link;fs:="/nfs/jade/iana" pan type:=link;fs:="/nfs/topaz/pan" mib type:=link;fs:="/nfs/ftp/mib" pcbackup type:=link;fs:="/nfs/ipc/pcbackup" defactom type:=link;fs:="/nfs/asd/defactom" web-cur type:=link;fs:="/" theseus type:=link;fs:="/nfs/isd3/theseus" rflucas type:=link;fs:="/nfs/div1/rflucas" counter type:=link;fs:="/nfs/infr/counter" adibi type:=link;fs:="/nfs/isd/adibi" web-pstl type:=link;fs:="/" web-iana type:=link;fs:="/" ldapuser type:=link;fs:="/" package type:=link;fs:="/nfs/m_mod1/package" buskirk type:=link;fs:="/nfs/guest/buskirk" rogers type:=link;fs:="/nfs/div2/rogers" jmoore type:=link;fs:="/nfs/isd3/jmoore" yaser type:=link;fs:="/nfs/guest/yaser" zita type:=link;fs:="/nfs/jade/zita" yushunwa type:=link;fs:="/nfs/ruby/yushunwa" rajgarhi type:=link;fs:="/nfs/guest/rajgarhi" anuraagm type:=link;fs:="/nfs/guest/anuraagm" sonjain type:=link;fs:="/nfs/isd2/sonjain" nlserv type:=link;fs:="/nfs/isd3/nlserv" lara type:=link;fs:="/nfs/isd2/lara" drew type:=link;fs:="/nfs/ipc/drew" pvm type:=link;fs:="/nfs/guest/pvm" pinfosrv type:=link;fs:="/nfs/gost/pfs" m_shared type:=link;fs:="/nfs/m_app1/m_shared" abramson type:=link;fs:="/nfs/div1/abramson" srinath type:=link;fs:="/nfs/guest/srinath" samtani type:=link;fs:="/nfs/isd2/samtani" jchame type:=link;fs:="/nfs/div1/jchame" model type:=link;fs:="/nfs/m_mod1/model" dford type:=link;fs:="/nfs/isd2/dford" eric type:=link;fs:="/nfs/neon/eric" goldberg type:=link;fs:="/nfs/m_usr/goldberg" sidjain type:=link;fs:="/nfs/v6/sidjain" carlos type:=link;fs:="/nfs/m_usr/carlos" cnpa type:=link;fs:="/nfs/div7/cnpa" p4 type:=link;fs:="/nfs/div1/cad/p4" bartlett type:=link;fs:="/nfs/jade/bartlett" hussain type:=link;fs:="/nfs/ruby/hussain" bhatti type:=link;fs:="/nfs/div1/bhatti" neno type:=link;fs:="/nfs/guest/neno" paradox type:=link;fs:="/nfs/neon/paradox" neesdaq type:=link;fs:="/nfs/asd2/neesdaq" loomora type:=link;fs:="/nfs/isd/loomora" cousins type:=link;fs:="/nfs/m_usr/cousins" clayton type:=link;fs:="/nfs/isd3/clayton" minton type:=link;fs:="/nfs/guest/minton" madmin type:=link;fs:="/nfs/m_usr/madmin" smmsp type:=link;fs:="/var/spool/mqueue" inc-work type:=link;fs:="/nfs/jade/inc-work" crnmosis type:=link;fs:="/nfs/m_app1/crnmosis" pkhoury type:=link;fs:="/nfs/isd2/pkhoury" mgalley type:=link;fs:="/nfs/guest/mgalley" lnadmin type:=link;fs:="/nfs/ruby/lnadmin" div8rpt type:=link;fs:="/nfs/neon/div8rpt" div4rpt type:=link;fs:="/nfs/neon/div4rpt" ddutta type:=link;fs:="/nfs/ruby/ddutta" d7adm type:=link;fs:="/nfs/jade/d7adm" kenj type:=link;fs:="/nfs/ipc/kenj" isx type:=link;fs:="/nfs/isd/isx" ora_alto type:=link;fs:="/nfs/alto/ora_alto" kyamada type:=link;fs:="/nfs/guest/kyamada" schorr type:=link;fs:="/nfs/neon/schorr" nouhi type:=link;fs:="/nfs/isd/nouhi" elves type:=link;fs:="/nfs/isd3/elves" dono type:=link;fs:="/nfs/isd/dono" wcadmin type:=link;fs:="/nfs/ipc/wcadmin" tbenzel type:=link;fs:="/nfs/neon/tbenzel" margiej type:=link;fs:="/nfs/ivory/margiej" sharad type:=link;fs:="/nfs/v5/sharad" remedy type:=link;fs:="/nfs/neon/remedy" tilp type:=link;fs:="/nfs/div1/tilp" hjma type:=link;fs:="/nfs/m_usr/hjma" publicpc type:=link;fs:="/nfs/isd/publicpc" maj-domo type:=link;fs:="/nfs/ipc/maj-domo" actiondb type:=link;fs:="/nfs/u2/actiondb" mallard type:=link;fs:="/nfs/amber/mallard" shumin type:=link;fs:="/nfs/isd3/shumin" xbone type:=link;fs:="/nfs/jade/xbone" puid3 type:=link;fs:="/none" vmjoyner type:=link;fs:="/nfs/m_usr/vmjoyner" echihabi type:=link;fs:="/nfs/guest/echihabi" hdaume type:=link;fs:="/nfs/isd3/hdaume" foukia type:=link;fs:="/nfs/ruby/foukia" expect type:=link;fs:="/nfs/topaz/expect" coreyc type:=link;fs:="/nfs/ivory/coreyc" sweep type:=link;fs:="/local/sophos" puid5 type:=link;fs:="/none" ch-mm type:=link;fs:="/nfs/div7/ch-mm" loom type:=link;fs:="/nfs/isd2/loom" pat type:=link;fs:="/nfs/m_usr/pat" chaudhry type:=link;fs:="/nfs/isd2/chaudhry" aeronaut type:=link;fs:="/nfs/ipc/aeronaut" masseyd type:=link;fs:="/nfs/guest/masseyd" martinm type:=link;fs:="/nfs/topaz/martinm" donghui type:=link;fs:="/nfs/isd2/donghui" graehl type:=link;fs:="/nfs/topaz/graehl" baoshi type:=link;fs:="/nfs/eisd/baoshi" jtran type:=link;fs:="/nfs/div1/jtran" brent type:=link;fs:="/nfs/isd2/brent" sdeneefe type:=link;fs:="/nfs/isd/sdeneefe" quamrul type:=link;fs:="/nfs/topaz/quamrul" mib-adm type:=link;fs:="/nfs/coms/mib-adm" safari type:=link;fs:="/nfs/share/safari" berson type:=link;fs:="/nfs/guest/berson" touch type:=link;fs:="/nfs/ruby/touch" kurinsky type:=link;fs:="/nfs/topaz/kurinsky" uscms01 type:=link;fs:="/nfs/asd/uscms01" div7rpt type:=link;fs:="/nfs/neon/div7rpt" labore type:=link;fs:="/nfs/amber/labore" unify type:=link;fs:="/usr/unify" mcgee type:=link;fs:="/nfs/asd2/mcgee" skim type:=link;fs:="/nfs/isd2/skim" mack type:=link;fs:="/nfs/topaz/mack" finn type:=link;fs:="/nfs/ruby/finn" lcr type:=link;fs:="/nfs/m_usr/lcr" sullivan type:=link;fs:="/nfs/ivory/sullivan" johnmgce type:=link;fs:="/nfs/asd2/johnmgce" istouser type:=link;fs:="/nfs/share/istouser" d8recrut type:=link;fs:="/nfs/asd/d8recrut" div6rpt type:=link;fs:="/nfs/neon/div6rpt" toonen type:=link;fs:="/nfs/guest/toonen" shanky type:=link;fs:="/nfs/guest/shanky" yvaid type:=link;fs:="/nfs/ivory/yvaid" rahul type:=link;fs:="/nfs/topaz/rahul" nsnam type:=link;fs:="/nfs/ruby/nsnam" rayshon type:=link;fs:="/nfs/m_usr/rayshon" scadds type:=link;fs:="/nfs/gren/scadds" dragos type:=link;fs:="/nfs/isd/dragos" bester type:=link;fs:="/nfs/guest/bester" ojeil type:=link;fs:="/nfs/isd/ojeil" argos type:=link;fs:="/nfs/isd2/argos" tar type:=link;fs:="/nfs/topaz/tar" shengnan type:=link;fs:="/nfs/isd/shengnan" 10recept type:=link;fs:="/nfs/ivory/10recept" sudafed type:=link;fs:="/nfs/ruby/sudafed" mkramer type:=link;fs:="/nfs/v6/mkramer" macgreg type:=link;fs:="/nfs/div2/macgreg" acttest type:=link;fs:="/nfs/ipc/acttest" olomu type:=link;fs:="/nfs/v5/olomu" uucp type:=link;fs:="/var/spool/uucppublic" kemp type:=link;fs:="/nfs/div7/kemp" ravinder type:=link;fs:="/nfs/div1/ravinder" ershaghi type:=link;fs:="/nfs/div7/ershaghi" wormuth type:=link;fs:="/nfs/m_usr/wormuth" jaewook type:=link;fs:="/nfs/div1/jaewook" mmop type:=link;fs:="/nfs/conf/mmop" bob type:=link;fs:="/nfs/neon/bob" bin type:=link;fs:="/bin" linkscan type:=link;fs:="/nfs/m_app1/linkscan" vision type:=link;fs:="/nfs/div2/vision" karlcz type:=link;fs:="/nfs/guest/karlcz" ddavis type:=link;fs:="/nfs/div1/ddavis" tdey type:=link;fs:="/nfs/isd/tdey" purestat type:=link;fs:="/nfs/ipc/purestat" ora_dmkr type:=link;fs:="/nfs/div2/ora_dmkr" info-sys type:=link;fs:="/nfs/div7/info-sys" web-ict type:=link;fs:="/" tsacore type:=link;fs:="/nfs/asd/tsacore" isiuser type:=link;fs:="/nfs/share/isiuser" div1rpt type:=link;fs:="/nfs/neon/div1rpt" prober type:=link;fs:="/nfs/m_prb1/prober" braden type:=link;fs:="/nfs/gren/braden" pltfrm03 type:=link;fs:="/nfs/v6/pltfrm03" bkrishna type:=link;fs:="/nfs/gren/bkrishna" rs1test type:=link;fs:="/nfs/m_app1/rs1test" loomftp type:=link;fs:="/nfs/isd2/loomftp/loomftp" aridemo type:=link;fs:="/nfs/isd3/aridemo" sumitm type:=link;fs:="/nfs/div1/sumitm" dianee type:=link;fs:="/nfs/ipc/dianee" neven type:=link;fs:="/nfs/div2/neven" asyed type:=link;fs:="/nfs/guest/asyed" hmt type:=link;fs:="/nfs/ipc/hmt" gjthomas type:=link;fs:="/nfs/div7/gjthomas" philpot type:=link;fs:="/nfs/isd3/philpot" haldar type:=link;fs:="/nfs/ruby/haldar" e2e-mm type:=link;fs:="/nfs/ruby/e2e-mm" bbnrs1 type:=link;fs:="/nfs/m_app1/bbnrs1" sdlin type:=link;fs:="/nfs/isd2/sdlin" d7cnd type:=link;fs:="/nfs/gren/d7cnd" vahi type:=link;fs:="/nfs/asd2/vahi" tomw type:=link;fs:="/nfs/ipc/tomw" radu type:=link;fs:="/nfs/isd/radu" payroll type:=link;fs:="/nfs/ivory/payroll" lnxuser type:=link;fs:="/nfs/div1/lnxuser" gridcvs type:=link;fs:="/nfs/asd/gridcvs" imr-ed type:=link;fs:="/nfs/coms/imr-ed" bmoore type:=link;fs:="/nfs/isd/bmoore" mjtorres type:=link;fs:="/nfs/isd2/mjtorres" gritchey type:=link;fs:="/nfs/guest/gritchey" cinquini type:=link;fs:="/nfs/guest/cinquini" liyuan type:=link;fs:="/nfs/jade/liyuan" jsweet type:=link;fs:="/nfs/guest/jsweet" eromo type:=link;fs:="/nfs/ivory/eromo" dserv type:=link;fs:="/nfs/div2/dserv" hovy type:=link;fs:="/nfs/isd2/hovy" web-usrl type:=link;fs:="/" tryutov type:=link;fs:="/nfs/gren/tryutov" deelman type:=link;fs:="/nfs/asd/deelman" d7guest type:=link;fs:="/nfs/div7/d7guest" johnh type:=link;fs:="/nfs/gren/johnh" koda type:=link;fs:="/nfs/u2/koda" benc type:=link;fs:="/nfs/v6/benc" rim type:=link;fs:="/nfs/guest/rim" web-mos type:=link;fs:="/" leiding type:=link;fs:="/nfs/topaz/leiding" lindam type:=link;fs:="/nfs/ivory/lindam" joseph type:=link;fs:="/nfs/gren/joseph" dongho type:=link;fs:="/nfs/div7/dongho" fabio type:=link;fs:="/nfs/jade/fabio" crago type:=link;fs:="/nfs/guest/crago" june type:=link;fs:="/nfs/v6/june" d7unsupp type:=link;fs:="/nfs/gren/d7unsupp" jshetty type:=link;fs:="/nfs/guest/jshetty" allcock type:=link;fs:="/nfs/guest/allcock" web-bo type:=link;fs:="/" kapoor type:=link;fs:="/nfs/div7/kapoor" jordan type:=link;fs:="/nfs/asd/jordan" carley type:=link;fs:="/nfs/ivory/carley" rynge type:=link;fs:="/nfs/asd/rynge" puid1 type:=link;fs:="/none" svn type:=link;fs:="/nfs/jade/svn" jtb type:=link;fs:="/nfs/div1/jtb" beverlyh type:=link;fs:="/nfs/ivory/beverlyh" yuhe type:=link;fs:="/nfs/v6/yuhe" mote type:=link;fs:="/nfs/isd3/mote" dson type:=link;fs:="/nfs/guest/dson" ilt type:=link;fs:="/nfs/ivory/ilt" yuseonki type:=link;fs:="/nfs/guest/yuseonki" usdomreg type:=link;fs:="/nfs/coms/usdomreg" mulligan type:=link;fs:="/nfs/guest/mulligan" michelle type:=link;fs:="/nfs/guest/michelle" federico type:=link;fs:="/nfs/guest/federico" vernier type:=link;fs:="/nfs/m_usr/vernier" gregor type:=link;fs:="/nfs/guest/gregor" genew type:=link;fs:="/nfs/div1/genew" ecoe type:=link;fs:="/nfs/div7/ecoe" purchase type:=link;fs:="/nfs/ivory/purchase" pszekely type:=link;fs:="/nfs/div2/pszekely" imsuser type:=link;fs:="/" varunr type:=link;fs:="/nfs/isd/varunr" rfc-ed type:=link;fs:="/nfs/jade/rfc-ed" padmin type:=link;fs:="/nfs/ivory/padmin" globus type:=link;fs:="/nfs/asd2/globus" moody type:=link;fs:="/nfs/isd3/moody" tdw type:=link;fs:="/nfs/ipc/tdw" thiebaux type:=link;fs:="/nfs/asd/thiebaux" letstrav type:=link;fs:="/nfs/guest/letstrav" cristina type:=link;fs:="/nfs/asd2/cristina" umosis type:=link;fs:="/nfs/m_app1/umosis" moses type:=link;fs:="/nfs/ivory/moses" chris type:=link;fs:="/nfs/ipc/chris" zyda type:=link;fs:="/nfs/neon/zyda" ipgr type:=link;fs:="/nfs/infr/ipgr" jairmail type:=link;fs:="/nfs/isd3/jairmail" isiguest type:=link;fs:="/nfs/guest/isiguest" deschon type:=link;fs:="/nfs/jade/deschon" d3admin type:=link;fs:="/nfs/amber/d3admin" vgupta type:=link;fs:="/nfs/guest/vgupta" sheena type:=link;fs:="/nfs/isd2/sheena" tambe type:=link;fs:="/nfs/guest/tambe" mcai type:=link;fs:="/nfs/div2/mcai" rfl type:=link;fs:="/nfs/div1/rfl" cyl type:=link;fs:="/nfs/isd/cyl" dimitrap type:=link;fs:="/nfs/isd/dimitrap" web-usd type:=link;fs:="/" library type:=link;fs:="/nfs/ivory/library" icsuser type:=link;fs:="/" griphyn type:=link;fs:="/nfs/v5/griphyn" cmassey type:=link;fs:="/nfs/ipc/cmassey" victor type:=link;fs:="/nfs/isd2/victor" fredh type:=link;fs:="/nfs/ivory/fredh" tbds type:=link;fs:="/nfs/tufa/tbds" sys type:=link;fs:="/" etg type:=link;fs:="/nfs/amber/etg" hansford type:=link;fs:="/nfs/m_usr/hansford" pingali type:=link;fs:="/nfs/ruby/pingali" modtool type:=link;fs:="/nfs/cad10/modtool" rrios type:=link;fs:="/nfs/ivory/rrios" mikez type:=link;fs:="/nfs/ipc/mikez" meisi type:=link;fs:="/nfs/topaz/meisi" rich type:=link;fs:="/nfs/guest/rich" kyao type:=link;fs:="/nfs/eisd/kyao" sri type:=link;fs:="/nfs/isd3/sri" umdomreg type:=link;fs:="/nfs/ruby/umdomreg" vendors type:=link;fs:="/nfs/m_mod1/vendors" mdorosz type:=link;fs:="/nfs/div2/mdorosz" dktest type:=link;fs:="/nfs/gren/dktest" flhou type:=link;fs:="/nfs/isd/flhou" yamazaki type:=link;fs:="/nfs/div7/yamazaki" wordperf type:=link;fs:="/nfs/m_app1/wordperf" bedernik type:=link;fs:="/nfs/isd2/bedernik" jeanine type:=link;fs:="/nfs/div7/jeanine" cakers type:=link;fs:="/nfs/m_usr/cakers" divam type:=link;fs:="/nfs/asd/divam" jjg type:=link;fs:="/nfs/asd/jjg" michelso type:=link;fs:="/nfs/isd2/michelso" akanauka type:=link;fs:="/nfs/neon/akanauka" dominik type:=link;fs:="/nfs/ipc/dominik" bugacov type:=link;fs:="/nfs/guest/bugacov" condor type:=link;fs:="/nfs/v5/condor" helen type:=link;fs:="/nfs/m_usr/helen" chase type:=link;fs:="/nfs/asd/chase" rutu type:=link;fs:="/nfs/isd2/rutu" kary type:=link;fs:="/nfs/amber/kary" pvenugop type:=link;fs:="/nfs/div2/pvenugop" profiles type:=link;fs:="/local/profiles" nastaran type:=link;fs:="/nfs/div1/nastaran" ettelaie type:=link;fs:="/nfs/topaz/ettelaie" ambite type:=link;fs:="/nfs/amber/ambite" jiao type:=link;fs:="/nfs/ruby/jiao" qa type:=link;fs:="/nfs/m_app1/qa" szekely type:=link;fs:="/nfs/div2/szekely" ryarber type:=link;fs:="/nfs/ivory/ryarber" jessica type:=link;fs:="/nfs/ipc/jessica" crogers type:=link;fs:="/nfs/div2/crogers" xiangf type:=link;fs:="/nfs/v6/xiangf" allard type:=link;fs:="/nfs/div2/allard" meder type:=link;fs:="/nfs/guest/meder" --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="amd.removable" cdrom type:=cdfs;addopts:=ro,nocache;dev:=/dev/acd0 --gj572EiMnwbLXET9 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="amd.isi" etc wire==boreas-net.isi.edu;type:=nfs;rhost:=boreas;rfs:=/usr/share/etc; faber wire==boreas-net.isi.edu;type:=nfs;rhost:=boreas;rfs:=/home/faber; --gj572EiMnwbLXET9-- --4jXrM3lyYWu4nBt5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCl5XUaUz3f+Zf+XsRAkmHAKC52Xg3+DvdtVJzMDaykW2hVn9Q0ACdFiNS OIYBTk/qPlGzc6gZlTbyXfw= =moHK -----END PGP SIGNATURE----- --4jXrM3lyYWu4nBt5-- From owner-freebsd-current@FreeBSD.ORG Fri May 27 22:37:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 66C3216A41C; Fri, 27 May 2005 22:37:50 +0000 (GMT) (envelope-from antony.t.curtis@ntlworld.com) Received: from mta08-winn.mailhost.ntl.com (smtpout16.mailhost.ntl.com [212.250.162.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F18243D1F; Fri, 27 May 2005 22:37:48 +0000 (GMT) (envelope-from antony.t.curtis@ntlworld.com) Received: from aamta05-winn.mailhost.ntl.com ([212.250.162.8]) by mta08-winn.mailhost.ntl.com with ESMTP id <20050527223747.GDEP26549.mta08-winn.mailhost.ntl.com@aamta05-winn.mailhost.ntl.com>; Fri, 27 May 2005 23:37:47 +0100 Received: from pcgem.xiphis.org ([81.103.110.177]) by aamta05-winn.mailhost.ntl.com with ESMTP id <20050527223747.MYFQ8884.aamta05-winn.mailhost.ntl.com@pcgem.xiphis.org>; Fri, 27 May 2005 23:37:47 +0100 From: Antony T Curtis To: Dag-Erling =?ISO-8859-1?Q?Sm=F8rgrav?= In-Reply-To: <867jhlk9z5.fsf@xps.des.no> References: <20050522112612.GA37841@frontfree.net> <20050523003843.GO850@obiwan.tataz.chchile.org> <1116815005.838.3.camel@spirit> <1116999375.731.7.camel@spirit> <429468C3.5040207@centtech.com> <867jhlk9z5.fsf@xps.des.no> Content-Type: text/plain; charset=ISO-8859-1 Date: Fri, 27 May 2005 23:37:42 +0100 Message-Id: <1117233462.87322.9.camel@pcgem.xiphis.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.1.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: Xin LI , Eric Anderson , freebsd-current@freebsd.org, delphij@freebsd.org, Eric Kjeldergaard , Jeremie Le Hen Subject: Re: [CALL FOR TESTERS] VESA High Resolution Console support from DragonFly X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 22:37:50 -0000 On Thu, 2005-05-26 at 22:28 +0200, Dag-Erling Smørgrav wrote: > Eric Anderson writes: > > I noticed that changing to 16bit (instead of 32 or 24) helped a lot. > > ...because more pixels fit in a single 64 kB page, so the console code > doesn't have to switch pages as much while redrawing the screen. > Switching pages requires switching to virtual x86 mode (stalling the > CPU and invalidating the cache) to invoke the VESA BIOS. On graphic > adapters with linear framebuffer support (pretty much all of them > today), you can map the entire framebuffer into memory to avoid > paging, but our VESA driver doesn't know how to do that. Strange, I thought that the VESA driver did know how to do that. I recall years ago writing a driver for XFree86 3.3 which used the FreeBSD VESA driver to switch video mode and set up a linear frame buffer. I have even found the ancient email with it... http://listserver.uk.freebsd.org/pipermail/freebsd-users/2001-May/003629.html -- Antony T Curtis, BSc. UNIX, Linux, *BSD, Networking antony.t.curtis@ntlworld.com C++, J2EE, Perl, MySQL, Apache IT Consultancy. From owner-freebsd-current@FreeBSD.ORG Fri May 27 22:53:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 196E616A41C for ; Fri, 27 May 2005 22:53:34 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: from ox.eicat.ca (ox.eicat.ca [66.96.30.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id D54A943D1F for ; Fri, 27 May 2005 22:53:33 +0000 (GMT) (envelope-from dgilbert@daveg.ca) Received: by ox.eicat.ca (Postfix, from userid 66) id 9D346101E7; Fri, 27 May 2005 18:53:32 -0400 (EDT) Received: by canoe.dclg.ca (Postfix, from userid 101) id 4A43F1A08E1; Fri, 27 May 2005 18:53:30 -0400 (EDT) From: David Gilbert MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17047.42218.175565.975497@canoe.dclg.ca> Date: Fri, 27 May 2005 18:53:30 -0400 To: freebsd-current@freebsd.org X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Subject: ich4 recording. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 May 2005 22:53:34 -0000 With -CURRENT, I have the following probe line: pcm0: port 0xb800-0xb8ff,0xbc40-0xbc7f mem 0xf4fff800-0xf4fff9ff,0xf4fff400-0xf4fff4ff irq 9 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: ... when I try to record with audacity, I get nothing. when I run "mixer mic 75" ... I hear the mic input through the laptop speakers. Recording doesn't work still. mixer indicates that the recording source is 'mic' ... does ICH4 not record? Known bug? Dave. -- ============================================================================ |David Gilbert, Independent Contractor. | Two things can only be | |Mail: dave@daveg.ca | equal if and only if they | |http://daveg.ca | are precisely opposite. | =========================================================GLO================ From owner-freebsd-current@FreeBSD.ORG Sat May 28 09:39:41 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6B00516A41C for ; Sat, 28 May 2005 09:39:41 +0000 (GMT) (envelope-from emil@cs.rmit.edu.au) Received: from ppp162-47.static.internode.on.net (ppp162-47.static.internode.on.net [150.101.162.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3DEE43D48 for ; Sat, 28 May 2005 09:39:38 +0000 (GMT) (envelope-from emil@cs.rmit.edu.au) Received: by ppp162-47.static.internode.on.net (Poofix, from userid 1001) id 3BE3A6218; Sat, 28 May 2005 19:39:27 +1000 (EST) Date: Sat, 28 May 2005 19:39:27 +1000 From: Emil Mikulic To: freebsd-current@freebsd.org Message-ID: <20050528093927.GA75204@dmr.ath.cx> Mail-Followup-To: Emil Mikulic , freebsd-current@freebsd.org References: <20050522110627.GA48162@dmr.ath.cx> <1116770431.58707.6.camel@RabbitsDen> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1116770431.58707.6.camel@RabbitsDen> X-PGP-ID: 1024D/344A699F X-PGP-Fingerprint: EE97 2C84 6D07 E76C F075 C0BA ED2A 9319 344A 699F X-Written-On: dmr.ath.cx (FreeBSD 6.0-CURRENT i386) User-Agent: Mutt/1.5.9i Subject: Re: ath0 goes down periodically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 09:39:41 -0000 On Sun, May 22, 2005 at 10:00:31AM -0400, Alexandre Sunny Kovalenko wrote: > I have been observing similar behavior with my Atheros card when I > have neighboring station with the stronger signal then one from my > own. Over here I have never seen another SSID show up, and I very much doubt any of my neighbors have any WiFi gear. --Emil From owner-freebsd-current@FreeBSD.ORG Sat May 28 10:02:34 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A492D16A41C for ; Sat, 28 May 2005 10:02:34 +0000 (GMT) (envelope-from emil@cs.rmit.edu.au) Received: from ppp162-47.static.internode.on.net (ppp162-47.static.internode.on.net [150.101.162.47]) by mx1.FreeBSD.org (Postfix) with ESMTP id 23C0C43D48 for ; Sat, 28 May 2005 10:02:32 +0000 (GMT) (envelope-from emil@cs.rmit.edu.au) Received: by ppp162-47.static.internode.on.net (Poofix, from userid 1001) id B83F76218; Sat, 28 May 2005 20:02:19 +1000 (EST) Date: Sat, 28 May 2005 20:02:19 +1000 From: Emil Mikulic To: Sam Leffler Message-ID: <20050528100219.GC75204@dmr.ath.cx> Mail-Followup-To: Emil Mikulic , Sam Leffler , freebsd-current@freebsd.org References: <20050522110627.GA48162@dmr.ath.cx> <4290B89E.1040107@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4290B89E.1040107@errno.com> X-PGP-ID: 1024D/344A699F X-PGP-Fingerprint: EE97 2C84 6D07 E76C F075 C0BA ED2A 9319 344A 699F X-Written-On: dmr.ath.cx (FreeBSD 6.0-CURRENT i386) User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org Subject: Re: ath0 goes down periodically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 10:02:34 -0000 On Sun, May 22, 2005 at 09:51:42AM -0700, Sam Leffler wrote: > Emil Mikulic wrote: > >At home I have a FreeBSD 6-CURRENT machine with an ath card acting as > >an access point. Every once in a while, wireless traffic stops and I > >have to log in to this machine and manually bounce the interface to > >get it going again. > > When this happens can you see beacons being xmit'd by the ap? Also > the output of athstats (src/tools/tools/ath) may be useful. As well as the AP machine, I have a FreeBSD 5-STABLE machine upstairs which is a WiFi client. On which machine do you want me to turn debugging on, and which flags? I've played around with /usr/src/tools/tools/ath/athdebug.c and /usr/src/tools/tools/ath/80211debug.c before. What I remember is: - using one of the two tools to set some some flag lets me see beacons =) - not to turn on certain flags on the AP machine since it has a serial console and the flood of debugging output makes it grind to a halt =/ Is there an easy way around this? Or do I only need to watch for beacons on the client machine? --Emil From owner-freebsd-current@FreeBSD.ORG Sat May 28 12:21:32 2005 Return-Path: X-Original-To: freebsd-current@FreeBSD.org Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 612A516A432 for ; Sat, 28 May 2005 12:21:32 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from hood.oook.cz (hood.oook.cz [212.27.205.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7206743D4C for ; Sat, 28 May 2005 12:21:31 +0000 (GMT) (envelope-from pav@FreeBSD.org) Received: from hood.oook.cz (localhost.oook.cz [127.0.0.1]) by hood.oook.cz (8.13.3/8.13.3) with ESMTP id j4SCLHf1091312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 May 2005 14:21:17 +0200 (CEST) (envelope-from pav@FreeBSD.org) Received: (from pav@localhost) by hood.oook.cz (8.13.3/8.13.3/Submit) id j4SCLGin091311; Sat, 28 May 2005 14:21:16 +0200 (CEST) (envelope-from pav@FreeBSD.org) X-Authentication-Warning: hood.oook.cz: pav set sender to pav@FreeBSD.org using -f From: Pav Lucistnik To: David Gilbert In-Reply-To: <17047.42218.175565.975497@canoe.dclg.ca> References: <17047.42218.175565.975497@canoe.dclg.ca> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0ko82Q65b6G6XJaDVRO8" Date: Sat, 28 May 2005 14:21:16 +0200 Message-Id: <1117282876.24044.19.camel@hood.oook.cz> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Cc: freebsd-current@FreeBSD.org Subject: Re: ich4 recording. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pav@FreeBSD.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 12:21:32 -0000 --=-0ko82Q65b6G6XJaDVRO8 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable David Gilbert p=ED=B9e v p=E1 27. 05. 2005 v 18:53 -0400: > With -CURRENT, I have the following probe line: >=20 > pcm0: port 0xb800-0xb8ff,0xbc40-0xbc7f mem 0xf4fff= 800-0xf4fff9ff,0xf4fff400-0xf4fff4ff irq 9 at device 31.5 on pci0 > pcm0: [GIANT-LOCKED] > pcm0: >=20 > ... when I try to record with audacity, I get nothing. >=20 > when I run "mixer mic 75" ... I hear the mic input through the laptop > speakers. Recording doesn't work still. >=20 > mixer indicates that the recording source is 'mic' ... >=20 > does ICH4 not record? Known bug? And mixer rec is set to non-zero volume? --=20 Pav Lucistnik And please, please, please add COMMENTS to your code. Reading uncommented PERL is like chewing on chunks of broken glass, only without the tasty blood sauce to go with it. -- John Rowan in rec.games.roguelike.adom --=-0ko82Q65b6G6XJaDVRO8 Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCmGI8ntdYP8FOsoIRAgO0AJwOlnoNAOzblYRyjtclRos76Vex1QCfTojL 8VQxrCYVuviiCbvYCeOEAio= =IBO7 -----END PGP SIGNATURE----- --=-0ko82Q65b6G6XJaDVRO8-- From owner-freebsd-current@FreeBSD.ORG Sat May 28 15:22:17 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 39A2616A422 for ; Sat, 28 May 2005 15:22:17 +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 724FF43D1D for ; Sat, 28 May 2005 15:22:13 +0000 (GMT) (envelope-from doconnor@gsoft.com.au) Received: from inchoate.gsoft.com.au (localhost [127.0.0.1]) (authenticated bits=0) by cain.gsoft.com.au (8.12.11/8.12.10) with ESMTP id j4SFLiBo072796; Sun, 29 May 2005 00:51:44 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sun, 29 May 2005 00:51:17 +0930 User-Agent: KMail/1.8 References: <17047.42218.175565.975497@canoe.dclg.ca> In-Reply-To: <17047.42218.175565.975497@canoe.dclg.ca> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3175149.vSiUUxi95d"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200505290051.37736.doconnor@gsoft.com.au> X-Spam-Score: -2.5 () IN_REP_TO, PGP_SIGNATURE_2, QUOTED_EMAIL_TEXT, REFERENCES, SPAM_PHRASE_00_01, USER_AGENT X-Scanned-By: MIMEDefang 2.16 (www . roaringpenguin . com / mimedefang) Cc: David Gilbert Subject: Re: ich4 recording. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 15:22:17 -0000 --nextPart3175149.vSiUUxi95d Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sat, 28 May 2005 08:23, David Gilbert wrote: > pcm0: port 0xb800-0xb8ff,0xbc40-0xbc7f mem > 0xf4fff800-0xf4fff9ff,0xf4fff400-0xf4fff4ff irq 9 at device 31.5 on pci0 > ... when I try to record with audacity, I get nothing. > > when I run "mixer mic 75" ... I hear the mic input through the laptop > speakers. Recording doesn't work still. > > mixer indicates that the recording source is 'mic' ... > > does ICH4 not record? Known bug? I have *exactly* the same chipset and it seems to work fine. I just did a test recording with Audacity from the built in mic of my lapto= p=20 (Audacity set the recording source). It's in a Dell Inspiron 8600. =09 =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 --nextPart3175149.vSiUUxi95d Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCmIyB5ZPcIHs/zowRAhEZAJ9Vo+29A8oghkSfc0G0AT3gYjv5rgCeN58l D/M8KNMbt0KdkpvSSjdpOCE= =4xbJ -----END PGP SIGNATURE----- --nextPart3175149.vSiUUxi95d-- From owner-freebsd-current@FreeBSD.ORG Sat May 28 15:31:59 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7B22D16A41C for ; Sat, 28 May 2005 15:31:59 +0000 (GMT) (envelope-from kuku@www.kukulies.org) Received: from www.kukulies.org (www.kukulies.org [213.146.112.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id C2CAF43D1F for ; Sat, 28 May 2005 15:31:58 +0000 (GMT) (envelope-from kuku@www.kukulies.org) Received: from www.kukulies.org (localhost [127.0.0.1]) by www.kukulies.org (8.13.1/8.12.10) with ESMTP id j4SFVuWA080091 for ; Sat, 28 May 2005 17:31:56 +0200 (CEST) (envelope-from kuku@www.kukulies.org) Received: (from kuku@localhost) by www.kukulies.org (8.13.1/8.12.10/Submit) id j4SFVtxi080090 for freebsd-current@freebsd.org; Sat, 28 May 2005 17:31:55 +0200 (CEST) (envelope-from kuku) Date: Sat, 28 May 2005 17:31:55 +0200 From: "Christoph P. Kukulies" To: freebsd-current@freebsd.org Message-ID: <20050528153155.GA75114@kukulies.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: .depend line 264: Inconsistent operator for ipf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 15:31:59 -0000 After cvsupping into a 6.0-current of January 2005 and a subsequent make buildworld I'm getting the following in the cleandir phase: rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/init (cleandir) rm -f init init.o init.8.gz init.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ip6fw (cleandir) rm -f ip6fw ip6fw.o ip6fw.8.gz ip6fw.8.cat.gz rm -f .depend GPATH GRTAGS GSYMS GTAGS ===> sbin/ipf (cleandir) ".depend", line 264: Inconsistent operator for ipf make: fatal errors encountered -- cannot continue *** Error code 1 Stop in /usr/src/sbin. *** Error code 1 Stop in /usr/src. ... -- Chris Christoph P. U. Kukulies kuku_at_kukulies.org From owner-freebsd-current@FreeBSD.ORG Sat May 28 16:34:58 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E873516A41F for ; Sat, 28 May 2005 16:34:58 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.208.78.105]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BC0D43FBD for ; Sat, 28 May 2005 15:50:27 +0000 (GMT) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (localhost [127.0.0.1]) by troutmask.apl.washington.edu (8.13.3/8.13.1) with ESMTP id j4SFoQGW012957; Sat, 28 May 2005 08:50:26 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.3/8.13.1/Submit) id j4SFoQGQ012956; Sat, 28 May 2005 08:50:26 -0700 (PDT) (envelope-from sgk) Date: Sat, 28 May 2005 08:50:26 -0700 From: Steve Kargl To: "Christoph P. Kukulies" Message-ID: <20050528155026.GA12941@troutmask.apl.washington.edu> References: <20050528153155.GA75114@kukulies.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050528153155.GA75114@kukulies.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: .depend line 264: Inconsistent operator for ipf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 16:34:59 -0000 On Sat, May 28, 2005 at 05:31:55PM +0200, Christoph P. Kukulies wrote: > ===> sbin/ipf (cleandir) > ".depend", line 264: Inconsistent operator for ipf > make: fatal errors encountered -- cannot continue > *** Error code 1 > make cleandepend -- Steve From owner-freebsd-current@FreeBSD.ORG Sat May 28 16:36:55 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 78D2B16A421 for ; Sat, 28 May 2005 16:36:55 +0000 (GMT) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (tourist.net8.nerim.net [213.41.176.3]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0674F43E49 for ; Sat, 28 May 2005 16:04:46 +0000 (GMT) (envelope-from amon@sockar.homeip.net) Received: from sockar.homeip.net (localhost [127.0.0.1]) by sockar.homeip.net (8.13.3/8.13.3) with ESMTP id j4SG4eKP024976 for ; Sat, 28 May 2005 18:04:40 +0200 (CEST) (envelope-from amon@sockar.homeip.net) Received: (from amon@localhost) by sockar.homeip.net (8.13.3/8.13.3/Submit) id j4SG4dh6024975 for freebsd-current@freebsd.org; Sat, 28 May 2005 18:04:39 +0200 (CEST) (envelope-from amon) Date: Sat, 28 May 2005 18:04:39 +0200 From: Herve Boulouis To: freebsd-current@freebsd.org Message-ID: <20050528160439.GA81706@ra.aabs> References: <42960F8F.2050109@samsco.org> <42961195.30608@centtech.com> <429613FB.80100@samsco.org> <42968AD4.3020603@centtech.com> <4296997C.9030700@samsco.org> <20050526235852.M54386@lexi.siliconlandmark.com> <42969C1B.5010301@samsco.org> <20050527092544.GB18696@cirb503493.alcatel.com.au> <4C7F0B94-4D12-41A3-9A61-C3B620804671@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=unknown-8bit Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4C7F0B94-4D12-41A3-9A61-C3B620804671@mac.com> User-Agent: Mutt/1.4.2.1i Subject: Re: Disable read/write caching to disk? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 16:36:55 -0000 Le 27/05/2005 13:09, Charles Swiger a écrit: > > >Solaris clustering routes all I/O to a shared filesystem to a single > >'master' node, which is responsible for all physical I/O to the disk. > >This would significantly simplify cache coherency management. > > Apple's Xsan clustering solution relies on a so-called "metadata > controller", which keeps track of locking and provides syncronization > and invalidation notification when the filesystem metadata changes. > SAN clients still read the actual file data directly via fibre > channel, but they also need IP-level connectivity via ethernet (an > unroutable LAN is fine) to the MDC. SGI's CXFS works exactly the same way. The metadata server (one per filesystem) is accessed through an ip network and data are accessed through the SAN. I suppose that the journaling capabilities of XFS are used to do the metadata server's work but I'm not sure. -- Herve Boulouis From owner-freebsd-current@FreeBSD.ORG Sat May 28 16:45:50 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A4EDF16A420 for ; Sat, 28 May 2005 16:45:50 +0000 (GMT) (envelope-from kuku@www.kukulies.org) Received: from www.kukulies.org (www.kukulies.org [213.146.112.180]) by mx1.FreeBSD.org (Postfix) with ESMTP id 13D7B443D3 for ; Sat, 28 May 2005 16:29:32 +0000 (GMT) (envelope-from kuku@www.kukulies.org) Received: from www.kukulies.org (localhost [127.0.0.1]) by www.kukulies.org (8.13.1/8.12.10) with ESMTP id j4SGTTxu086613; Sat, 28 May 2005 18:29:29 +0200 (CEST) (envelope-from kuku@www.kukulies.org) Received: (from kuku@localhost) by www.kukulies.org (8.13.1/8.12.10/Submit) id j4SGTSli086612; Sat, 28 May 2005 18:29:28 +0200 (CEST) (envelope-from kuku) Date: Sat, 28 May 2005 18:29:28 +0200 From: "Christoph P. Kukulies" To: Steve Kargl Message-ID: <20050528162928.GA85305@kukulies.org> References: <20050528153155.GA75114@kukulies.org> <20050528155026.GA12941@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050528155026.GA12941@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.1i Cc: freebsd-current@freebsd.org Subject: Re: .depend line 264: Inconsistent operator for ipf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 16:45:50 -0000 On Sat, May 28, 2005 at 08:50:26AM -0700, Steve Kargl wrote: > On Sat, May 28, 2005 at 05:31:55PM +0200, Christoph P. Kukulies wrote: > > ===> sbin/ipf (cleandir) > > ".depend", line 264: Inconsistent operator for ipf > > make: fatal errors encountered -- cannot continue > > *** Error code 1 > > > > make cleandepend That doesn't help either. Same picture. -- Chris Christoph P. U. Kukulies kuku_at_kukulies.org From owner-freebsd-current@FreeBSD.ORG Sat May 28 18:05:15 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AA28016A41C for ; Sat, 28 May 2005 18:05:15 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received: from mp2.macomnet.net (mp2.macomnet.net [195.128.64.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1794343D48 for ; Sat, 28 May 2005 18:05:14 +0000 (GMT) (envelope-from maxim@macomnet.ru) Received-SPF: pass (mp2.macomnet.net: domain of maxim@macomnet.ru designates 127.0.0.1 as permitted sender) receiver=mp2.macomnet.net; client_ip=127.0.0.1; envelope-from=maxim@macomnet.ru; Received: from localhost (localhost [127.0.0.1]) by mp2.macomnet.net (8.12.11/8.12.11) with ESMTP id j4SI5CsN027136; Sat, 28 May 2005 22:05:12 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Sat, 28 May 2005 22:05:12 +0400 (MSD) From: Maxim Konovalov To: "Christoph P. Kukulies" In-Reply-To: <20050528162928.GA85305@kukulies.org> Message-ID: <20050528220437.V14963@mp2.macomnet.net> References: <20050528153155.GA75114@kukulies.org> <20050528155026.GA12941@troutmask.apl.washington.edu> <20050528162928.GA85305@kukulies.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: .depend line 264: Inconsistent operator for ipf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 18:05:15 -0000 On Sat, 28 May 2005, 18:29+0200, Christoph P. Kukulies wrote: > On Sat, May 28, 2005 at 08:50:26AM -0700, Steve Kargl wrote: > > On Sat, May 28, 2005 at 05:31:55PM +0200, Christoph P. Kukulies wrote: > > > ===> sbin/ipf (cleandir) > > > ".depend", line 264: Inconsistent operator for ipf > > > make: fatal errors encountered -- cannot continue > > > *** Error code 1 > > > > > > > make cleandepend > > That doesn't help either. Same picture. Could you show ls -l /usr/src/sbin/ipf/ -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Sat May 28 18:08:43 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3E03316A41F for ; Sat, 28 May 2005 18:08:43 +0000 (GMT) (envelope-from sam@errno.com) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id A7E0643D4C for ; Sat, 28 May 2005 18:08:42 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.90] ([66.127.85.90]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j4SI8Xms077746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 28 May 2005 11:08:33 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <4298B3A9.9050906@errno.com> Date: Sat, 28 May 2005 11:08:41 -0700 From: Sam Leffler Organization: Errno Consulting User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Emil Mikulic References: <20050522110627.GA48162@dmr.ath.cx> <4290B89E.1040107@errno.com> <20050528100219.GC75204@dmr.ath.cx> In-Reply-To: <20050528100219.GC75204@dmr.ath.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: ath0 goes down periodically X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 18:08:43 -0000 Emil Mikulic wrote: > On Sun, May 22, 2005 at 09:51:42AM -0700, Sam Leffler wrote: > >>Emil Mikulic wrote: >> >>>At home I have a FreeBSD 6-CURRENT machine with an ath card acting as >>>an access point. Every once in a while, wireless traffic stops and I >>>have to log in to this machine and manually bounce the interface to >>>get it going again. >> >>When this happens can you see beacons being xmit'd by the ap? Also >>the output of athstats (src/tools/tools/ath) may be useful. > > > As well as the AP machine, I have a FreeBSD 5-STABLE machine upstairs > which is a WiFi client. On which machine do you want me to turn debugging > on, and which flags? > > I've played around with /usr/src/tools/tools/ath/athdebug.c and > /usr/src/tools/tools/ath/80211debug.c before. > > What I remember is: > > - using one of the two tools to set some some flag lets me see beacons > =) > > - not to turn on certain flags on the AP machine since it has a serial > console and the flood of debugging output makes it grind to a halt > =/ > > Is there an easy way around this? Or do I only need to watch for > beacons on the client machine? I thought you had a machine using the ath driver and acting as an ap. You said periodically that machine would stop operating correctly and you had to mark the interface down+up to revive it. Assuming this I said, when the machine acting as an ap stops working can you see still see beacon frames being transmitted? To do this you need to have another machine. If the other machine is a client to the ap and using an ath card then 80211stats should show the count of beacon frames processed growing. Otherwise you can use tcpdump on the other machine to see beacon frames using something like: tcpdump -i ath0 -y IEEE802_11 or if it's not any ath card then you may need to do something different. If your problem is that the ap stops broadcasting beacons then all data frames will backup behind because normal data frames are queued on a different h/w tx queue that will be blocked by the inability to xmit the beacon frames. This condition is usually described as the "stuck beacon problem". I have a fix for this problem that I haven't committed yet. Sam From owner-freebsd-current@FreeBSD.ORG Sat May 28 21:47:37 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9285716A41C for ; Sat, 28 May 2005 21:47:37 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from ms-smtp-03-eri0.southeast.rr.com (ms-smtp-03-lbl.southeast.rr.com [24.25.9.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3355E43D49 for ; Sat, 28 May 2005 21:47:36 +0000 (GMT) (envelope-from morganw@chemikals.org) Received: from volatile.chemikals.org (cpe-024-211-118-154.sc.res.rr.com [24.211.118.154]) by ms-smtp-03-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j4SLlXY4028783; Sat, 28 May 2005 17:47:33 -0400 (EDT) Received: from volatile.chemikals.org (morganw@localhost [127.0.0.1]) by volatile.chemikals.org (8.13.3/8.13.3) with ESMTP id j4SLleWv025504; Sat, 28 May 2005 17:47:40 -0400 (EDT) (envelope-from morganw@chemikals.org) Received: from localhost (morganw@localhost) by volatile.chemikals.org (8.13.3/8.13.3/Submit) with ESMTP id j4SLleLX025501; Sat, 28 May 2005 17:47:40 -0400 (EDT) (envelope-from morganw@chemikals.org) X-Authentication-Warning: volatile.chemikals.org: morganw owned process doing -bs Date: Sat, 28 May 2005 17:47:40 -0400 (EDT) From: Wesley Morgan To: "Christoph P. Kukulies" In-Reply-To: <20050528162928.GA85305@kukulies.org> Message-ID: <20050528174641.T25345@volatile.chemikals.org> References: <20050528153155.GA75114@kukulies.org> <20050528155026.GA12941@troutmask.apl.washington.edu> <20050528162928.GA85305@kukulies.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: freebsd-current@freebsd.org, Steve Kargl Subject: Re: .depend line 264: Inconsistent operator for ipf X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 May 2005 21:47:37 -0000 On Sat, 28 May 2005, Christoph P. Kukulies wrote: > On Sat, May 28, 2005 at 08:50:26AM -0700, Steve Kargl wrote: >> On Sat, May 28, 2005 at 05:31:55PM +0200, Christoph P. Kukulies wrote: >>> ===> sbin/ipf (cleandir) >>> ".depend", line 264: Inconsistent operator for ipf >>> make: fatal errors encountered -- cannot continue >>> *** Error code 1 >>> >> >> make cleandepend > > That doesn't help either. Same picture. Try either rm -rf your /usr/obj or go into /usr/src/sbin/ipf and do make cleandir twice. -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!