From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 01:33: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 90D0916A41C for ; Sun, 12 Jun 2005 01:33:19 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3D9AA43D4C for ; Sun, 12 Jun 2005 01:33:19 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5C1XIKX032143; Sat, 11 Jun 2005 18:33:18 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5C1XHbX032141; Sat, 11 Jun 2005 18:33:17 -0700 Date: Sat, 11 Jun 2005 18:33:17 -0700 From: Brooks Davis To: Brooks Davis Message-ID: <20050612013317.GA31782@odin.ac.hmc.edu> References: <20050610221017.GB17775@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="0OAP2g/MAC+5xKAE" Content-Disposition: inline In-Reply-To: <20050610221017.GB17775@odin.ac.hmc.edu> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@freebsd.org Subject: FIXED Re: WARNING: current unstable 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, 12 Jun 2005 01:33:19 -0000 --0OAP2g/MAC+5xKAE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 10, 2005 at 03:10:17PM -0700, Brooks Davis wrote: > It looks like my test systems were running some of the few drivers that > aren't suffering from a very strange bug. You may wish to avoid > updating. I'm investigating, but so far, nothing makes much sense. :( I've fixed the bugs I know about (MII-bus drivers, IPv6 neighbor discovery, and leaking ifnets). -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --0OAP2g/MAC+5xKAE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCq5DKXY6L6fI4GtQRAgyLAJ95zIRkVXcg/CVxTfVqb8Cv2U/PEwCg0Afi hDsJEKyeWgaE40jtlDmxSqU= =NgNr -----END PGP SIGNATURE----- --0OAP2g/MAC+5xKAE-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 01:54: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 6BD7316A41C for ; Sun, 12 Jun 2005 01:54:19 +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 308A343D1F for ; Sun, 12 Jun 2005 01:54:18 +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 j5C1sCgV067812; Sat, 11 Jun 2005 18:54:12 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5C1sC16067810; Sat, 11 Jun 2005 18:54:12 -0700 (PDT) (envelope-from obrien) Date: Sat, 11 Jun 2005 18:54:12 -0700 From: "David O'Brien" To: Kevin Oberman Message-ID: <20050612015412.GA67746@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, Kevin Oberman , Randy Bush References: <17061.50409.445735.361770@roam.psg.com> <20050607183512.9D8025D07@ptavv.es.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050607183512.9D8025D07@ptavv.es.net> 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: Randy Bush , freebsd-current@freebsd.org Subject: Re: HEADSUP: OpenBSD dhclient incoming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: Sun, 12 Jun 2005 01:54:19 -0000 On Tue, Jun 07, 2005 at 11:35:12AM -0700, Kevin Oberman wrote: > > not an issue. due to roaming etc. i start dh* myself. and i hope > > one day to go more vanilla, so thanks for making good ice cream! > > Randy, > > Have you looked at Tobias Roth's profile tool. You can find it at: > https://projects.fsck.ch/profile > > It's a very nice tool that I hope will make it into the base system > some day. We could adapt src/etc/rc.d/bootconf.sh to FreeBSD and bring in NetBSD's newbtconf(8). -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 02:21: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 C511916A41C; Sun, 12 Jun 2005 02:21:13 +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 65BFA43D1D; Sun, 12 Jun 2005 02:21:13 +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 j5C2L6EY068340; Sat, 11 Jun 2005 19:21:06 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5C2L5OU068339; Sat, 11 Jun 2005 19:21:05 -0700 (PDT) (envelope-from obrien) Date: Sat, 11 Jun 2005 19:21:05 -0700 From: "David O'Brien" To: Ruslan Ermilov Message-ID: <20050612022105.GB67746@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ruslan Ermilov , Dag-Erling Sm?rgrav , freebsd-current@freebsd.org References: <20050609234619.AD1F67306E@freebsd-current.sentex.ca> <84dead720506091950779d1661@mail.gmail.com> <86oeae3d8f.fsf@xps.des.no> <20050610071828.GB78035@ip.net.ua> <867jh23bwh.fsf@xps.des.no> <20050610074706.GE78035@ip.net.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050610074706.GE78035@ip.net.ua> 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: Dag-Erling Sm?rgrav , freebsd-current@freebsd.org Subject: Re: [current tinderbox] failure on ...all... 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: Sun, 12 Jun 2005 02:21:13 -0000 On Fri, Jun 10, 2005 at 10:47:06AM +0300, Ruslan Ermilov wrote: > On Fri, Jun 10, 2005 at 09:32:14AM +0200, Dag-Erling Sm?rgrav wrote: > > Ruslan Ermilov writes: > > > And if you feel that -fno-strict-aliasing is evil, why not dike it > > > out from sys.mk? > > > > 'ncvs annotate /usr/src/share/mk/sys/mk | grep aliasing' and you'll > > realize that any attempt to touch it would result in a huge flamewar. > > > I don't see a flamewar, only the mention that it breaks some notable > ports. If it's not suitable for ports, then we should invent a mean > to compile only src/ *without* -fno-strict-aliasing. I tried. But Kris refused to consider the following for committing. The problem is something like 3 ports will not build with "-fno-strict-aliasing". Those are the gcc28, gnat[*] ports. [*] I really don't understand why we have a GCC 2.8 based Ada compiler when Ada has been a native part of GCC since version 3.1... -- -- David (obrien@FreeBSD.org) Index: bsd.port.mk =================================================================== RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v retrieving revision 1.512 diff -u -r1.512 bsd.port.mk --- bsd.port.mk 9 Jun 2005 20:39:43 -0000 1.512 +++ bsd.port.mk 11 Jun 2005 14:38:58 -0000 @@ -1396,6 +1402,11 @@ .endif .endif .endif +.if ${CFLAGS:M-O[23s]} != "" +.if !defined(WITHOUT_NO_STRICT_ALIASING) +CFLAGS+= -fno-strict-aliasing +.endif +.endif .if defined(NOPORTDOCS) PLIST_SUB+= PORTDOCS="@comment " From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 02:49:39 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 B56EB16A41C; Sun, 12 Jun 2005 02:49:39 +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 C715743D48; Sun, 12 Jun 2005 02:49:36 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 85FC45123D; Sat, 11 Jun 2005 22:49:23 -0400 (EDT) Date: Sat, 11 Jun 2005 22:49:22 -0400 From: Kris Kennaway To: obrien@freebsd.org, Ruslan Ermilov , Dag-Erling Sm?rgrav , freebsd-current@freebsd.org Message-ID: <20050612024922.GA57913@xor.obsecurity.org> References: <20050609234619.AD1F67306E@freebsd-current.sentex.ca> <84dead720506091950779d1661@mail.gmail.com> <86oeae3d8f.fsf@xps.des.no> <20050610071828.GB78035@ip.net.ua> <867jh23bwh.fsf@xps.des.no> <20050610074706.GE78035@ip.net.ua> <20050612022105.GB67746@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="lrZ03NoBR/3+SXJZ" Content-Disposition: inline In-Reply-To: <20050612022105.GB67746@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: [current tinderbox] failure on ...all... 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, 12 Jun 2005 02:49:39 -0000 --lrZ03NoBR/3+SXJZ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 11, 2005 at 07:21:05PM -0700, David O'Brien wrote: > On Fri, Jun 10, 2005 at 10:47:06AM +0300, Ruslan Ermilov wrote: > > On Fri, Jun 10, 2005 at 09:32:14AM +0200, Dag-Erling Sm?rgrav wrote: > > > Ruslan Ermilov writes: > > > > And if you feel that -fno-strict-aliasing is evil, why not dike it > > > > out from sys.mk? > > >=20 > > > 'ncvs annotate /usr/src/share/mk/sys/mk | grep aliasing' and you'll > > > realize that any attempt to touch it would result in a huge flamewar. > > >=20 > > I don't see a flamewar, only the mention that it breaks some notable > > ports. If it's not suitable for ports, then we should invent a mean > > to compile only src/ *without* -fno-strict-aliasing. >=20 > I tried. But Kris refused to consider the following for committing. > The problem is something like 3 ports will not build with > "-fno-strict-aliasing". Those are the gcc28, gnat[*] ports. No, I was waiting for you to provide the patch that has zero net damage, i.e. which fixes those 3 ports and leaves nothing broken for someone else to clean up. Kris --lrZ03NoBR/3+SXJZ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCq6KyWry0BWjoQKURAn5BAKD3qD4ZEKtsgAO6d2nvj7qHHhAWbACg0d16 7+1YRU5bHM3n2a+yUVsUX5c= =mtyC -----END PGP SIGNATURE----- --lrZ03NoBR/3+SXJZ-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 03:36: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 E981716A41C; Sun, 12 Jun 2005 03:36:22 +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 A5A8C43D49; Sun, 12 Jun 2005 03:36:22 +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 j5C3aLTm070569; Sat, 11 Jun 2005 20:36:21 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5C3aGpd070568; Sat, 11 Jun 2005 20:36:16 -0700 (PDT) (envelope-from obrien) Date: Sat, 11 Jun 2005 20:36:16 -0700 From: "David O'Brien" To: Slawa Olhovchenkov Message-ID: <20050612033616.GE67746@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Slawa Olhovchenkov , Scott Long , hackers@freebsd.org, 'FreeBSD Current' References: <42A11C92.5050505@samsco.org> <20050605200233.GA38531@zxy.spb.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050605200233.GA38531@zxy.spb.ru> 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: hackers@freebsd.org, 'FreeBSD Current' Subject: Re: HEADS UP! 6.0 Schedule, 6.0-CURRENT Snapshot 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: Sun, 12 Jun 2005 03:36:23 -0000 On Mon, Jun 06, 2005 at 12:02:33AM +0400, Slawa Olhovchenkov wrote: > On Fri, Jun 03, 2005 at 09:14:26PM -0600, Scott Long wrote: > > > All, > > > > The long anticipated and much feared 6.0 code freeze is about to begin! > > I'll cut to the chase: > > > > June 10 - Feature freeze + code slush > > ^^^^^^^ > > > > July 10 - RELENG_6 branch > > August 1 - RELENG_6_0 branch > > August 15 - 6.0-RELEASE > > Nice time for compat5x? Yes, it will be there. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 03:54: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 F232616A41F; Sun, 12 Jun 2005 03:54:45 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5687743D48; Sun, 12 Jun 2005 03:54:45 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.12.11/8.12.11) with ESMTP id j5C3siTO021294; Sat, 11 Jun 2005 21:54:44 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.12.11/8.12.5/Submit) id j5C3seJv021293; Sat, 11 Jun 2005 21:54:40 -0600 (MDT) (envelope-from ken) Date: Sat, 11 Jun 2005 21:54:40 -0600 From: "Kenneth D. Merry" To: "Raphael H. Becker" Message-ID: <20050612035440.GA21262@nargothrond.kdm.org> References: <20050608152459.BF24E16A45C@hub.freebsd.org> <1118248386.7479.10.camel@zappa.Chelsea-Ct.Org> <20050608171130.GA64736@over-yonder.net> <1118252322.7479.28.camel@zappa.Chelsea-Ct.Org> <20050609113616.I41471@p-i-n.com> <20050609130511.GA732@uk.tiscali.com> <20050610162814.A25098@p-i-n.com> <20050610150718.GA7005@nargothrond.kdm.org> <20050612002508.B25098@p-i-n.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050612002508.B25098@p-i-n.com> User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.85.1/925/Sat Jun 11 12:55:32 2005 on nargothrond.kdm.org X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: Accessing SCSI-Devices >2TB 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, 12 Jun 2005 03:54:46 -0000 On Sun, Jun 12, 2005 at 00:25:08 +0200, Raphael H. Becker wrote: > On Fri, Jun 10, 2005 at 09:07:18AM -0600, Kenneth D. Merry wrote: > > > > and here the relevant diffs: > > > http://rabe.uugrn.org/temp/FreeBSD/bigraid/dmesg.knoppix_diff.txt > > > > This is quite interesting: > [....] > > Linux notices that the device returned 0xffffffff as the capacity in > > response to a READ CAPACITY(10) command, so it tries a READ CAPACITY(16) > > command, which *fails*. > > > > So even under Linux you aren't getting the full capacity of your device, > > you're only getting 2TB. > > The support told me, SuSE Linux is known to work with >2TB in one device, > means they might have some patches to work around. I will try a SuSE > live system next days just to get sure it works. But the System won't > be SuSE in future. It would be interesting to see whether that works. That would help narrow down the problem slightly. > > > Second I rebooted FreeBSD with CAMDEBUG in kernel and enabled it via > > > "camcontrol debug ..." and did a "camcontrol rescan 1" then: > > > http://rabe.uugrn.org/temp/FreeBSD/bigraid/freebsd54_camdebug.txt > > > > camcontrol debug -I isn't quite what we need in this situation. Instead, > > you should try 'camcontrol debug -c'. > > # camcontrol debug -c 1:0 > # camcontrol rescan 1 > Re-scan of bus 1 was successful > > in /var/log/messages: > > kernel: (probe0:ahc1:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > kernel: (probe0:ahc1:0:0:0): INQUIRY. CDB: 12 0 0 0 24 0 > kernel: (probe0:ahc1:0:0:0): INQUIRY. CDB: 12 0 0 0 fc 0 > kernel: (probe0:ahc1:0:0:0): MODE SENSE(06). CDB: 1a 0 a 0 14 0 > kernel: (probe0:ahc1:0:0:0): INQUIRY. CDB: 12 1 80 0 ff 0 > kernel: (probe0:ahc1:0:0:1): INQUIRY. CDB: 12 20 0 0 24 0 > kernel: (probe0:ahc1:0:0:2): INQUIRY. CDB: 12 40 0 0 24 0 > kernel: (probe0:ahc1:0:0:3): INQUIRY. CDB: 12 60 0 0 24 0 > kernel: (probe0:ahc1:0:0:4): INQUIRY. CDB: 12 80 0 0 24 0 > kernel: (probe0:ahc1:0:0:5): INQUIRY. CDB: 12 a0 0 0 24 0 > kernel: (probe0:ahc1:0:0:6): INQUIRY. CDB: 12 c0 0 0 24 0 > kernel: (probe0:ahc1:0:0:7): INQUIRY. CDB: 12 e0 0 0 24 0 > > Does not say anything to me. Hmm, well, you're not going to see the problem CDB that way, because the probe has already happened. To see it, you either need to compile in the debugging flags, or do the following: - unplug the cable from the machine to the RAID array - camcontrol rescan 1 - plug the cable back in - camcontrol rescan 1 > > > Any idea, whats wrong with it? > > > > >From what I can see, it's likely the device is misbehaving. The fact that > > the 16 byte read capacity fails under Linux is telling. If you've got a > > device that supports a LUN size greater than 2TB, it must support the 16 > > byte read capacity and read/write commands. > > So you would say this is a misbehaviour of the RAID's firmware/controller? It's either the RAID box or the ahc driver from what I can see at this point. See below. > > Here are some more things you can try. Does your system boot? > Well, that RAID is just one of 3 RAIDs, the system is on the internal PERC-RAID. > > > If so, we > > can try sending a few commands to the device via the pass(4) driver and see > > what happens. > > > First, run 'camcontrol devlist' and see if the array is there and whether > > there is a pass device attached. If so, try this: > > > > camcontrol cmd passX -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" > > at scbus1 target 0 lun 0 (pass3) > # camcontrol cmd pass3 -v -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4" > -1 512 Okay, that's good. The -1 means that the RAID box is telling us that we need to send the 16 byte read capacity command to get the true capacity. (That's what a capacity of 0xffffffff, or -1, means.) > > That will send a standard 10 byte read capacity command to the device. > > Next, try a 16 byte read capacity. This is where things are likely failing > > in the da(4) driver attach, and apparantly where things are failing under > > Linux: > > > > camcontrol cmd passX -v -c "9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0" -i 12 "i4 i4 i4" > > # camcontrol cmd pass3 -v -c "9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0" -i 12 "i4 i4 i4" > camcontrol: error sending command > (pass3:ahc1:0:0:0): SERVICE ACTION IN(16). CDB: 9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0 > (pass3:ahc1:0:0:0): CAM Status: Target Bus Phase Sequence Failure > > dmesg: > (pass3:ahc1:0:0:0): No or incomplete CDB sent to device. > (pass3:ahc1:0:0:0): Protocol violation in Message-in phase. Attempting to abort. > (pass3:ahc1:0:0:0): Abort Tag Message Sent > (pass3:ahc1:0:0:0): SCB 8 - Abort Tag Completed. Hmm, okay, at this point, we have a SCSI protocol violation. (Which is the same thing you saw before.) So this pretty much means it is the 16 byte read capacity that is triggering the problem. The question is, is this problem on the RAID box or in the ahc driver? I would lean towards saying the RAID box has the issue, but Justin (CCed) may be able to give a little more insight. > > If that works, there is some other problem. If it fails, then we're > > fairly close to the problem. > > So, if it's a problem with the RAIDs firmware and/or maybe hardware, > do you expect there's a workaround in FreeBSD for it? It's either a problem with the firmware on the RAID controller or with the ahc driver. If it turns out that the RAID controller is at fault, then you'll need to get fixed firmware. It'll be interesting to see whether a SuSE live system works with it. (And reports a capacity that is greater than 2TB.) Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 08:18: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 9A0EB16A41C for ; Sun, 12 Jun 2005 08:18:23 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 46C6243D48 for ; Sun, 12 Jun 2005 08:18:22 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id BC7B750C75 for ; Sun, 12 Jun 2005 17:18:21 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 32E3350D00 for ; Sun, 12 Jun 2005 17:18:20 +0900 (JST) Date: Sun, 12 Jun 2005 17:18:20 +0900 Message-ID: <7mhdg4q983.wl%kuriyama@imgsrc.co.jp> From: Jun Kuriyama To: Current User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Cc: Subject: Acquiring lockmgr lock "ufs" with non-sleepable locks 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, 12 Jun 2005 08:18:23 -0000 As of today's current: Acquiring lockmgr lock "ufs" with the following non-sleepable locks held: exclusive sleep mutex vnode pollinfo r = 0 (0xc4814000) locked @ /usr/src/sys/kern/kern_event.c:881 KDB: stack backtrace: kdb_backtrace(1,3001,c3fa229c,c3a36780,ecf71a5c) at kdb_backtrace+0x29 witness_warn(5,c070c378,c06a435b,c06ad03d) at witness_warn+0x18e lockmgr(c3fa2278,3001,c3fa229c,c3a36780,ecf71a88) at lockmgr+0x8d vop_stdlock(ecf71acc,c06f58c0,ecf71acc,ecf71a98,c0612184) at vop_stdlock+0x1e VOP_LOCK_APV(c06f5e00,ecf71acc,ecf71aac,c067caff,ecf71acc) at VOP_LOCK_APV+0x87 ffs_lock(ecf71acc,1001,c3fa2220,ecf71ae8,c0566634) at ffs_lock+0x10 VOP_LOCK_APV(c06f58c0,ecf71acc) at VOP_LOCK_APV+0x87 vn_lock(c3fa2220,1001,c3a36780) at vn_lock+0xa4 filt_vfsread(c3ac9264,0,0,ffffffff,0) at filt_vfsread+0x3a kqueue_register(c3dd6480,ecf71bf4,c3a36780,1,0) at kqueue_register+0x668 kern_kevent(c3a36780,4,1,0,ecf71cc8) at kern_kevent+0xc9 kevent(c3a36780,ecf71d04,6,1,292) at kevent+0x55 syscall(3b,3b,3b,1,804e068) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (363, FreeBSD ELF32, kevent), eip = 0x280b9503, esp = 0xbfbfe8ec, ebp = 0xbfbfe938 --- -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 08:57:50 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 90FE016A41C; Sun, 12 Jun 2005 08:57:50 +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 0998543D53; Sun, 12 Jun 2005 08:57:49 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j5C8vYfC074062; Sun, 12 Jun 2005 04:57:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j5C8vmaS013751; Sun, 12 Jun 2005 04:57:48 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id C44217306E; Sun, 12 Jun 2005 04:57:48 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050612085748.C44217306E@freebsd-current.sentex.ca> Date: Sun, 12 Jun 2005 04:57:48 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [current tinderbox] failure on alpha/alpha 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: Sun, 12 Jun 2005 08:57:50 -0000 TB --- 2005-06-12 07:15:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-06-12 07:15:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-06-12 07:15:01 - cleaning the object tree TB --- 2005-06-12 07:15:33 - checking out the source tree TB --- 2005-06-12 07:15:33 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-06-12 07:15:33 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-06-12 07:25:39 - building world (CFLAGS=-O2 -pipe) TB --- 2005-06-12 07:25:39 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-06-12 07:25:39 - /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-06-12 08:35:47 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-12 08:35:47 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-06-12 08:35:47 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jun 12 08:35:48 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 Sun Jun 12 08:49:45 UTC 2005 TB --- 2005-06-12 08:49:45 - generating LINT kernel config TB --- 2005-06-12 08:49:45 - cd /home/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- 2005-06-12 08:49:45 - /usr/bin/make -B LINT TB --- 2005-06-12 08:49:45 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-12 08:49:45 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-06-12 08:49:45 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 12 08:49:45 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -I/tinderbox/CURRENT/alpha/alpha/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/md4c.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -I/tinderbox/CURRENT/alpha/alpha/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/md5c.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -I/tinderbox/CURRENT/alpha/alpha/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/sched_4bsd.c In file included from /tinderbox/CURRENT/alpha/alpha/src/sys/kern/sched_4bsd.c:1388: /tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_switch.c: In function `maybe_preempt_in_ksegrp': /tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_switch.c:435: error: `IPI_PREEMPT' undeclared (first use in this function) /tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_switch.c:435: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_switch.c:435: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-06-12 08:57:48 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-06-12 08:57:48 - ERROR: failed to build lint kernel TB --- 2005-06-12 08:57:48 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 11:06:36 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 8425116A41C; Sun, 12 Jun 2005 11:06:36 +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 D7A4B43D48; Sun, 12 Jun 2005 11:06:35 +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 j5CB6X1A008376 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 12 Jun 2005 15:06:33 +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 j5CB6WQC074292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jun 2005 15:06:32 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j5CB6Wj4074291; Sun, 12 Jun 2005 15:06:32 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 12 Jun 2005 15:06:31 +0400 From: Gleb Smirnoff To: delphij@FreeBSD.org Message-ID: <20050612110631.GA74232@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline 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: consoles broken on Thinkpad T20 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, 12 Jun 2005 11:06:36 -0000 Xin, today I've upgraded to recent current, and got the following breakage. When my notebook boots, right after printing "Updating motd", screen goes black. After it has finished booting I can't switch consoles - Alt-{F2,F3 .. F8} produces beep. ALt-F1 does not, but screen is black. I've found a workaround - switching ttyv0 off in /etc/ttys gives me ability to switch consoles and work. The first vty is black still. I've also tried putting 'exit 0' in the very beginning of /etc/rc.d/syscons. In this case I see as notebook continues to boot, but at the very end, after local startup, the first vty goes black. Now I work with this line in /etc/ttys, to be able to log in: ttyv0 "/usr/libexec/getty Pc" cons25r off secure Then I started X and tried to play with resolution on vtys: root@think:~:|>vidcontrol MODE_279 < /dev/ttyv1 root@think:~:|> I switched to ttyv1 and it was in nice 1024x768 resolution. Then: root@think:~:|>vidcontrol MODE_279 < /dev/ttyv0 Floating point exception: 8 (core dumped) The first console is black. root@think:~:|>gdb `which vidcontrol` vidcontrol.core #0 0x08049365 in video_mode (argc=0, argv=0xbfbfe930, mode_index=0x804dca4) at /usr/src/usr.sbin/vidcontrol/vidcontrol.c:659 659 size[1] = new_mode_info.vi_height / (gdb) bt #0 0x08049365 in video_mode (argc=0, argv=0xbfbfe930, mode_index=0x804dca4) at /usr/src/usr.sbin/vidcontrol/vidcontrol.c:659 #1 0x080499d8 in main (argc=2, argv=0xbfbfe930) at /usr/src/usr.sbin/vidcontrol/vidcontrol.c:1253 (gdb) -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 11:27:10 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 41DE716A41C; Sun, 12 Jun 2005 11:27:10 +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 9631843D1F; Sun, 12 Jun 2005 11:27:09 +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 j5CBR7Mm008716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 12 Jun 2005 15:27:08 +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 j5CBR7pY074506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jun 2005 15:27:07 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j5CBR6Wc074505; Sun, 12 Jun 2005 15:27:06 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 12 Jun 2005 15:27:06 +0400 From: Gleb Smirnoff To: delphij@FreeBSD.org Message-ID: <20050612112706.GB74232@cell.sick.ru> References: <20050612110631.GA74232@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050612110631.GA74232@cell.sick.ru> 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: consoles broken on Thinkpad T20 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, 12 Jun 2005 11:27:10 -0000 On Sun, Jun 12, 2005 at 03:06:31PM +0400, Gleb Smirnoff wrote: T> The first console is black. T> T> root@think:~:|>gdb `which vidcontrol` vidcontrol.core T> #0 0x08049365 in video_mode (argc=0, argv=0xbfbfe930, mode_index=0x804dca4) T> at /usr/src/usr.sbin/vidcontrol/vidcontrol.c:659 T> 659 size[1] = new_mode_info.vi_height / T> (gdb) bt T> #0 0x08049365 in video_mode (argc=0, argv=0xbfbfe930, mode_index=0x804dca4) T> at /usr/src/usr.sbin/vidcontrol/vidcontrol.c:659 T> #1 0x080499d8 in main (argc=2, argv=0xbfbfe930) T> at /usr/src/usr.sbin/vidcontrol/vidcontrol.c:1253 T> (gdb) Some more info: (gdb) p new_mode_info.vi_height $1 = 768 (gdb) p font_height $2 = 0 (gdb) p cur_info.console_info.font_size $3 = 0 (gdb) Seems like the problem is that vidcontrol can't determine current font height. Ok, I've tried to force non raster mode on /dev/ttyv0: root@think:~:|>vidcontrol VGA_80x25 < /dev/ttyv0 It works. My first ttys is alive again. I see cursor, and I can see log messages here. No login prompt, since it is truned off in /etc/ttys. After that I can even set raster mode on it: root@think:~:|>vidcontrol MODE_279 < /dev/ttyv0 root@think:~:|> So, it looks like on startup vidcontrol can't determine font height and leaves ttyv0 in inconsistent state. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 11:37: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 A4DEF16A41C for ; Sun, 12 Jun 2005 11:37:44 +0000 (GMT) (envelope-from paul.richards@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.207]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A44243D55 for ; Sun, 12 Jun 2005 11:37:44 +0000 (GMT) (envelope-from paul.richards@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so885648wri for ; Sun, 12 Jun 2005 04:37:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=I9Sb0THFB4eiGahR5IYt0xwLzXmDqR00m0C2deRULYPZrUSRkOfUn98nSVQ5b/RiWhdCw4LnSm7uNda5IElwgpBLfeVu2OejG2hH1u2ASfQB9O3cZxzeUx+7R+RIiYsN2PBE+xeRuHr+ni0Yxd0QfXCblCEWHMw4ry6gnbE9V0E= Received: by 10.54.2.61 with SMTP id 61mr873233wrb; Sun, 12 Jun 2005 04:37:43 -0700 (PDT) Received: by 10.54.97.7 with HTTP; Sun, 12 Jun 2005 04:37:43 -0700 (PDT) Message-ID: Date: Sun, 12 Jun 2005 12:37:43 +0100 From: Paul Richards To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Immediate reboots on amd64 after upgrading to current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Paul Richards List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2005 11:37:44 -0000 Hi, I was running 5.4 (amd64) but was looking to get my nForce4 nic working. I heard about the nve driver in current and so I upgraded to current. I followed the handbook instructions of essentially make buildworld, buildkernel, installkernel etc.. When I rebooted however I found that the new kernel immediately reboots after selecting any of the options on the boot menu (safe mode, normal, single user, etc). I've restored my system to 5.4 (it didn't have anything important anyway) but I was wondering what actually went wrong.. Is the 6-current broken at the moment? (unlikely as it seems like quite a severe break) Did I miss something to do with reconfiguring the boot process? What should I look out for when I try again..? --=20 Paul Richards From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 12:38:14 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 99F3C16A41C; Sun, 12 Jun 2005 12:38:14 +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 0185B43D1D; Sun, 12 Jun 2005 12:38:13 +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 j5CCcBrG009642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 12 Jun 2005 16:38:12 +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 j5CCcBYJ074833 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jun 2005 16:38:11 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j5CCcBRC074832; Sun, 12 Jun 2005 16:38:11 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 12 Jun 2005 16:38:10 +0400 From: Gleb Smirnoff To: delphij@FreeBSD.org Message-ID: <20050612123810.GA74776@cell.sick.ru> References: <20050612110631.GA74232@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050612110631.GA74232@cell.sick.ru> 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: consoles broken on Thinkpad T20 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, 12 Jun 2005 12:38:14 -0000 On Sun, Jun 12, 2005 at 03:06:31PM +0400, Gleb Smirnoff wrote: T> today I've upgraded to recent current, and got the following breakage. T> When my notebook boots, right after printing "Updating motd", T> screen goes black. After it has finished booting I can't switch T> consoles - Alt-{F2,F3 .. F8} produces beep. ALt-F1 does not, but T> screen is black. I've found a workaround - switching ttyv0 off T> in /etc/ttys gives me ability to switch consoles and work. The first T> vty is black still. T> T> I've also tried putting 'exit 0' in the very beginning of /etc/rc.d/syscons. T> In this case I see as notebook continues to boot, but at the very end, T> after local startup, the first vty goes black. I've found that problem is caused by /usr/sbin/ispcvt call from /etc/rc.d/syscons and later rom /etc/rc.d/pcvt. Calling ispcvt by hand causes the same black screen and other symptoms as describe in above quote. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 12:56: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 0F0E016A41C; Sun, 12 Jun 2005 12:56:00 +0000 (GMT) (envelope-from saw@online.de) Received: from smtp2.netcologne.de (smtp2.netcologne.de [194.8.194.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6C6943D48; Sun, 12 Jun 2005 12:55:59 +0000 (GMT) (envelope-from saw@online.de) Received: from [192.168.0.69] (xdsl-213-196-252-144.netcologne.de [213.196.252.144]) by smtp2.netcologne.de (Postfix) with ESMTP id 917D24480; Sun, 12 Jun 2005 14:55:57 +0200 (MEST) Message-ID: <42AC30DF.1000706@online.de> Date: Sun, 12 Jun 2005 14:55:59 +0200 From: Sascha Wildner Organization: Yoyodyne Natural Born Configurators User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <20050612110631.GA74232@cell.sick.ru> <20050612112706.GB74232@cell.sick.ru> In-Reply-To: <20050612112706.GB74232@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: delphij@FreeBSD.org, current@FreeBSD.org Subject: Re: consoles broken on Thinkpad T20 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, 12 Jun 2005 12:56:00 -0000 Gleb Smirnoff wrote: > Some more info: > > (gdb) p new_mode_info.vi_height > $1 = 768 > (gdb) p font_height > $2 = 0 > (gdb) p cur_info.console_info.font_size > $3 = 0 > (gdb) Gleb, could you please send: a) the output of "vidcontrol -i mode" b) the output of "p cur_info" (from gdb) Thanks, Sascha From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 12:57:18 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 38A8B16A41C; Sun, 12 Jun 2005 12:57:18 +0000 (GMT) (envelope-from saw@online.de) Received: from smtp2.netcologne.de (smtp2.netcologne.de [194.8.194.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E70743D53; Sun, 12 Jun 2005 12:57:17 +0000 (GMT) (envelope-from saw@online.de) Received: from [192.168.0.69] (xdsl-213-196-252-144.netcologne.de [213.196.252.144]) by smtp2.netcologne.de (Postfix) with ESMTP id 07F564480; Sun, 12 Jun 2005 14:57:15 +0200 (MEST) Message-ID: <42AC312E.8080501@online.de> Date: Sun, 12 Jun 2005 14:57:18 +0200 From: Sascha Wildner Organization: Yoyodyne Natural Born Configurators User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Gleb Smirnoff References: <20050612110631.GA74232@cell.sick.ru> <20050612123810.GA74776@cell.sick.ru> In-Reply-To: <20050612123810.GA74776@cell.sick.ru> Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Cc: delphij@FreeBSD.org, current@FreeBSD.org Subject: Re: consoles broken on Thinkpad T20 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, 12 Jun 2005 12:57:18 -0000 Gleb Smirnoff wrote: > I've found that problem is caused by /usr/sbin/ispcvt call from /etc/rc.d/syscons > and later rom /etc/rc.d/pcvt. > > Calling ispcvt by hand causes the same black screen and other symptoms as > describe in above quote. I think that was fixed recently. Regards, Sascha P.S. Ignore my previous answer. From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 13:18:37 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 1006816A41C; Sun, 12 Jun 2005 13:18:37 +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 4B8A443D4C; Sun, 12 Jun 2005 13:18:36 +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 j5CDIYPu010141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 12 Jun 2005 17:18:34 +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 j5CDIXHe074987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jun 2005 17:18:33 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j5CDIX2L074986; Sun, 12 Jun 2005 17:18:33 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Sun, 12 Jun 2005 17:18:33 +0400 From: Gleb Smirnoff To: Xin LI Message-ID: <20050612131833.GB74776@cell.sick.ru> References: <20050612110631.GA74232@cell.sick.ru> <20050612123810.GA74776@cell.sick.ru> <1118580107.819.1.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1118580107.819.1.camel@spirit> 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: delphij@FreeBSD.org, current@FreeBSD.org Subject: Re: consoles broken on Thinkpad T20 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, 12 Jun 2005 13:18:37 -0000 On Sun, Jun 12, 2005 at 08:41:47PM +0800, Xin LI wrote: X> ??? 2005-06-12?????? 16:38 +0400???Gleb Smirnoff????????? X> > On Sun, Jun 12, 2005 at 03:06:31PM +0400, Gleb Smirnoff wrote: X> > T> today I've upgraded to recent current, and got the following breakage. X> > T> When my notebook boots, right after printing "Updating motd", X> > T> screen goes black. After it has finished booting I can't switch X> > T> consoles - Alt-{F2,F3 .. F8} produces beep. ALt-F1 does not, but X> > T> screen is black. I've found a workaround - switching ttyv0 off X> > T> in /etc/ttys gives me ability to switch consoles and work. The first X> > T> vty is black still. X> > T> X> > T> I've also tried putting 'exit 0' in the very beginning of /etc/rc.d/syscons. X> > T> In this case I see as notebook continues to boot, but at the very end, X> > T> after local startup, the first vty goes black. X> > X> > I've found that problem is caused by /usr/sbin/ispcvt call from /etc/rc.d/syscons X> > and later rom /etc/rc.d/pcvt. X> > X> > Calling ispcvt by hand causes the same black screen and other symptoms as X> > describe in above quote. X> X> Which sys/dev/syscons/scvesactl.c version do you have? Is it 1.22? Oops. It is 1.21. I suppose this is already fixed. Thanks! -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 13:37:39 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 A559D16A41C for ; Sun, 12 Jun 2005 13:37:39 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from colgate.yandex.ru (colgate.yandex.ru [213.180.200.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5AE3443D53 for ; Sun, 12 Jun 2005 13:37:39 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from YAMAIL (colgate.yandex.ru) by mail.yandex.ru id ; Sun, 12 Jun 2005 17:37:03 +0400 Date: Sun, 12 Jun 2005 17:37:03 +0400 (MSD) From: "Polakov Alexander" Sender: polachok@narod.ru Message-Id: <42AC3A7F.000002.04175@colgate.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: polachok@narod.ru To: freebsd-current@freebsd.org X-Source-Ip: 213.158.9.84 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: cannot build anything big X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: polachok@narod.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2005 13:37:39 -0000 I cannot build anything big: kernel, CURRENT's world, then Xorg, perl. I rebuilt openbox & fluxbox and they fails with a core dump, so I have to get prebuilt packages. CFLAGS are not set. The CPUTYPE is set to pentium3. Kernel is compiled with PREEMPTION and ULE scheduler. Please, help! -- Alexander Polakov From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 13:43: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 3017916A41C for ; Sun, 12 Jun 2005 13:43:46 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout05.sul.t-online.com (mailout05.sul.t-online.com [194.25.134.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 97BB243D53 for ; Sun, 12 Jun 2005 13:43:45 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd21.aul.t-online.de by mailout05.sul.t-online.com with smtp id 1DhSkZ-0002W8-01; Sun, 12 Jun 2005 15:43:43 +0200 Received: from Andro-Beta.Leidinger.net (GupvTEZcgeHUJC+HDy+c7Bp3KwTck4sq1ZjwKAbrw0yXoTRSHM-Rgw@[84.165.231.64]) by fwd21.sul.t-online.de with esmtp id 1DhSkW-0JyWHI0; Sun, 12 Jun 2005 15:43: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 j5CDhbAS003581 for ; Sun, 12 Jun 2005 15:43:38 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sun, 12 Jun 2005 15:44:03 +0200 From: Alexander Leidinger To: current@freebsd.org Message-ID: <20050612154403.2b49d0d8@Magellan.Leidinger.net> X-Mailer: Sylpheed-Claws 1.9.11 (GTK+ 2.6.7; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: GupvTEZcgeHUJC+HDy+c7Bp3KwTck4sq1ZjwKAbrw0yXoTRSHM-Rgw@t-dialin.net X-TOI-MSGID: c62f98af-d5fb-45e6-a26e-f27c12cd39e2 Cc: Subject: TODO list for volunteers (similar to the list of things for Google's summer of 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, 12 Jun 2005 13:43:46 -0000 Hi, I want to compile a list of things where a volunteer can pick an entry and improve FreeBSD. It's similar to the list of things one can do when he wants to participate in Google's summer of code, but without the restrictions (they want real code only, AFAIK docs improvements without source code doesn't count) or benefits (they give you money for the work) of it. This doesn't mean you aren't allowed to sponsor some entries :-), it just means a volunteer gets only the spiritual benefits (an entry in the official contributors list) guaranteed. It should be a list of things which need to be fixed (e.g. CPU usage display in top when a program uses threads or fixing/improving the locking of the sound subsystem) and a list of new features we want to see in FreeBSD (e.g. documenting the sound subsystem or implementing iSCSI). I already have a list of ~16 entries (on paper) and like to get your ideas too to compile a nice list. This isn't limited to src/ stuff only, feel free to also tell me about your favorite doc/ or ports/ task (regarding ports: only tell me about infrastructure changes, not about individual ports you want to see show up in the collection; in general: please don't tell me about open PRs which need to get committed). Ideally you should tell me about the requirements of a task too. Also feel free to tell me if you're willing to mentor a specific kind of work or if you want to coordinate something (like on the summer of code page). If you want to submit entries which are important but covered on other FreeBSD pages (like on the SMP, dingo or bigdisk pages) please submit the links to those pages instead. I will also add those entries from the summer of code list, which aren't taken after google doesn't accept new participants anymore. I intend to write everything up over the next week and give it to some of our docs people for SGML review (if nobody volunteers I pick someone out of the blue and ask nicely for a review :-) ). Bye, Alexander. -- Intel: where Quality is job number 0.9998782345! 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 Jun 12 14:31:23 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 20CDC16A41C; Sun, 12 Jun 2005 14:31:23 +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 C702143D1D; Sun, 12 Jun 2005 14:31:22 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j5CEV6XG087790; Sun, 12 Jun 2005 10:31:06 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j5CEVLfI005259; Sun, 12 Jun 2005 10:31:21 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id AF2017306E; Sun, 12 Jun 2005 10:31:21 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050612143121.AF2017306E@freebsd-current.sentex.ca> Date: Sun, 12 Jun 2005 10:31:21 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on clamscanner1 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [current tinderbox] failure on i386/pc98 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: Sun, 12 Jun 2005 14:31:23 -0000 TB --- 2005-06-12 13:09:50 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-06-12 13:09:50 - starting CURRENT tinderbox run for i386/pc98 TB --- 2005-06-12 13:09:50 - cleaning the object tree TB --- 2005-06-12 13:10:09 - checking out the source tree TB --- 2005-06-12 13:10:09 - cd /home/tinderbox/CURRENT/i386/pc98 TB --- 2005-06-12 13:10:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-06-12 13:16:17 - building world (CFLAGS=-O2 -pipe) TB --- 2005-06-12 13:16:17 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-06-12 13:16:17 - /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-06-12 14:24:34 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-12 14:24:34 - cd /home/tinderbox/CURRENT/i386/pc98/src TB --- 2005-06-12 14:24:34 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jun 12 14:24:34 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/pc98/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -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 -Werror /tinderbox/CURRENT/i386/pc98/src/sys/dev/nsp/nsp_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/pc98/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -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 -Werror /tinderbox/CURRENT/i386/pc98/src/sys/dev/sio/sio_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/pc98/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -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 -Werror /tinderbox/CURRENT/i386/pc98/src/sys/dev/sn/if_sn_pccard.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/pc98/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -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 -Werror /tinderbox/CURRENT/i386/pc98/src/sys/dev/snc/dp83932.c /tinderbox/CURRENT/i386/pc98/src/sys/dev/snc/dp83932.c: In function `sncconfig': /tinderbox/CURRENT/i386/pc98/src/sys/dev/snc/dp83932.c:169: error: `dev' undeclared (first use in this function) /tinderbox/CURRENT/i386/pc98/src/sys/dev/snc/dp83932.c:169: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/i386/pc98/src/sys/dev/snc/dp83932.c:169: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. *** Error code 1 Stop in /tinderbox/CURRENT/i386/pc98/src. TB --- 2005-06-12 14:31:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-06-12 14:31:21 - ERROR: failed to build generic kernel TB --- 2005-06-12 14:31:21 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 14:40:20 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 6AC0716A41C; Sun, 12 Jun 2005 14:40:20 +0000 (GMT) (envelope-from nyan@jp.FreeBSD.org) Received: from watery.cc.kogakuin.ac.jp (watery.cc.kogakuin.ac.jp [133.80.152.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id D4C1D43D49; Sun, 12 Jun 2005 14:40:19 +0000 (GMT) (envelope-from nyan@jp.FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) by watery.cc.kogakuin.ac.jp (8.13.3/8.13.3) with ESMTP id j5CEeINq022968; Sun, 12 Jun 2005 23:40:18 +0900 (JST) (envelope-from nyan@jp.FreeBSD.org) Date: Sun, 12 Jun 2005 23:39:40 +0900 (JST) Message-Id: <20050612.233940.41649233.nyan@jp.FreeBSD.org> To: brooks@FreeBSD.org From: Takahashi Yoshihiro In-Reply-To: <20050612143121.AF2017306E@freebsd-current.sentex.ca> References: <20050612143121.AF2017306E@freebsd-current.sentex.ca> X-Mailer: Mew version 4.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.org Subject: Re: [current tinderbox] failure on i386/pc98 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, 12 Jun 2005 14:40:20 -0000 A pc98 kernel is still broken. Please compile GENERIC and LINT kernels at least. In article <20050612143121.AF2017306E@freebsd-current.sentex.ca> FreeBSD Tinderbox writes: > TB --- 2005-06-12 13:09:50 - tinderbox 2.3 running on freebsd-current.sentex.ca > TB --- 2005-06-12 13:09:50 - starting CURRENT tinderbox run for i386/pc98 > TB --- 2005-06-12 13:09:50 - cleaning the object tree > TB --- 2005-06-12 13:10:09 - checking out the source tree > TB --- 2005-06-12 13:10:09 - cd /home/tinderbox/CURRENT/i386/pc98 > TB --- 2005-06-12 13:10:09 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src > TB --- 2005-06-12 13:16:17 - building world (CFLAGS=-O2 -pipe) > TB --- 2005-06-12 13:16:17 - cd /home/tinderbox/CURRENT/i386/pc98/src > TB --- 2005-06-12 13:16:17 - /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-06-12 14:24:34 - building generic kernel (COPTFLAGS=-O2 -pipe) > TB --- 2005-06-12 14:24:34 - cd /home/tinderbox/CURRENT/i386/pc98/src > TB --- 2005-06-12 14:24:34 - /usr/bin/make buildkernel KERNCONF=GENERIC > >>> Kernel build for GENERIC started on Sun Jun 12 14:24:34 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 > [...] > cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/pc98/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -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 -Werror /tinderbox/CURRENT/i386/pc98/src/sys/dev/nsp/nsp_pccard.c > cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/pc98/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -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 -Werror /tinderbox/CURRENT/i386/pc98/src/sys/dev/sio/sio_pccard.c > cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/pc98/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -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 -Werror /tinderbox/CURRENT/i386/pc98/src/sys/dev/sn/if_sn_pccard! .c > cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/tinderbox/CURRENT/i386/pc98/src/sys -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/altq -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/pf -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ngatm -I/tinderbox/CURRENT/i386/pc98/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -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 -Werror /tinderbox/CURRENT/i386/pc98/src/sys/dev/snc/dp83932.c > /tinderbox/CURRENT/i386/pc98/src/sys/dev/snc/dp83932.c: In function `sncconfig': > /tinderbox/CURRENT/i386/pc98/src/sys/dev/snc/dp83932.c:169: error: `dev' undeclared (first use in this function) > /tinderbox/CURRENT/i386/pc98/src/sys/dev/snc/dp83932.c:169: error: (Each undeclared identifier is reported only once > /tinderbox/CURRENT/i386/pc98/src/sys/dev/snc/dp83932.c:169: error: for each function it appears in.) > *** Error code 1 > > Stop in /tinderbox/CURRENT/i386/pc98/obj/pc98/tinderbox/CURRENT/i386/pc98/src/sys/GENERIC. > *** Error code 1 > > Stop in /tinderbox/CURRENT/i386/pc98/src. > *** Error code 1 > > Stop in /tinderbox/CURRENT/i386/pc98/src. > TB --- 2005-06-12 14:31:21 - WARNING: /usr/bin/make returned exit code 1 > TB --- 2005-06-12 14:31:21 - ERROR: failed to build generic kernel > TB --- 2005-06-12 14:31:21 - tinderbox aborted > > _______________________________________________ > 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" --- TAKAHASHI Yoshihiro From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 14:47: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 B69D516A41C for ; Sun, 12 Jun 2005 14:47:08 +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 857F043D1F for ; Sun, 12 Jun 2005 14:47:08 +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 j5CEl88m010653; Sun, 12 Jun 2005 07:47:08 -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 j5CEl34T010652; Sun, 12 Jun 2005 07:47:03 -0700 (PDT) (envelope-from sgk) Date: Sun, 12 Jun 2005 07:47:03 -0700 From: Steve Kargl To: Paul Richards Message-ID: <20050612144703.GB10314@troutmask.apl.washington.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Immediate reboots on amd64 after upgrading to 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: Sun, 12 Jun 2005 14:47:08 -0000 On Sun, Jun 12, 2005 at 12:37:43PM +0100, Paul Richards wrote: > > I followed the handbook instructions of essentially make buildworld, > buildkernel, installkernel etc.. When I rebooted however I found that > the new kernel immediately reboots after selecting any of the options > on the boot menu (safe mode, normal, single user, etc). I'm seeing the exact same behavior. I upgraded a mid May current to June 9th current and see this problem. I backed up to June 1st via cvsup and the boot problem is still there. Ran out of time to track things down until next week :-(. > Is the 6-current broken at the moment? (unlikely as it seems like > quite a severe break) In my experience, the answer is yes. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 14:48: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 1F67F16A41C for ; Sun, 12 Jun 2005 14:48: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 CBE6843D4C for ; Sun, 12 Jun 2005 14:48:57 +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 j5CEmveV010674; Sun, 12 Jun 2005 07:48:57 -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 j5CEmssH010673; Sun, 12 Jun 2005 07:48:54 -0700 (PDT) (envelope-from sgk) Date: Sun, 12 Jun 2005 07:48:54 -0700 From: Steve Kargl To: Polakov Alexander Message-ID: <20050612144854.GC10314@troutmask.apl.washington.edu> References: <42AC3A7F.000002.04175@colgate.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42AC3A7F.000002.04175@colgate.yandex.ru> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: cannot build anything big 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, 12 Jun 2005 14:48:58 -0000 On Sun, Jun 12, 2005 at 05:37:03PM +0400, Polakov Alexander wrote: > I cannot build anything big: kernel, CURRENT's world, then Xorg, perl. > I rebuilt openbox & fluxbox and they fails with a core dump, so I have > to get prebuilt packages. > CFLAGS are not set. The CPUTYPE is set to pentium3. Kernel is compiled > with PREEMPTION and ULE scheduler. > Please, help! What are the reported errors? -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 15:42: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 855C316A41C for ; Sun, 12 Jun 2005 15:42:29 +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 300D643D48 for ; Sun, 12 Jun 2005 15:42:29 +0000 (GMT) (envelope-from joseph.koshy@gmail.com) Received: by rproxy.gmail.com with SMTP id i8so840391rne for ; Sun, 12 Jun 2005 08:42:28 -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=FGYpOV5yx6O7q+FObbg0TRXxWwSsgWtfk0kuiDhBEZ3eSi4BBlxJDhDhZLJhoxeoLeRaQoGeP1/lIyZaRYubO2joz5ioEdUrVYk8jZ08ohTilTn8d2CFQv5A1tnKr/YyEAldLmNt1M+ETrqdcpYig1232+K1dgpltjiG/HNsz7I= Received: by 10.38.65.57 with SMTP id n57mr446722rna; Sun, 12 Jun 2005 08:40:45 -0700 (PDT) Received: by 10.38.209.73 with HTTP; Sun, 12 Jun 2005 08:40:44 -0700 (PDT) Message-ID: <84dead72050612084014c28604@mail.gmail.com> Date: Sun, 12 Jun 2005 21:10:44 +0530 From: Joseph Koshy To: polachok@narod.ru In-Reply-To: <42AC3A7F.000002.04175@colgate.yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42AC3A7F.000002.04175@colgate.yandex.ru> Cc: freebsd-current@freebsd.org Subject: Re: cannot build anything big 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: Sun, 12 Jun 2005 15:42:29 -0000 > CFLAGS are not set. The CPUTYPE is set to pentium3. Kernel is=20 > compiled with PREEMPTION and ULE scheduler. Are you getting a SIGILL signal with newly compiled binaries while stock binaries are working? If so, please compile a 'hello world' program and post the output of a 'ktrace'd run. --=20 FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 16:24:35 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 6A71C16A41C for ; Sun, 12 Jun 2005 16:24:35 +0000 (GMT) (envelope-from fmayhar@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8E1C43D49 for ; Sun, 12 Jun 2005 16:24:34 +0000 (GMT) (envelope-from fmayhar@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so29392nzk for ; Sun, 12 Jun 2005 09:24:33 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:to:content-type:organization:date:message-id:mime-version:x-mailer:from; b=Yewey6+uKBgPc+exFdRYQ22TekskJypweYzJET9/AM5ZNm7Vma217ZMRmY+coAhxYCr+WT+gbAOPLynXuxCo6hVwoMBgybFPw33BE9X0E4rZrYCp+5rK1Pe1RCKNyj7cc5Cj7Sni3kqH7lFyz5CbSzB/b7muX0krIEerfARioHU= Received: by 10.36.34.4 with SMTP id h4mr2124668nzh; Sun, 12 Jun 2005 09:24:33 -0700 (PDT) Received: from localhost.localdomain ([4.232.111.208]) by mx.gmail.com with ESMTP id 12sm2137515nzn.2005.06.12.09.24.29; Sun, 12 Jun 2005 09:24:33 -0700 (PDT) To: current@freebsd.org Content-Type: multipart/mixed; boundary="=-ZiBA4/zBUjp1BryjWHeq" Organization: Exit Consulting Date: Sun, 12 Jun 2005 09:24:26 -0700 Message-Id: <1118593466.16330.1.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port From: Frank Mayhar Cc: Subject: Silent ACPI-related reset booting latest 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: Sun, 12 Jun 2005 16:24:35 -0000 --=-ZiBA4/zBUjp1BryjWHeq Content-Type: text/plain Content-Transfer-Encoding: 7bit I just rebuilt with the latest bits as of this afternoon. Apparently, some commit within the last 24 to 48 hours or so has broken ACPI on my Inspiron 5160. Booting with ACPI I get as far as 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 #43: Sat Jun 11 20:33:21 PDT 2005 frank@lap:/home/obj/usr/src/sys/AUTON WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Mobile Intel(R) Pentium(R) 4 CPU 2.80GHz (2790.72-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Features=0xbfebfbff Features2=0x459d> Hyperthreading: 2 logical CPUs real memory = 536662016 (511 MB) avail memory = 511586304 (487 MB) and it silently reboots. Without ACPI the boot continues. A full dmesg (without ACPI, obviously) is attached. This is just a heads-up. I haven't tried to figure it out yet as it happened late last night. I'll try to look at it today, but if someone fixes it before then that would be great. :-) (Apologies if this comes through twice; I'm fighting ISP insanity, sigh.) -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ --=-ZiBA4/zBUjp1BryjWHeq Content-Disposition: attachment; filename=dmesg.lap Content-Type: text/plain; name=dmesg.lap; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 #43: Sat Jun 11 20:33:21 PDT 2005 frank@lap:/home/obj/usr/src/sys/AUTON WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Mobile Intel(R) Pentium(R) 4 CPU 2.80GHz (2790.72-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Features=0xbfebfbff Features2=0x459d> Hyperthreading: 2 logical CPUs real memory = 536662016 (511 MB) avail memory = 511586304 (487 MB) ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: Please update driver or contact the maintainer. est: cpu_vendor GenuineIntel, msr 152800001528, bus_clk, 64 device_attach: est0 attach returned 6 p4tcc0: on cpu0 pcib0: pcibus 0 on motherboard pir0: on motherboard $PIR: Using invalid BIOS IRQ 11 from 0.29.INTA is for link 0x60 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.3 (no driver attached) pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xfc000000-0xfcffffff,0xd0000000-0xdfffffff irq 11 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] uhci0: port 0xbf80-0xbf9f irq 11 at device 29.0 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 uhci1: port 0xbf40-0xbf5f irq 11 at device 29.1 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 uhci2: port 0xbf20-0xbf3f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xf4fffc00-0xf4ffffff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 bfe0: mem 0xfaffe000-0xfaffffff irq 11 at device 1.0 on pci2 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:0f:1f:26:c6:65 bfe0: [GIANT-LOCKED] ath0: mem 0xfafe0000-0xfafeffff irq 11 at device 2.0 on pci2 ath0: [GIANT-LOCKED] ath0: Ethernet address: 00:02:6f:21:ed:0a ath0: mac 5.9 phy 4.3 radio 3.6 cbb0: irq 11 at device 4.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: <1394 Open Host Controller Interface> mem 0xfaffd800-0xfaffdfff,0xfaff8000-0xfaffbfff irq 11 at device 4.1 on pci2 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 34:4f:c0:00:26:8f:58:a1 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1f4ba000 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 36:4f:c0:8f:58:a1 fwe0: Ethernet address: 36:4f:c0:8f:58:a1 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcm0: port 0xb800-0xb8ff,0xbc40-0xbc7f mem 0xf4fff800-0xf4fff9ff,0xf4fff400-0xf4fff4ff irq 11 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: orm0: at iomem 0xc0000-0xcf7ff,0xcf800-0xcffff 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 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: flags 0x1000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (irq) Timecounter "TSC" frequency 2790720503 Hz quality 800 Timecounters tick every 1.000 msec acd0: DVDROM at ata0-master UDMA33 ad2: 57231MB at ata1-master UDMA100 ATA PseudoRAID loaded Trying to mount root from ufs:/dev/ad2s4a --=-ZiBA4/zBUjp1BryjWHeq-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 16:38: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 8348D16A422; Sun, 12 Jun 2005 16:38:05 +0000 (GMT) (envelope-from max@love2party.net) Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.186]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4293043E14; Sun, 12 Jun 2005 16:34:10 +0000 (GMT) (envelope-from max@love2party.net) Received: from p54A3C3C9.dip.t-dialin.net [84.163.195.201] (helo=donor.laier.local) by mrelayeu.kundenserver.de with ESMTP (Nemesis), id 0MKwtQ-1DhVPV0Ffo-00013f; Sun, 12 Jun 2005 18:34:09 +0200 From: Max Laier To: freebsd-current@freebsd.org Date: Sun, 12 Jun 2005 18:33:54 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart6079990.JVTdZoh8OC"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506121834.02020.max@love2party.net> X-Provags-ID: kundenserver.de abuse@kundenserver.de login:61c499deaeeba3ba5be80f48ecc83056 Cc: freebsd-ipfw@freebsd.org Subject: Fwd: cvs commit: src/sys/netinet ip_fw2.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: Sun, 12 Jun 2005 16:38:05 -0000 --nextPart6079990.JVTdZoh8OC Content-Type: multipart/mixed; boundary="Boundary-01=_0PGrC/u4C6yc+AM" Content-Transfer-Encoding: 7bit Content-Disposition: inline --Boundary-01=_0PGrC/u4C6yc+AM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline All, if you are relying on IPFW2's new IPv6 capabilities as your IPv6 packet=20 filter, it's time to update. The commit below fixes a problem with in the= =20 code that would match random IPv6 packets to IPv4 rules. =2D-=20 /"\ Best regards, | mlaier@freebsd.org \ / Max Laier | ICQ #67774661 X http://pf4freebsd.love2party.net/ | mlaier@EFnet / \ ASCII Ribbon Campaign | Against HTML Mail and News --Boundary-01=_0PGrC/u4C6yc+AM Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Description: Max Laier : cvs commit: src/sys/netinet ip_fw2.c Content-Disposition: inline; filename*= Return-Path: Delivered-To: mlaier@vampire.homelinux.org Received: (qmail 51960 invoked by alias); 12 Jun 2005 16:27:44 -0000 Delivered-To: max@vampire.homelinux.org Received: (qmail 51957 invoked from network); 12 Jun 2005 16:27:44 -0000 Received: from mx2.freebsd.org (216.136.204.119) by p54a3c3c9.dip.t-dialin.net with SMTP; 12 Jun 2005 16:27:44 -0000 Received: from hub.freebsd.org (hub.freebsd.org [216.136.204.18]) by mx2.freebsd.org (Postfix) with ESMTP id 0D70558DAF for ; Sun, 12 Jun 2005 16:27:17 +0000 (GMT) (envelope-from owner-src-committers@FreeBSD.org) Received: by hub.freebsd.org (Postfix) id 7514516A480; Sun, 12 Jun 2005 16:27:13 +0000 (GMT) Delivered-To: mlaier@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 538) id 5FEE116A420; Sun, 12 Jun 2005 16:27:11 +0000 (GMT) X-Original-To: src-committers@FreeBSD.org Delivered-To: src-committers@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AB5D116A41C; Sun, 12 Jun 2005 16:27:10 +0000 (GMT) (envelope-from mlaier@FreeBSD.org) Received: from repoman.freebsd.org (repoman.freebsd.org [216.136.204.115]) by mx1.FreeBSD.org (Postfix) with ESMTP id 725C743D1F; Sun, 12 Jun 2005 16:27:10 +0000 (GMT) (envelope-from mlaier@FreeBSD.org) Received: from repoman.freebsd.org (localhost [127.0.0.1]) by repoman.freebsd.org (8.13.1/8.13.1) with ESMTP id j5CGRAFg090004; Sun, 12 Jun 2005 16:27:10 GMT (envelope-from mlaier@repoman.freebsd.org) Received: (from mlaier@localhost) by repoman.freebsd.org (8.13.1/8.13.1/Submit) id j5CGRAMe090003; Sun, 12 Jun 2005 16:27:10 GMT (envelope-from mlaier) Message-Id: <200506121627.j5CGRAMe090003@repoman.freebsd.org> From: Max Laier Date: Sun, 12 Jun 2005 16:27:10 +0000 (UTC) To: src-committers@FreeBSD.org, cvs-src@FreeBSD.org, cvs-all@FreeBSD.org Subject: cvs commit: src/sys/netinet ip_fw2.c X-FreeBSD-CVS-Branch: HEAD Sender: owner-src-committers@FreeBSD.org Precedence: bulk X-Loop: FreeBSD.ORG Content-Type: X-UID: 30203 X-Length: 2823 mlaier 2005-06-12 16:27:10 UTC FreeBSD src repository Modified files: sys/netinet ip_fw2.c Log: When doing matching based on dst_ip/src_ip make sure we are really looking on an IPv4 packet as these variables are uninitialized if not. This used to allow arbitrary IPv6 packets depending on the value in the uninitialized variables. Some opcodes (most noteably O_REJECT) do not support IPv6 at all right now. Reviewed by: brooks, glebius Security: IPFW might pass IPv6 packets depending on stack contents. Approved by: re (blanket) Revision Changes Path 1.102 +13 -10 src/sys/netinet/ip_fw2.c --Boundary-01=_0PGrC/u4C6yc+AM-- --nextPart6079990.JVTdZoh8OC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCrGP5XyyEoT62BG0RApU5AJsFZZm4zlb6hF/yw8M33NsqE/CkZgCeN0+w tQeouPZfZc+e/XBfbo3oa60= =Qq/k -----END PGP SIGNATURE----- --nextPart6079990.JVTdZoh8OC-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 11 14:58: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 A038816A41C for ; Sat, 11 Jun 2005 14:58:08 +0000 (GMT) (envelope-from stefan.dietiker@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 555F643D4C for ; Sat, 11 Jun 2005 14:58:08 +0000 (GMT) (envelope-from stefan.dietiker@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so573124nzp for ; Sat, 11 Jun 2005 07:58:07 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=cDOAs3CXibmKMrNywa5X6n6xtqVzZ2IrrlPE0M1/VMbxONUBaSvUiZavo/mEzFr9IZkj4Wpe1S0svKup5gB6JP1Rb/ZX3Yh/mWT1RhXpWZD1xG1gA9Q0oAUIHLFRPZQEXZbtjvioC65NCgvk+92r1BQ/IVHmSfFopyzsjyHiRLE= Received: by 10.36.58.19 with SMTP id g19mr1991566nza; Sat, 11 Jun 2005 07:58:07 -0700 (PDT) Received: by 10.36.23.5 with HTTP; Sat, 11 Jun 2005 07:58:07 -0700 (PDT) Message-ID: Date: Sat, 11 Jun 2005 16:58:07 +0200 From: Stefan Dietiker To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Mailman-Approved-At: Sun, 12 Jun 2005 16:48:19 +0000 Subject: Atheros AR5213 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Stefan Dietiker List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2005 14:58:08 -0000 Hi I've got a simple but important question: Is the Atheros AR5213 chip supported on 6.0-current? greets me From owner-freebsd-current@FreeBSD.ORG Sat Jun 11 22:17: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 B68BB16A41C for ; Sat, 11 Jun 2005 22:17:23 +0000 (GMT) (envelope-from jasonh@cc.gatech.edu) Received: from sark4.cc.gatech.edu (sark4.cc.gatech.edu [130.207.7.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 67F7043D48 for ; Sat, 11 Jun 2005 22:17:23 +0000 (GMT) (envelope-from jasonh@cc.gatech.edu) Received: from siwenna.cc.gatech.edu (siwenna.cc.gatech.edu [130.207.7.232]) by sark4.cc.gatech.edu (8.12.10/8.12.8) with ESMTP id j5BMHMJ5024460 for ; Sat, 11 Jun 2005 18:17:22 -0400 (EDT) Received: (from www@localhost) by siwenna.cc.gatech.edu (8.12.10/8.12.8) id j5BMHMu5028875; Sat, 11 Jun 2005 18:17:22 -0400 (EDT) X-Authentication-Warning: siwenna.cc.gatech.edu: www set sender to jasonh@cc.gatech.edu using -f Received: from cpe-24-27-59-14.austin.res.rr.com ([24.27.59.14]) (SquirrelMail authenticated user jasonh); by webmail.cc.gatech.edu with HTTP; Sat, 11 Jun 2005 18:17:22 -0400 (EDT) Message-ID: <32946.24.27.59.14.1118528242.squirrel@24.27.59.14> Date: Sat, 11 Jun 2005 18:17:22 -0400 (EDT) From: jasonh@cc.gatech.edu To: freebsd-current@freebsd.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Mailman-Approved-At: Sun, 12 Jun 2005 16:48:19 +0000 Subject: Reboot when trying to load -current (amd64) 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: Sat, 11 Jun 2005 22:17:23 -0000 Hi all, I just tried upgrading from 5.4-STABLE/amd64 to 6.0-CURRENT/amd64, using the conventional cvsup/make buildworld/make kernel method. Everything built cleanly, but upon rebooting, I found that all of the boot loader options except "Escape to loader prompt" cause the machine to immediately reboot with absolutely no indication as to the cause of the problem. Nothing is displayed on the console, even with the verbose option. This happens both with GENERIC and my own custom (no SMP/debugging) kernel config. However, as I mentioned earlier, I can escape to a loader prompt and boot my 5.4 kernel with no problems. The mailing list and /usr/src/UPDATING don't seem to provide any hint as to what could be wrong--is there something obvious I'm missing? Here are the relevant lines from /etc/make.conf, in case that may have a bearing on my situation: CPUTYPE?=athlon64 CFLAGS= -O -pipe COPTFLAGS= -O -pipe Motherboard is Asus A8V Deluxe w/ Athlon 64 3500+. Thanks, Jason Harmening From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 04:24: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 06A9216A420; Sun, 12 Jun 2005 04:24:06 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id B379B43D1F; Sun, 12 Jun 2005 04:24:06 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 5AD4F278C; Sat, 11 Jun 2005 23:24:06 -0500 (CDT) Date: Sat, 11 Jun 2005 23:24:06 -0500 To: obrien@freebsd.org, Ruslan Ermilov , Dag-Erling Sm?rgrav , freebsd-current@freebsd.org Message-ID: <20050612042406.GB5996@soaustin.net> References: <20050609234619.AD1F67306E@freebsd-current.sentex.ca> <84dead720506091950779d1661@mail.gmail.com> <86oeae3d8f.fsf@xps.des.no> <20050610071828.GB78035@ip.net.ua> <867jh23bwh.fsf@xps.des.no> <20050610074706.GE78035@ip.net.ua> <20050612022105.GB67746@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050612022105.GB67746@dragon.NUXI.org> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Sun, 12 Jun 2005 16:48:19 +0000 Cc: Mark Linimon Subject: Re: [current tinderbox] failure on ...all... 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, 12 Jun 2005 04:24:07 -0000 > I tried. But Kris refused to consider the following for committing. > The problem is something like 3 ports will not build with > "-fno-strict-aliasing". Those are the gcc28, gnat[*] ports. > > [*] I really don't understand why we have a GCC 2.8 based Ada compiler > when Ada has been a native part of GCC since version 3.1... If these ports are useless, why don't we mark them DEPRECATED and after a decent interval, get rid of them? In this day and age, anyone who's on gcc27 or gcc28 is hopelessly behind anyways. I can't imagine that with the long-established track record of gcc295 there is any reason to keep them. mcl From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 05:47: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 4B2A316A41C for ; Sun, 12 Jun 2005 05:47:46 +0000 (GMT) (envelope-from fmayhar@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id D94C043D1D for ; Sun, 12 Jun 2005 05:47:45 +0000 (GMT) (envelope-from fmayhar@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so753065nzp for ; Sat, 11 Jun 2005 22:47:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:to:content-type:organization:date:message-id:mime-version:x-mailer:from; b=OBKvI/X899+t5uWN2C3NSXlIUbWtoDYXe03jlWDjFKZwfQR4m+xYMlci9sMWEZQnDFzLd6Zj/LFJ7vSO08dV8hzN1JoqWTu6KXJ2jSSNiWKDA/jDKSMO7b51gTywQIa5GH+Kj0/Aa/7Ad50uja3K46EhZAbXyudkIOheHny6Cj0= Received: by 10.36.222.44 with SMTP id u44mr2245537nzg; Sat, 11 Jun 2005 22:47:45 -0700 (PDT) Received: from localhost.localdomain ([4.233.41.252]) by mx.gmail.com with ESMTP id 38sm1935516nzk.2005.06.11.22.47.41; Sat, 11 Jun 2005 22:47:45 -0700 (PDT) To: current@freebsd.org Content-Type: multipart/mixed; boundary="=-+cYHkhlOiQdXLAMgo8w3" Organization: Exit Consulting Date: Sat, 11 Jun 2005 22:47:38 -0700 Message-Id: <1118555258.14559.7.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port From: Frank Mayhar X-Mailman-Approved-At: Sun, 12 Jun 2005 16:48:19 +0000 Cc: Subject: Silent ACPI-related reset booting latest 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: Sun, 12 Jun 2005 05:47:46 -0000 --=-+cYHkhlOiQdXLAMgo8w3 Content-Type: text/plain Content-Transfer-Encoding: 7bit I just rebuilt with the latest bits as of this afternoon. Apparently, some commit within the last 24 to 48 hours or so has broken ACPI on my Inspiron 5160. Booting with ACPI I get as far as 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 #43: Sat Jun 11 20:33:21 PDT 2005 frank@lap:/home/obj/usr/src/sys/AUTON WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Mobile Intel(R) Pentium(R) 4 CPU 2.80GHz (2790.72-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Features=0xbfebfbff Features2=0x459d> Hyperthreading: 2 logical CPUs real memory = 536662016 (511 MB) avail memory = 511586304 (487 MB) and it silently reboots. Without ACPI the boot continues. A full dmesg (without ACPI, obviously) is attached. This is just a heads-up. I haven't tried to figure it out yet and it's late so I'll look at it tomorrow at the earliest. (And maybe someone will fix it overnight. :-) -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ --=-+cYHkhlOiQdXLAMgo8w3 Content-Disposition: attachment; filename=dmesg.lap Content-Type: text/plain; name=dmesg.lap; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 #43: Sat Jun 11 20:33:21 PDT 2005 frank@lap:/home/obj/usr/src/sys/AUTON WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Mobile Intel(R) Pentium(R) 4 CPU 2.80GHz (2790.72-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf34 Stepping = 4 Features=0xbfebfbff Features2=0x459d> Hyperthreading: 2 logical CPUs real memory = 536662016 (511 MB) avail memory = 511586304 (487 MB) ath_hal: 0.9.14.9 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413) npx0: [FAST] npx0: on motherboard npx0: INT 16 interface cpu0 on motherboard est0: on cpu0 est: CPU supports Enhanced Speedstep, but is not recognized. est: Please update driver or contact the maintainer. est: cpu_vendor GenuineIntel, msr 152800001528, bus_clk, 64 device_attach: est0 attach returned 6 p4tcc0: on cpu0 pcib0: pcibus 0 on motherboard pir0: on motherboard $PIR: Using invalid BIOS IRQ 11 from 0.29.INTA is for link 0x60 pci0: on pcib0 pci0: at device 0.1 (no driver attached) pci0: at device 0.3 (no driver attached) pcib1: at device 1.0 on pci0 pci1: on pcib1 nvidia0: mem 0xfc000000-0xfcffffff,0xd0000000-0xdfffffff irq 11 at device 0.0 on pci1 nvidia0: [GIANT-LOCKED] uhci0: port 0xbf80-0xbf9f irq 11 at device 29.0 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 uhci1: port 0xbf40-0xbf5f irq 11 at device 29.1 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 uhci2: port 0xbf20-0xbf3f irq 11 at device 29.2 on pci0 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered ehci0: mem 0xf4fffc00-0xf4ffffff irq 11 at device 29.7 on pci0 ehci0: [GIANT-LOCKED] usb3: EHCI version 1.0 usb3: companion controllers, 2 ports each: usb0 usb1 usb2 usb3: on ehci0 usb3: USB revision 2.0 uhub3: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub3: 6 ports with 6 removable, self powered pcib2: at device 30.0 on pci0 pci2: on pcib2 bfe0: mem 0xfaffe000-0xfaffffff irq 11 at device 1.0 on pci2 miibus0: on bfe0 bmtphy0: on miibus0 bmtphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto bfe0: Ethernet address: 00:0f:1f:26:c6:65 bfe0: [GIANT-LOCKED] ath0: mem 0xfafe0000-0xfafeffff irq 11 at device 2.0 on pci2 ath0: [GIANT-LOCKED] ath0: Ethernet address: 00:02:6f:21:ed:0a ath0: mac 5.9 phy 4.3 radio 3.6 cbb0: irq 11 at device 4.0 on pci2 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 fwohci0: <1394 Open Host Controller Interface> mem 0xfaffd800-0xfaffdfff,0xfaff8000-0xfaffbfff irq 11 at device 4.1 on pci2 fwohci0: [GIANT-LOCKED] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 34:4f:c0:00:26:8f:58:a1 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 dcons_crom0: on firewire0 dcons_crom0: bus_addr 0x1f4ba000 sbp0: on firewire0 fwe0: on firewire0 if_fwe0: Fake Ethernet address: 36:4f:c0:8f:58:a1 fwe0: Ethernet address: 36:4f:c0:8f:58:a1 fwohci0: Initiate bus reset fwohci0: node_id=0xc000ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf at device 31.1 on pci0 ata0: on atapci0 ata1: on atapci0 pcm0: port 0xb800-0xb8ff,0xbc40-0xbc7f mem 0xf4fff800-0xf4fff9ff,0xf4fff400-0xf4fff4ff irq 11 at device 31.5 on pci0 pcm0: [GIANT-LOCKED] pcm0: orm0: at iomem 0xc0000-0xcf7ff,0xcf800-0xcffff 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 atkbdc0: at port 0x60,0x64 on isa0 atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: flags 0x1000 irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Generic PS/2 mouse, device ID 0 unknown: can't assign resources (memory) unknown: can't assign resources (port) unknown: can't assign resources (irq) Timecounter "TSC" frequency 2790720503 Hz quality 800 Timecounters tick every 1.000 msec acd0: DVDROM at ata0-master UDMA33 ad2: 57231MB at ata1-master UDMA100 ATA PseudoRAID loaded Trying to mount root from ufs:/dev/ad2s4a --=-+cYHkhlOiQdXLAMgo8w3-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 12:42:03 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 94B6016A41C; Sun, 12 Jun 2005 12:42:03 +0000 (GMT) (envelope-from delphij@geekcn.org) Received: from tarsier.geekcn.org (tarsier.geekcn.org [210.51.165.229]) by mx1.FreeBSD.org (Postfix) with ESMTP id 44D3443D49; Sun, 12 Jun 2005 12:42:02 +0000 (GMT) (envelope-from delphij@geekcn.org) Received: from [192.168.1.9] (unknown [221.221.168.89]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by tarsier.geekcn.org (Postfix) with ESMTP id 24ED4EB0B23; Sun, 12 Jun 2005 20:41:59 +0800 (CST) From: Xin LI To: Gleb Smirnoff In-Reply-To: <20050612123810.GA74776@cell.sick.ru> References: <20050612110631.GA74232@cell.sick.ru> <20050612123810.GA74776@cell.sick.ru> Content-Type: text/plain; charset=UTF-8 Date: Sun, 12 Jun 2005 20:41:47 +0800 Message-Id: <1118580107.819.1.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Sun, 12 Jun 2005 16:48:19 +0000 Cc: delphij@FreeBSD.org, current@FreeBSD.org Subject: Re: consoles broken on Thinkpad T20 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, 12 Jun 2005 12:42:03 -0000 在 2005-06-12日的 16:38 +0400，Gleb Smirnoff写é“： > On Sun, Jun 12, 2005 at 03:06:31PM +0400, Gleb Smirnoff wrote: > T> today I've upgraded to recent current, and got the following breakage. > T> When my notebook boots, right after printing "Updating motd", > T> screen goes black. After it has finished booting I can't switch > T> consoles - Alt-{F2,F3 .. F8} produces beep. ALt-F1 does not, but > T> screen is black. I've found a workaround - switching ttyv0 off > T> in /etc/ttys gives me ability to switch consoles and work. The first > T> vty is black still. > T> > T> I've also tried putting 'exit 0' in the very beginning of /etc/rc.d/syscons. > T> In this case I see as notebook continues to boot, but at the very end, > T> after local startup, the first vty goes black. > > I've found that problem is caused by /usr/sbin/ispcvt call from /etc/rc.d/syscons > and later rom /etc/rc.d/pcvt. > > Calling ispcvt by hand causes the same black screen and other symptoms as > describe in above quote. Which sys/dev/syscons/scvesactl.c version do you have? Is it 1.22? Cheers, From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 16:50: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 27E9016A41C; Sun, 12 Jun 2005 16:50:00 +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 DAF9643E62; Sun, 12 Jun 2005 16:42:03 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j5CGflhB093554; Sun, 12 Jun 2005 12:41:47 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j5CGg3tn044718; Sun, 12 Jun 2005 12:42:03 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id F227E7306E; Sun, 12 Jun 2005 12:42:02 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050612164202.F227E7306E@freebsd-current.sentex.ca> Date: Sun, 12 Jun 2005 12:42:02 -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 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: Sun, 12 Jun 2005 16:50:00 -0000 TB --- 2005-06-12 14:31:21 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-06-12 14:31:21 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2005-06-12 14:31:21 - cleaning the object tree TB --- 2005-06-12 14:31:54 - checking out the source tree TB --- 2005-06-12 14:31:54 - cd /home/tinderbox/CURRENT/ia64/ia64 TB --- 2005-06-12 14:31:54 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-06-12 14:37:43 - building world (CFLAGS=-O2 -pipe) TB --- 2005-06-12 14:37:43 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-06-12 14:37:43 - /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-06-12 16:10:29 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-12 16:10:29 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-06-12 16:10:29 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jun 12 16:10:29 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 Sun Jun 12 16:30:53 UTC 2005 TB --- 2005-06-12 16:30:53 - generating LINT kernel config TB --- 2005-06-12 16:30:53 - cd /home/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/conf TB --- 2005-06-12 16:30:53 - /usr/bin/make -B LINT TB --- 2005-06-12 16:30:53 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-12 16:30:53 - cd /home/tinderbox/CURRENT/ia64/ia64/src TB --- 2005-06-12 16:30:53 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 12 16:30:54 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/dev/twa -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT /ia64/ia64/src/sys/kern/md4c.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/dev/twa -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT /ia64/ia64/src/sys/kern/md5c.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/ia64/ia64/src/sys -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/altq -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/pf -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/ia64/ia64/src/sys/dev/twa -I/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /tinderbox/CURRENT /ia64/ia64/src/sys/kern/sched_4bsd.c In file included from /tinderbox/CURRENT/ia64/ia64/src/sys/kern/sched_4bsd.c:1388: /tinderbox/CURRENT/ia64/ia64/src/sys/kern/kern_switch.c: In function `maybe_preempt_in_ksegrp': /tinderbox/CURRENT/ia64/ia64/src/sys/kern/kern_switch.c:435: error: `IPI_PREEMPT' undeclared (first use in this function) /tinderbox/CURRENT/ia64/ia64/src/sys/kern/kern_switch.c:435: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/ia64/ia64/src/sys/kern/kern_switch.c:435: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/obj/ia64/tinderbox/CURRENT/ia64/ia64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /tinderbox/CURRENT/ia64/ia64/src. TB --- 2005-06-12 16:42:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-06-12 16:42:02 - ERROR: failed to build lint kernel TB --- 2005-06-12 16:42:02 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 16:54: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 1C20316A44F for ; Sun, 12 Jun 2005 16:54:30 +0000 (GMT) (envelope-from fmayhar@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id BD71D43F00 for ; Sun, 12 Jun 2005 16:51:27 +0000 (GMT) (envelope-from fmayhar@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so19770nzp for ; Sun, 12 Jun 2005 09:51:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:to:cc:in-reply-to:references:content-type:organization:date:message-id:mime-version:x-mailer:content-transfer-encoding:from; b=TUlUUzwCPru8EaOe6qKOsyMqXPL0wuubvIgxHJNI1Ah8IR1eZ+D3hTTc1JWFRn0tiYAzJfVCJ/a+uOLxXo0sC4Og3EfOiwPRfU6t3jCxqbeGwkyhOe+vfjcWl2PGb4UebYIIonOsZmZx7gxVhUlw6PisWh5QBfXXRK2bflSO3PA= Received: by 10.36.3.2 with SMTP id 2mr2343170nzc; Sun, 12 Jun 2005 09:51:23 -0700 (PDT) Received: from localhost.localdomain ([4.232.111.208]) by mx.gmail.com with ESMTP id 17sm2331956nzo.2005.06.12.09.51.21; Sun, 12 Jun 2005 09:51:23 -0700 (PDT) To: Stefan Dietiker In-Reply-To: References: Content-Type: text/plain Organization: Exit Consulting Date: Sun, 12 Jun 2005 09:51:18 -0700 Message-Id: <1118595078.16330.3.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit From: Frank Mayhar Cc: freebsd-current@freebsd.org Subject: Re: Atheros AR5213 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, 12 Jun 2005 16:54:30 -0000 On Sat, 2005-06-11 at 16:58 +0200, Stefan Dietiker wrote: > I've got a simple but important question: Is the Atheros AR5213 chip > supported on 6.0-current? ath0@pci2:2:0: class=0x020000 card=0x2042168c chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' class = network subclass = ethernet The short answer is "yes." -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 16:54: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 6A88016A475 for ; Sun, 12 Jun 2005 16:54:54 +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 AC8E143E4D for ; Sun, 12 Jun 2005 16:54:31 +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 j5CGsUtq011868; Sun, 12 Jun 2005 09:54:30 -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 j5CGsUNQ011867; Sun, 12 Jun 2005 09:54:30 -0700 (PDT) (envelope-from sgk) Date: Sun, 12 Jun 2005 09:54:30 -0700 From: Steve Kargl To: jasonh@cc.gatech.edu Message-ID: <20050612165430.GA11825@troutmask.apl.washington.edu> References: <32946.24.27.59.14.1118528242.squirrel@24.27.59.14> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <32946.24.27.59.14.1118528242.squirrel@24.27.59.14> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Reboot when trying to load -current (amd64) 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: Sun, 12 Jun 2005 16:54:57 -0000 On Sat, Jun 11, 2005 at 06:17:22PM -0400, jasonh@cc.gatech.edu wrote: > > I just tried upgrading from 5.4-STABLE/amd64 to 6.0-CURRENT/amd64, using > the conventional cvsup/make buildworld/make kernel method. Everything > built cleanly, but upon rebooting, I found that all of the boot loader > options except "Escape to loader prompt" cause the machine to immediately > reboot with absolutely no indication as to the cause of the problem. > Nothing is displayed on the console, even with the verbose option. This > happens both with GENERIC and my own custom (no SMP/debugging) kernel > config. However, as I mentioned earlier, I can escape to a loader prompt > and boot my 5.4 kernel with no problems. The mailing list and > /usr/src/UPDATING don't seem to provide any hint as to what could be > wrong--is there something obvious I'm missing? > -current of amd64 is currently hosed. -- Steve From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 17:37: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 E47F916A41C for ; Sun, 12 Jun 2005 17:37:48 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from ariel.yandex.ru (ariel.yandex.ru [213.180.200.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B8D643D1D for ; Sun, 12 Jun 2005 17:37:48 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from YAMAIL (ariel.yandex.ru) by mail.yandex.ru id ; Sun, 12 Jun 2005 21:37:42 +0400 Date: Sun, 12 Jun 2005 21:37:42 +0400 (MSD) From: "Polakov Alexander" Sender: polachok@narod.ru Message-Id: <42AC72E6.000001.07944@ariel.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: polachok@narod.ru To: jojo@matfyz.cz, freebsd-current@freebsd.org In-Reply-To: <20050612142203.GA16377@artax.karlin.mff.cuni.cz> References: <42AC3A7F.000002.04175@colgate.yandex.ru> <20050612142203.GA16377@artax.karlin.mff.cuni.cz> X-Source-Ip: 213.158.3.113 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: Subject: Re: cannot build anything big X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: polachok@narod.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2005 17:37:49 -0000 >On 2005-06-12 17:37 +0400, Polakov Alexander wrote: >> I cannot build anything big: kernel, CURRENT's world, then Xorg, perl. > >Why? What happens? > >> I rebuilt openbox & fluxbox and they fails with a core dump, so I have >> to get prebuilt packages. >> CFLAGS are not set. The CPUTYPE is set to pentium3. Kernel is compiled >> with PREEMPTION and ULE scheduler. >> Please, help! > >Looks like a faulty memory. > >-- >Marian Cerny You say faulty memory. But a few minutes ago I finished building/installing FreeBSD-STABLE. I booted form a FreeSBIE livecd and compiled the STABLE world with FreeSBIE's tools. Now I'll try to build CURRENT again, form just installed STABLE. -- Alexander Polakov From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 17:39: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 6776D16A41C for ; Sun, 12 Jun 2005 17:39:18 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from ariel.yandex.ru (ariel.yandex.ru [213.180.200.32]) by mx1.FreeBSD.org (Postfix) with ESMTP id 815A543D1D for ; Sun, 12 Jun 2005 17:39:17 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from YAMAIL (ariel.yandex.ru) by mail.yandex.ru id ; Sun, 12 Jun 2005 21:39:09 +0400 Date: Sun, 12 Jun 2005 21:39:09 +0400 (MSD) From: "Polakov Alexander" Sender: polachok@narod.ru Message-Id: <42AC733D.000004.07935@ariel.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: polachok@narod.ru To: sgk@troutmask.apl.washington.edu, freebsd-current@freebsd.org In-Reply-To: <20050612144854.GC10314@troutmask.apl.washington.edu> References: <42AC3A7F.000002.04175@colgate.yandex.ru> <20050612144854.GC10314@troutmask.apl.washington.edu> X-Source-Ip: 213.158.3.113 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_9PFZPWYXFQQMYJ0CCJD0" Cc: Subject: Re: cannot build anything big X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: polachok@narod.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Jun 2005 17:39:18 -0000 --------------Boundary-00=_9PFZPWYXFQQMYJ0CCJD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit >On Sun, Jun 12, 2005 at 05:37:03PM +0400, Polakov Alexander wrote: >> I cannot build anything big: kernel, CURRENT's world, then Xorg, perl. >> I rebuilt openbox & fluxbox and they fails with a core dump, so I have >> to get prebuilt packages. >> CFLAGS are not set. The CPUTYPE is set to pentium3. Kernel is compiled >> with PREEMPTION and ULE scheduler. >> Please, help! > >What are the reported errors? > Excuse me, please, I forgot the typescript. -- Alexander Polakov --------------Boundary-00=_9PFZPWYXFQQMYJ0CCJD0 Content-Disposition: attachment; Filename="typescript" Content-Type: application/octet-stream; name="typescript" Content-Transfer-Encoding: base64 U2NyaXB0IHN0YXJ0ZWQgb24gU2F0IEp1biAxMSAyMToxOTozNiAyMDA1CmRhcmtzdGFyIyB1bmFt ZSAtYRtbMTFgZGF0ZRtbSw0bWzExYHJtIC1yZiAvdmFyL2RiL3NldHVwLmV4ZS9uYW5vLTEuMi4z LxtbMTFgbWFuIHRwdXQbW0sbWzExYC91c3IvYmluL3RwdXQgY2ggMTAbWzExYG1hbiB0cHV0G1tL G1sxMWBybSAtcmYgL3Zhci9kYi9zZXR1cC5leGUvbmFuby0xLjIuMy8bWzExYGRhdGUbW0sNG1sx MWB1bmFtZSAtYRtbMTFgG1tLBwcHBwcHBwcHcHdkDQ0KL3Vzci9zcmMNCmRhcmtzdGFyIyBjZAgb W0sIG1tLcm0gLXJmIC91c3Ivb2JqLw0NCmRhcmtzdGFyIyBscyAvdXNyL29iB2oHCBtbSwgbW0sI G1tLCBtbSwgbW0sIG1tLCBtbSwgbW0sICBtbSwgbW0tta2RpciAvdXNyL29iagcNDQpkYXJrc3Rh ciMgbWFrZSBidWlsZHdvcmxkDQ0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+IFJlYnVpbGRpbmcgdGhlIHRlbXBvcmFy eSBidWlsZCB0cmVlDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0Kcm0gLXJmIC91c3Ivb2JqL3Vzci9zcmMvdG1wDQpta2RpciAt cCAvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2Jpbg0KbWtkaXIgLXAgL3Vzci9vYmov dXNyL3NyYy90bXAvbGVnYWN5L3Vzci9nYW1lcw0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy90 bXAvbGVnYWN5L3Vzci9pbmNsdWRlL2MrKy8zLjQNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMv dG1wL2xlZ2FjeS91c3IvaW5jbHVkZS9zeXMNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvdG1w L2xlZ2FjeS91c3IvbGliDQpta2RpciAtcCAvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNy L2xpYmV4ZWMNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2Jpbg0K bWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9zaGFyZS9kaWN0DQpta2Rp ciAtcCAvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL3NoYXJlL2dyb2ZmX2ZvbnQvZGV2 WDEwMA0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9zaGFyZS9ncm9m Zl9mb250L2RldlgxMDAtMTINCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91 c3Ivc2hhcmUvZ3JvZmZfZm9udC9kZXZYNzUNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvdG1w L2xlZ2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9udC9kZXZYNzUtMTINCm1rZGlyIC1wIC91c3Ivb2Jq L3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9udC9kZXZhc2NpaQ0KbWtkaXIg LXAgL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9zaGFyZS9ncm9mZl9mb250L2RldmNw MTA0Nw0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9zaGFyZS9ncm9m Zl9mb250L2RldmR2aQ0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9z aGFyZS9ncm9mZl9mb250L2Rldmh0bWwNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xl Z2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9udC9kZXZrb2k4LXINCm1rZGlyIC1wIC91c3Ivb2JqL3Vz ci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9udC9kZXZsYXRpbjENCm1rZGlyIC1w IC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9udC9kZXZsYnAN Cm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvZ3JvZmZfZm9u dC9kZXZsajQNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUv Z3JvZmZfZm9udC9kZXZwcw0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vz ci9zaGFyZS9ncm9mZl9mb250L2RldnV0ZjgNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvdG1w L2xlZ2FjeS91c3Ivc2hhcmUvdG1hYy9tZG9jDQpta2RpciAtcCAvdXNyL29iai91c3Ivc3JjL3Rt cC9sZWdhY3kvdXNyL3NoYXJlL3RtYWMvbW0NCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvdG1w L2xpYg0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy90bXAvdXNyL2Jpbg0KbWtkaXIgLXAgL3Vz ci9vYmovdXNyL3NyYy90bXAvdXNyL2luY2x1ZGUNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMv dG1wL3Vzci9saWIvY29tcGF0L2FvdXQNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vz ci9saWJkYXRhL2xkc2NyaXB0cw0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy90bXAvdXNyL2xp YmV4ZWMNCm1rZGlyIC1wIC91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9zYmluDQpta2RpciAtcCAv dXNyL29iai91c3Ivc3JjL3RtcC91c3Ivc2hhcmUvbWlzYw0KbWtkaXIgLXAgL3Vzci9vYmovdXNy L3NyYy90bXAvdXNyL3NoYXJlL3NubXAvZGVmcw0KbWtkaXIgLXAgL3Vzci9vYmovdXNyL3NyYy90 bXAvdXNyL3NoYXJlL3NubXAvbWlicw0KbXRyZWUgLWRlVSAtZiAvdXNyL3NyYy9ldGMvbXRyZWUv QlNELmluY2x1ZGUuZGlzdCAgLXAgL3Vzci9vYmovdXNyL3NyYy90bXAvdXNyL2luY2x1ZGUgPi9k ZXYvbnVsbA0KbG4gLXNmIC91c3Ivc3JjL3N5cyAvdXNyL29iai91c3Ivc3JjL3RtcA0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KPj4+IHN0YWdlIDEuMTogbGVnYWN5IHJlbGVhc2UgY29tcGF0aWJpbGl0eSBzaGltcw0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCmNkIC91c3Ivc3JjOyBNQUtFT0JKRElSUFJFRklYPS91c3Ivb2JqL3Vzci9zcmMvdG1wICBJ TlNUQUxMPSJzaCAvdXNyL3NyYy90b29scy9pbnN0YWxsLnNoIiAgUEFUSD0vdXNyL29iai91c3Iv c3JjL3RtcC9sZWdhY3kvdXNyL3NiaW46L3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9i aW46L3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9nYW1lczovc2JpbjovYmluOi91c3Iv c2JpbjovdXNyL2JpbiAgV09STERUTVA9L3Vzci9vYmovdXNyL3NyYy90bXAgIE1BS0VGTEFHUz0i LW0gL3Vzci9zcmMvdG9vbHMvYnVpbGQvbWsgIC1tIC91c3Ivc3JjL3NoYXJlL21rIiBtYWtlIC1m IE1ha2VmaWxlLmluYzEgIERFU1RESVI9ICBCT09UU1RSQVBQSU5HPTYwMDAzMCAgLUROT19IVE1M IC1ETk9fSU5GTyAtRE5PX0xJTlQgLUROT19NQU4gLUROT19OTFMgLUROT19QSUMgIC1ETk9fUFJP RklMRSAtRE5PX1NIQVJFRCAtRE5PX0NQVV9DRkxBR1MgLUROT19XQVJOUyBsZWdhY3kNCj09PT4g dG9vbHMvYnVpbGQgKG9iaixpbmNsdWRlcyxkZXBlbmQsYWxsLGluc3RhbGwpDQovdXNyL29iai91 c3Ivc3JjL3RtcC91c3Ivc3JjL3Rvb2xzL2J1aWxkIGNyZWF0ZWQgZm9yIC91c3Ivc3JjL3Rvb2xz L2J1aWxkDQpjZCAvdXNyL3NyYy90b29scy9idWlsZDsgbWFrZSBidWlsZGluY2x1ZGVzOyBtYWtl IGluc3RhbGxpbmNsdWRlcw0Kcm0gLWYgLmRlcGVuZA0KbWtkZXAgLWYgLmRlcGVuZCAtYSAgICAt SS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAvdXNyL3NyYy90b29scy9i dWlsZC9kdW1teS5jDQpjYyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgIC1JL3Vzci9v YmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL3Rvb2xzL2J1aWxk L2R1bW15LmMNCmJ1aWxkaW5nIHN0YXRpYyBlZ2FjeSBsaWJyYXJ5DQpyYW5saWIgbGliZWdhY3ku YQ0Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtQyAtbyByb290IC1nIHdoZWVsIC1tIDQ0 NCAgIGxpYmVnYWN5LmEgL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9saWINCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+PiBzdGFnZSAxLjI6IGJvb3RzdHJhcCB0b29scw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCmNkIC91c3Ivc3JjOyBN QUtFT0JKRElSUFJFRklYPS91c3Ivb2JqL3Vzci9zcmMvdG1wICBJTlNUQUxMPSJzaCAvdXNyL3Ny Yy90b29scy9pbnN0YWxsLnNoIiAgUEFUSD0vdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNy L3NiaW46L3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9iaW46L3Vzci9vYmovdXNyL3Ny Yy90bXAvbGVnYWN5L3Vzci9nYW1lczovc2JpbjovYmluOi91c3Ivc2JpbjovdXNyL2JpbiAgV09S TERUTVA9L3Vzci9vYmovdXNyL3NyYy90bXAgIE1BS0VGTEFHUz0iLW0gL3Vzci9zcmMvdG9vbHMv YnVpbGQvbWsgIC1tIC91c3Ivc3JjL3NoYXJlL21rIiBtYWtlIC1mIE1ha2VmaWxlLmluYzEgIERF U1RESVI9ICBCT09UU1RSQVBQSU5HPTYwMDAzMCAgLUROT19IVE1MIC1ETk9fSU5GTyAtRE5PX0xJ TlQgLUROT19NQU4gLUROT19OTFMgLUROT19QSUMgIC1ETk9fUFJPRklMRSAtRE5PX1NIQVJFRCAt RE5PX0NQVV9DRkxBR1MgLUROT19XQVJOUyBib290c3RyYXAtdG9vbHMNCj09PT4gZ2FtZXMvZm9y dHVuZS9zdHJmaWxlIChvYmosZGVwZW5kLGFsbCxpbnN0YWxsKQ0KL3Vzci9vYmovdXNyL3NyYy90 bXAvdXNyL3NyYy9nYW1lcy9mb3J0dW5lL3N0cmZpbGUgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ2Ft ZXMvZm9ydHVuZS9zdHJmaWxlDQpybSAtZiAuZGVwZW5kDQpta2RlcCAtZiAuZGVwZW5kIC1hICAg IC1JL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC91c3Ivc3JjL2dhbWVz L2ZvcnR1bmUvc3RyZmlsZS9zdHJmaWxlLmMNCmVjaG8gc3RyZmlsZTogL3Vzci9saWIvbGliYy5h IC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvbGliL2xpYmVnYWN5LmEgPj4gLmRlcGVu ZA0KY2MgLU8yIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1waXBlICAtSS91c3Ivb2JqL3Vzci9zcmMv dG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy9nYW1lcy9mb3J0dW5lL3N0cmZpbGUv c3RyZmlsZS5jDQpjYyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgIC1JL3Vzci9vYmov dXNyL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlICAtc3RhdGljIC1ML3Vzci9vYmovdXNyL3Ny Yy90bXAvbGVnYWN5L3Vzci9saWIgLW8gc3RyZmlsZSBzdHJmaWxlLm8gLWxlZ2FjeQ0Kc2ggL3Vz ci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtcyAtbyByb290IC1nIHdoZWVsIC1tIDU1NSAgIHN0cmZp bGUgL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9nYW1lcw0KPT09PiBnbnUvdXNyLmJp bi9ncGVyZiAob2JqLGRlcGVuZCxhbGwsaW5zdGFsbCkNCi91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vz ci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4v Z3BlcmYNCj09PT4gZ251L3Vzci5iaW4vZ3BlcmYvZG9jIChvYmopDQovdXNyL29iai91c3Ivc3Jj L3RtcC91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmL2RvYyBjcmVhdGVkIGZvciAvdXNyL3NyYy9n bnUvdXNyLmJpbi9ncGVyZi9kb2MNCnJtIC1mIC5kZXBlbmQNCm1rZGVwIC1mIC5kZXBlbmQgLWEg ICAgLUkvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLUkvdXNyL3NyYy9n bnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dwZXJmL2xpYiAtSS91c3Ivc3JjL2du dS91c3IuYmluL2dwZXJmICAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250 cmliL2dwZXJmL3NyYy9ib29sLWFycmF5LmNjIC91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmLy4u Ly4uLy4uL2NvbnRyaWIvZ3BlcmYvc3JjL2dlbi1wZXJmLmNjIC91c3Ivc3JjL2dudS91c3IuYmlu L2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvc3JjL2hhc2gtdGFibGUuY2MgL3Vzci9zcmMv Z251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9zcmMvaXRlcmF0b3IuY2Mg L3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9zcmMva2V5 LWxpc3QuY2MgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVy Zi9zcmMvbGlzdC1ub2RlLmNjIC91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmLy4uLy4uLy4uL2Nv bnRyaWIvZ3BlcmYvc3JjL21haW4uY2MgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4v Li4vY29udHJpYi9ncGVyZi9zcmMvbmV3LmNjIC91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmLy4u Ly4uLy4uL2NvbnRyaWIvZ3BlcmYvc3JjL29wdGlvbnMuY2MgL3Vzci9zcmMvZ251L3Vzci5iaW4v Z3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9zcmMvcmVhZC1saW5lLmNjIC91c3Ivc3JjL2du dS91c3IuYmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvc3JjL3RyYWNlLmNjIC91c3Iv c3JjL2dudS91c3IuYmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvc3JjL3ZlY3RvcnMu Y2MgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9zcmMv dmVyc2lvbi5jYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dw ZXJmL2xpYi9oYXNoLmNjICAgDQplY2hvIGdwZXJmOiAvdXNyL2xpYi9saWJjLmEgL3Vzci9vYmov dXNyL3NyYy90bXAvbGVnYWN5L3Vzci9saWIvbGliZWdhY3kuYSA+PiAuZGVwZW5kDQplY2hvIGdw ZXJmOiAvdXNyL2xpYi9saWJzdGRjKysuYSA+PiAuZGVwZW5kDQo9PT0+IGdudS91c3IuYmluL2dw ZXJmL2RvYyAoZGVwZW5kKQ0KYysrIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZSAtSS91 c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtSS91c3Ivc3JjL2dudS91c3Iu YmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvbGliIC1JL3Vzci9zcmMvZ251L3Vzci5i aW4vZ3BlcmYgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9n cGVyZi9zcmMvYm9vbC1hcnJheS5jYw0KYysrIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlw ZSAtSS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtSS91c3Ivc3JjL2du dS91c3IuYmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvbGliIC1JL3Vzci9zcmMvZ251 L3Vzci5iaW4vZ3BlcmYgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29u dHJpYi9ncGVyZi9zcmMvZ2VuLXBlcmYuY2MNCmMrKyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcg LXBpcGUgLUkvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLUkvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dwZXJmL2xpYiAtSS91c3Ivc3Jj L2dudS91c3IuYmluL2dwZXJmIC1jIC91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmLy4uLy4uLy4u L2NvbnRyaWIvZ3BlcmYvc3JjL2hhc2gtdGFibGUuY2MNCmMrKyAtTzIgLWZuby1zdHJpY3QtYWxp YXNpbmcgLXBpcGUgLUkvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLUkv dXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dwZXJmL2xpYiAtSS91 c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmIC1jIC91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmLy4u Ly4uLy4uL2NvbnRyaWIvZ3BlcmYvc3JjL2l0ZXJhdG9yLmNjDQpjKysgLU8yIC1mbm8tc3RyaWN0 LWFsaWFzaW5nIC1waXBlIC1JL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRl IC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9saWIg LUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZiAtYyAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVy Zi8uLi8uLi8uLi9jb250cmliL2dwZXJmL3NyYy9rZXktbGlzdC5jYw0KYysrIC1PMiAtZm5vLXN0 cmljdC1hbGlhc2luZyAtcGlwZSAtSS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvaW5j bHVkZSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYv bGliIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYgLWMgL3Vzci9zcmMvZ251L3Vzci5iaW4v Z3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9zcmMvbGlzdC1ub2RlLmNjDQpjKysgLU8yIC1m bm8tc3RyaWN0LWFsaWFzaW5nIC1waXBlIC1JL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vz ci9pbmNsdWRlIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9n cGVyZi9saWIgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZiAtYyAvdXNyL3NyYy9nbnUvdXNy LmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dwZXJmL3NyYy9tYWluLmNjDQpjKysgLU8yIC1m bm8tc3RyaWN0LWFsaWFzaW5nIC1waXBlIC1JL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vz ci9pbmNsdWRlIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9n cGVyZi9saWIgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZiAtYyAvdXNyL3NyYy9nbnUvdXNy LmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dwZXJmL3NyYy9uZXcuY2MNCmMrKyAtTzIgLWZu by1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLUkvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNy L2luY2x1ZGUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmliL2dw ZXJmL2xpYiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmIC1jIC91c3Ivc3JjL2dudS91c3Iu YmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvc3JjL29wdGlvbnMuY2MNCmMrKyAtTzIg LWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLUkvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kv dXNyL2luY2x1ZGUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9jb250cmli L2dwZXJmL2xpYiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmIC1jIC91c3Ivc3JjL2dudS91 c3IuYmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvc3JjL3JlYWQtbGluZS5jYw0KYysr IC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZSAtSS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xl Z2FjeS91c3IvaW5jbHVkZSAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmLy4uLy4uLy4uL2Nv bnRyaWIvZ3BlcmYvbGliIC1JL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3BlcmYgLWMgL3Vzci9zcmMv Z251L3Vzci5iaW4vZ3BlcmYvLi4vLi4vLi4vY29udHJpYi9ncGVyZi9zcmMvdHJhY2UuY2MNCmMr KyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLUkvdXNyL29iai91c3Ivc3JjL3RtcC9s ZWdhY3kvdXNyL2luY2x1ZGUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8uLi9j b250cmliL2dwZXJmL2xpYiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmIC1jIC91c3Ivc3Jj L2dudS91c3IuYmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvc3JjL3ZlY3RvcnMuY2MN CmMrKyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLUkvdXNyL29iai91c3Ivc3JjL3Rt cC9sZWdhY3kvdXNyL2luY2x1ZGUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8uLi8u Li9jb250cmliL2dwZXJmL2xpYiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmIC1jIC91c3Iv c3JjL2dudS91c3IuYmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvc3JjL3ZlcnNpb24u Y2MNCmMrKyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLUkvdXNyL29iai91c3Ivc3Jj L3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8u Li8uLi9jb250cmliL2dwZXJmL2xpYiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmIC1jIC91 c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmLy4uLy4uLy4uL2NvbnRyaWIvZ3BlcmYvbGliL2hhc2gu Y2MNCmMrKyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLUkvdXNyL29iai91c3Ivc3Jj L3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLUkvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncGVyZi8uLi8u Li8uLi9jb250cmliL2dwZXJmL2xpYiAtSS91c3Ivc3JjL2dudS91c3IuYmluL2dwZXJmICAtc3Rh dGljIC1ML3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9saWIgLW8gZ3BlcmYgYm9vbC1h cnJheS5vIGdlbi1wZXJmLm8gaGFzaC10YWJsZS5vIGl0ZXJhdG9yLm8ga2V5LWxpc3QubyBsaXN0 LW5vZGUubyBtYWluLm8gbmV3Lm8gb3B0aW9ucy5vIHJlYWQtbGluZS5vIHRyYWNlLm8gdmVjdG9y cy5vIHZlcnNpb24ubyBoYXNoLm8gLWxlZ2FjeQ0KPT09PiBnbnUvdXNyLmJpbi9ncGVyZi9kb2Mg KGFsbCkNCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLXMgLW8gcm9vdCAtZyB3aGVlbCAt bSA1NTUgICBncGVyZiAvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2Jpbg0KPT09PiBn bnUvdXNyLmJpbi9ncGVyZi9kb2MgKGluc3RhbGwpDQo9PT0+IGdudS91c3IuYmluL2dyb2ZmL3Rt YWMgKG9iaixkZXBlbmQsYWxsLGluc3RhbGwpDQovdXNyL29iai91c3Ivc3JjL3RtcC91c3Ivc3Jj L2dudS91c3IuYmluL2dyb2ZmL3RtYWMgY3JlYXRlZCBmb3IgL3Vzci9zcmMvZ251L3Vzci5iaW4v Z3JvZmYvdG1hYw0Kc2VkIC1mIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMvLi4vLi4v Li4vLi4vY29udHJpYi9ncm9mZi90bWFjL3N0cmlwLnNlZCAvdXNyL3NyYy9nbnUvdXNyLmJpbi9n cm9mZi90bWFjLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ3JvZmYvdG1hYy9kb2MtY29tbW9uID4gZG9j LWNvbW1vbi1zDQpzZWQgLWYgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1hYy8uLi8uLi8u Li8uLi9jb250cmliL2dyb2ZmL3RtYWMvc3RyaXAuc2VkIC91c3Ivc3JjL2dudS91c3IuYmluL2dy b2ZmL3RtYWMvLi4vLi4vLi4vLi4vY29udHJpYi9ncm9mZi90bWFjL2RvYy1kaXRyb2ZmID4gZG9j LWRpdHJvZmYtcw0Kc2VkIC1mIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMvLi4vLi4v Li4vLi4vY29udHJpYi9ncm9mZi90bWFjL3N0cmlwLnNlZCAvdXNyL3NyYy9nbnUvdXNyLmJpbi9n cm9mZi90bWFjLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ3JvZmYvdG1hYy9kb2MtbnJvZmYgPiBkb2Mt bnJvZmYtcw0Kc2VkIC1mIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMvLi4vLi4vLi4v Li4vY29udHJpYi9ncm9mZi90bWFjL3N0cmlwLnNlZCAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9m Zi90bWFjLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ3JvZmYvdG1hYy9kb2Mtc3ltcyA+IGRvYy1zeW1z LXMNCnNlZCAtZiAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi90bWFjLy4uLy4uLy4uLy4uL2Nv bnRyaWIvZ3JvZmYvdG1hYy9zdHJpcC5zZWQgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1h Yy9mci5JU084ODU5LTEgPiBmci5JU084ODU5LTEtcw0Kc2VkIC1mIC91c3Ivc3JjL2dudS91c3Iu YmluL2dyb2ZmL3RtYWMvLi4vLi4vLi4vLi4vY29udHJpYi9ncm9mZi90bWFjL3N0cmlwLnNlZCAv dXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi90bWFjL3J1LktPSTgtUiA+IHJ1LktPSTgtUi1zDQpz ZWQgLWYgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1hYy8uLi8uLi8uLi8uLi9jb250cmli L2dyb2ZmL3RtYWMvc3RyaXAuc2VkIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMvLi4v Li4vLi4vLi4vY29udHJpYi9ncm9mZi90bWFjL2UudG1hYyA+IGUudG1hYy1zDQpzZWQgLWYgL3Vz ci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1hYy8uLi8uLi8uLi8uLi9jb250cmliL2dyb2ZmL3Rt YWMvc3RyaXAuc2VkIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMvLi4vLi4vLi4vLi4v Y29udHJpYi9ncm9mZi90bWFjL2RvYy50bWFjID4gZG9jLnRtYWMtcw0Kc2VkIC1mIC91c3Ivc3Jj L2dudS91c3IuYmluL2dyb2ZmL3RtYWMvLi4vLi4vLi4vLi4vY29udHJpYi9ncm9mZi90bWFjL3N0 cmlwLnNlZCAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi90bWFjL21kb2MubG9jYWwgPiBtZG9j LmxvY2FsLXMNCnNlZCAtZSAicztAVE1BQ19BTl9QUkVGSVhAOztnIiAgLWUgInM7QFRNQUNfU19Q UkVGSVhAOztnIiAgLWUgInM7QFBOTVRPUFNfTk9TRVRQQUdFQDtwbm10b3BzO2ciICAvdXNyL3Ny Yy9nbnUvdXNyLmJpbi9ncm9mZi90bWFjLy4uLy4uLy4uLy4uL2NvbnRyaWIvZ3JvZmYvdG1hYy9h bi50bWFjID4gYW4udG1hYy1zDQpzZWQgLWUgInM7QFRNQUNfQU5fUFJFRklYQDs7ZyIgIC1lICJz O0BUTUFDX1NfUFJFRklYQDs7ZyIgIC1lICJzO0BQTk1UT1BTX05PU0VUUEFHRUA7cG5tdG9wcztn IiAgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1hYy8uLi8uLi8uLi8uLi9jb250cmliL2dy b2ZmL3RtYWMvbWFuLnRtYWMgPiBtYW4udG1hYy1zDQpzZWQgLWUgInM7QFRNQUNfQU5fUFJFRklY QDs7ZyIgIC1lICJzO0BUTUFDX1NfUFJFRklYQDs7ZyIgIC1lICJzO0BQTk1UT1BTX05PU0VUUEFH RUA7cG5tdG9wcztnIiAgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1hYy8uLi8uLi8uLi8u Li9jb250cmliL2dyb2ZmL3RtYWMvcy50bWFjID4gcy50bWFjLXMNCnNlZCAtZSAicztAVE1BQ19B Tl9QUkVGSVhAOztnIiAgLWUgInM7QFRNQUNfU19QUkVGSVhAOztnIiAgLWUgInM7QFBOTVRPUFNf Tk9TRVRQQUdFQDtwbm10b3BzO2ciICAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi90bWFjLy4u Ly4uLy4uLy4uL2NvbnRyaWIvZ3JvZmYvdG1hYy9tcy50bWFjID4gbXMudG1hYy1zDQpzZWQgLWUg InM7QFRNQUNfQU5fUFJFRklYQDs7ZyIgIC1lICJzO0BUTUFDX1NfUFJFRklYQDs7ZyIgIC1lICJz O0BQTk1UT1BTX05PU0VUUEFHRUA7cG5tdG9wcztnIiAgL3Vzci9zcmMvZ251L3Vzci5iaW4vZ3Jv ZmYvdG1hYy8uLi8uLi8uLi8uLi9jb250cmliL2dyb2ZmL3RtYWMvd3d3LnRtYWMgPiB3d3cudG1h Yy1zDQpjZCAvdXNyL3NyYy9nbnUvdXNyLmJpbi9ncm9mZi90bWFjLy4uLy4uLy4uLy4uL2NvbnRy aWIvZ3JvZmYvdG1hYzsgIHNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8gcm9vdCAtZyB3 aGVlbCAtbSA0NDQgIG1hbmRvYy50bWFjIGFuZG9jLnRtYWMgYW4tb2xkLnRtYWMgIG1lLnRtYWMg IG1kb2MudG1hYyAgcGljLnRtYWMgIGE0LnRtYWMgIHBhcGVyc2l6ZS50bWFjICBlYy50bWFjICBz YWZlci50bWFjICB0cmFjZS50bWFjICBwcy50bWFjIHBzb2xkLnRtYWMgcHNwaWMudG1hYyBwc2F0 ay50bWFjICBkdmkudG1hYyAgdHR5LnRtYWMgdHR5LWNoYXIudG1hYyAgbGF0aW4xLnRtYWMgbGF0 aW4yLnRtYWMgbGF0aW45LnRtYWMgY3AxMDQ3LnRtYWMgIFgudG1hYyBYcHMudG1hYyAgbGo0LnRt YWMgIGxicC50bWFjICBodG1sLnRtYWMgaHRtbC1lbmQudG1hYyAgZXVyb3BzLnRtYWMgIGNvbXBv c2l0ZS50bWFjICBlcW5yYyAgdHJvZmZyYyB0cm9mZnJjLWVuZCAgaHlwaGVuLnVzIGh5cGhlbmV4 LnVzIC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvdG1hYw0KY2QgL3Vzci9z cmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1hYzsgIHNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2gg LW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgIGtvaTgtci50bWFjIGh5cGhlbi5ydSAvdXNyL29iai91 c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL3NoYXJlL3RtYWMNCmNkIC91c3Ivb2JqL3Vzci9zcmMvdG1w L3Vzci9zcmMvZ251L3Vzci5iaW4vZ3JvZmYvdG1hYw0Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFs bC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgZS50bWFjLXMgL3Vzci9vYmovdXNyL3NyYy90 bXAvbGVnYWN5L3Vzci9zaGFyZS90bWFjL2UudG1hYw0Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFs bC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgZG9jLnRtYWMtcyAvdXNyL29iai91c3Ivc3Jj L3RtcC9sZWdhY3kvdXNyL3NoYXJlL3RtYWMvZG9jLnRtYWMNCnNoIC91c3Ivc3JjL3Rvb2xzL2lu c3RhbGwuc2ggLW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgIG1kb2MubG9jYWwtcyAvdXNyL29iai91 c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL3NoYXJlL3RtYWMvbWRvYy5sb2NhbA0Kc2ggL3Vzci9zcmMv dG9vbHMvaW5zdGFsbC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgYW4udG1hYy1zIC91c3Iv b2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvdG1hYy9hbi50bWFjDQpzaCAvdXNyL3Ny Yy90b29scy9pbnN0YWxsLnNoIC1vIHJvb3QgLWcgd2hlZWwgLW0gNDQ0ICBtYW4udG1hYy1zIC91 c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvdG1hYy9tYW4udG1hYw0Kc2ggL3Vz ci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgcy50bWFjLXMg L3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9zaGFyZS90bWFjL3MudG1hYw0Kc2ggL3Vz ci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgbXMudG1hYy1z IC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvdG1hYy9tcy50bWFjDQpzaCAv dXNyL3NyYy90b29scy9pbnN0YWxsLnNoIC1vIHJvb3QgLWcgd2hlZWwgLW0gNDQ0ICB3d3cudG1h Yy1zIC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvdG1hYy93d3cudG1hYw0K c2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgZG9j LWNvbW1vbi1zIC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Ivc2hhcmUvdG1hYy9tZG9j L2RvYy1jb21tb24NCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8gcm9vdCAtZyB3aGVl bCAtbSA0NDQgIGRvYy1kaXRyb2ZmLXMgL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9z aGFyZS90bWFjL21kb2MvZG9jLWRpdHJvZmYNCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2gg LW8gcm9vdCAtZyB3aGVlbCAtbSA0NDQgIGRvYy1ucm9mZi1zIC91c3Ivb2JqL3Vzci9zcmMvdG1w L2xlZ2FjeS91c3Ivc2hhcmUvdG1hYy9tZG9jL2RvYy1ucm9mZg0Kc2ggL3Vzci9zcmMvdG9vbHMv aW5zdGFsbC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgZG9jLXN5bXMtcyAvdXNyL29iai91 c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL3NoYXJlL3RtYWMvbWRvYy9kb2Mtc3ltcw0Kc2ggL3Vzci9z cmMvdG9vbHMvaW5zdGFsbC5zaCAtbyByb290IC1nIHdoZWVsIC1tIDQ0NCAgZnIuSVNPODg1OS0x LXMgL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9zaGFyZS90bWFjL21kb2MvZnIuSVNP ODg1OS0xDQpzaCAvdXNyL3NyYy90b29scy9pbnN0YWxsLnNoIC1vIHJvb3QgLWcgd2hlZWwgLW0g NDQ0ICBydS5LT0k4LVItcyAvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL3NoYXJlL3Rt YWMvbWRvYy9ydS5LT0k4LVINCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLW8gcm9vdCAt ZyB3aGVlbCAtbSA0NDQgIC91c3Ivc3JjL2dudS91c3IuYmluL2dyb2ZmL3RtYWMvLi4vLi4vLi4v Li4vY29udHJpYi9ncm9mZi90bWFjL21hbi5sb2NhbCAvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdh Y3kvdXNyL3NoYXJlL3RtYWMNCj09PT4gdXNyLmJpbi9sb3JkZXIgKG9iaixkZXBlbmQsYWxsLGlu c3RhbGwpDQovdXNyL29iai91c3Ivc3JjL3RtcC91c3Ivc3JjL3Vzci5iaW4vbG9yZGVyIGNyZWF0 ZWQgZm9yIC91c3Ivc3JjL3Vzci5iaW4vbG9yZGVyDQpzaCAvdXNyL3NyYy90b29scy9pbnN0YWxs LnNoIC1vIHJvb3QgIC1nIHdoZWVsIC1tIDU1NSAgL3Vzci9zcmMvdXNyLmJpbi9sb3JkZXIvbG9y ZGVyLnNoICAvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2Jpbi9sb3JkZXINCj09PT4g dXNyLmJpbi9tYWtld2hhdGlzIChvYmosZGVwZW5kLGFsbCxpbnN0YWxsKQ0KL3Vzci9vYmovdXNy L3NyYy90bXAvdXNyL3NyYy91c3IuYmluL21ha2V3aGF0aXMgY3JlYXRlZCBmb3IgL3Vzci9zcmMv dXNyLmJpbi9tYWtld2hhdGlzDQpybSAtZiAuZGVwZW5kDQpta2RlcCAtZiAuZGVwZW5kIC1hICAg IC1JL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC91c3Ivc3JjL3Vzci5i aW4vbWFrZXdoYXRpcy9tYWtld2hhdGlzLmMNCmVjaG8gbWFrZXdoYXRpczogL3Vzci9saWIvbGli Yy5hIC91c3IvbGliL2xpYnouYSAvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2xpYi9s aWJlZ2FjeS5hID4+IC5kZXBlbmQNCmNjIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZSAg LUkvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvdXNy LmJpbi9tYWtld2hhdGlzL21ha2V3aGF0aXMuYw0KY2MgLU8yIC1mbm8tc3RyaWN0LWFsaWFzaW5n IC1waXBlICAtSS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAgLXN0YXRp YyAtTC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvbGliIC1vIG1ha2V3aGF0aXMgbWFr ZXdoYXRpcy5vIC1seiAtbGVnYWN5DQpzaCAvdXNyL3NyYy90b29scy9pbnN0YWxsLnNoIC1zIC1v IHJvb3QgLWcgd2hlZWwgLW0gNTU1ICAgbWFrZXdoYXRpcyAvdXNyL29iai91c3Ivc3JjL3RtcC9s ZWdhY3kvdXNyL2Jpbg0Kc2ggL3Vzci9zcmMvdG9vbHMvaW5zdGFsbC5zaCAtbyByb290ICAtZyB3 aGVlbCAtbSA1NTUgIC91c3Ivc3JjL3Vzci5iaW4vbWFrZXdoYXRpcy9tYWtld2hhdGlzLmxvY2Fs LnNoICAvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2xpYmV4ZWMvbWFrZXdoYXRpcy5s b2NhbA0KL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9saWJleGVjL2NhdG1hbi5sb2Nh bCAtPiAvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2xpYmV4ZWMvbWFrZXdoYXRpcy5s b2NhbA0KPT09PiB1c3IuYmluL3JwY2dlbiAob2JqLGRlcGVuZCxhbGwsaW5zdGFsbCkNCi91c3Iv b2JqL3Vzci9zcmMvdG1wL3Vzci9zcmMvdXNyLmJpbi9ycGNnZW4gY3JlYXRlZCBmb3IgL3Vzci9z cmMvdXNyLmJpbi9ycGNnZW4NCnJtIC1mIC5kZXBlbmQNCm1rZGVwIC1mIC5kZXBlbmQgLWEgICAg LURpbmxpbmU9cnBjZ2VuX2lubGluZSAtSS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Iv aW5jbHVkZSAvdXNyL3NyYy91c3IuYmluL3JwY2dlbi9ycGNfbWFpbi5jIC91c3Ivc3JjL3Vzci5i aW4vcnBjZ2VuL3JwY19jbG50b3V0LmMgL3Vzci9zcmMvdXNyLmJpbi9ycGNnZW4vcnBjX2NvdXQu YyAvdXNyL3NyYy91c3IuYmluL3JwY2dlbi9ycGNfaG91dC5jIC91c3Ivc3JjL3Vzci5iaW4vcnBj Z2VuL3JwY19wYXJzZS5jIC91c3Ivc3JjL3Vzci5iaW4vcnBjZ2VuL3JwY19zYW1wbGUuYyAvdXNy L3NyYy91c3IuYmluL3JwY2dlbi9ycGNfc2Nhbi5jIC91c3Ivc3JjL3Vzci5iaW4vcnBjZ2VuL3Jw Y19zdmNvdXQuYyAvdXNyL3NyYy91c3IuYmluL3JwY2dlbi9ycGNfdGJsb3V0LmMgL3Vzci9zcmMv dXNyLmJpbi9ycGNnZW4vcnBjX3V0aWwuYw0KZWNobyBycGNnZW46IC91c3IvbGliL2xpYmMuYSAv dXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2xpYi9saWJlZ2FjeS5hID4+IC5kZXBlbmQN CmNjIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZSAtRGlubGluZT1ycGNnZW5faW5saW5l ICAtSS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy91 c3IuYmluL3JwY2dlbi9ycGNfbWFpbi5jDQpjYyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBp cGUgLURpbmxpbmU9cnBjZ2VuX2lubGluZSAgLUkvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kv dXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvdXNyLmJpbi9ycGNnZW4vcnBjX2NsbnRvdXQuYw0KY2Mg LU8yIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1waXBlIC1EaW5saW5lPXJwY2dlbl9pbmxpbmUgIC1J L3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL3Vzci5i aW4vcnBjZ2VuL3JwY19jb3V0LmMNCmNjIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZSAt RGlubGluZT1ycGNnZW5faW5saW5lICAtSS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3Iv aW5jbHVkZSAtYyAvdXNyL3NyYy91c3IuYmluL3JwY2dlbi9ycGNfaG91dC5jDQpjYyAtTzIgLWZu by1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLURpbmxpbmU9cnBjZ2VuX2lubGluZSAgLUkvdXNyL29i ai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvdXNyLmJpbi9ycGNn ZW4vcnBjX3BhcnNlLmMNCmNjIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZSAtRGlubGlu ZT1ycGNnZW5faW5saW5lICAtSS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVk ZSAtYyAvdXNyL3NyYy91c3IuYmluL3JwY2dlbi9ycGNfc2FtcGxlLmMNCmNjIC1PMiAtZm5vLXN0 cmljdC1hbGlhc2luZyAtcGlwZSAtRGlubGluZT1ycGNnZW5faW5saW5lICAtSS91c3Ivb2JqL3Vz ci9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy91c3IuYmluL3JwY2dlbi9y cGNfc2Nhbi5jDQpjYyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLURpbmxpbmU9cnBj Z2VuX2lubGluZSAgLUkvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMg L3Vzci9zcmMvdXNyLmJpbi9ycGNnZW4vcnBjX3N2Y291dC5jDQpjYyAtTzIgLWZuby1zdHJpY3Qt YWxpYXNpbmcgLXBpcGUgLURpbmxpbmU9cnBjZ2VuX2lubGluZSAgLUkvdXNyL29iai91c3Ivc3Jj L3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vzci9zcmMvdXNyLmJpbi9ycGNnZW4vcnBjX3Ri bG91dC5jDQpjYyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLURpbmxpbmU9cnBjZ2Vu X2lubGluZSAgLUkvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vz ci9zcmMvdXNyLmJpbi9ycGNnZW4vcnBjX3V0aWwuYw0KY2MgLU8yIC1mbm8tc3RyaWN0LWFsaWFz aW5nIC1waXBlIC1EaW5saW5lPXJwY2dlbl9pbmxpbmUgIC1JL3Vzci9vYmovdXNyL3NyYy90bXAv bGVnYWN5L3Vzci9pbmNsdWRlICAtc3RhdGljIC1ML3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5 L3Vzci9saWIgLW8gcnBjZ2VuIHJwY19tYWluLm8gcnBjX2NsbnRvdXQubyBycGNfY291dC5vIHJw Y19ob3V0Lm8gcnBjX3BhcnNlLm8gcnBjX3NhbXBsZS5vIHJwY19zY2FuLm8gcnBjX3N2Y291dC5v IHJwY190YmxvdXQubyBycGNfdXRpbC5vIC1sZWdhY3kNCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3Rh bGwuc2ggLXMgLW8gcm9vdCAtZyB3aGVlbCAtbSA1NTUgICBycGNnZW4gL3Vzci9vYmovdXNyL3Ny Yy90bXAvbGVnYWN5L3Vzci9iaW4NCj09PT4gdXNyLmJpbi94aW5zdGFsbCAob2JqLGRlcGVuZCxh bGwsaW5zdGFsbCkNCi91c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9zcmMvdXNyLmJpbi94aW5zdGFs bCBjcmVhdGVkIGZvciAvdXNyL3NyYy91c3IuYmluL3hpbnN0YWxsDQpybSAtZiAuZGVwZW5kDQpt a2RlcCAtZiAuZGVwZW5kIC1hICAgIC1JL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9p bmNsdWRlIC91c3Ivc3JjL3Vzci5iaW4veGluc3RhbGwveGluc3RhbGwuYw0KZWNobyB4aW5zdGFs bDogL3Vzci9saWIvbGliYy5hIC91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvbGliL2xp YmVnYWN5LmEgPj4gLmRlcGVuZA0KY2MgLU8yIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1waXBlICAt SS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyAvdXNyL3NyYy91c3Iu YmluL3hpbnN0YWxsL3hpbnN0YWxsLmMNCmNjIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlw ZSAgLUkvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgIC1zdGF0aWMgLUwv dXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2xpYiAtbyB4aW5zdGFsbCB4aW5zdGFsbC5v IC1sZWdhY3kNCnNoIC91c3Ivc3JjL3Rvb2xzL2luc3RhbGwuc2ggLXMgLW8gcm9vdCAtZyB3aGVl bCAtbSA1NTUgICB4aW5zdGFsbCAvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2Jpbi9p bnN0YWxsDQo9PT0+IHVzci5zYmluL2NvbmZpZyAob2JqLGRlcGVuZCxhbGwsaW5zdGFsbCkNCi91 c3Ivb2JqL3Vzci9zcmMvdG1wL3Vzci9zcmMvdXNyLnNiaW4vY29uZmlnIGNyZWF0ZWQgZm9yIC91 c3Ivc3JjL3Vzci5zYmluL2NvbmZpZw0KeWFjYyAtZCAvdXNyL3NyYy91c3Iuc2Jpbi9jb25maWcv Y29uZmlnLnkNCmNwIHkudGFiLmMgY29uZmlnLmMNCmxleCAtdCAgL3Vzci9zcmMvdXNyLnNiaW4v Y29uZmlnL2xhbmcubCA+IGxhbmcuYw0Kcm0gLWYgLmRlcGVuZA0KbWtkZXAgLWYgLmRlcGVuZCAt YSAgICAtSS4gLUkvdXNyL3NyYy91c3Iuc2Jpbi9jb25maWcgLUkvdXNyL29iai91c3Ivc3JjL3Rt cC9sZWdhY3kvdXNyL2luY2x1ZGUgY29uZmlnLmMgL3Vzci9zcmMvdXNyLnNiaW4vY29uZmlnL21h aW4uYyBsYW5nLmMgL3Vzci9zcmMvdXNyLnNiaW4vY29uZmlnL21rbWFrZWZpbGUuYyAvdXNyL3Ny Yy91c3Iuc2Jpbi9jb25maWcvbWtoZWFkZXJzLmMgL3Vzci9zcmMvdXNyLnNiaW4vY29uZmlnL21r b3B0aW9ucy5jDQplY2hvIGNvbmZpZzogL3Vzci9saWIvbGliYy5hIC91c3IvbGliL2xpYmwuYSAv dXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2xpYi9saWJlZ2FjeS5hID4+IC5kZXBlbmQN CmNjIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZSAtSS4gLUkvdXNyL3NyYy91c3Iuc2Jp bi9jb25maWcgIC1JL3Vzci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIGNv bmZpZy5jDQpjYyAtTzIgLWZuby1zdHJpY3QtYWxpYXNpbmcgLXBpcGUgLUkuIC1JL3Vzci9zcmMv dXNyLnNiaW4vY29uZmlnICAtSS91c3Ivb2JqL3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVk ZSAtYyAvdXNyL3NyYy91c3Iuc2Jpbi9jb25maWcvbWFpbi5jDQpjYyAtTzIgLWZuby1zdHJpY3Qt YWxpYXNpbmcgLXBpcGUgLUkuIC1JL3Vzci9zcmMvdXNyLnNiaW4vY29uZmlnICAtSS91c3Ivb2Jq L3Vzci9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAtYyBsYW5nLmMNCmNjIC1PMiAtZm5vLXN0 cmljdC1hbGlhc2luZyAtcGlwZSAtSS4gLUkvdXNyL3NyYy91c3Iuc2Jpbi9jb25maWcgIC1JL3Vz ci9vYmovdXNyL3NyYy90bXAvbGVnYWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL3Vzci5zYmlu L2NvbmZpZy9ta21ha2VmaWxlLmMNCmNjIC1PMiAtZm5vLXN0cmljdC1hbGlhc2luZyAtcGlwZSAt SS4gLUkvdXNyL3NyYy91c3Iuc2Jpbi9jb25maWcgIC1JL3Vzci9vYmovdXNyL3NyYy90bXAvbGVn YWN5L3Vzci9pbmNsdWRlIC1jIC91c3Ivc3JjL3Vzci5zYmluL2NvbmZpZy9ta2hlYWRlcnMuYw0K Y2MgLU8yIC1mbm8tc3RyaWN0LWFsaWFzaW5nIC1waXBlIC1JLiAtSS91c3Ivc3JjL3Vzci5zYmlu L2NvbmZpZyAgLUkvdXNyL29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL2luY2x1ZGUgLWMgL3Vz ci9zcmMvdXNyLnNiaW4vY29uZmlnL21rb3B0aW9ucy5jDQpjYyAtTzIgLWZuby1zdHJpY3QtYWxp YXNpbmcgLXBpcGUgLUkuIC1JL3Vzci9zcmMvdXNyLnNiaW4vY29uZmlnICAtSS91c3Ivb2JqL3Vz ci9zcmMvdG1wL2xlZ2FjeS91c3IvaW5jbHVkZSAgLXN0YXRpYyAtTC91c3Ivb2JqL3Vzci9zcmMv dG1wL2xlZ2FjeS91c3IvbGliIC1vIGNvbmZpZyBjb25maWcubyBtYWluLm8gbGFuZy5vIG1rbWFr ZWZpbGUubyBta2hlYWRlcnMubyBta29wdGlvbnMubyAtbGwgLWxlZ2FjeQ0Kc2ggL3Vzci9zcmMv dG9vbHMvaW5zdGFsbC5zaCAtcyAtbyByb290IC1nIHdoZWVsIC1tIDU1NSAgIGNvbmZpZyAvdXNy L29iai91c3Ivc3JjL3RtcC9sZWdhY3kvdXNyL3NiaW4NCjogd3JvbmcgbnVtYmVyIG9yIHR5cGVz IG9mIGFyZ3VtZW50cw0KdXNhZ2U6IGluc3RhbGwgWy1iQ2NwU3N2XSBbLUIgc3VmZml4XSBbLWYg ZmxhZ3NdIFstZyBncm91cF0gWy1tIG1vZGVdDQogICAgICAgICAgICAgICBbLW8gb3duZXJdIGZp bGUxIGZpbGUyDQogICAgICAgaW5zdGFsbCBbLWJDY3BTc3ZdIFstQiBzdWZmaXhdIFstZiBmbGFn c10gWy1nIGdyb3VwXSBbLW0gbW9kZV0NCiAgICAgICAgICAgICAgIFstbyBvd25lcl0gZmlsZTEg Li4uIGZpbGVOIGRpcmVjdG9yeQ0KICAgICAgIGluc3RhbGwgLWQgWy12XSBbLWcgZ3JvdXBdIFst bSBtb2RlXSBbLW8gb3duZXJdIGRpcmVjdG9yeSAuLi4NCioqKiBFcnJvciBjb2RlIDY0DQoNClN0 b3AgaW4gL3Vzci9zcmMvdXNyLnNiaW4vY29uZmlnLg0KKioqIEVycm9yIGNvZGUgMQ0KDQpTdG9w IGluIC91c3Ivc3JjLg0KKioqIEVycm9yIGNvZGUgMQ0KDQpTdG9wIGluIC91c3Ivc3JjLg0KKioq IEVycm9yIGNvZGUgMQ0KDQpTdG9wIGluIC91c3Ivc3JjLg0KZGFya3N0YXIjIGV4aXQNDQpleGl0 DQoKU2NyaXB0IGRvbmUgb24gU2F0IEp1biAxMSAyMToyNDowMCAyMDA1Cg== --------------Boundary-00=_9PFZPWYXFQQMYJ0CCJD0-- From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 19:42:57 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 90DF916A41C; Sun, 12 Jun 2005 19:42:57 +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 106A643D1F; Sun, 12 Jun 2005 19:42:56 +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 j5CJgeYB000975; Sun, 12 Jun 2005 15:42:40 -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 j5CJgtmB069802; Sun, 12 Jun 2005 15:42:56 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 705507306E; Sun, 12 Jun 2005 15:42:55 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050612194255.705507306E@freebsd-current.sentex.ca> Date: Sun, 12 Jun 2005 15:42:55 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on clamscanner1 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: Sun, 12 Jun 2005 19:42:57 -0000 TB --- 2005-06-12 18:09:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-06-12 18:09:00 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-06-12 18:09:00 - cleaning the object tree TB --- 2005-06-12 18:09:30 - checking out the source tree TB --- 2005-06-12 18:09:30 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-06-12 18:09:30 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-06-12 18:15:28 - building world (CFLAGS=-O2 -pipe) TB --- 2005-06-12 18:15:28 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-06-12 18:15:28 - /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-06-12 19:23:10 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-12 19:23:10 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-06-12 19:23:10 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Sun Jun 12 19:23:10 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 Sun Jun 12 19:35:28 UTC 2005 TB --- 2005-06-12 19:35:28 - generating LINT kernel config TB --- 2005-06-12 19:35:28 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- 2005-06-12 19:35:28 - /usr/bin/make -B LINT TB --- 2005-06-12 19:35:28 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-12 19:35:28 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-06-12 19:35:28 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Sun Jun 12 19:35:28 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/md4c.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/md5c.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/sched_4bsd .c In file included from /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/sched_4bsd.c:1388: /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_switch.c: In function `maybe_preempt_in_ksegrp': /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_switch.c:435: error: `IPI_PREEMPT' undeclared (first use in this function) /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_switch.c:435: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_switch.c:435: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-06-12 19:42:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-06-12 19:42:55 - ERROR: failed to build lint kernel TB --- 2005-06-12 19:42:55 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 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 616D516A41C for ; Sun, 12 Jun 2005 19:54:25 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0CD4A43D48 for ; Sun, 12 Jun 2005 19:54:22 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from localhost.localdomain (yazzy.yazzy.org [192.168.98.11]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yazzy.org (Postfix) with ESMTP id 47C0439866; Sun, 12 Jun 2005 21:54:47 +0200 (CEST) Date: Sun, 12 Jun 2005 21:54:16 +0200 From: Marcin Jessa To: polachok@narod.ru Message-Id: <20050612215416.5ad80a68.lists@yazzy.org> In-Reply-To: <42AC72E6.000001.07944@ariel.yandex.ru> References: <42AC3A7F.000002.04175@colgate.yandex.ru> <20050612142203.GA16377@artax.karlin.mff.cuni.cz> <42AC72E6.000001.07944@ariel.yandex.ru> Organization: YazzY.org X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: cannot build anything big 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, 12 Jun 2005 19:54:25 -0000 You dont have any weirdness in your libmap.conf ? On Sun, 12 Jun 2005 21:37:42 +0400 (MSD) "Polakov Alexander" wrote: > >On 2005-06-12 17:37 +0400, Polakov Alexander wrote: > >> I cannot build anything big: kernel, CURRENT's world, then Xorg, perl. > > > >Why? What happens? > > > >> I rebuilt openbox & fluxbox and they fails with a core dump, so I have > >> to get prebuilt packages. > >> CFLAGS are not set. The CPUTYPE is set to pentium3. Kernel is compiled > >> with PREEMPTION and ULE scheduler. > >> Please, help! > > > >Looks like a faulty memory. > > > >-- > >Marian Cerny > > You say faulty memory. But a few minutes ago I finished building/installing FreeBSD-STABLE. I booted form a FreeSBIE livecd and compiled the STABLE world with FreeSBIE's tools. Now I'll try to build CURRENT again, form just installed STABLE. > > > -- > Alexander Polakov > > _______________________________________________ > 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 Jun 12 20:26: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 6AE6516A41C for ; Sun, 12 Jun 2005 20:26:19 +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 3744843D49 for ; Sun, 12 Jun 2005 20:26:19 +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 B06E919F3B for ; Sun, 12 Jun 2005 13:27:42 -0700 (PDT) From: "Darren Pilgrim" To: Date: Sun, 12 Jun 2005 13:26:16 -0700 Message-ID: <001a01c56f8c$fcb7b690$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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Cc: Subject: Changing console video mode results in loss of scrollback buffer contents. 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, 12 Jun 2005 20:26:19 -0000 I use the allscreens_flags to switch to higher-resolution, non-raster = mode at boot. On a May 22 -current, the scrollback buffer was intact after changing the resolution. On -current as of yesterday, when I change = console resolution, the scrollback buffer is lost. The new behaviour is = equivalent to issuing `vidcontrol -C`. Was this change intentional? From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 21:59: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 362C416A41C for ; Sun, 12 Jun 2005 21:59:06 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from efnet-math.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1DEC43D53 for ; Sun, 12 Jun 2005 21:59:05 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated bits=0) by efnet-math.org (8.13.1/8.13.1) with ESMTP id j5CLx3AD006544 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sun, 12 Jun 2005 17:59:04 -0400 In-Reply-To: <7mhdg4q983.wl%kuriyama@imgsrc.co.jp> References: <7mhdg4q983.wl%kuriyama@imgsrc.co.jp> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Sun, 12 Jun 2005 17:58:57 -0400 To: Jun Kuriyama X-Mailer: Apple Mail (2.730) Cc: Current Subject: Re: Acquiring lockmgr lock "ufs" with non-sleepable locks 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, 12 Jun 2005 21:59:06 -0000 Hi, On Jun 12, 2005, at 4:18 AM, Jun Kuriyama wrote: > > As of today's current: > > Acquiring lockmgr lock "ufs" with the following non-sleepable locks > held: > exclusive sleep mutex vnode pollinfo r = 0 (0xc4814000) locked @ / > usr/src/sys/kern/kern_event.c:881 > KDB: stack backtrace: > kdb_backtrace(1,3001,c3fa229c,c3a36780,ecf71a5c) at kdb_backtrace+0x29 > witness_warn(5,c070c378,c06a435b,c06ad03d) at witness_warn+0x18e > lockmgr(c3fa2278,3001,c3fa229c,c3a36780,ecf71a88) at lockmgr+0x8d > vop_stdlock(ecf71acc,c06f58c0,ecf71acc,ecf71a98,c0612184) at > vop_stdlock+0x1e > VOP_LOCK_APV(c06f5e00,ecf71acc,ecf71aac,c067caff,ecf71acc) at > VOP_LOCK_APV+0x87 > ffs_lock(ecf71acc,1001,c3fa2220,ecf71ae8,c0566634) at ffs_lock+0x10 > VOP_LOCK_APV(c06f58c0,ecf71acc) at VOP_LOCK_APV+0x87 > vn_lock(c3fa2220,1001,c3a36780) at vn_lock+0xa4 > filt_vfsread(c3ac9264,0,0,ffffffff,0) at filt_vfsread+0x3a > kqueue_register(c3dd6480,ecf71bf4,c3a36780,1,0) at kqueue_register > +0x668 > kern_kevent(c3a36780,4,1,0,ecf71cc8) at kern_kevent+0xc9 > kevent(c3a36780,ecf71d04,6,1,292) at kevent+0x55 > syscall(3b,3b,3b,1,804e068) at syscall+0x22f > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (363, FreeBSD ELF32, kevent), eip = 0x280b9503, esp = > 0xbfbfe8ec, ebp = 0xbfbfe938 --- This was introduced by my commit to take out the various kqueue operations outside of ufs. It is because we are trying to lock the vnode while holding the knlist mutex. I'll work on a fix on wednesday, as I'll unfortunately be a bit busy until then. I hope this won't cause you any inconvenience. Bye. -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 22:46:52 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 1659C16A420 for ; Sun, 12 Jun 2005 22:46:52 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABED643D1D for ; Sun, 12 Jun 2005 22:46:51 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd21.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1DhbE8-0000vx-01; Mon, 13 Jun 2005 00:46:48 +0200 Received: from Andro-Beta.Leidinger.net (ExGIr8ZXgez8On79rXXAFcHNprotj95kAainw97sG+z-Msw+fMY4cv@[84.165.231.64]) by fwd21.sul.t-online.de with esmtp id 1DhbE3-0yusk40; Mon, 13 Jun 2005 00:46:43 +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 j5CMkcbs002847; Mon, 13 Jun 2005 00:46:38 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Mon, 13 Jun 2005 00:47:04 +0200 From: Alexander Leidinger To: linimon@lonesome.com (Mark Linimon) Message-ID: <20050613004704.3c0d8fe2@Magellan.Leidinger.net> In-Reply-To: <20050612194227.GA11407@soaustin.net> References: <20050612154403.2b49d0d8@Magellan.Leidinger.net> <20050612194227.GA11407@soaustin.net> X-Mailer: Sylpheed-Claws 1.9.11 (GTK+ 2.6.7; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: ExGIr8ZXgez8On79rXXAFcHNprotj95kAainw97sG+z-Msw+fMY4cv@t-dialin.net X-TOI-MSGID: 8b573164-d62b-42db-9fe8-ec3f25b62fe9 Cc: current@freebsd.org Subject: Re: TODO list for volunteers (similar to the list of things for Google's summer of 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, 12 Jun 2005 22:46:52 -0000 On Sun, 12 Jun 2005 14:42:27 -0500 linimon@lonesome.com (Mark Linimon) wrote: > On Sun, Jun 12, 2005 at 03:44:03PM +0200, Alexander Leidinger wrote: > > I intend to write everything up over the next week and give it to some > > of our docs people for SGML review (if nobody volunteers I pick someone > > out of the blue and ask nicely for a review :-) ). > > I wonder if such a list, being fairly subject to change, might not be > better suired to a wiki rather than being committed to SGML? Technical reasons: If someone implements an entry from the list, it's not much work to commit the removal of the entry from the list. And since we don't want to have an endless list, the number of additions should be limited. Since a commit requires a commit log, the removal of a non-sense entry also comes with a reason (at least it should). At least the last part looks like a VCS is well suited for the job. Visual reasons: You can use the power of SQML to render structured data, while in a wiki you have to do everything on your own (with the typical cut&paste errors and inconsistencies). Do you have any strong reasons which make the wiki a better choice? Bye, Alexander. -- 0 and 1. Now what could be so hard about that? 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 Mon Jun 13 00:33: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 4699516A41C for ; Mon, 13 Jun 2005 00:33:42 +0000 (GMT) (envelope-from varga@stonehenge.sk) Received: from smtp.dkm.cz (smtp.dkm.cz [62.24.64.34]) by mx1.FreeBSD.org (Postfix) with SMTP id 7B62343D49 for ; Mon, 13 Jun 2005 00:33:39 +0000 (GMT) (envelope-from varga@stonehenge.sk) Received: (qmail 94170 invoked by uid 0); 13 Jun 2005 00:33:37 -0000 Received: from r4w254.chello.upc.cz (84.42.150.254) by smtp.dkm.cz with SMTP; 13 Jun 2005 00:33:37 -0000 From: Michal Varga To: freebsd-current@freebsd.org Content-Type: text/plain Organization: Stonehenge Date: Mon, 13 Jun 2005 02:34:06 +0200 Message-Id: <1118622846.789.22.camel@xenon.stonehenge.sk> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: 'allocbuf: buffer too small' reproducible 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: Mon, 13 Jun 2005 00:33:42 -0000 Hello guys, I'm running yesterday's i386 current (Sun Jun 12 05:15:18 CEST) and I just ran into this scary thing: I have a directory with some ~4000 files in it. When running `ls -al > blah.txt` through them, i'm getting "panic: allocbuf: buffer too small" instantly, checked three times to be sure. Is this a known bug, expected behavior with just me missing something important now at 2:30 AM, or is someone willing to investigate? m. -- Michal Varga Stonehenge From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 00:38: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 DB3EE16A41C for ; Mon, 13 Jun 2005 00:38:41 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (chesapeake.net [208.142.252.6]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8D6BA43D49 for ; Mon, 13 Jun 2005 00:38:41 +0000 (GMT) (envelope-from jroberson@chesapeake.net) Received: from mail.chesapeake.net (localhost [127.0.0.1]) by mail.chesapeake.net (8.12.10/8.12.10) with ESMTP id j5D0cek9056364; Sun, 12 Jun 2005 20:38:40 -0400 (EDT) (envelope-from jroberson@chesapeake.net) Received: from localhost (jroberson@localhost) by mail.chesapeake.net (8.12.10/8.12.10/Submit) with ESMTP id j5D0cedL056351; Sun, 12 Jun 2005 20:38:40 -0400 (EDT) (envelope-from jroberson@chesapeake.net) X-Authentication-Warning: mail.chesapeake.net: jroberson owned process doing -bs Date: Sun, 12 Jun 2005 20:38:39 -0400 (EDT) From: Jeff Roberson To: Michal Varga In-Reply-To: <1118622846.789.22.camel@xenon.stonehenge.sk> Message-ID: <20050612203829.N16943@mail.chesapeake.net> References: <1118622846.789.22.camel@xenon.stonehenge.sk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: 'allocbuf: buffer too small' reproducible 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: Mon, 13 Jun 2005 00:38:42 -0000 On Mon, 13 Jun 2005, Michal Varga wrote: > Hello guys, > I'm running yesterday's i386 current (Sun Jun 12 05:15:18 CEST) and I > just ran into this scary thing: > > I have a directory with some ~4000 files in it. When running > `ls -al > blah.txt` through them, i'm getting > > "panic: allocbuf: buffer too small" Can you get me a stack trace with ddb? > > instantly, checked three times to be sure. Is this a known bug, expected > behavior with just me missing something important now at 2:30 AM, or is > someone willing to investigate? > > m. > > -- > Michal Varga > Stonehenge > > _______________________________________________ > 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 Mon Jun 13 01:49: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 4A94016A41C for ; Mon, 13 Jun 2005 01:49:43 +0000 (GMT) (envelope-from pquerna@apache.org) Received: from utopia.in.force-elite.com (force-elite.com [216.255.199.145]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5DFA43D4C for ; Mon, 13 Jun 2005 01:49:42 +0000 (GMT) (envelope-from pquerna@apache.org) X-AuthUser: chip@force-elite.com Received: from [10.0.0.41] (10.0.0.41:2274) by utopia.in.force-elite.com with [XMail 1.17 (Linux/Ix86) ESMTP Server] id for from ; Sun, 12 Jun 2005 18:49:42 -0700 Message-ID: <42ACE639.8030509@apache.org> Date: Sun, 12 Jun 2005 18:49:45 -0700 From: Paul Querna 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=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: q@onthenet.com.au Subject: Panic with nve 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, 13 Jun 2005 01:49:43 -0000 Using the 6.0-CURRENT June 2nd Snapshot, I get a panic pretty quickly when using an original NForce 1 MCP Network Card(new nve driver). This has happened while I was running sysinstall via pxeboot, and starting a ftp install. This is what I copied from the screen, omitting some things later in the stack trace: anic: nve_ifstart: attempted use of a free mbuf! cpuid = 0 KBD: enter: panic [thread pid 35 tid 100022 ] Stopped at kdb_enter+0x2b db>trace kdb_enter(x0855c9c) at kdb_enter 0x2b panic(c082ad05,c08154dc,c1a388fc,c1a38800,ce7ebc80) at panic+0x127 nve_ifstart(c1a38800,) at nve_ifstart+0x366 if_start(c1a38800) at if_start+0x7b ether_output_frame(c1a38800,v1b35300,0,0,0) at ether_output_frame+0x1d9 ether_output(c1a38800,v1b35300,,c1ab67d0,c1ba8c60,v1b58b00) at ether_output+0x384 ip_output() tcp_output() ip_input() netisr_processqueue() swi_net(0) .... I don't have the gear locally to setup a serial console, so I am hoping this is enough to give someone a clue. It looks easy to reproduce, and I am happy to provide more information if needed. I did find a mention of a similar panic back in October of 2004, but it was for the fxp driver: http://lists.freebsd.org/pipermail/freebsd-net/2004-October/005222.html Thanks, -Paul Querna From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 04:32: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 E7F8616A41C; Mon, 13 Jun 2005 04:32:16 +0000 (GMT) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (mail.scsiguy.com [63.229.232.106]) by mx1.FreeBSD.org (Postfix) with ESMTP id 462BE43D1F; Mon, 13 Jun 2005 04:32:16 +0000 (GMT) (envelope-from gibbs@scsiguy.com) Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106]) (authenticated bits=0) by aslan.scsiguy.com (8.13.3/8.13.3) with ESMTP id j5D4WE64043586 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 12 Jun 2005 22:32:14 -0600 (MDT) (envelope-from gibbs@scsiguy.com) Date: Sun, 12 Jun 2005 22:32:14 -0600 From: "Justin T. Gibbs" To: "Kenneth D. Merry" , "Raphael H. Becker" Message-ID: In-Reply-To: <20050612035440.GA21262@nargothrond.kdm.org> References: <20050608152459.BF24E16A45C@hub.freebsd.org> <1118248386.7479.10.camel@zappa.Chelsea-Ct.Org> <20050608171130.GA64736@over-yonder.net> <1118252322.7479.28.camel@zappa.Chelsea-Ct.Org> <20050609113616.I41471@p-i-n.com> <20050609130511.GA732@uk.tiscali.com> <20050610162814.A25098@p-i-n.com> <20050610150718.GA7005@nargothrond.kdm.org> <20050612002508.B25098@p-i-n.com> <20050612035440.GA21262@nargothrond.kdm.org> X-Mailer: Mulberry/3.1.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: Accessing SCSI-Devices >2TB X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Justin T. Gibbs" List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2005 04:32:17 -0000 >> # camcontrol cmd pass3 -v -c "9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0" -i 12 "i4 i4 i4" >> camcontrol: error sending command >> (pass3:ahc1:0:0:0): SERVICE ACTION IN(16). CDB: 9e 10 0 0 0 0 0 0 0 0 0 0 0 c 0 0 >> (pass3:ahc1:0:0:0): CAM Status: Target Bus Phase Sequence Failure >> >> dmesg: >> (pass3:ahc1:0:0:0): No or incomplete CDB sent to device. >> (pass3:ahc1:0:0:0): Protocol violation in Message-in phase. Attempting to abort. >> (pass3:ahc1:0:0:0): Abort Tag Message Sent >> (pass3:ahc1:0:0:0): SCB 8 - Abort Tag Completed. > > Hmm, okay, at this point, we have a SCSI protocol violation. (Which is the > same thing you saw before.) > > So this pretty much means it is the 16 byte read capacity that is > triggering the problem. > > The question is, is this problem on the RAID box or in the ahc driver? I > would lean towards saying the RAID box has the issue, but Justin (CCed) may > be able to give a little more insight. The diagnostics indicate that the aic7xxx chip believes the entire CDB was not transferred to the target before the target attempted to disconnect or complete the command. While 16byte cdb support in this driver was reported to work correctly in the past, that does not guarantee that I haven't somehow broken it - the firmware could be incorrectly determining cdb transfer completion status in this case even though the logic appears to be correct. I'll try to setup a target mode emulation environment this week to see if I can replicate the problem. What controller/chip are you using? -- Justin From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 06:56: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 9FE3316A41C; Mon, 13 Jun 2005 06:56:25 +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 5687B43D48; Mon, 13 Jun 2005 06:56:25 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5D6uKrY030156; Sun, 12 Jun 2005 23:56:20 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5D6uI2t030155; Sun, 12 Jun 2005 23:56:18 -0700 (PDT) (envelope-from obrien) Date: Sun, 12 Jun 2005 23:56:18 -0700 From: "David O'Brien" To: Mark Linimon Message-ID: <20050613065618.GA30092@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Mark Linimon , Ruslan Ermilov , Dag-Erling Sm?rgrav , freebsd-current@freebsd.org References: <20050609234619.AD1F67306E@freebsd-current.sentex.ca> <84dead720506091950779d1661@mail.gmail.com> <86oeae3d8f.fsf@xps.des.no> <20050610071828.GB78035@ip.net.ua> <867jh23bwh.fsf@xps.des.no> <20050610074706.GE78035@ip.net.ua> <20050612022105.GB67746@dragon.NUXI.org> <20050612042406.GB5996@soaustin.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050612042406.GB5996@soaustin.net> 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: Dag-Erling Sm?rgrav , freebsd-current@freebsd.org Subject: Re: [current tinderbox] failure on ...all... 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, 13 Jun 2005 06:56:25 -0000 On Sat, Jun 11, 2005 at 11:24:06PM -0500, Mark Linimon wrote: > > I tried. But Kris refused to consider the following for committing. > > The problem is something like 3 ports will not build with > > "-fno-strict-aliasing". Those are the gcc28, gnat[*] ports. > > > > [*] I really don't understand why we have a GCC 2.8 based Ada compiler > > when Ada has been a native part of GCC since version 3.1... > > If these ports are useless, why don't we mark them DEPRECATED and > after a decent interval, get rid of them? > > In this day and age, anyone who's on gcc27 or gcc28 is hopelessly > behind anyways. I could say that about tons of other ports. The gcc28 port works fine, and I don't see what is wrong with the patch I supplied. gcc28 is still the fastest compiler (in terms of compiler speed) we have on FreeBSD. It is still useful. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 07:11:35 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 BA87916A41C; Mon, 13 Jun 2005 07:11:35 +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 6E23743D48; Mon, 13 Jun 2005 07:11:35 +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 j5D7BIuE028130; Mon, 13 Jun 2005 03:11:18 -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 j5D7BYjO016283; Mon, 13 Jun 2005 03:11:34 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id ED9A47306E; Mon, 13 Jun 2005 03:11:33 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050613071133.ED9A47306E@freebsd-current.sentex.ca> Date: Mon, 13 Jun 2005 03:11:33 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on clamscanner3 X-Virus-Status: Clean X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 Cc: Subject: [current tinderbox] failure on alpha/alpha 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: Mon, 13 Jun 2005 07:11:35 -0000 TB --- 2005-06-13 05:15:01 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-06-13 05:15:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-06-13 05:15:01 - cleaning the object tree TB --- 2005-06-13 05:15:32 - checking out the source tree TB --- 2005-06-13 05:15:32 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-06-13 05:15:32 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-06-13 05:28:32 - building world (CFLAGS=-O2 -pipe) TB --- 2005-06-13 05:28:32 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-06-13 05:28:32 - /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-06-13 06:48:23 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-13 06:48:23 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-06-13 06:48:23 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Jun 13 06:48:23 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 Mon Jun 13 07:02:19 UTC 2005 TB --- 2005-06-13 07:02:19 - generating LINT kernel config TB --- 2005-06-13 07:02:19 - cd /home/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- 2005-06-13 07:02:19 - /usr/bin/make -B LINT TB --- 2005-06-13 07:02:19 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-13 07:02:19 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-06-13 07:02:19 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 13 07:02:19 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -I/tinderbox/CURRENT/alpha/alpha/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/md4c.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -I/tinderbox/CURRENT/alpha/alpha/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/md5c.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -I/tinderbox/CURRENT/alpha/alpha/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/sched_4bsd.c In file included from /tinderbox/CURRENT/alpha/alpha/src/sys/kern/sched_4bsd.c:1388: /tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_switch.c: In function `maybe_preempt_in_ksegrp': /tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_switch.c:435: error: `IPI_PREEMPT' undeclared (first use in this function) /tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_switch.c:435: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_switch.c:435: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-06-13 07:11:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-06-13 07:11:33 - ERROR: failed to build lint kernel TB --- 2005-06-13 07:11:33 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 07:21: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 40E2216A428; Mon, 13 Jun 2005 07:21:16 +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 CD7B343D1D; Mon, 13 Jun 2005 07:21:15 +0000 (GMT) (envelope-from bkoenig@cs.tu-berlin.de) Received: from eurystheus.local (port-212-202-39-126.dynamic.qsc.de [212.202.39.126]) by mail.efacilitas.de (Postfix) with ESMTP id EF119123978; Mon, 13 Jun 2005 09:19:40 +0200 (CEST) Received: from localhost (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id 2FCF012B0F7; Mon, 13 Jun 2005 09:19:43 +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 47267-09; Mon, 13 Jun 2005 09:19:36 +0200 (CEST) Received: from [192.168.1.67] (eurystheus.local [192.168.1.67]) by eurystheus.local (Postfix) with ESMTP id DF8C612B02A; Mon, 13 Jun 2005 09:19:36 +0200 (CEST) Message-ID: <42AD3388.2010009@cs.tu-berlin.de> Date: Mon, 13 Jun 2005 09:19:36 +0200 From: =?ISO-8859-1?Q?Bj=F6rn_K=F6nig?= 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: obrien@freebsd.org References: <20050609234619.AD1F67306E@freebsd-current.sentex.ca> <84dead720506091950779d1661@mail.gmail.com> <86oeae3d8f.fsf@xps.des.no> <20050610071828.GB78035@ip.net.ua> <867jh23bwh.fsf@xps.des.no> <20050610074706.GE78035@ip.net.ua> <20050612022105.GB67746@dragon.NUXI.org> <20050612042406.GB5996@soaustin.net> <20050613065618.GA30092@dragon.NUXI.org> In-Reply-To: <20050613065618.GA30092@dragon.NUXI.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Scanned: amavisd-new at example.com Cc: Mark Linimon , freebsd-current@freebsd.org, =?ISO-8859-1?Q?Dag-Erling_Sm=F8?= =?ISO-8859-1?Q?rgrav?= Subject: Re: [current tinderbox] failure on ...all... 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, 13 Jun 2005 07:21:16 -0000 David O'Brien wrote: > I could say that about tons of other ports. The gcc28 port works fine, > and I don't see what is wrong with the patch I supplied. gcc28 is still > the fastest compiler (in terms of compiler speed) we have on FreeBSD. It > is still useful. For what is it useful? It can't compile C++ code, it has a lack of standard conformance, gcc295 isn't quite worse and the utility ccache is a good choice you if you need fast recompilation. Björn From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 08:42: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 E4B8016A41C for ; Mon, 13 Jun 2005 08:42:08 +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 9B9C843D1F for ; Mon, 13 Jun 2005 08:42:08 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5D8fn7X062595; Mon, 13 Jun 2005 01:41:49 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5D8fnlP062594; Mon, 13 Jun 2005 01:41:49 -0700 (PDT) (envelope-from obrien) Date: Mon, 13 Jun 2005 01:41:49 -0700 From: "David O'Brien" To: =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= Message-ID: <20050613084148.GA57865@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, =?unknown-8bit?Q?Bj=F6rn_K=F6nig?= References: <84dead720506091950779d1661@mail.gmail.com> <86oeae3d8f.fsf@xps.des.no> <20050610071828.GB78035@ip.net.ua> <867jh23bwh.fsf@xps.des.no> <20050610074706.GE78035@ip.net.ua> <20050612022105.GB67746@dragon.NUXI.org> <20050612042406.GB5996@soaustin.net> <20050613065618.GA30092@dragon.NUXI.org> <42AD3388.2010009@cs.tu-berlin.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42AD3388.2010009@cs.tu-berlin.de> 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 Subject: Re: [current tinderbox] failure on ...all... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: Mon, 13 Jun 2005 08:42:09 -0000 On Mon, Jun 13, 2005 at 09:19:36AM +0200, Bjrn Knig wrote: > David O'Brien wrote: > >I could say that about tons of other ports. The gcc28 port works fine, > >and I don't see what is wrong with the patch I supplied. gcc28 is still > >the fastest compiler (in terms of compiler speed) we have on FreeBSD. It > >is still useful. > > For what is it useful? It can't compile C++ code, Funny for me, I just compiled some C++ code (using catch-throw) exceptions and it ran fine. > it has a lack of > standard conformance, gcc295 isn't quite worse and the utility ccache is > a good choice you if you need fast recompilation. Then for you, use gcc295. But there is C++ code and C code that gcc295 won't compile. That is why I keep gcc28 around. I don't see why the existence of gcc28 is a hardship for you. I've even set NO_CDROM to not be a burden for you. It builds in 1 minute 30 seconds on my machine, so its not a burden on the package cluster either. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 08:54: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 7D4A716A41C for ; Mon, 13 Jun 2005 08:54:59 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from pantene.yandex.ru (pantene.yandex.ru [213.180.200.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2D75B43D48 for ; Mon, 13 Jun 2005 08:54:59 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from YAMAIL (pantene.yandex.ru) by mail.yandex.ru id ; Mon, 13 Jun 2005 12:54:50 +0400 Date: Mon, 13 Jun 2005 12:54:50 +0400 (MSD) From: "Polakov Alexander" Sender: polachok@narod.ru Message-Id: <42AD49DA.000003.01950@pantene.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: polachok@narod.ru To: lists@yazzy.org, freebsd-current@freebsd.org In-Reply-To: <20050612215416.5ad80a68.lists@yazzy.org> References: <42AC3A7F.000002.04175@colgate.yandex.ru> <20050612215416.5ad80a68.lists@yazzy.org> X-Source-Ip: 213.158.14.240 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Cc: Subject: Re: cannot build anything big X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: polachok@narod.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, 13 Jun 2005 08:54:59 -0000 >You dont have any weirdness in your libmap.conf ? I don't have any libmap.conf -- Alexander Polakov From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 09:03: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 EC7AD16A41C for ; Mon, 13 Jun 2005 09:03:08 +0000 (GMT) (envelope-from Jan.Grant@bristol.ac.uk) Received: from diri.bris.ac.uk (diri.bris.ac.uk [137.222.10.112]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BA1E43D49 for ; Mon, 13 Jun 2005 09:03:08 +0000 (GMT) (envelope-from Jan.Grant@bristol.ac.uk) Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by diri.bris.ac.uk with esmtp (Exim 4.51) id 1DhkqW-0007bY-EQ; Mon, 13 Jun 2005 10:03:05 +0100 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 4.50) id 1DhkqL-0005Gb-Vv; Mon, 13 Jun 2005 10:02:54 +0100 Date: Mon, 13 Jun 2005 10:02:53 +0100 (BST) From: Jan Grant X-X-Sender: cmjg@mail.ilrt.bris.ac.uk To: Alexander Leidinger In-Reply-To: <20050613004704.3c0d8fe2@Magellan.Leidinger.net> Message-ID: References: <20050612154403.2b49d0d8@Magellan.Leidinger.net> <20050612194227.GA11407@soaustin.net> <20050613004704.3c0d8fe2@Magellan.Leidinger.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Jan Grant X-Spam-Score: -2.8 X-Spam-Level: -- Cc: Mark Linimon , current@freebsd.org Subject: Re: TODO list for volunteers (similar to the list of things for Google's summer of 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, 13 Jun 2005 09:03:09 -0000 On Mon, 13 Jun 2005, Alexander Leidinger wrote: > On Sun, 12 Jun 2005 14:42:27 -0500 > linimon@lonesome.com (Mark Linimon) wrote: > > > On Sun, Jun 12, 2005 at 03:44:03PM +0200, Alexander Leidinger wrote: > > > I intend to write everything up over the next week and give it to some > > > of our docs people for SGML review (if nobody volunteers I pick someone > > > out of the blue and ask nicely for a review :-) ). > > > > I wonder if such a list, being fairly subject to change, might not be > > better suired to a wiki rather than being committed to SGML? > > Technical reasons: > If someone implements an entry from the list, it's not much work to > commit the removal of the entry from the list. And since we don't want > to have an endless list, the number of additions should be limited. > Since a commit requires a commit log, the removal of a non-sense entry > also comes with a reason (at least it should). > > At least the last part looks like a VCS is well suited for the job. > > Visual reasons: > You can use the power of SQML to render structured data, while in a > wiki you have to do everything on your own (with the typical cut&paste > errors and inconsistencies). > > Do you have any strong reasons which make the wiki a better choice? Is there a reason why feature-requests can't be integrated into the bug tracking system? -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44 (0)117 9287088 or 3317661 http://ioctl.org/jan/ Bolstered by my success with vi, I proceeded to learn C with 'learn c'. From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 09:44: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 8E53516A41C for ; Mon, 13 Jun 2005 09:44:22 +0000 (GMT) (envelope-from keramida@FreeBSD.org) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id D5D3A43D53 for ; Mon, 13 Jun 2005 09:44:21 +0000 (GMT) (envelope-from keramida@FreeBSD.org) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j5D9iGCr017060; Mon, 13 Jun 2005 12:44:17 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) by orion.daedalusnetworks.priv (8.13.4/8.13.4) with ESMTP id j5D9iGQR081828; Mon, 13 Jun 2005 12:44:16 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Received: (from keramida@localhost) by orion.daedalusnetworks.priv (8.13.4/8.13.4/Submit) id j5D9iGLD081821; Mon, 13 Jun 2005 12:44:16 +0300 (EEST) (envelope-from keramida@FreeBSD.org) Date: Mon, 13 Jun 2005 12:44:16 +0300 From: Giorgos Keramidas To: Jan Grant , Alexander Leidinger , Mark Linimon Message-ID: <20050613094415.GA79267@orion.daedalusnetworks.priv> References: <20050612154403.2b49d0d8@Magellan.Leidinger.net> <20050612194227.GA11407@soaustin.net> <20050613004704.3c0d8fe2@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Cc: freebsd-current@FreeBSD.org Subject: Re: TODO list for volunteers (similar to the list of things for Google's summer of 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, 13 Jun 2005 09:44:22 -0000 On 2005-06-13 10:02, Jan Grant wrote: > Is there a reason why feature-requests can't be integrated into the > bug tracking system? Aren't they already? http://www.freebsd.org/cgi/query-pr-summary.cgi?class=wish From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 09:47: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 4DE7716A41C; Mon, 13 Jun 2005 09:47:57 +0000 (GMT) (envelope-from Jan.Grant@bristol.ac.uk) Received: from dirg.bris.ac.uk (dirg.bris.ac.uk [137.222.10.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id EF3CA43D1F; Mon, 13 Jun 2005 09:47:56 +0000 (GMT) (envelope-from Jan.Grant@bristol.ac.uk) Received: from mail.ilrt.bris.ac.uk ([137.222.16.62]) by dirg.bris.ac.uk with esmtp (Exim 4.51) id 1DhlXr-0002oj-I5; Mon, 13 Jun 2005 10:47:56 +0100 Received: from cmjg (helo=localhost) by mail.ilrt.bris.ac.uk with local-esmtp (Exim 4.50) id 1DhlXp-0007WC-Ro; Mon, 13 Jun 2005 10:47:50 +0100 Date: Mon, 13 Jun 2005 10:47:49 +0100 (BST) From: Jan Grant X-X-Sender: cmjg@mail.ilrt.bris.ac.uk To: Giorgos Keramidas In-Reply-To: <20050613094415.GA79267@orion.daedalusnetworks.priv> Message-ID: References: <20050612154403.2b49d0d8@Magellan.Leidinger.net> <20050612194227.GA11407@soaustin.net> <20050613004704.3c0d8fe2@Magellan.Leidinger.net> <20050613094415.GA79267@orion.daedalusnetworks.priv> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: Jan Grant X-Spam-Score: -2.8 X-Spam-Level: -- Cc: Alexander Leidinger , freebsd-current@FreeBSD.org, Mark Linimon Subject: Re: TODO list for volunteers (similar to the list of things for Google's summer of 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, 13 Jun 2005 09:47:57 -0000 On Mon, 13 Jun 2005, Giorgos Keramidas wrote: > On 2005-06-13 10:02, Jan Grant wrote: > > Is there a reason why feature-requests can't be integrated into the > > bug tracking system? > > Aren't they already? > > http://www.freebsd.org/cgi/query-pr-summary.cgi?class=wish Yup. The question was semi-rhetorical: since the tracking system already does this, why not stick the various "junior hacker challenges" and so on into the bug tracking system? Since one of the pieces of advice offered to newcomers who want to get into kernel hacking is, "pick a bug report and fix it", it seems that that's a reasonable place to house this. -- jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/ Tel +44 (0)117 9287088 or 3317661 http://ioctl.org/jan/ Work #90: As many pseudo-intellectual sycophants as necessary to make one inarticulate scotsman think he's a genius in command of The Profound. From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 10:19: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 0BA8C16A41C; Mon, 13 Jun 2005 10:19:20 +0000 (GMT) (envelope-from rabe@p-i-n.com) Received: from dns.p-i-n.com (dns.p-i-n.com [145.253.185.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0EEA43D48; Mon, 13 Jun 2005 10:19:18 +0000 (GMT) (envelope-from rabe@p-i-n.com) Received: from p-i-n.com (inside.p-i-n.com [129.10.9.21]) by dns.p-i-n.com (8.12.9p2/8.12.9) with ESMTP id j5DAJGOf032084; Mon, 13 Jun 2005 12:19:16 +0200 (CEST) (envelope-from rabe@p-i-n.com) Received: (from rabe@localhost) by p-i-n.com (8.11.6/8.11.6) id j5DAJFJ69759; Mon, 13 Jun 2005 12:19:15 +0200 (CEST) (envelope-from rabe) Date: Mon, 13 Jun 2005 12:19:15 +0200 From: "Raphael H. Becker" To: "Justin T. Gibbs" Message-ID: <20050613121915.C25098@p-i-n.com> References: <1118248386.7479.10.camel@zappa.Chelsea-Ct.Org> <20050608171130.GA64736@over-yonder.net> <1118252322.7479.28.camel@zappa.Chelsea-Ct.Org> <20050609113616.I41471@p-i-n.com> <20050609130511.GA732@uk.tiscali.com> <20050610162814.A25098@p-i-n.com> <20050610150718.GA7005@nargothrond.kdm.org> <20050612002508.B25098@p-i-n.com> <20050612035440.GA21262@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from gibbs@scsiguy.com on Sun, Jun 12, 2005 at 10:32:14PM -0600 Organization: PHOENIX Pharmahandel AG & Co KG, Mannheim, Deutschland Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org, "Kenneth D. Merry" Subject: Re: Accessing SCSI-Devices >2TB 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, 13 Jun 2005 10:19:20 -0000 On Sun, Jun 12, 2005 at 10:32:14PM -0600, Justin T. Gibbs wrote: > even though the logic appears to be correct. I'll try to setup a > target mode emulation environment this week to see if I can replicate > the problem. What controller/chip are you using? dmesg: [...] acpi0: on motherboard acpi0: Power Button (fixed) [...] pcib5: on acpi0 pci1: on pcib5 [...] ahc0: port 0xdc00-0xdcff mem 0xfcf01000-0xfcf01fff irq 20 at device 8.0 on pci1 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0xd800-0xd8ff mem 0xfcf00000-0xfcf00fff irq 21 at device 8.1 on pci1 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs [...] pciconf -lv [...] ahc0@pci1:8:0: class=0x010000 card=0xf6209005 chip=0x00c09005 rev=0x01 hdr=0x00 vendor = 'Adaptec Inc' device = 'AHA-39160 (AIC-7899A) Ultra160 SCSI Host Adapter' class = mass storage subclass = SCSI ahc1@pci1:8:1: class=0x010000 card=0xf6209005 chip=0x00c09005 rev=0x01 hdr=0x00 vendor = 'Adaptec Inc' device = 'AHA-39160 (AIC-7899A) Ultra160 SCSI Host Adapter' class = mass storage subclass = SCSI [...] Hopefully this is what you need. TIA Raphael Becker PS+BTW: any idea why the internal PERC is not listed in camcontrol devlist? In dmesg its listed like aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 on pci4 aac0: i960RX 100MHz, 118MB cache memory, optional battery present aac0: Kernel 2.7-1, Build 3170, S/N 5410d3 aac0: Supported Options=75c [...] aacd0: on aac0 aacd0: 69425MB (142182912 sectors) pciconf: aac0@pci4:8:1: class=0x010400 card=0x01211028 chip=0x000a1028 rev=0x01 hdr=0x00 vendor = 'Dell Computer Corporation' device = 'PowerEdge 3/Di Expandable RAID Controller' class = mass storage subclass = RAID It's not SCSI? From owner-freebsd-current@FreeBSD.ORG Sun Jun 12 19:42:28 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 8B68216A41C for ; Sun, 12 Jun 2005 19:42:28 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5663943D1D for ; Sun, 12 Jun 2005 19:42:28 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 89D2027A0; Sun, 12 Jun 2005 14:42:27 -0500 (CDT) Date: Sun, 12 Jun 2005 14:42:27 -0500 To: Alexander Leidinger Message-ID: <20050612194227.GA11407@soaustin.net> References: <20050612154403.2b49d0d8@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050612154403.2b49d0d8@Magellan.Leidinger.net> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Mon, 13 Jun 2005 11:44:51 +0000 Cc: Mark Linimon , current@freebsd.org Subject: Re: TODO list for volunteers (similar to the list of things for Google's summer of 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, 12 Jun 2005 19:42:28 -0000 On Sun, Jun 12, 2005 at 03:44:03PM +0200, Alexander Leidinger wrote: > I intend to write everything up over the next week and give it to some > of our docs people for SGML review (if nobody volunteers I pick someone > out of the blue and ask nicely for a review :-) ). I wonder if such a list, being fairly subject to change, might not be better suired to a wiki rather than being committed to SGML? mcl From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 00:50: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 7D32E16A41C for ; Mon, 13 Jun 2005 00:50:31 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A5AF43D48 for ; Mon, 13 Jun 2005 00:50:31 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 1A91E27A5; Sun, 12 Jun 2005 19:50:30 -0500 (CDT) Date: Sun, 12 Jun 2005 19:50:30 -0500 To: Alexander Leidinger Message-ID: <20050613005030.GA22676@soaustin.net> References: <20050612154403.2b49d0d8@Magellan.Leidinger.net> <20050612194227.GA11407@soaustin.net> <20050613004704.3c0d8fe2@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050613004704.3c0d8fe2@Magellan.Leidinger.net> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) X-Mailman-Approved-At: Mon, 13 Jun 2005 11:44:51 +0000 Cc: Mark Linimon , current@freebsd.org Subject: Re: TODO list for volunteers (similar to the list of things for Google's summer of 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, 13 Jun 2005 00:50:31 -0000 On Mon, Jun 13, 2005 at 12:47:04AM +0200, Alexander Leidinger wrote: > Do you have any strong reasons which make the wiki a better choice? Lower barrier to entry. I mean, I have a doc commit bit and never found our markup that hard to master, but that doesn't mean that everyone else is interested in doing so. I just think it would be lower-weight and thus more people might be able to contribute to it. mcl From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 07: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 8AC9E16A41C for ; Mon, 13 Jun 2005 07:37:10 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from rosebud.otenet.gr (rosebud.otenet.gr [195.170.0.94]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0EE843D49 for ; Mon, 13 Jun 2005 07:37:08 +0000 (GMT) (envelope-from keramida@ceid.upatras.gr) Received: from orion.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by rosebud.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j5D7b4QK002145; Mon, 13 Jun 2005 10:37:04 +0300 Received: from orion.daedalusnetworks.priv (orion [127.0.0.1]) by orion.daedalusnetworks.priv (8.13.4/8.13.4) with ESMTP id j5D7awiL045687; Mon, 13 Jun 2005 10:36:58 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Received: (from keramida@localhost) by orion.daedalusnetworks.priv (8.13.4/8.13.4/Submit) id j5D7am7T045682; Mon, 13 Jun 2005 10:36:48 +0300 (EEST) (envelope-from keramida@ceid.upatras.gr) Date: Mon, 13 Jun 2005 10:36:47 +0300 From: Giorgos Keramidas To: Steve Kargl Message-ID: <20050613073647.GA45570@orion.daedalusnetworks.priv> References: <32946.24.27.59.14.1118528242.squirrel@24.27.59.14> <20050612165430.GA11825@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050612165430.GA11825@troutmask.apl.washington.edu> X-Mailman-Approved-At: Mon, 13 Jun 2005 11:44:51 +0000 Cc: freebsd-current@freebsd.org, jasonh@cc.gatech.edu Subject: Re: Reboot when trying to load -current (amd64) 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: Mon, 13 Jun 2005 07:37:10 -0000 On 2005-06-12 09:54, Steve Kargl wrote: >On Sat, Jun 11, 2005 at 06:17:22PM -0400, jasonh@cc.gatech.edu wrote: >> I just tried upgrading from 5.4-STABLE/amd64 to 6.0-CURRENT/amd64, using >> the conventional cvsup/make buildworld/make kernel method. Everything >> built cleanly, but upon rebooting, I found that all of the boot loader >> options except "Escape to loader prompt" cause the machine to immediately >> reboot with absolutely no indication as to the cause of the problem. > > -current of amd64 is currently hosed. An amd64 laptop arrives here today, so it will be a great opportunity to play around until I find what causes this :) That is, unless someone else beats me to it. From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 11:47: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 AF33216A41C; Mon, 13 Jun 2005 11:47:27 +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 1932C43D4C; Mon, 13 Jun 2005 11:47:26 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd17.aul.t-online.de by mailout07.sul.t-online.com with smtp id 1DhnPY-0003uo-02; Mon, 13 Jun 2005 13:47:24 +0200 Received: from Andro-Beta.Leidinger.net (TcV7PTZeZe5dR5Lmy7TGOE9o8zeZhPVYwgxhyn0uutq2PH7qN-9Aw+@[84.165.203.214]) by fwd17.sul.t-online.de with esmtp id 1DhnPQ-2169Ts0; Mon, 13 Jun 2005 13:47:16 +0200 Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j5DBl6I5045499; Mon, 13 Jun 2005 13:47:07 +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, 13 Jun 2005 13:47:06 +0200 Message-ID: <20050613134706.zphfkyk26g4kos0c@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 13 Jun 2005 13:47:06 +0200 From: Alexander Leidinger To: Giorgos Keramidas References: <20050612154403.2b49d0d8@Magellan.Leidinger.net> <20050612194227.GA11407@soaustin.net> <20050613004704.3c0d8fe2@Magellan.Leidinger.net> <20050613094415.GA79267@orion.daedalusnetworks.priv> In-Reply-To: <20050613094415.GA79267@orion.daedalusnetworks.priv> 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: TcV7PTZeZe5dR5Lmy7TGOE9o8zeZhPVYwgxhyn0uutq2PH7qN-9Aw+@t-dialin.net X-TOI-MSGID: ed6ad250-601d-47ea-b5f9-03ac0d7537fc Cc: Jan Grant , freebsd-current@FreeBSD.org, Mark Linimon Subject: Re: TODO list for volunteers (similar to the list of things for Google's summer of 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, 13 Jun 2005 11:47:27 -0000 Giorgos Keramidas wrote: > On 2005-06-13 10:02, Jan Grant wrote: >> Is there a reason why feature-requests can't be integrated into the >> bug tracking system? A list of user requests is different from a prefiltered list of things which should be done... > Aren't they already? > > http://www.freebsd.org/cgi/query-pr-summary.cgi?class=wish And obviously they aren't as public and documented as such a list should be. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 I was in accord with the system so long as it permitted me to function effectively. -- Albert Speer From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 12:56: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 363D916A41C for ; Mon, 13 Jun 2005 12:56: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 C19AB43D1F for ; Mon, 13 Jun 2005 12:56: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 j5DCuh2N077924 for ; Mon, 13 Jun 2005 07:56:43 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42AD8270.8060906@centtech.com> Date: Mon, 13 Jun 2005 07:56:16 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050603 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/934/Sun Jun 12 17:44:50 2005 on mh1.centtech.com X-Virus-Status: Clean Subject: _mtx_lock_sleep kernel crash.. 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, 13 Jun 2005 12:56:45 -0000 I'm getting this: panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ /usr/src/sys/vm/vm_kern.c:295 cpuid = 0 KDB: enter: panic [thread pid 0 tid 0 ] Stopped at kdb_enter+0x2b: nop On bootup with my -current from a few days ago. Here's how I reproduce it: With a GENERIC kernel, add any of these to your /boot/loader.conf: vkbd_load="YES" snd_pcm_load="YES" snd_ich_load="YES" Removing 'smp' option from the kernel seems to fix it. db> trace Tracing pid 0 tid 0 td 0xc094b300 kdb_enter(c0882b13) at kdb_enter+0x2b panic(c0881fc3,c089d374,c089d714,127,c1059144) at panic+0x127 _mtx_lock_sleep(c1059144,c094b300,0,c089d714,127) at _mtx_lock_sleep+0x36 _mtx_lock_flags(c1059144,0,c089d714,127) at _mtx_lock_flags+0x85 _vm_map_lock(c10590c0,c089d714,127) at _vm_map_lock+0x26 kmem_malloc(c10590c0,1000,101,c0c20abc,c078d2cd) at kmem_malloc+0x32 page_alloc(c1063c60,1000,c0c20aaf,101,c0c20abc) at page_alloc+0x1a slab_zalloc(c1063c60,101,c1063c60,c1063c60,c1064640) at slab_zalloc+0xa1 uma_zone_slab(c1063c60,1,c1064648,0,c089c9cd,894) at uma_zone_slab+0xe8 uma_zalloc_internal(c1063c60,0,1,c1064648,0) at uma_zalloc_internal+0x29 uma_zalloc_arg(c1063c60,0,1) at uma_zalloc_arg+0x2fb vm_map_entry_create(c10590c0,0,c1056d8c,7070001,c1056d8c) at vm_map_entry_create+0x1e vm_map_insert(c10590c0,c09a8a20,23b2000,0,c22b1000) at vm_map_insert+0x1fc kmem_malloc(c10590c0,1000,101,c0c20bf4,c078d6c6) at kmem_malloc+0xc8 page_alloc(c1063c60,1000,c0c20c17,101,c1064640) at page_alloc+0x1a startup_alloc(c1063c60,1000,c0c20c17,101,c089c9cd) at startup_alloc+0xb2 slab_zalloc(c1063c60,101,6e,c1058f04,c103d624) at slab_zalloc+0xa1 uma_zone_slab(c1063c60,1,1,74,f643) at uma_zone_slab+0xe8 uma_zalloc_bucket(c1063c60,1) at uma_zalloc_bucket+0x130 uma_zalloc_arg(c1063c60,0,1) at uma_zalloc_arg+0x2b8 vm_map_entry_create(c1059000,10,c1056e9c,707f000,c1056e9c) at vm_map_entry_create+0x1e vm_map_insert(c1059000,0,0,0,e0990000) at vm_map_insert+0x1fc vm_map_find(c1059000,0,0,0,c0c20d2c,1000,1,7,7,4) at vm_map_find+0x86 kmem_alloc_nofault(c1059000,1000,400,c1022462,0) at kmem_alloc_nofault+0x37 pmap_mapdev(3ffd3400,68,c0c20d74,c080268a,c22a8584) at pmap_mapdev+0x58 madt_setup_local(c22a8584,c0921e10,c0c20d88,c0617932,0) at madt_setup_local+0x14 apic_init(0,c1ec00,c1e000,0,c0447db5) at apic_init+0x116 mi_startup() at mi_startup+0x96 begin() at begin+0x2c Any more debugging I can do? 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 Jun 13 15:06:05 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 1F93D16A41C for ; Mon, 13 Jun 2005 15:06:05 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8368A43D4C for ; Mon, 13 Jun 2005 15:06:04 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd25.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1DhqVm-0003sa-02; Mon, 13 Jun 2005 17:06:02 +0200 Received: from Andro-Beta.Leidinger.net (ZCZrJ6ZcreH5TSn4Y64hnBPJsVG02vpHmSqnTfyuxjxoKq3jvffY8g@[84.165.203.214]) by fwd25.sul.t-online.de with esmtp id 1DhqVb-0hWx1c0; Mon, 13 Jun 2005 17:05:51 +0200 Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j5DF5klg082000; Mon, 13 Jun 2005 17:05:46 +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, 13 Jun 2005 17:05:46 +0200 Message-ID: <20050613170546.utdvsmcyog0og0kg@netchild.homeip.net> X-Priority: 3 (Normal) Date: Mon, 13 Jun 2005 17:05:46 +0200 From: Alexander Leidinger To: Mark Linimon References: <20050612154403.2b49d0d8@Magellan.Leidinger.net> <20050612194227.GA11407@soaustin.net> <20050613004704.3c0d8fe2@Magellan.Leidinger.net> <20050613005030.GA22676@soaustin.net> In-Reply-To: <20050613005030.GA22676@soaustin.net> 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: ZCZrJ6ZcreH5TSn4Y64hnBPJsVG02vpHmSqnTfyuxjxoKq3jvffY8g@t-dialin.net X-TOI-MSGID: 30caf5a2-d932-42a4-a33a-ff11b36e1008 Cc: current@freebsd.org Subject: Re: TODO list for volunteers (similar to the list of things for Google's summer of 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, 13 Jun 2005 15:06:05 -0000 Mark Linimon wrote: > On Mon, Jun 13, 2005 at 12:47:04AM +0200, Alexander Leidinger wrote: >> Do you have any strong reasons which make the wiki a better choice? > > Lower barrier to entry. I mean, I have a doc commit bit and never > found our markup that hard to master, but that doesn't mean that > everyone else is interested in doing so. > > I just think it would be lower-weight and thus more people might be > able to contribute to it. Do you think it's more easy than to copy an existing entry and make modifications to it? And in case someone really fears the document, he is always free to ask if someone can markup his ideas. I'm thinking about the wiki as some kind of scratchboard. One can prototype something in it, or allow highly concruent developments of some sort. I don't think we need this for this list. I see the TODO list for volunteers as something more similar to our wishlist document. It also changes more or less frequently, and everyone is free to add and remove entries. Nobody complained so far that it's too complicated. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 "If you can count your money, you don't have a billion dollars." -- J. Paul Getty From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 17:58: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 6FA9516A41C for ; Mon, 13 Jun 2005 17:58:14 +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 CBFA543D5F for ; Mon, 13 Jun 2005 17:58:13 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5DHwC14013324; Mon, 13 Jun 2005 10:58:13 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5DHwCGv013323; Mon, 13 Jun 2005 10:58:12 -0700 (PDT) (envelope-from obrien) Date: Mon, 13 Jun 2005 10:58:12 -0700 From: "David O'Brien" To: Paul Richards Message-ID: <20050613175812.GA13200@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Paul Richards , freebsd-current@freebsd.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Subject: Re: Immediate reboots on amd64 after upgrading to current 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, 13 Jun 2005 17:58:14 -0000 On Sun, Jun 12, 2005 at 12:37:43PM +0100, Paul Richards wrote: > Is the 6-current broken at the moment? (unlikely as it seems like > quite a severe break) Definitely. A June 10th 4am UTC kernel works fine for me. A June 11 midnight UTC kernel, does an instana-reboot. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 18:20: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 E38D316A41C for ; Mon, 13 Jun 2005 18:20:30 +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 815AC43D1D for ; Mon, 13 Jun 2005 18:20:30 +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 j5DIPMUO005789; Mon, 13 Jun 2005 12:25:22 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42ADCDD5.9040209@samsco.org> Date: Mon, 13 Jun 2005 12:17:57 -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: Steve Kargl References: <20050612144703.GB10314@troutmask.apl.washington.edu> In-Reply-To: <20050612144703.GB10314@troutmask.apl.washington.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@freebsd.org, Paul Richards Subject: Re: Immediate reboots on amd64 after upgrading to 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, 13 Jun 2005 18:20:31 -0000 Steve Kargl wrote: > On Sun, Jun 12, 2005 at 12:37:43PM +0100, Paul Richards wrote: > >>I followed the handbook instructions of essentially make buildworld, >>buildkernel, installkernel etc.. When I rebooted however I found that >>the new kernel immediately reboots after selecting any of the options >>on the boot menu (safe mode, normal, single user, etc). > > > I'm seeing the exact same behavior. I upgraded a mid May current > to June 9th current and see this problem. I backed up to June 1st > via cvsup and the boot problem is still there. Ran out of time > to track things down until next week :-(. > > >>Is the 6-current broken at the moment? (unlikely as it seems like >>quite a severe break) > > > In my experience, the answer is yes. > Does the SNAP004 snapshot that I published work any better for you? Scott From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 18:40: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 025EB16A41C for ; Mon, 13 Jun 2005 18:40:02 +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 BF3BA43D1D for ; Mon, 13 Jun 2005 18:40:01 +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 j5DIe1Xh023861; Mon, 13 Jun 2005 11:40:01 -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 j5DIe1Qd023860; Mon, 13 Jun 2005 11:40:01 -0700 (PDT) (envelope-from sgk) Date: Mon, 13 Jun 2005 11:40:00 -0700 From: Steve Kargl To: Scott Long Message-ID: <20050613183959.GA23472@troutmask.apl.washington.edu> References: <20050612144703.GB10314@troutmask.apl.washington.edu> <42ADCDD5.9040209@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42ADCDD5.9040209@samsco.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Paul Richards Subject: Re: Immediate reboots on amd64 after upgrading to 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, 13 Jun 2005 18:40:02 -0000 On Mon, Jun 13, 2005 at 12:17:57PM -0600, Scott Long wrote: > Steve Kargl wrote: > > >On Sun, Jun 12, 2005 at 12:37:43PM +0100, Paul Richards wrote: > > > >>I followed the handbook instructions of essentially make buildworld, > >>buildkernel, installkernel etc.. When I rebooted however I found that > >>the new kernel immediately reboots after selecting any of the options > >>on the boot menu (safe mode, normal, single user, etc). > > > >I'm seeing the exact same behavior. I upgraded a mid May current > >to June 9th current and see this problem. I backed up to June 1st > >via cvsup and the boot problem is still there. Ran out of time > >to track things down until next week :-(. > > > >>Is the 6-current broken at the moment? (unlikely as it seems like > >>quite a severe break) > > > >In my experience, the answer is yes. > > > > Does the SNAP004 snapshot that I published work any better for you? > I'm downloading the ISO at the moment. firefox says it will take another 35 minutes. All I need is the kernel. Is there some place on freebsd.org from which I can pull the kernel? Also, David O'Brien has seen the instant reboot with a June 11th kernel, but he was able to boot a June 10th kernel. The ISO is from June 3rd source, so it is probably fine. My problem with a June 1st kernel may be a self-inflicted, premature installworld on June 9th. -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 18:41: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 F05A816A41C for ; Mon, 13 Jun 2005 18:41:08 +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 62D4E43D1F for ; Mon, 13 Jun 2005 18:41:08 +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 j5DIk01f005899; Mon, 13 Jun 2005 12:46:00 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42ADD2AB.7070608@samsco.org> Date: Mon, 13 Jun 2005 12:38:35 -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: Steve Kargl References: <20050612144703.GB10314@troutmask.apl.washington.edu> <42ADCDD5.9040209@samsco.org> <20050613183959.GA23472@troutmask.apl.washington.edu> In-Reply-To: <20050613183959.GA23472@troutmask.apl.washington.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@freebsd.org, Paul Richards Subject: Re: Immediate reboots on amd64 after upgrading to 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, 13 Jun 2005 18:41:09 -0000 Steve Kargl wrote: > On Mon, Jun 13, 2005 at 12:17:57PM -0600, Scott Long wrote: > >>Steve Kargl wrote: >> >> >>>On Sun, Jun 12, 2005 at 12:37:43PM +0100, Paul Richards wrote: >>> >>> >>>>I followed the handbook instructions of essentially make buildworld, >>>>buildkernel, installkernel etc.. When I rebooted however I found that >>>>the new kernel immediately reboots after selecting any of the options >>>>on the boot menu (safe mode, normal, single user, etc). >>> >>>I'm seeing the exact same behavior. I upgraded a mid May current >>>to June 9th current and see this problem. I backed up to June 1st >>>via cvsup and the boot problem is still there. Ran out of time >>>to track things down until next week :-(. >>> >>> >>>>Is the 6-current broken at the moment? (unlikely as it seems like >>>>quite a severe break) >>> >>>In my experience, the answer is yes. >>> >> >>Does the SNAP004 snapshot that I published work any better for you? >> > > > I'm downloading the ISO at the moment. firefox says it will take > another 35 minutes. All I need is the kernel. Is there some > place on freebsd.org from which I can pull the kernel? > > Also, David O'Brien has seen the instant reboot with a June 11th > kernel, but he was able to boot a June 10th kernel. The ISO > is from June 3rd source, so it is probably fine. My problem with > a June 1st kernel may be a self-inflicted, premature installworld > on June 9th. > You could pull the bootonly ISO and try that. Scott From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 18:53:02 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 61FB216A41C; Mon, 13 Jun 2005 18:53:02 +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 0676243D53; Mon, 13 Jun 2005 18:53:01 +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 j5DIqiua013525; Mon, 13 Jun 2005 14:52:44 -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 j5DIr0aU021551; Mon, 13 Jun 2005 14:53:00 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id 8930E7306E; Mon, 13 Jun 2005 14:53:00 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050613185300.8930E7306E@freebsd-current.sentex.ca> Date: Mon, 13 Jun 2005 14:53:00 -0400 (EDT) X-Virus-Scanned: ClamAV version 0.84, clamav-milter version 0.84e on clamscanner1 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: Mon, 13 Jun 2005 18:53:02 -0000 TB --- 2005-06-13 17:19:07 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-06-13 17:19:07 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2005-06-13 17:19:07 - cleaning the object tree TB --- 2005-06-13 17:19:35 - checking out the source tree TB --- 2005-06-13 17:19:35 - cd /home/tinderbox/CURRENT/sparc64/sparc64 TB --- 2005-06-13 17:19:35 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-06-13 17:25:30 - building world (CFLAGS=-O2 -pipe) TB --- 2005-06-13 17:25:30 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-06-13 17:25:30 - /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-06-13 18:32:49 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-13 18:32:49 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-06-13 18:32:49 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Mon Jun 13 18:32:49 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 Mon Jun 13 18:45:38 UTC 2005 TB --- 2005-06-13 18:45:38 - generating LINT kernel config TB --- 2005-06-13 18:45:38 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- 2005-06-13 18:45:38 - /usr/bin/make -B LINT TB --- 2005-06-13 18:45:38 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-13 18:45:38 - cd /home/tinderbox/CURRENT/sparc64/sparc64/src TB --- 2005-06-13 18:45:38 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Mon Jun 13 18:45:38 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/md4c.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/md5c.c cc -c -O2 -pipe -fno-strict-aliasing -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/altq -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/pf -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ngatm -I/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/sched_4bsd .c In file included from /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/sched_4bsd.c:1388: /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_switch.c: In function `maybe_preempt_in_ksegrp': /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_switch.c:435: error: `IPI_PREEMPT' undeclared (first use in this function) /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_switch.c:435: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_switch.c:435: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/tinderbox/CURRENT/sparc64/sparc64/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. *** Error code 1 Stop in /tinderbox/CURRENT/sparc64/sparc64/src. TB --- 2005-06-13 18:53:00 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-06-13 18:53:00 - ERROR: failed to build lint kernel TB --- 2005-06-13 18:53:00 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 19:12: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 B7C8216A41C for ; Mon, 13 Jun 2005 19:12:50 +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 35F0443D4C for ; Mon, 13 Jun 2005 19:12:50 +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 j5DJCmki000623; Mon, 13 Jun 2005 12:12:48 -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 j5DJCmAR000622; Mon, 13 Jun 2005 12:12:48 -0700 (PDT) (envelope-from sgk) Date: Mon, 13 Jun 2005 12:12:48 -0700 From: Steve Kargl To: Scott Long Message-ID: <20050613191248.GA572@troutmask.apl.washington.edu> References: <20050612144703.GB10314@troutmask.apl.washington.edu> <42ADCDD5.9040209@samsco.org> <20050613183959.GA23472@troutmask.apl.washington.edu> <42ADD2AB.7070608@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42ADD2AB.7070608@samsco.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Paul Richards Subject: Re: Immediate reboots on amd64 after upgrading to 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, 13 Jun 2005 19:12:50 -0000 On Mon, Jun 13, 2005 at 12:38:35PM -0600, Scott Long wrote: > Steve Kargl wrote: > > >I'm downloading the ISO at the moment. firefox says it will take > >another 35 minutes. All I need is the kernel. Is there some > >place on freebsd.org from which I can pull the kernel? > > > >Also, David O'Brien has seen the instant reboot with a June 11th > >kernel, but he was able to boot a June 10th kernel. The ISO > >is from June 3rd source, so it is probably fine. My problem with > >a June 1st kernel may be a self-inflicted, premature installworld > >on June 9th. > > > > You could pull the bootonly ISO and try that. > Thanks. I pulled the bootonly ISO. I then used a mdconfig /dev/md4 to mount the ISO image and copied /cdrom/boot/kernel/* to my /boot/sgk/*. I was able to boot the kernel. sysctl -a reports kern.osrelease: 6.0-CURRENT-SNAP004 kern.osrevision: 199506 kern.version: FreeBSD 6.0-CURRENT-SNAP004 #0: Wed Jun 1 20:05:46 UTC 2005 root@fanboy.samsco.home:/usr/obj/usr/src/sys/GENERIC kern.osreldate: 600029 kern.bootfile: /boot/sgk/kernel -- Steve From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 19:26: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 34EA716A41F for ; Mon, 13 Jun 2005 19:26:00 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id CEC6E43D1D for ; Mon, 13 Jun 2005 19:25:59 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Jun 2005 15:23:08 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id A831C13614; Mon, 13 Jun 2005 15:23:08 -0400 (EDT) Date: Mon, 13 Jun 2005 15:23:08 -0400 From: Ed Maste To: freebsd-current@freebsd.org Message-ID: <20050613192308.GA87640@sandvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 13 Jun 2005 19:23:08.0935 (UTC) FILETIME=[54EA2170:01C5704D] Subject: savecore(8) increments /var/crash/bounds on each boot 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, 13 Jun 2005 19:26:00 -0000 I notice that as of sbin/savecore/savecore.c 1.72 and in 5.4-RELEASE savecore increments the number in /var/crash/bounds on each boot, regardless of whether it rebooted due to panic or was a clean shutdown. Is this the desired behaviour or an unintentional side effect? We've been monitoring the value in bounds to detect panics, which of course doesn't work anymore. -- Ed Maste, Sandvine Inc. From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 20:03: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 ABEB416A41C for ; Mon, 13 Jun 2005 20:03:50 +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 8A89443D1F for ; Mon, 13 Jun 2005 20:03:50 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 7AF0A72DDF; Mon, 13 Jun 2005 13:03:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 7854E72DDD; Mon, 13 Jun 2005 13:03:50 -0700 (PDT) Date: Mon, 13 Jun 2005 13:03:50 -0700 (PDT) From: Doug White To: Ed Maste In-Reply-To: <20050613192308.GA87640@sandvine.com> Message-ID: <20050613130317.G2682@carver.gumbysoft.com> References: <20050613192308.GA87640@sandvine.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: savecore(8) increments /var/crash/bounds on each boot 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, 13 Jun 2005 20:03:50 -0000 On Mon, 13 Jun 2005, Ed Maste wrote: > I notice that as of sbin/savecore/savecore.c 1.72 and in 5.4-RELEASE > savecore increments the number in /var/crash/bounds on each boot, > regardless of whether it rebooted due to panic or was a clean shutdown. > > Is this the desired behaviour or an unintentional side effect? > We've been monitoring the value in bounds to detect panics, which > of course doesn't work anymore. Its certainly not the historical behavior :-) Think you could submit a patch with the fix? -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 20:05: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 B92EF16A41C for ; Mon, 13 Jun 2005 20:05:03 +0000 (GMT) (envelope-from hungershausen@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 56C1643D48 for ; Mon, 13 Jun 2005 20:05:03 +0000 (GMT) (envelope-from hungershausen@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so345335wri for ; Mon, 13 Jun 2005 13:05:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=SaDLx4CU8V0OoEIGAMcHgkQvZKwIHaFw4VBW8r/XxqB8Ag8PEtvME8xIpt6n82bHS8r8rRMSkGNbVwAfgMjz+qAf18D5hiAYofM9EgC0EvpUKDsq1eq6RZ17SiFLSE5DGiL9OXVe87CWJ2FfDfLSt/BFkTWJgeQcfX2fAAU48bI= Received: by 10.54.25.52 with SMTP id 52mr3025464wry; Mon, 13 Jun 2005 13:05:02 -0700 (PDT) Received: by 10.54.139.11 with HTTP; Mon, 13 Jun 2005 13:05:02 -0700 (PDT) Message-ID: Date: Mon, 13 Jun 2005 22:05:02 +0200 From: Rainer Hungershausen To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: if_ral + wpa_supplicant stack backtrace X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rainer Hungershausen List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2005 20:05:03 -0000 I get the following stack backtrace when using wpa_supplicant with ral0 I'm using 6.0-CURRENT from June 7th with GENERIC kernel. 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 (0xc2059d58) locked @= =20 /usr/src/sys/dev/ral/if_ral.c :2161 KDB: stack backtrace: kdb_backtrace(1,20,c1052580,1,e7c87b18) at kdb_backtrace+0x29 witness_warn(5,0,c086fa59,c0875351,20) at witness_warn+0x18e uma_zalloc_arg(c1052580,0,2) at uma_zalloc_arg+0x41 malloc(18,c08b7b80,2,801c69ea,c1f67c8c) at malloc+0xae ieee80211_ioctl_setoptie(c2059260,c2205940,e7c87b78,246,c0924f40) at=20 ieee80211_ioctl_setoptie+0x38 ieee80211_ioctl_set80211(c2059260,801c69ea,c2205940,0,c2059000) at=20 ieee80211_ioctl_set80211+0x6bb ieee80211_ioctl(c2059260,801c69ea,c2205940,e7c87c2c,801c69ea) at=20 ieee80211_ioctl+0x105 ral_ioctl(c2059000,801c69ea,c2205940,e7c87c38,c0629c1c) at ral_ioctl+0x80 in_control(c25e2298,801c69ea,c2205940,c2059000,c236f480) at in_control+0xb3= 3 ifioctl(c25e2298,801c69ea,c2205940,c236f480,0) at ifioctl+0x198 soo_ioctl(c2383828,801c69ea,c2205940,c25e7380,c236f480) at soo_ioctl+0x2db ioctl(c236f480,e7c87d04,3,1,282) at ioctl+0x370 syscall(3b,3b,3b,bfbfe04c,8063160) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (54, FreeBSD ELF32, ioctl), eip =3D 0x280f21db, esp =3D 0xbfbfe= 00c,=20 ebp =3D 0xbfbfe068 --- ral0: link state changed to UP ieee80211_load_module: load the wlan_ccmp module by hand for now. ral0: link state changed to DOWN I don't know what all this means, but after loading wlan_ccmp it works fine= =20 though... Regards, Rainer From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 20:50: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 0515D16A41C for ; Mon, 13 Jun 2005 20:50:56 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id 906DC43D49 for ; Mon, 13 Jun 2005 20:50:53 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 13 Jun 2005 16:50:52 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 47CE013607; Mon, 13 Jun 2005 16:50:52 -0400 (EDT) Date: Mon, 13 Jun 2005 16:50:52 -0400 From: Ed Maste To: Doug White Message-ID: <20050613205052.GA91486@sandvine.com> References: <20050613192308.GA87640@sandvine.com> <20050613130317.G2682@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: <20050613130317.G2682@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 13 Jun 2005 20:50:52.0500 (UTC) FILETIME=[963E6940:01C57059] Cc: freebsd-current@freebsd.org Subject: Re: savecore(8) increments /var/crash/bounds on each boot 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, 13 Jun 2005 20:50:56 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Jun 13, 2005 at 01:03:50PM -0700, Doug White wrote: > On Mon, 13 Jun 2005, Ed Maste wrote: > > > I notice that as of sbin/savecore/savecore.c 1.72 and in 5.4-RELEASE > > savecore increments the number in /var/crash/bounds on each boot, > > regardless of whether it rebooted due to panic or was a clean shutdown. > > > > Is this the desired behaviour or an unintentional side effect? > > We've been monitoring the value in bounds to detect panics, which > > of course doesn't work anymore. > > Its certainly not the historical behavior :-) > > Think you could submit a patch with the fix? The attached patch does the trick. In -vv mode the bounds used to be included with the first/last dump header output -- I just replaced it with -1. Problem originally discovered by Adrian Dewhurst. -- Ed Maste, Sandvine Inc. --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="savecore.patch" --- savecore.c.orig 2005-06-13 16:19:41.000000000 -0400 +++ savecore.c 2005-06-13 16:16:39.000000000 -0400 @@ -236,7 +236,6 @@ int bounds, status; u_int sectorsize; - bounds = getbounds(); dmpcnt = 0; mediasize = 0; status = STATUS_UNKNOWN; @@ -337,10 +336,10 @@ if (verbose >= 2) { printf("First dump headers:\n"); - printheader(stdout, &kdhf, device, bounds, -1); + printheader(stdout, &kdhf, device, -1, -1); printf("\nLast dump headers:\n"); - printheader(stdout, &kdhl, device, bounds, -1); + printheader(stdout, &kdhl, device, -1, -1); printf("\n"); } @@ -373,6 +372,8 @@ goto closefd; } + bounds = getbounds(); + sprintf(buf, "info.%d", bounds); /* --17pEHd4RhPHOinZp-- From owner-freebsd-current@FreeBSD.ORG Mon Jun 13 22:41:39 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 77AD916A41C for ; Mon, 13 Jun 2005 22:41:39 +0000 (GMT) (envelope-from joeldiaz@nc.rr.com) Received: from ms-smtp-02-eri0.southeast.rr.com (ms-smtp-02-lbl.southeast.rr.com [24.25.9.101]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3769A43D49 for ; Mon, 13 Jun 2005 22:41:38 +0000 (GMT) (envelope-from joeldiaz@nc.rr.com) Received: from [10.0.1.3] (cpe-069-134-210-251.nc.res.rr.com [69.134.210.251]) by ms-smtp-02-eri0.southeast.rr.com (8.12.10/8.12.7) with ESMTP id j5DMfZ0V001727; Mon, 13 Jun 2005 18:41:35 -0400 (EDT) In-Reply-To: <42ACE639.8030509@apache.org> References: <42ACE639.8030509@apache.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Joel Diaz Date: Mon, 13 Jun 2005 06:43:00 -0400 To: Paul Querna X-Mailer: Apple Mail (2.730) X-Virus-Scanned: Symantec AntiVirus Scan Engine Cc: q@onthenet.com.au, freebsd-current@freebsd.org Subject: Re: Panic with nve 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, 13 Jun 2005 22:41:39 -0000 On Jun 12, 2005, at 9:49 PM, Paul Querna wrote: > Using the 6.0-CURRENT June 2nd Snapshot, I get a panic pretty > quickly when using an original NForce 1 MCP Network Card(new nve > driver). This has happened while I was running sysinstall via > pxeboot, and starting a ftp install. This is what I copied from > the screen, omitting some things later in the stack trace: > > anic: nve_ifstart: attempted use of a free mbuf! > cpuid = 0 > KBD: enter: panic > [thread pid 35 tid 100022 ] > Stopped at kdb_enter+0x2b > db>trace > kdb_enter(x0855c9c) at kdb_enter 0x2b > panic(c082ad05,c08154dc,c1a388fc,c1a38800,ce7ebc80) at panic+0x127 > nve_ifstart(c1a38800,) at nve_ifstart+0x366 > if_start(c1a38800) at if_start+0x7b > ether_output_frame(c1a38800,v1b35300,0,0,0) at ether_output_frame > +0x1d9 > ether_output(c1a38800,v1b35300,,c1ab67d0,c1ba8c60,v1b58b00) at > ether_output+0x384 > ip_output() > tcp_output() > ip_input() > netisr_processqueue() > swi_net(0) > .... > > I don't have the gear locally to setup a serial console, so I am > hoping this is enough to give someone a clue. It looks easy to > reproduce, and I am happy to provide more information if needed. > > I did find a mention of a similar panic back in October of 2004, > but it was for the fxp driver: > http://lists.freebsd.org/pipermail/freebsd-net/2004-October/ > 005222.html > > Thanks, > > -Paul Querna I'm seeing the same thing here on my NForce 2 board. It used to be that I couldn't do a buildworld through SSH, but now I can trigger the panic by simply loading up a remote X session. After using X for about a minute, I get the following: %panic: nve_ifstart: attempted use of a free mbuf! cpuid = 0 KDB: enter: panic [thread pid 571 tid 100087 ] Stopped at kdb_enter+0x2b: nop db> trace Tracing pid 571 tid 100087 td 0xc2735000 kdb_enter(c084ebd5) at kdb_enter+0x2b panic(c08237f7,c080dffc,c2395100,350,e8cbaa98) at panic+0x127 nve_ifstart(c2395000) at nve_ifstart+0x35a if_start(c2395000) at if_start+0x7b ether_output_frame(c2395000,c239ec00,0,0,0) at ether_output_frame+0x1d9 ether_output(c2395000,c239ec00,eb12cad8,c273cbdc,c2732100) at ether_output+0x3b4 ip_output(c239ec00,0,eb12cad4,0,0) at ip_output+0x6fc tcp_output(c274eac8) at tcp_output+0xfb2 tcp_usr_rcvd(c2728a60,0,c2728ac8,0,c0855428) at tcp_usr_rcvd+0x82 soreceive(c2728a60,0,eb12cc78,0,0) at soreceive+0xc63 soo_read(c2690ab0,eb12cc78,c2691a00,0,c2735000) at soo_read+0x41 dofileread(c2735000,c2690ab0,3,bfbf9e40,4000) at dofileread+0xad read(c2735000,eb12cd04,3,2b,202) at read+0x3b syscall(3b,3b,3b,bfbf9e40,8078b40) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip = 0x282bc753, esp = 0xbfbf9e2c, ebp = 0xbfbfde58 --- db> Thanks, Joel Diaz > _______________________________________________ > 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 Jun 14 02:00: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 19FED16A41C; Tue, 14 Jun 2005 02:00:01 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) by mx1.FreeBSD.org (Postfix) with ESMTP id A051443D53; Tue, 14 Jun 2005 02:00:00 +0000 (GMT) (envelope-from ken@nargothrond.kdm.org) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.12.11/8.12.11) with ESMTP id j5E1xxN0033941; Mon, 13 Jun 2005 19:59:59 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.12.11/8.12.5/Submit) id j5E1xw73033940; Mon, 13 Jun 2005 19:59:58 -0600 (MDT) (envelope-from ken) Date: Mon, 13 Jun 2005 19:59:58 -0600 From: "Kenneth D. Merry" To: "Raphael H. Becker" Message-ID: <20050614015958.GA33865@nargothrond.kdm.org> References: <20050608171130.GA64736@over-yonder.net> <1118252322.7479.28.camel@zappa.Chelsea-Ct.Org> <20050609113616.I41471@p-i-n.com> <20050609130511.GA732@uk.tiscali.com> <20050610162814.A25098@p-i-n.com> <20050610150718.GA7005@nargothrond.kdm.org> <20050612002508.B25098@p-i-n.com> <20050612035440.GA21262@nargothrond.kdm.org> <20050613121915.C25098@p-i-n.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050613121915.C25098@p-i-n.com> User-Agent: Mutt/1.4.2i X-Virus-Scanned: ClamAV 0.85.1/937/Mon Jun 13 15:46:03 2005 on nargothrond.kdm.org X-Virus-Status: Clean Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: Accessing SCSI-Devices >2TB 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, 14 Jun 2005 02:00:01 -0000 On Mon, Jun 13, 2005 at 12:19:15 +0200, Raphael H. Becker wrote: > PS+BTW: any idea why the internal PERC is not listed in camcontrol devlist? > > In dmesg its listed like > aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 on pci4 > aac0: i960RX 100MHz, 118MB cache memory, optional battery present > aac0: Kernel 2.7-1, Build 3170, S/N 5410d3 > aac0: Supported Options=75c > [...] > aacd0: on aac0 > aacd0: 69425MB (142182912 sectors) > > pciconf: > aac0@pci4:8:1: class=0x010400 card=0x01211028 chip=0x000a1028 rev=0x01 hdr=0x00 > vendor = 'Dell Computer Corporation' > device = 'PowerEdge 3/Di Expandable RAID Controller' > class = mass storage > subclass = RAID > > It's not SCSI? It is a SCSI RAID controller, but the interface to the OS is a block interface, not a SCSI interface (*). It isn't routed through the SCSI layer, since that wouldn't really help it that much. (*) There is a SCSI passthrough interface for some aac controllers that can be enabled via the aacp driver. Ken -- Kenneth Merry ken@FreeBSD.ORG From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 02:22:58 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 2ACCE16A41C for ; Tue, 14 Jun 2005 02:22:58 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.198]) by mx1.FreeBSD.org (Postfix) with ESMTP id D881943D55 for ; Tue, 14 Jun 2005 02:22:57 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so135397nzk for ; Mon, 13 Jun 2005 19:22:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VXfQBLRG1GCwG5zMRAJ7S3ZE0ZxCBiM/6Y/iNLNpaLcU5+Ul2yN3JoYXn/0Zl3MjCVUDTcWKhrobLaoroJf9XyOhLL2eKjEEcVSIsNwW4QcBjDbvxz+0oy9i11L4OUtsPfVA/W5XjHQj9yrCjTLeJ1ZpzoGiqvTbZxOamqOZr8s= Received: by 10.36.129.6 with SMTP id b6mr3069751nzd; Mon, 13 Jun 2005 19:22:57 -0700 (PDT) Received: by 10.36.88.8 with HTTP; Mon, 13 Jun 2005 19:22:57 -0700 (PDT) Message-ID: Date: Tue, 14 Jun 2005 10:22:57 +0800 From: Jiawei Ye To: current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Cc: Subject: Revenge Of The SiS(4X) and A New Hope X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jiawei Ye List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 02:22:58 -0000 sis.ko drm module is broken on -current for quite a while. Starting X reboots the machine without leaving any crash dumps or kernel panic messages. Is there anything I can provide to diagnose the problem? With sis.ko present, disabling DRI in xorg.conf still reboots the machine spontaneously. I have to move sis.ko to another name to prevent auto-loading of the module. This seems to be the only current work-around. Jiawei --=20 "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 04:39: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 582A816A41C; Tue, 14 Jun 2005 04:39:13 +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 DD40C43D1F; Tue, 14 Jun 2005 04:39:12 +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 j5E4i0Im008862; Mon, 13 Jun 2005 22:44:00 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42AE5ED7.8070309@samsco.org> Date: Mon, 13 Jun 2005 22:36: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: "Kenneth D. Merry" References: <20050608171130.GA64736@over-yonder.net> <1118252322.7479.28.camel@zappa.Chelsea-Ct.Org> <20050609113616.I41471@p-i-n.com> <20050609130511.GA732@uk.tiscali.com> <20050610162814.A25098@p-i-n.com> <20050610150718.GA7005@nargothrond.kdm.org> <20050612002508.B25098@p-i-n.com> <20050612035440.GA21262@nargothrond.kdm.org> <20050613121915.C25098@p-i-n.com> <20050614015958.GA33865@nargothrond.kdm.org> In-Reply-To: <20050614015958.GA33865@nargothrond.kdm.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-scsi@freebsd.org, freebsd-current@freebsd.org, "Raphael H. Becker" Subject: Re: Accessing SCSI-Devices >2TB 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, 14 Jun 2005 04:39:13 -0000 Kenneth D. Merry wrote: > On Mon, Jun 13, 2005 at 12:19:15 +0200, Raphael H. Becker wrote: > >>PS+BTW: any idea why the internal PERC is not listed in camcontrol devlist? >> >>In dmesg its listed like >>aac0: mem 0xf0000000-0xf7ffffff irq 30 at device 8.1 on pci4 >>aac0: i960RX 100MHz, 118MB cache memory, optional battery present >>aac0: Kernel 2.7-1, Build 3170, S/N 5410d3 >>aac0: Supported Options=75c >>[...] >>aacd0: on aac0 >>aacd0: 69425MB (142182912 sectors) >> >>pciconf: >>aac0@pci4:8:1: class=0x010400 card=0x01211028 chip=0x000a1028 rev=0x01 hdr=0x00 >> vendor = 'Dell Computer Corporation' >> device = 'PowerEdge 3/Di Expandable RAID Controller' >> class = mass storage >> subclass = RAID >> >>It's not SCSI? > > > It is a SCSI RAID controller, but the interface to the OS is a block > interface, not a SCSI interface (*). It isn't routed through the SCSI > layer, since that wouldn't really help it that much. > > (*) There is a SCSI passthrough interface for some aac controllers that > can be enabled via the aacp driver. > > Ken And the aacp device causes many more problems than it solves, so I'll likely be disabling it soon. It only provides simple userland SCSI access to cdroms and tape drives, anyways. Scott From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 06:01: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 BB6A516A41C for ; Tue, 14 Jun 2005 06:01:52 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66C4D43D48 for ; Tue, 14 Jun 2005 06:01:52 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.51 (FreeBSD)) id 1Di4Uc-0000Hh-0D; Tue, 14 Jun 2005 10:01:46 +0400 From: Vladimir Grebenschikov To: Brooks Davis In-Reply-To: <20050607034620.GA32718@odin.ac.hmc.edu> References: <20050607034620.GA32718@odin.ac.hmc.edu> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Tue, 14 Jun 2005 10:01:45 +0400 Message-Id: <1118728905.939.5.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: OpenBSD dhclient incoming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 06:01:52 -0000 =F7 =D0=CE, 06/06/2005 =D7 20:46 -0700, Brooks Davis =D0=C9=DB=C5=D4: > I'm about to start importing the OpenBSD dhclient and required > support in /etc. I will unhook dhclient from the build while I work so > there shouldn't be much breakage for most people I have strange behavior of new dhclient + devd: just after boot (with ethernet plugged) I have no devd events about state of media and have interface down, but after first ifconfig (even without parameters, even executed by any user) "link state chages to UP" event appears and devd starts dhclient on interface. I do not think that it is desired behavior. my rc.conf, related to this:=20 ifconfig_fxp0=3D"dhcp" network_interfaces=3D"lo0" devd_enable=3D"YES" Probably I need to comment network_interfaces line, but anyway, now it works strange. > -- Brooks --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 06:11:10 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 CE00916A41C; Tue, 14 Jun 2005 06:11:10 +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 845CD43D53; Tue, 14 Jun 2005 06:11:10 +0000 (GMT) (envelope-from tinderbox@freebsd.org) Received: from smtp1.sentex.ca (smtp1c.sentex.ca [64.7.153.10]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j5E6Apap065519; Tue, 14 Jun 2005 02:10:52 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: from freebsd-current.sentex.ca (freebsd-current.sentex.ca [64.7.128.98]) by smtp1.sentex.ca (8.13.3/8.13.3) with ESMTP id j5E6B9DI049698; Tue, 14 Jun 2005 02:11:09 -0400 (EDT) (envelope-from tinderbox@freebsd.org) Received: by freebsd-current.sentex.ca (Postfix, from userid 666) id EE2AD7306E; Tue, 14 Jun 2005 02:11:08 -0400 (EDT) Sender: FreeBSD Tinderbox From: FreeBSD Tinderbox To: FreeBSD Tinderbox , , Precedence: bulk Message-Id: <20050614061108.EE2AD7306E@freebsd-current.sentex.ca> Date: Tue, 14 Jun 2005 02:11:08 -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 alpha/alpha 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, 14 Jun 2005 06:11:11 -0000 TB --- 2005-06-14 04:00:00 - tinderbox 2.3 running on freebsd-current.sentex.ca TB --- 2005-06-14 04:00:00 - starting CURRENT tinderbox run for alpha/alpha TB --- 2005-06-14 04:00:01 - cleaning the object tree TB --- 2005-06-14 04:00:25 - checking out the source tree TB --- 2005-06-14 04:00:25 - cd /home/tinderbox/CURRENT/alpha/alpha TB --- 2005-06-14 04:00:25 - /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2005-06-14 04:11:26 - building world (CFLAGS=-O2 -pipe) TB --- 2005-06-14 04:11:26 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-06-14 04:11: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-06-14 05:39:32 - building generic kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-14 05:39:32 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-06-14 05:39:32 - /usr/bin/make buildkernel KERNCONF=GENERIC >>> Kernel build for GENERIC started on Tue Jun 14 05:39:33 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 Jun 14 06:01:34 UTC 2005 TB --- 2005-06-14 06:01:34 - generating LINT kernel config TB --- 2005-06-14 06:01:34 - cd /home/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- 2005-06-14 06:01:34 - /usr/bin/make -B LINT TB --- 2005-06-14 06:01:34 - building LINT kernel (COPTFLAGS=-O2 -pipe) TB --- 2005-06-14 06:01:34 - cd /home/tinderbox/CURRENT/alpha/alpha/src TB --- 2005-06-14 06:01:34 - /usr/bin/make buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Tue Jun 14 06:01:35 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 [...] cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -I/tinderbox/CURRENT/alpha/alpha/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/md4c.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -I/tinderbox/CURRENT/alpha/alpha/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/md5c.c cc -c -O2 -pipe -fno-strict-aliasing -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/tinderbox/CURRENT/alpha/alpha/src/sys -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/altq -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/pf -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -I/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ngatm -I/tinderbox/CURRENT/alpha/alpha/src/sys/dev/twa -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /tinderbox/CURRENT/alpha/alpha/src/sys/kern/sched_4bsd.c In file included from /tinderbox/CURRENT/alpha/alpha/src/sys/kern/sched_4bsd.c:1388: /tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_switch.c: In function `maybe_preempt_in_ksegrp': /tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_switch.c:435: error: `IPI_PREEMPT' undeclared (first use in this function) /tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_switch.c:435: error: (Each undeclared identifier is reported only once /tinderbox/CURRENT/alpha/alpha/src/sys/kern/kern_switch.c:435: error: for each function it appears in.) *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/obj/alpha/tinderbox/CURRENT/alpha/alpha/src/sys/LINT. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. *** Error code 1 Stop in /tinderbox/CURRENT/alpha/alpha/src. TB --- 2005-06-14 06:11:08 - WARNING: /usr/bin/make returned exit code 1 TB --- 2005-06-14 06:11:08 - ERROR: failed to build lint kernel TB --- 2005-06-14 06:11:08 - tinderbox aborted From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 06:13: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 DD6A516A41F for ; Tue, 14 Jun 2005 06:13:33 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id ABB8043D1D for ; Tue, 14 Jun 2005 06:13:29 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.51 (FreeBSD)) id 1Di4fv-0000HR-Ve; Tue, 14 Jun 2005 10:13:27 +0400 From: Vladimir Grebenschikov To: Andre Guibert de Bruet In-Reply-To: <20050610083705.X42933@lexi.siliconlandmark.com> References: <20050522112612.GA37841@frontfree.net> <1118222710.1505.6.camel@localhost> <20050608145511.D42933@lexi.siliconlandmark.com> <1118260623.966.3.camel@localhost> <20050608172021.W42933@lexi.siliconlandmark.com> <1118395661.1066.3.camel@localhost> <20050610083705.X42933@lexi.siliconlandmark.com> Content-Type: multipart/mixed; boundary="=-C1Px2giEIuelF2g3mbPe" Organization: SWsoft Date: Tue, 14 Jun 2005 10:13:27 +0400 Message-Id: <1118729607.1008.4.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: freebsd-current@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: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 06:13:34 -0000 --=-C1Px2giEIuelF2g3mbPe Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable =F7 =D0=D4, 10/06/2005 =D7 08:43 -0400, Andre Guibert de Bruet =D0=C9=DB=C5= =D4: > On Fri, 10 Jun 2005, Vladimir Grebenschikov wrote: > > ? ??, 08/06/2005 ? 17:29 -0400, Andre Guibert de Bruet ?????: > >> On Wed, 8 Jun 2005, Vladimir Grebenschikov wrote: > >>> ? ??, 08/06/2005 ? 14:56 -0400, Andre Guibert de Bruet ?????: > >>>> > >>>> Let me guess... It's a laptop screen or an LCD panel? > >>> > >>> Yes, exactly, it is sony vzio z1. > >>> > >>> (II) RADEON(0): Panel ID string: Samsung LTN150P1-L02 > >>> (II) RADEON(0): Panel Size from BIOS: 1400x1050 > >>> (II) RADEON(0): BIOS provided dividers will be used. > >> > >> Most laptop LCDs and cheaper desktop panels take a while (The dreaded > >> second or two) to switch resolutions. Try the patch with an external c= rt > >> monitor plugged in and display mirroring enabled to see the difference= for > >> yourself (Or simply try it on a desktop with a radeon card and a crt). > > > > I have got a maximum waiting for switching from X to console (X screen > > disappeared very quick) - about 10 secs, probably it related to some > > disk activity, can syscon pages be swapped ? >=20 > Wow. 10 seconds goes beyond the limits of reasonable. I seen this only once or few number of times, usual time is 3-5 secs, but I think it is too much also. > I would not expect to see syscons pages being swapped, even under extreme= =20 > memory pressure. How much memory is available in this system? Could you=20 > make a recent boot -v (With the patch) and the kernel config available? In attachment, most drivers loaded as modules on boot (see attached loader.conf). Also I have attached log of X server. # kldstat Password: Id Refs Address Size Name 1 51 0xc0400000 2ee178 kernel 2 1 0xc06ef000 4228 vesa.ko 3 2 0xc06f4000 e5a0 msdosfs.ko 4 1 0xc0703000 b884 ntfs.ko 5 1 0xc070f000 9d5c if_fxp.ko 6 2 0xc0719000 17a48 miibus.ko 7 1 0xc0731000 5748 snd_ich.ko 8 2 0xc0737000 1d794 sound.ko 9 8 0xc0755000 1ee64 usb.ko 10 1 0xc0774000 7b38 ukbd.ko 11 1 0xc077c000 386c ulpt.ko 12 1 0xc0780000 3cf8 ums.ko 13 1 0xc0784000 63f8 umass.ko 14 9 0xc078b000 12440 agp.ko 15 2 0xc079e000 51d8 sysvmsg.ko 16 2 0xc07a4000 5e00 sysvsem.ko 17 2 0xc07aa000 5134 sysvshm.ko 18 2 0xc07b0000 1fc18 smbfs.ko 19 6 0xc07d0000 38d4 libiconv.ko 20 3 0xc07d4000 17fc libmchain.ko 21 1 0xc07d6000 7744 ng_ubt.ko 22 6 0xc07de000 c5f0 netgraph.ko 23 1 0xc07eb000 a7a4 sbp.ko 24 2 0xc07f6000 13af4 firewire.ko 25 1 0xc080a000 2c28 wlan_wep.ko 26 2 0xc080d000 1bb34 wlan.ko 27 1 0xc0829000 25a0 acpi_sony.ko 28 1 0xc082c000 a77c cbb.ko 29 3 0xc0837000 3154 exca.ko 30 1 0xc083b000 c6e8 pccard.ko 31 1 0xc2768000 2000 msdosfs_iconv.ko 32 4 0xc2a70000 2000 ng_bluetooth.ko 33 1 0xc2a7b000 c000 ng_hci.ko 34 1 0xc2a87000 e000 ng_l2cap.ko 35 1 0xc2a9d000 16000 ng_btsocket.ko 36 1 0xc2abb000 3000 ng_socket.ko 37 1 0xc2ae4000 15000 linux.ko # > Andy --=20 Vladimir B. Grebenschikov vova@fbsd.ru --=-C1Px2giEIuelF2g3mbPe Content-Disposition: attachment; filename=dmesg.boot Content-Type: text/plain; name=dmesg.boot; charset=KOI8-R Content-Transfer-Encoding: base64 RnJlZUJTRCA2LjAtQ1VSUkVOVCAjNDogVGh1IEp1biAgOSAwMzoxODozMiBNU0QgMjAwNQ0KICAg IHJvb3RAdmJvb2suZmJzZC5ydTovdXNyL29iai91c3Ivc3JjL3N5cy9WQk9PSw0KUHJlbG9hZGVk IGVsZiBrZXJuZWwgIi9ib290L2tlcm5lbC9rZXJuZWwiIGF0IDB4YzA4NDkwMDAuDQpQcmVsb2Fk ZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL3Zlc2Eua28iIGF0IDB4YzA4NDkxYTguDQpQcmVs b2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL21zZG9zZnMua28iIGF0IDB4YzA4NDkyNTQu DQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL250ZnMua28iIGF0IDB4YzA4NDkz MDAuDQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL2lmX2Z4cC5rbyIgYXQgMHhj MDg0OTNhYy4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvbWlpYnVzLmtvIiBh dCAweGMwODQ5NDU4Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9zbmRfaWNo LmtvIiBhdCAweGMwODQ5NTA0Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9z b3VuZC5rbyIgYXQgMHhjMDg0OTViMC4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJu ZWwvdXNiLmtvIiBhdCAweGMwODQ5NjVjLg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tl cm5lbC91a2JkLmtvIiBhdCAweGMwODQ5NzA0Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290 L2tlcm5lbC91bHB0LmtvIiBhdCAweGMwODQ5N2IwLg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9i b290L2tlcm5lbC91bXMua28iIGF0IDB4YzA4NDk4NWMuDQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAi L2Jvb3Qva2VybmVsL3VtYXNzLmtvIiBhdCAweGMwODQ5OTA0Lg0KUHJlbG9hZGVkIGVsZiBtb2R1 bGUgIi9ib290L2tlcm5lbC9hZ3Aua28iIGF0IDB4YzA4NDk5YjAuDQpQcmVsb2FkZWQgZWxmIG1v ZHVsZSAiL2Jvb3Qva2VybmVsL3N5c3Ztc2cua28iIGF0IDB4YzA4NDlhNTguDQpQcmVsb2FkZWQg ZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL3N5c3ZzZW0ua28iIGF0IDB4YzA4NDliMDQuDQpQcmVs b2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL3N5c3ZzaG0ua28iIGF0IDB4YzA4NDliYjAu DQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL3NtYmZzLmtvIiBhdCAweGMwODQ5 YzVjLg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9saWJpY29udi5rbyIgYXQg MHhjMDg0OWQwOC4NClByZWxvYWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvbGlibWNoYWlu LmtvIiBhdCAweGMwODQ5ZGI4Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9u Z191YnQua28iIGF0IDB4YzA4NDllNjguDQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2Vy bmVsL25ldGdyYXBoLmtvIiBhdCAweGMwODQ5ZjE0Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9i b290L2tlcm5lbC9zYnAua28iIGF0IDB4YzA4NDlmYzQuDQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAi L2Jvb3Qva2VybmVsL2ZpcmV3aXJlLmtvIiBhdCAweGMwODRhMDZjLg0KUHJlbG9hZGVkIGVsZiBt b2R1bGUgIi9ib290L2tlcm5lbC93bGFuX3dlcC5rbyIgYXQgMHhjMDg0YTExYy4NClByZWxvYWRl ZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvd2xhbi5rbyIgYXQgMHhjMDg0YTFjYy4NClByZWxv YWRlZCBlbGYgbW9kdWxlICIvYm9vdC9rZXJuZWwvYWNwaV9zb255LmtvIiBhdCAweGMwODRhMjc4 Lg0KUHJlbG9hZGVkIGVsZiBtb2R1bGUgIi9ib290L2tlcm5lbC9jYmIua28iIGF0IDB4YzA4NGEz MjguDQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL2V4Y2Eua28iIGF0IDB4YzA4 NGEzZDAuDQpQcmVsb2FkZWQgZWxmIG1vZHVsZSAiL2Jvb3Qva2VybmVsL3BjY2FyZC5rbyIgYXQg MHhjMDg0YTQ3Yy4NCkNhbGlicmF0aW5nIGNsb2NrKHMpIC4uLiBpODI1NCBjbG9jazogMTE5MzE0 MCBIeg0KQ0xLX1VTRV9JODI1NF9DQUxJQlJBVElPTiBub3Qgc3BlY2lmaWVkIC0gdXNpbmcgZGVm YXVsdCBmcmVxdWVuY3kNClRpbWVjb3VudGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHog cXVhbGl0eSAwDQpDYWxpYnJhdGluZyBUU0MgY2xvY2sgLi4uIFRTQyBjbG9jazogMTY4Njk2ODAw MCBIeg0KQ1BVOiBJbnRlbChSKSBQZW50aXVtKFIpIE0gcHJvY2Vzc29yIDE3MDBNSHogKDE2ODYu OTctTUh6IDY4Ni1jbGFzcyBDUFUpDQogIE9yaWdpbiA9ICJHZW51aW5lSW50ZWwiICBJZCA9IDB4 Njk1ICBTdGVwcGluZyA9IDUNCiAgRmVhdHVyZXM9MHhhN2U5ZjliZjxGUFUsVk1FLERFLFBTRSxU U0MsTVNSLE1DRSxDWDgsU0VQLE1UUlIsUEdFLE1DQSxDTU9WLFBBVCxDTEZMVVNILERUUyxBQ1BJ LE1NWCxGWFNSLFNTRSxTU0UyLFRNLFBCRT4NCiAgRmVhdHVyZXMyPTB4MTgwPEVTVCxUTTI+DQpy ZWFsIG1lbW9yeSAgPSAxMDczMTUyMDAwICgxMDIzIE1CKQ0KUGh5c2ljYWwgbWVtb3J5IGNodW5r KHMpOg0KMHgwMDAwMDAwMDAwMDAxMDAwIC0gMHgwMDAwMDAwMDAwMDllZmZmLCA2NDcxNjggYnl0 ZXMgKDE1OCBwYWdlcykNCjB4MDAwMDAwMDAwMDEwMDAwMCAtIDB4MDAwMDAwMDAwMDNmZmZmZiwg MzE0NTcyOCBieXRlcyAoNzY4IHBhZ2VzKQ0KMHgwMDAwMDAwMDAwYzI1MDAwIC0gMHgwMDAwMDAw MDNlZDQxZmZmLCAxMDQxMzU0NzUyIGJ5dGVzICgyNTQyMzcgcGFnZXMpDQphdmFpbCBtZW1vcnkg PSAxMDQxMjM1OTY4ICg5OTMgTUIpDQpiaW9zMzI6IEZvdW5kIEJJT1MzMiBTZXJ2aWNlIERpcmVj dG9yeSBoZWFkZXIgYXQgMHhjMDBmNmE1MA0KYmlvczMyOiBFbnRyeSA9IDB4ZmQ3NTEgKGMwMGZk NzUxKSAgUmV2ID0gMCAgTGVuID0gMQ0KcGNpYmlvczogUENJIEJJT1MgZW50cnkgYXQgMHhmZDc1 MCsweDI3Mw0KcG5wYmlvczogRm91bmQgUG5QIEJJT1MgZGF0YSBhdCAweGMwMGY2YWEwDQpwbnBi aW9zOiBFbnRyeSA9IGYwMDAwOmJlMDkgIFJldiA9IDEuMA0KT3RoZXIgQklPUyBzaWduYXR1cmVz IGZvdW5kOg0Kd2xhbjogPDgwMi4xMSBMaW5rIExheWVyPg0KcmFuZG9tOiA8ZW50cm9weSBzb3Vy Y2UsIFNvZnR3YXJlLCBZYXJyb3c+DQpWRVNBOiBpbmZvcm1hdGlvbiBibG9jaw0KNTYgNDUgNTMg NDEgMDAgMDIgMDAgMDEgMDAgMDEgMDEgMDAgMDAgMDAgMjIgMDAgDQowMCAwMSAwMCAwMSAwMCAw MSAxNCAwMSAwMCAwMSAyYSAwMSAwMCAwMSAyZiAwMSANCjAwIDAxIDgyIDAxIDBkIDAxIDBlIDAx IDBmIDAxIDIwIDAxIDkyIDAxIDkzIDAxIA0KOTQgMDEgOTUgMDEgOTYgMDEgYTIgMDEgYTMgMDEg YTQgMDEgYTUgMDEgYTYgMDEgDQpWRVNBOiA2MCBtb2RlKHMpIGZvdW5kDQpWRVNBOiB2Mi4wLCAx NjM4NGsgbWVtb3J5LCBmbGFnczoweDEsIG1vZGUgdGFibGU6MHhjMDZmMjMyMiAoMTAwMDAyMikN ClZFU0E6IEFUSSBNT0JJTElUWSBSQURFT04NClZFU0E6IEFUSSBUZWNobm9sb2dpZXMgSW5jLiBS MTAwIDAxLjAwDQppbzogPEkvTz4NCm5ldHNtYl9kZXY6IGxvYWRlZA0KbWVtOiA8bWVtb3J5Pg0K UGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQNCm51bGw6IDxudWxsIGRldmljZSwgemVy byBkZXZpY2U+DQpucHgwOiBbRkFTVF0NCm5weDA6IDxtYXRoIHByb2Nlc3Nvcj4gb24gbW90aGVy Ym9hcmQNCm5weDA6IElOVCAxNiBpbnRlcmZhY2UNCmFjcGkwOiA8U09OWT4gb24gbW90aGVyYm9h cmQNCmFjcGkwOiBbTVBTQUZFXQ0KcGNpX29wZW4oMSk6CW1vZGUgMSBhZGRyIHBvcnQgKDB4MGNm OCkgaXMgMHg4MDAwZjkwNA0KcGNpX29wZW4oMWEpOgltb2RlMXJlcz0weDgwMDAwMDAwICgweDgw MDAwMDAwKQ0KcGNpX2NmZ2NoZWNrOglkZXZpY2UgMCBbY2xhc3M9MDYwMDAwXSBbaGRyPTAwXSBp cyB0aGVyZSAoaWQ9MzM0MDgwODYpDQpwY2liaW9zOiBCSU9TIHZlcnNpb24gMi4xMA0KRm91bmQg JFBJUiB0YWJsZSwgOSBlbnRyaWVzIGF0IDB4YzAwZmRmMzANClBDSS1Pbmx5IEludGVycnVwdHM6 IG5vbmUNCkxvY2F0aW9uICBCdXMgRGV2aWNlIFBpbiAgTGluayAgSVJRcw0KZW1iZWRkZWQgICAg MiAgICA1ICAgIEEgICAweDY5ICAzDQplbWJlZGRlZCAgICAyICAgIDggICAgQSAgIDB4NjggIDkN CnNsb3QgMyAgICAgIDIgICAxMSAgICBBICAgMHg2MyAgOQ0KZW1iZWRkZWQgICAgMCAgIDI5ICAg IEEgICAweDYwICA5DQplbWJlZGRlZCAgICAwICAgMjkgICAgQiAgIDB4NjMgIDkNCmVtYmVkZGVk ICAgIDAgICAgMSAgICBBICAgMHg2MCAgMyA0IDUgNiA3IDkgMTAgMTINCmVtYmVkZGVkICAgIDAg ICAgMSAgICBCICAgMHg2MSAgMyA0IDUgNiA3IDkgMTAgMTINCkFjcGlPc0Rlcml2ZVBjaUlkOiBi dXMgMiBkZXYgNSBmdW5jIDANCkFjcGlPc0Rlcml2ZVBjaUlkOiBidXMgMCBkZXYgMzEgZnVuYyAw DQpBY3BpT3NEZXJpdmVQY2lJZDogYnVzIDAgZGV2IDAgZnVuYyAwDQpwY2lfbGluazA6IDxBQ1BJ IFBDSSBMaW5rIExOS0E+IGlycSA5IG9uIGFjcGkwDQpwY2lfbGluazA6IExpbmtzIGFmdGVyIGlu aXRpYWwgcHJvYmU6DQpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICAgIDAgICAgOSAgIE4g ICAgIDAgIDkNCnBjaV9saW5rMDogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOg0KSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgICAwICAgIDkgICBOICAgICAwICA5DQpwY2lfbGlu azA6IExpbmtzIGFmdGVyIGRpc2FibGU6DQpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICAg IDAgIDI1NSAgIE4gICAgIDAgIDkNCnBjaV9saW5rMTogPEFDUEkgUENJIExpbmsgTE5LQj4gaXJx IDAgb24gYWNwaTANCnBjaV9saW5rMTogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToNCkluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogICAgMCAgMjU1ICAgTiAgICAgMCAgOQ0KcGNpX2xpbmsx OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246DQpJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcw0KICAgIDAgIDI1NSAgIE4gICAgIDAgIDkNCnBjaV9saW5rMTogTGlua3MgYWZ0ZXIgZGlz YWJsZToNCkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogICAgMCAgMjU1ICAgTiAgICAgMCAg OQ0KcGNpX2xpbmsyOiA8QUNQSSBQQ0kgTGluayBMTktDPiBpcnEgMCBvbiBhY3BpMA0KcGNpX2xp bmsyOiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOg0KSW5kZXggIElSUSAgUnRkICBSZWYgIElS UXMNCiAgICAwICAyNTUgICBOICAgICAwICA5DQpwY2lfbGluazI6IExpbmtzIGFmdGVyIGluaXRp YWwgdmFsaWRhdGlvbjoNCkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogICAgMCAgMjU1ICAg TiAgICAgMCAgOQ0KcGNpX2xpbmsyOiBMaW5rcyBhZnRlciBkaXNhYmxlOg0KSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMNCiAgICAwICAyNTUgICBOICAgICAwICA5DQpwY2lfbGluazM6IDxBQ1BJ IFBDSSBMaW5rIExOS0Q+IGlycSA5IG9uIGFjcGkwDQpwY2lfbGluazM6IExpbmtzIGFmdGVyIGlu aXRpYWwgcHJvYmU6DQpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICAgIDAgICAgOSAgIE4g ICAgIDAgIDkNCnBjaV9saW5rMzogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOg0KSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgICAwICAgIDkgICBOICAgICAwICA5DQpwY2lfbGlu azM6IExpbmtzIGFmdGVyIGRpc2FibGU6DQpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICAg IDAgIDI1NSAgIE4gICAgIDAgIDkNCnBjaV9saW5rNDogPEFDUEkgUENJIExpbmsgTE5LRT4gaXJx IDkgb24gYWNwaTANCnBjaV9saW5rNDogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToNCkluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogICAgMCAgICA5ICAgTiAgICAgMCAgOQ0KcGNpX2xpbms0 OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246DQpJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcw0KICAgIDAgICAgOSAgIE4gICAgIDAgIDkNCnBjaV9saW5rNDogTGlua3MgYWZ0ZXIgZGlz YWJsZToNCkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogICAgMCAgMjU1ICAgTiAgICAgMCAg OQ0KcGNpX2xpbms1OiA8QUNQSSBQQ0kgTGluayBMTktGPiBpcnEgMyBvbiBhY3BpMA0KcGNpX2xp bms1OiBMaW5rcyBhZnRlciBpbml0aWFsIHByb2JlOg0KSW5kZXggIElSUSAgUnRkICBSZWYgIElS UXMNCiAgICAwICAgIDMgICBOICAgICAwICA5DQpwY2lfbGluazU6IExpbmtzIGFmdGVyIGluaXRp YWwgdmFsaWRhdGlvbjoNCkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogICAgMCAgMjU1ICAg TiAgICAgMCAgOQ0KcGNpX2xpbms1OiBMaW5rcyBhZnRlciBkaXNhYmxlOg0KSW5kZXggIElSUSAg UnRkICBSZWYgIElSUXMNCiAgICAwICAyNTUgICBOICAgICAwICA5DQpwY2lfbGluazY6IDxBQ1BJ IFBDSSBMaW5rIExOS0c+IGlycSAwIG9uIGFjcGkwDQpwY2lfbGluazY6IExpbmtzIGFmdGVyIGlu aXRpYWwgcHJvYmU6DQpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICAgIDAgIDI1NSAgIE4g ICAgIDAgIDkNCnBjaV9saW5rNjogTGlua3MgYWZ0ZXIgaW5pdGlhbCB2YWxpZGF0aW9uOg0KSW5k ZXggIElSUSAgUnRkICBSZWYgIElSUXMNCiAgICAwICAyNTUgICBOICAgICAwICA5DQpwY2lfbGlu azY6IExpbmtzIGFmdGVyIGRpc2FibGU6DQpJbmRleCAgSVJRICBSdGQgIFJlZiAgSVJRcw0KICAg IDAgIDI1NSAgIE4gICAgIDAgIDkNCnBjaV9saW5rNzogPEFDUEkgUENJIExpbmsgTE5LSD4gaXJx IDAgb24gYWNwaTANCnBjaV9saW5rNzogTGlua3MgYWZ0ZXIgaW5pdGlhbCBwcm9iZToNCkluZGV4 ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogICAgMCAgMjU1ICAgTiAgICAgMCAgOQ0KcGNpX2xpbms3 OiBMaW5rcyBhZnRlciBpbml0aWFsIHZhbGlkYXRpb246DQpJbmRleCAgSVJRICBSdGQgIFJlZiAg SVJRcw0KICAgIDAgIDI1NSAgIE4gICAgIDAgIDkNCnBjaV9saW5rNzogTGlua3MgYWZ0ZXIgZGlz YWJsZToNCkluZGV4ICBJUlEgIFJ0ZCAgUmVmICBJUlFzDQogICAgMCAgMjU1ICAgTiAgICAgMCAg OQ0KYWNwaV9lYzA6IDxFbWJlZGRlZCBDb250cm9sbGVyOiBHUEUgMHgxYz4gcG9ydCAweDYyLDB4 NjYgb24gYWNwaTANCmFjcGlfZWMwOiBpbmZvOiBuZXcgbWF4IGRlbGF5IGlzIDMwMCB1cw0KQUNQ SSB0aW1lcjogMS8wIDEvMCAxLzAgMS8wIDEvMCAxLzAgMS8wIDEvMCAxLzAgMS8wIC0+IDEwDQpU aW1lY291bnRlciAiQUNQSS1mYXN0IiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5IDEwMDAN CmFjcGlfdGltZXIwOiA8MjQtYml0IHRpbWVyIGF0IDMuNTc5NTQ1TUh6PiBwb3J0IDB4MTAwOC0w eDEwMGIgb24gYWNwaTANCmNwdTA6IDxBQ1BJIENQVT4gb24gYWNwaTANCmFjcGlfcGVyZjA6IDxB Q1BJIENQVSBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MA0KYWNwaV9wZXJmMDogZmFpbGVkIGlu IFBFUkZfU1RBVFVTIGF0dGFjaA0KZGV2aWNlX2F0dGFjaDogYWNwaV9wZXJmMCBhdHRhY2ggcmV0 dXJuZWQgNg0KYWNwaV90aHJvdHRsZTA6IDxBQ1BJIENQVSBUaHJvdHRsaW5nPiBvbiBjcHUwDQph Y3BpX3Rocm90dGxlMDogUF9DTlQgZnJvbSBQX0JMSyAweDEwMTANCmFjcGlfcGVyZjA6IDxBQ1BJ IENQVSBGcmVxdWVuY3kgQ29udHJvbD4gb24gY3B1MA0KYWNwaV9wZXJmMDogZmFpbGVkIGluIFBF UkZfU1RBVFVTIGF0dGFjaA0KZGV2aWNlX2F0dGFjaDogYWNwaV9wZXJmMCBhdHRhY2ggcmV0dXJu ZWQgNg0KYWNwaV9saWQwOiA8Q29udHJvbCBNZXRob2QgTGlkIFN3aXRjaD4gb24gYWNwaTANCmFj cGlfYnV0dG9uMDogPFBvd2VyIEJ1dHRvbj4gb24gYWNwaTANCnBjaWIwOiA8QUNQSSBIb3N0LVBD SSBicmlkZ2U+IHBvcnQgMHhjZjgtMHhjZmYgb24gYWNwaTANCnBjaTA6IDxBQ1BJIFBDSSBidXM+ IG9uIHBjaWIwDQpwY2kwOiBwaHlzaWNhbCBidXM9MA0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBk ZXY9MHgzMzQwLCByZXZpZD0weDAzDQoJYnVzPTAsIHNsb3Q9MCwgZnVuYz0wDQoJY2xhc3M9MDYt MDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgy MDkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9 MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KCW1hcFsxMF06IHR5cGUgMywgcmFuZ2Ug MzIsIGJhc2UgZTAwMDAwMDAsIHNpemUgMjgsIGVuYWJsZWQNCmZvdW5kLT4JdmVuZG9yPTB4ODA4 NiwgZGV2PTB4MzM0MSwgcmV2aWQ9MHgwMw0KCWJ1cz0wLCBzbG90PTEsIGZ1bmM9MA0KCWNsYXNz PTA2LTA0LTAwLCBoZHJ0eXBlPTB4MDEsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA3LCBzdGF0cmVn PTB4MDBhMCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDYwICgyODgwIG5zKSwg bWluZ250PTB4MGMgKDMwMDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCmZvdW5kLT4JdmVuZG9y PTB4ODA4NiwgZGV2PTB4MjRjMiwgcmV2aWQ9MHgwMw0KCWJ1cz0wLCBzbG90PTI5LCBmdW5jPTAN CgljbGFzcz0wYy0wMy0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0xDQoJY21kcmVnPTB4MDAwNSwg c3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBu cyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWEsIGly cT05DQoJbWFwWzIwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwMTgwMCwgc2l6ZSAgNSwg ZW5hYmxlZA0KcGNpYjA6IG1hdGNoZWQgZW50cnkgZm9yIDAuMjkuSU5UQSAoc3JjIFxcX1NCXy5Q Q0kwLkxQQ0IuTE5LQTowKQ0KcGNpYjA6IHNsb3QgMjkgSU5UQSByb3V0ZWQgdG8gaXJxIDkgdmlh IFxcX1NCXy5QQ0kwLkxQQ0IuTE5LQQ0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHgyNGM0 LCByZXZpZD0weDAzDQoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9MQ0KCWNsYXNzPTBjLTAzLTAwLCBo ZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA1LCBzdGF0cmVnPTB4MDI4MCwgY2Fj aGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4MDAgKDAg bnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49YiwgaXJxPTkNCgltYXBbMjBdOiB0eXBl IDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAxODIwLCBzaXplICA1LCBlbmFibGVkDQpwY2liMDogbWF0 Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRCIChzcmMgXFxfU0JfLlBDSTAuTFBDQi5MTktEOjApDQpw Y2liMDogc2xvdCAyOSBJTlRCIHJvdXRlZCB0byBpcnEgOSB2aWEgXFxfU0JfLlBDSTAuTFBDQi5M TktEDQpmb3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDI0YzcsIHJldmlkPTB4MDMNCglidXM9 MCwgc2xvdD0yOSwgZnVuYz0yDQoJY2xhc3M9MGMtMDMtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9 MA0KCWNtZHJlZz0weDAwMDUsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQ0K CWxhdHRpbWVyPTB4MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgw IG5zKQ0KCWludHBpbj1jLCBpcnE9MjU1DQoJbWFwWzIwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFz ZSAwMDAwMTg0MCwgc2l6ZSAgNSwgZW5hYmxlZA0KZm91bmQtPgl2ZW5kb3I9MHg4MDg2LCBkZXY9 MHgyNGNkLCByZXZpZD0weDAzDQoJYnVzPTAsIHNsb3Q9MjksIGZ1bmM9Nw0KCWNsYXNzPTBjLTAz LTIwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA2LCBzdGF0cmVnPTB4MDI5 MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgwIG5zKSwgbWluZ250PTB4 MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49ZCwgaXJxPTI1NQ0KCXBvd2Vy c3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KCW1hcFsxMF06IHR5cGUgMSwgcmFu Z2UgMzIsIGJhc2UgZDAwMDAwMDAsIHNpemUgMTAsIGVuYWJsZWQNCmZvdW5kLT4JdmVuZG9yPTB4 ODA4NiwgZGV2PTB4MjQ0OCwgcmV2aWQ9MHg4Mw0KCWJ1cz0wLCBzbG90PTMwLCBmdW5jPTANCglj bGFzcz0wNi0wNC0wMCwgaGRydHlwZT0weDAxLCBtZmRldj0wDQoJY21kcmVnPTB4MDAwNywgc3Rh dHJlZz0weDgwODAsIGNhY2hlbG5zej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyks IG1pbmdudD0weDA0ICgxMDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQpmb3VuZC0+CXZlbmRv cj0weDgwODYsIGRldj0weDI0Y2MsIHJldmlkPTB4MDMNCglidXM9MCwgc2xvdD0zMSwgZnVuYz0w DQoJY2xhc3M9MDYtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQ0KCWNtZHJlZz0weDAwMGYs IHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4MDAgKDAg bnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KZm91bmQtPgl2ZW5k b3I9MHg4MDg2LCBkZXY9MHgyNGNhLCByZXZpZD0weDAzDQoJYnVzPTAsIHNsb3Q9MzEsIGZ1bmM9 MQ0KCWNsYXNzPTAxLTAxLThhLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMDA1 LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykNCglsYXR0aW1lcj0weDAwICgw IG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykNCglpbnRwaW49YSwg aXJxPTI1NQ0KCW1hcFsyMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDE4NjAsIHNpemUg IDQsIGVuYWJsZWQNCgltYXBbMjRdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIDAwMDAwMDAwLCBz aXplIDEwLCBtZW1vcnkgZGlzYWJsZWQNCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRj MywgcmV2aWQ9MHgwMw0KCWJ1cz0wLCBzbG90PTMxLCBmdW5jPTMNCgljbGFzcz0wYy0wNS0wMCwg aGRydHlwZT0weDAwLCBtZmRldj0wDQoJY21kcmVnPTB4MDAwMSwgc3RhdHJlZz0weDAyODAsIGNh Y2hlbG5zej0wIChkd29yZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWIsIGlycT0yNTUNCgltYXBbMjBdOiB0 eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAxODgwLCBzaXplICA1LCBlbmFibGVkDQpmb3VuZC0+ CXZlbmRvcj0weDgwODYsIGRldj0weDI0YzUsIHJldmlkPTB4MDMNCglidXM9MCwgc2xvdD0zMSwg ZnVuYz01DQoJY2xhc3M9MDQtMDEtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MA0KCWNtZHJlZz0w eDAwMDcsIHN0YXRyZWc9MHgwMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4 MDAgKDAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1heGxhdD0weDAwICgwIG5zKQ0KCWludHBp bj1iLCBpcnE9OQ0KCXBvd2Vyc3BlYyAyICBzdXBwb3J0cyBEMCBEMyAgY3VycmVudCBEMA0KCW1h cFsxMF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDFjMDAsIHNpemUgIDgsIGVuYWJsZWQN CgltYXBbMTRdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAxOGMwLCBzaXplICA2LCBlbmFi bGVkDQoJbWFwWzE4XTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBkMDAwMGMwMCwgc2l6ZSAgOSwg ZW5hYmxlZA0KCW1hcFsxY106IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZDAwMDA4MDAsIHNpemUg IDgsIGVuYWJsZWQNCnBjaWIwOiBtYXRjaGVkIGVudHJ5IGZvciAwLjMxLklOVEIgKHNyYyBcXF9T Ql8uUENJMC5MUENCLkxOS0I6MCkNCnBjaV9saW5rMTogUGlja2VkIElSUSA5IHdpdGggd2VpZ2h0 IDQNCnBjaWIwOiBzbG90IDMxIElOVEIgcm91dGVkIHRvIGlycSA5IHZpYSBcXF9TQl8uUENJMC5M UENCLkxOS0INCmZvdW5kLT4JdmVuZG9yPTB4ODA4NiwgZGV2PTB4MjRjNiwgcmV2aWQ9MHgwMw0K CWJ1cz0wLCBzbG90PTMxLCBmdW5jPTYNCgljbGFzcz0wNy0wMy0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0wDQoJY21kcmVnPTB4MDAwNSwgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0wIChkd29y ZHMpDQoJbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4 MDAgKDAgbnMpDQoJaW50cGluPWIsIGlycT0yNTUNCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAg RDMgIGN1cnJlbnQgRDANCgltYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDAyNDAw LCBzaXplICA4LCBlbmFibGVkDQoJbWFwWzE0XTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAw MjAwMCwgc2l6ZSAgNywgZW5hYmxlZA0KYWdwMDogPEludGVsIDgyODU1IGhvc3QgdG8gQUdQIGJy aWRnZT4gbWVtIDB4ZTAwMDAwMDAtMHhlZmZmZmZmZiBhdCBkZXZpY2UgMC4wIG9uIHBjaTANCmFn cDA6IFJlc2VydmVkIDB4MTAwMDAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGUw MDAwMDAwDQphZ3AwOiBhbGxvY2F0aW5nIEdBVFQgZm9yIGFwZXJ0dXJlIG9mIHNpemUgMjU2TQ0K cGNpYjE6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTANCnBjaWIx OiAgIHNlY29uZGFyeSBidXMgICAgIDENCnBjaWIxOiAgIHN1Ym9yZGluYXRlIGJ1cyAgIDENCnBj aWIxOiAgIEkvTyBkZWNvZGUgICAgICAgIDB4MzAwMC0weDNmZmYNCnBjaWIxOiAgIG1lbW9yeSBk ZWNvZGUgICAgIDB4ZDAxMDAwMDAtMHhkMDFmZmZmZg0KcGNpYjE6ICAgcHJlZmV0Y2hlZCBkZWNv ZGUgMHhkODAwMDAwMC0weGRmZmZmZmZmDQpwY2kxOiA8QUNQSSBQQ0kgYnVzPiBvbiBwY2liMQ0K cGNpMTogcGh5c2ljYWwgYnVzPTENCmZvdW5kLT4JdmVuZG9yPTB4MTAwMiwgZGV2PTB4NGM1OSwg cmV2aWQ9MHgwMA0KCWJ1cz0xLCBzbG90PTAsIGZ1bmM9MA0KCWNsYXNzPTAzLTAwLTAwLCBoZHJ0 eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9MHgwMjgzLCBzdGF0cmVnPTB4MDJiMCwgY2FjaGVs bnN6PTE2IChkd29yZHMpDQoJbGF0dGltZXI9MHg0MiAoMTk4MCBucyksIG1pbmdudD0weDA4ICgy MDAwIG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpDQoJaW50cGluPWEsIGlycT05DQoJcG93ZXJzcGVj IDIgIHN1cHBvcnRzIEQwIEQxIEQyIEQzICBjdXJyZW50IEQwDQoJbWFwWzEwXTogdHlwZSAzLCBy YW5nZSAzMiwgYmFzZSBkODAwMDAwMCwgc2l6ZSAyNywgZW5hYmxlZA0KcGNpYjE6IChudWxsKSBy ZXF1ZXN0ZWQgbWVtb3J5IHJhbmdlIDB4ZDgwMDAwMDAtMHhkZmZmZmZmZjogZ29vZA0KCW1hcFsx NF06IHR5cGUgNCwgcmFuZ2UgMzIsIGJhc2UgMDAwMDMwMDAsIHNpemUgIDgsIGVuYWJsZWQNCnBj aWIxOiAobnVsbCkgcmVxdWVzdGVkIEkvTyByYW5nZSAweDMwMDAtMHgzMGZmOiBpbiByYW5nZQ0K CW1hcFsxOF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZDAxMDAwMDAsIHNpemUgMTYsIGVuYWJs ZWQNCnBjaWIxOiAobnVsbCkgcmVxdWVzdGVkIG1lbW9yeSByYW5nZSAweGQwMTAwMDAwLTB4ZDAx MGZmZmY6IGdvb2QNCnBjaWIxOiBtYXRjaGVkIGVudHJ5IGZvciAxLjAuSU5UQSAoc3JjIFxcX1NC Xy5QQ0kwLkxQQ0IuTE5LQTowKQ0KcGNpYjE6IHNsb3QgMCBJTlRBIHJvdXRlZCB0byBpcnEgOSB2 aWEgXFxfU0JfLlBDSTAuTFBDQi5MTktBDQpwY2kxOiA8ZGlzcGxheSwgVkdBPiBhdCBkZXZpY2Ug MC4wIChubyBkcml2ZXIgYXR0YWNoZWQpDQp1aGNpMDogPEludGVsIDgyODAxREIgKElDSDQpIFVT QiBjb250cm9sbGVyIFVTQi1BPiBwb3J0IDB4MTgwMC0weDE4MWYgaXJxIDkgYXQgZGV2aWNlIDI5 LjAgb24gcGNpMA0KdWhjaTA6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUg NCBhdCAweDE4MDANCnVoY2kwOiBbR0lBTlQtTE9DS0VEXQ0KdXNiMDogPEludGVsIDgyODAxREIg KElDSDQpIFVTQiBjb250cm9sbGVyIFVTQi1BPiBvbiB1aGNpMA0KdXNiMDogVVNCIHJldmlzaW9u IDEuMA0KdWh1YjA6IEludGVsIFVIQ0kgcm9vdCBodWIsIGNsYXNzIDkvMCwgcmV2IDEuMDAvMS4w MCwgYWRkciAxDQp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQN CnVoY2kxOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNCLUI+IHBvcnQg MHgxODIwLTB4MTgzZiBpcnEgOSBhdCBkZXZpY2UgMjkuMSBvbiBwY2kwDQp1aGNpMTogUmVzZXJ2 ZWQgMHgyMCBieXRlcyBmb3IgcmlkIDB4MjAgdHlwZSA0IGF0IDB4MTgyMA0KdWhjaTE6IFtHSUFO VC1MT0NLRURdDQp1c2IxOiA8SW50ZWwgODI4MDFEQiAoSUNINCkgVVNCIGNvbnRyb2xsZXIgVVNC LUI+IG9uIHVoY2kxDQp1c2IxOiBVU0IgcmV2aXNpb24gMS4wDQp1aHViMTogSW50ZWwgVUhDSSBy b290IGh1YiwgY2xhc3MgOS8wLCByZXYgMS4wMC8xLjAwLCBhZGRyIDENCnVodWIxOiAyIHBvcnRz IHdpdGggMiByZW1vdmFibGUsIHNlbGYgcG93ZXJlZA0KdWhjaTI6IDxJbnRlbCA4MjgwMURCIChJ Q0g0KSBVU0IgY29udHJvbGxlciBVU0ItQz4gcG9ydCAweDE4NDAtMHgxODVmIGF0IGRldmljZSAy OS4yIG9uIHBjaTANCnVoY2kyOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgyMCB0eXBl IDQgYXQgMHgxODQwDQpwY2liMDogbWF0Y2hlZCBlbnRyeSBmb3IgMC4yOS5JTlRDIChzcmMgXFxf U0JfLlBDSTAuTFBDQi5MTktDOjApDQpwY2lfbGluazI6IFBpY2tlZCBJUlEgOSB3aXRoIHdlaWdo dCA3DQpwY2liMDogc2xvdCAyOSBJTlRDIHJvdXRlZCB0byBpcnEgOSB2aWEgXFxfU0JfLlBDSTAu TFBDQi5MTktDDQp1aGNpMjogW0dJQU5ULUxPQ0tFRF0NCnVzYjI6IDxJbnRlbCA4MjgwMURCIChJ Q0g0KSBVU0IgY29udHJvbGxlciBVU0ItQz4gb24gdWhjaTINCnVzYjI6IFVTQiByZXZpc2lvbiAx LjANCnVodWIyOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMQ0KdWh1YjI6IDIgcG9ydHMgd2l0aCAyIHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQpl aGNpMDogPEVIQ0kgKGdlbmVyaWMpIFVTQiAyLjAgY29udHJvbGxlcj4gbWVtIDB4ZDAwMDAwMDAt MHhkMDAwMDNmZiBhdCBkZXZpY2UgMjkuNyBvbiBwY2kwDQplaGNpMDogUmVzZXJ2ZWQgMHg0MDAg Ynl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGQwMDAwMDAwDQpwY2liMDogbWF0Y2hlZCBl bnRyeSBmb3IgMC4yOS5JTlREIChzcmMgXFxfU0JfLlBDSTAuTFBDQi5MTktIOjApDQpwY2lfbGlu azc6IFBpY2tlZCBJUlEgOSB3aXRoIHdlaWdodCA5DQpwY2liMDogc2xvdCAyOSBJTlREIHJvdXRl ZCB0byBpcnEgOSB2aWEgXFxfU0JfLlBDSTAuTFBDQi5MTktIDQplaGNpMDogW0dJQU5ULUxPQ0tF RF0NCnVzYjM6IEVIQ0kgdmVyc2lvbiAxLjANCnVzYjM6IGNvbXBhbmlvbiBjb250cm9sbGVycywg MiBwb3J0cyBlYWNoOiB1c2IwIHVzYjEgdXNiMg0KdXNiMzogPEVIQ0kgKGdlbmVyaWMpIFVTQiAy LjAgY29udHJvbGxlcj4gb24gZWhjaTANCnVzYjM6IFVTQiByZXZpc2lvbiAyLjANCnVodWIzOiBJ bnRlbCBFSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAyLjAwLzEuMDAsIGFkZHIgMQ0KdWh1 YjM6IDYgcG9ydHMgd2l0aCA2IHJlbW92YWJsZSwgc2VsZiBwb3dlcmVkDQp1bWFzczA6IFNvbnkg VVNCIE1lbW9yeSBTdGljayBTbG90LCByZXYgMi4wMC8xLjEwLCBhZGRyIDINCnVtYXNzMDogR2V0 IE1heCBMdW4gbm90IHN1cHBvcnRlZCAoU1RBTExFRCkNCnVtYXNzMDowOjA6LTE6IEF0dGFjaGVk IHRvIHNjYnVzMA0KcGNpYjI6IDxBQ1BJIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMzAuMCBv biBwY2kwDQpwY2liMjogICBzZWNvbmRhcnkgYnVzICAgICAyDQpwY2liMjogICBzdWJvcmRpbmF0 ZSBidXMgICAyDQpwY2liMjogICBJL08gZGVjb2RlICAgICAgICAweDQwMDAtMHg0ZmZmDQpwY2li MjogICBtZW1vcnkgZGVjb2RlICAgICAweGQwMjAwMDAwLTB4ZDAyZmZmZmYNCnBjaWIyOiAgIHBy ZWZldGNoZWQgZGVjb2RlIDB4ZmZmMDAwMDAtMHhmZmZmZg0KcGNpYjI6ICAgU3VidHJhY3RpdmVs eSBkZWNvZGVkIGJyaWRnZS4NCnBjaTI6IDxBQ1BJIFBDSSBidXM+IG9uIHBjaWIyDQpwY2kyOiBw aHlzaWNhbCBidXM9Mg0KZm91bmQtPgl2ZW5kb3I9MHgxMTgwLCBkZXY9MHgwNDc1LCByZXZpZD0w eGI4DQoJYnVzPTIsIHNsb3Q9NSwgZnVuYz0wDQoJY2xhc3M9MDYtMDctMDAsIGhkcnR5cGU9MHgw MiwgbWZkZXY9MQ0KCWNtZHJlZz0weDAwMDcsIHN0YXRyZWc9MHgwMjEwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDA3ICgxNzUwIG5zKQ0KCWludHBpbj1hLCBpcnE9Mw0KCXBvd2Vyc3BlYyAyICBzdXBw b3J0cyBEMCBEMSBEMiBEMyAgY3VycmVudCBEMA0KCW1hcFsxMF06IHR5cGUgMSwgcmFuZ2UgMzIs IGJhc2UgMDAwMDAwMDAsIHNpemUgMTIsIGVuYWJsZWQNCnBjaWIyOiBtYXRjaGVkIGVudHJ5IGZv ciAyLjUuSU5UQSAoc3JjIFxcX1NCXy5QQ0kwLkxQQ0IuTE5LRjowKQ0KcGNpX2xpbms1OiBQaWNr ZWQgSVJRIDkgd2l0aCB3ZWlnaHQgMTENCnBjaWIyOiBzbG90IDUgSU5UQSByb3V0ZWQgdG8gaXJx IDkgdmlhIFxcX1NCXy5QQ0kwLkxQQ0IuTE5LRg0KZm91bmQtPgl2ZW5kb3I9MHgxMTgwLCBkZXY9 MHgwNTUxLCByZXZpZD0weDAwDQoJYnVzPTIsIHNsb3Q9NSwgZnVuYz0xDQoJY2xhc3M9MGMtMDAt MTAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MQ0KCWNtZHJlZz0weDAwMDYsIHN0YXRyZWc9MHgwMjEw LCBjYWNoZWxuc3o9MCAoZHdvcmRzKQ0KCWxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9 MHgwMiAoNTAwIG5zKSwgbWF4bGF0PTB4MDQgKDEwMDAgbnMpDQoJaW50cGluPWIsIGlycT0yNTUN Cglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDANCgltYXBbMTBdOiB0eXBl IDEsIHJhbmdlIDMyLCBiYXNlIGQwMjAyMDAwLCBzaXplIDExLCBlbmFibGVkDQpwY2liMjogKG51 bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhkMDIwMjAwMC0weGQwMjAyN2ZmOiBnb29kDQpm b3VuZC0+CXZlbmRvcj0weDgwODYsIGRldj0weDEwM2QsIHJldmlkPTB4ODMNCglidXM9Miwgc2xv dD04LCBmdW5jPTANCgljbGFzcz0wMi0wMC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wDQoJY21k cmVnPTB4MDAxNywgc3RhdHJlZz0weDAyOTAsIGNhY2hlbG5zej0xNiAoZHdvcmRzKQ0KCWxhdHRp bWVyPTB4NDIgKDE5ODAgbnMpLCBtaW5nbnQ9MHgwOCAoMjAwMCBucyksIG1heGxhdD0weDM4ICgx NDAwMCBucykNCglpbnRwaW49YSwgaXJxPTkNCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDEg RDIgRDMgIGN1cnJlbnQgRDANCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQwMjAw MDAwLCBzaXplIDEyLCBlbmFibGVkDQpwY2liMjogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFu Z2UgMHhkMDIwMDAwMC0weGQwMjAwZmZmOiBnb29kDQoJbWFwWzE0XTogdHlwZSA0LCByYW5nZSAz MiwgYmFzZSAwMDAwNDAwMCwgc2l6ZSAgNiwgZW5hYmxlZA0KcGNpYjI6IChudWxsKSByZXF1ZXN0 ZWQgSS9PIHJhbmdlIDB4NDAwMC0weDQwM2Y6IGluIHJhbmdlDQpwY2liMjogbWF0Y2hlZCBlbnRy eSBmb3IgMi44LklOVEEgKHNyYyBcXF9TQl8uUENJMC5MUENCLkxOS0U6MCkNCnBjaWIyOiBzbG90 IDggSU5UQSByb3V0ZWQgdG8gaXJxIDkgdmlhIFxcX1NCXy5QQ0kwLkxQQ0IuTE5LRQ0KZm91bmQt Pgl2ZW5kb3I9MHg4MDg2LCBkZXY9MHg0MjIwLCByZXZpZD0weDA1DQoJYnVzPTIsIHNsb3Q9MTEs IGZ1bmM9MA0KCWNsYXNzPTAyLTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTANCgljbWRyZWc9 MHgwMDE2LCBzdGF0cmVnPTB4MDI5MCwgY2FjaGVsbnN6PTE2IChkd29yZHMpDQoJbGF0dGltZXI9 MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAzICg3NTAgbnMpLCBtYXhsYXQ9MHgxOCAoNjAwMCBu cykNCglpbnRwaW49YSwgaXJxPTkNCglwb3dlcnNwZWMgMiAgc3VwcG9ydHMgRDAgRDMgIGN1cnJl bnQgRDANCgltYXBbMTBdOiB0eXBlIDEsIHJhbmdlIDMyLCBiYXNlIGQwMjAxMDAwLCBzaXplIDEy LCBlbmFibGVkDQpwY2liMjogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhkMDIwMTAw MC0weGQwMjAxZmZmOiBnb29kDQpwY2liMjogbWF0Y2hlZCBlbnRyeSBmb3IgMi4xMS5JTlRBIChz cmMgXFxfU0JfLlBDSTAuTFBDQi5MTktEOjApDQpwY2liMjogc2xvdCAxMSBJTlRBIHJvdXRlZCB0 byBpcnEgOSB2aWEgXFxfU0JfLlBDSTAuTFBDQi5MTktEDQpjYmIwOiA8UkY1QzQ3NSBQQ0ktQ2Fy ZEJ1cyBCcmlkZ2U+IGlycSA5IGF0IGRldmljZSA1LjAgb24gcGNpMg0KcGNpYjI6IGNiYjAgcmVx dWVzdGVkIG1lbW9yeSByYW5nZSAweGQwMjAwMDAwLTB4ZDAyZmZmZmY6IGdvb2QNCmNiYjA6IExh enkgYWxsb2NhdGlvbiBvZiAweDEwMDAgYnl0ZXMgcmlkIDB4MTAgdHlwZSAzIGF0IDB4ZDAyMDMw MDANCnBjY2FyZDA6IDwxNi1iaXQgUENDYXJkIGJ1cz4gb24gY2JiMA0KY2JiMDogW01QU0FGRV0N CmNiYjA6IFBDSSBDb25maWd1cmF0aW9uIHNwYWNlOg0KICAweDAwOiAweDA0NzUxMTgwIDB4MDIx MDAwMDcgMHgwNjA3MDBiOCAweDAwODI0MDAwIA0KICAweDEwOiAweGQwMjAzMDAwIDB4MDIwMDAw ZGMgMHg0MDA0MDMwMiAweGZmZmZmMDAwIA0KICAweDIwOiAweDAwMDAwMDAwIDB4ZmZmZmYwMDAg MHgwMDAwMDAwMCAweGZmZmZmZmZjIA0KICAweDMwOiAweDAwMDAwMDAwIDB4ZmZmZmZmZmMgMHgw MDAwMDAwMCAweDA3MDAwMTA5IA0KICAweDQwOiAweDgxNDAxMDRkIDB4MDAwMDAwMDEgMHgwMDAw MDAwMCAweDAwMDAwMDAwIA0KICAweDUwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAw MCAweDAwMDAwMDAwIA0KICAweDYwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAw eDAwMDAwMDAwIA0KICAweDcwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAw MDAwMDAwIA0KICAweDgwOiAweDI0YTAwMDAxIDB4MDAwMDAwMDAgMHgwNDYzMDQ2MyAweDAwMDAw MDAwIA0KICAweDkwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAw IA0KICAweGEwOiAweDgwMDAwMDQ2IDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIA0K ICAweGIwOiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIA0KICAw eGMwOiAweDgxNDAxMDRkIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIA0KICAweGQw OiAweDAwMDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweGZlMGEwMDAxIA0KICAweGUwOiAw eDI0YzA0MDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIA0KICAweGYwOiAweDAw MDAwMDAwIDB4MDAwMDAwMDAgMHgwMDAwMDAwMCAweDAwMDAwMDAwIA0KZndvaGNpMDogPFJpY29o IFI1QzU1MT4gbWVtIDB4ZDAyMDIwMDAtMHhkMDIwMjdmZiBhdCBkZXZpY2UgNS4xIG9uIHBjaTIN CmZ3b2hjaTA6IFJlc2VydmVkIDB4ODAwIGJ5dGVzIGZvciByaWQgMHgxMCB0eXBlIDMgYXQgMHhk MDIwMjAwMA0KcGNpYjI6IG1hdGNoZWQgZW50cnkgZm9yIDIuNS5JTlRCIChzcmMgXFxfU0JfLlBD STAuTFBDQi5MTktHOjApDQpwY2lfbGluazY6IFBpY2tlZCBJUlEgOSB3aXRoIHdlaWdodCAxNA0K cGNpYjI6IHNsb3QgNSBJTlRCIHJvdXRlZCB0byBpcnEgOSB2aWEgXFxfU0JfLlBDSTAuTFBDQi5M TktHDQpmd29oY2kwOiBbTVBTQUZFXQ0KZndvaGNpMDogT0hDSSB2ZXJzaW9uIDEuMCAoUk9NPTEp DQpmd29oY2kwOiBOby4gb2YgSXNvY2hyb25vdXMgY2hhbm5lbHMgaXMgNC4NCmZ3b2hjaTA6IEVV STY0IDA4OjAwOjQ2OjAzOjAxOjhkOmUwOjNjDQpmd29oY2kwOiBQaHkgMTM5NGEgYXZhaWxhYmxl IFM0MDAsIDIgcG9ydHMuDQpmd29oY2kwOiBMaW5rIFM0MDAsIG1heF9yZWMgMjA0OCBieXRlcy4N CmZpcmV3aXJlMDogPElFRUUxMzk0KEZpcmVXaXJlKSBidXM+IG9uIGZ3b2hjaTANCnNicDA6IDxT QlAtMi9TQ1NJIG92ZXIgRmlyZVdpcmU+IG9uIGZpcmV3aXJlMA0KZndvaGNpMDogSW5pdGlhdGUg YnVzIHJlc2V0DQpmd29oY2kwOiBub2RlX2lkPTB4YzgwMGZmYzAsIGdlbj0xLCBDWUNMRU1BU1RF UiBtb2RlDQpmaXJld2lyZTA6IDEgbm9kZXMsIG1heGhvcCA8PSAwLCBjYWJsZSBJUk0gPSAwICht ZSkNCmZpcmV3aXJlMDogYnVzIG1hbmFnZXIgMCAobWUpDQpmeHAwOiA8SW50ZWwgODI4MDFEQiAo SUNINCkgUHJvLzEwMCBWRSBFdGhlcm5ldD4gcG9ydCAweDQwMDAtMHg0MDNmIG1lbSAweGQwMjAw MDAwLTB4ZDAyMDBmZmYgaXJxIDkgYXQgZGV2aWNlIDguMCBvbiBwY2kyDQpmeHAwOiBSZXNlcnZl ZCAweDEwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGQwMjAwMDAwDQpmeHAwOiB1 c2luZyBtZW1vcnkgc3BhY2UgcmVnaXN0ZXIgbWFwcGluZw0KZnhwMDogUENJIElEczogODA4NiAx MDNkIDEwNGQgODE0MCAwMDgzDQpmeHAwOiBEeW5hbWljIFN0YW5kYnkgbW9kZSBpcyBkaXNhYmxl ZA0KbWlpYnVzMDogPE1JSSBidXM+IG9uIGZ4cDANCmlucGh5MDogPGk4MjU2MkVUIDEwLzEwMCBt ZWRpYSBpbnRlcmZhY2U+IG9uIG1paWJ1czANCmlucGh5MDogIDEwYmFzZVQsIDEwYmFzZVQtRkRY LCAxMDBiYXNlVFgsIDEwMGJhc2VUWC1GRFgsIGF1dG8NCmZ4cDA6IGJwZiBhdHRhY2hlZA0KZnhw MDogRXRoZXJuZXQgYWRkcmVzczogMDg6MDA6NDY6Yzg6NDU6YjMNCmZ4cDA6IFtNUFNBRkVdDQpw Y2kyOiA8bmV0d29yaz4gYXQgZGV2aWNlIDExLjAgKG5vIGRyaXZlciBhdHRhY2hlZCkNCnBjaTI6 MTE6MDogVHJhbnNpdGlvbiBmcm9tIEQwIHRvIEQzDQppc2FiMDogPFBDSS1JU0EgYnJpZGdlPiBh dCBkZXZpY2UgMzEuMCBvbiBwY2kwDQppc2EwOiA8SVNBIGJ1cz4gb24gaXNhYjANCmF0YXBjaTA6 IDxJbnRlbCBJQ0g0IFVETUExMDAgY29udHJvbGxlcj4gcG9ydCAweDFmMC0weDFmNywweDNmNiww eDE3MC0weDE3NywweDM3NiwweDE4NjAtMHgxODZmIGF0IGRldmljZSAzMS4xIG9uIHBjaTANCmF0 YXBjaTA6IFJlc2VydmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweDE4NjAN CmF0YTA6IDxBVEEgY2hhbm5lbCAwPiBvbiBhdGFwY2kwDQphdGFwY2kwOiBSZXNlcnZlZCAweDgg Ynl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweDFmMA0KYXRhcGNpMDogUmVzZXJ2ZWQgMHgx IGJ5dGVzIGZvciByaWQgMHgxNCB0eXBlIDQgYXQgMHgzZjYNCmF0YTA6IHJlc2V0IHRwMSBtYXNr PTAzIG9zdGF0MD01MCBvc3RhdDE9MDANCmF0YTA6IHN0YXQwPTB4NTAgZXJyPTB4MDEgbHNiPTB4 MDAgbXNiPTB4MDANCmF0YTA6IHN0YXQxPTB4MDAgZXJyPTB4MDEgbHNiPTB4MDAgbXNiPTB4MDAN CmF0YTA6IHJlc2V0IHRwMiBzdGF0MD01MCBzdGF0MT0wMCBkZXZpY2VzPTB4MTxBVEFfTUFTVEVS Pg0KYXRhMDogW01QU0FGRV0NCmF0YTE6IDxBVEEgY2hhbm5lbCAxPiBvbiBhdGFwY2kwDQphdGFw Y2kwOiBSZXNlcnZlZCAweDggYnl0ZXMgZm9yIHJpZCAweDE4IHR5cGUgNCBhdCAweDE3MA0KYXRh cGNpMDogUmVzZXJ2ZWQgMHgxIGJ5dGVzIGZvciByaWQgMHgxYyB0eXBlIDQgYXQgMHgzNzYNCmF0 YTE6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD01MCBvc3RhdDE9MDANCmF0YTE6IHN0YXQwPTB4 MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWINCmF0YTE6IHN0YXQxPTB4MDAgZXJyPTB4MDEg bHNiPTB4MTQgbXNiPTB4ZWINCmF0YTE6IHJlc2V0IHRwMiBzdGF0MD0wMCBzdGF0MT0wMCBkZXZp Y2VzPTB4YzxBVEFQSV9TTEFWRSxBVEFQSV9NQVNURVI+DQphdGExOiBbTVBTQUZFXQ0KcGNpMDog PHNlcmlhbCBidXMsIFNNQnVzPiBhdCBkZXZpY2UgMzEuMyAobm8gZHJpdmVyIGF0dGFjaGVkKQ0K cGNtMDogPEludGVsIElDSDQgKDgyODAxREIpPiBwb3J0IDB4MWMwMC0weDFjZmYsMHgxOGMwLTB4 MThmZiBtZW0gMHhkMDAwMGMwMC0weGQwMDAwZGZmLDB4ZDAwMDA4MDAtMHhkMDAwMDhmZiBpcnEg OSBhdCBkZXZpY2UgMzEuNSBvbiBwY2kwDQpwY20wOiBSZXNlcnZlZCAweDEwMCBieXRlcyBmb3Ig cmlkIDB4MTAgdHlwZSA0IGF0IDB4MWMwMA0KcGNtMDogUmVzZXJ2ZWQgMHg0MCBieXRlcyBmb3Ig cmlkIDB4MTQgdHlwZSA0IGF0IDB4MThjMA0KcGNtMDogW0dJQU5ULUxPQ0tFRF0NCnBjbTA6IDxZ YW1haGEgWU1GNzUzIEFDOTcgQ29kZWMgKGlkID0gMHg1OTRkNDgwMyk+DQpwY20wOiBDb2RlYyBm ZWF0dXJlcyAxOCBiaXQgREFDLCA1IGJpdCBtYXN0ZXIgdm9sdW1lLCBubyAzRCBTdGVyZW8gRW5o YW5jZW1lbnQNCnBjbTA6IFByaW1hcnkgY29kZWMgZXh0ZW5kZWQgZmVhdHVyZXMgcmVzZXJ2ZWQg MSwgQU1BUCwgcmVzZXJ2ZWQgNA0KcGNtMDogc25kYnVmX3NldG1hcCAzZTZiYTAwMCwgNDAwMDsg MHhmNTJjODAwMCAtPiAzZTZiYTAwMA0KcGNtMDogc25kYnVmX3NldG1hcCAzZTZiNjAwMCwgNDAw MDsgMHhmNTJjYzAwMCAtPiAzZTZiNjAwMA0KcGNpMDogPHNpbXBsZSBjb21tcywgZ2VuZXJpYyBt b2RlbT4gYXQgZGV2aWNlIDMxLjYgKG5vIGRyaXZlciBhdHRhY2hlZCkNCnBjaTA6MzE6NjogVHJh bnNpdGlvbiBmcm9tIEQwIHRvIEQzDQphY3BpX3R6MDogPFRoZXJtYWwgWm9uZT4gb24gYWNwaTAN CmFjcGlfc29ueTA6IDxTb255IG5vdGVib29rIGNvbnRyb2xsZXI+IG9uIGFjcGkwDQphY3BpX3Nv bnkwOiBQSUQgMA0KYXRrYmRjMDogPEtleWJvYXJkIGNvbnRyb2xsZXIgKGk4MDQyKT4gcG9ydCAw eDYwLDB4NjQgaXJxIDEgb24gYWNwaTANCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBh dGtiZGMwDQphdGtiZDogdGhlIGN1cnJlbnQga2JkIGNvbnRyb2xsZXIgY29tbWFuZCBieXRlIDAw NDcNCmF0a2JkOiBrZXlib2FyZCBJRCAweDQxYWIgKDIpDQprYmQwIGF0IGF0a2JkMA0Ka2JkMDog YXRrYmQwLCBBVCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgzZDAwMDANCmF0a2Jk MDogW0dJQU5ULUxPQ0tFRF0NCnBzbTA6IHVuYWJsZSB0byBhbGxvY2F0ZSBJUlENCnBzbWNwbnAw OiA8UFMvMiBtb3VzZSBwb3J0PiBpcnEgMTIgb24gYWNwaTANCnBzbTA6IGN1cnJlbnQgY29tbWFu ZCBieXRlOjAwNDcNCnBzbTA6IDxQUy8yIE1vdXNlPiBpcnEgMTIgb24gYXRrYmRjMA0KcHNtMDog W0dJQU5ULUxPQ0tFRF0NCnBzbTA6IG1vZGVsIEdsaWRlUG9pbnQsIGRldmljZSBJRCAwLTAwLCAy IGJ1dHRvbnMNCnBzbTA6IGNvbmZpZzowMDAwMDAwMCwgZmxhZ3M6MDAwMDAwMDgsIHBhY2tldCBz aXplOjMNCnBzbTA6IHN5bmNtYXNrOmMwLCBzeW5jYml0czowMA0KYWNwaV9jbWJhdDA6IDxDb250 cm9sIE1ldGhvZCBCYXR0ZXJ5PiBvbiBhY3BpMA0KYWNwaV9hY2FkMDogPEFDIEFkYXB0ZXI+IG9u IGFjcGkwDQphdGE6IGF0YTAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0DQphdGE6IGF0YTEg YWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0DQphdGtiZGM6IGF0a2JkYzAgYWxyZWFkeSBleGlz dHM7IHNraXBwaW5nIGl0DQpzYzogc2MwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdA0Kdmdh OiB2Z2EwIGFscmVhZHkgZXhpc3RzOyBza2lwcGluZyBpdA0KcG5wX2lkZW50aWZ5OiBUcnlpbmcg UmVhZF9Qb3J0IGF0IDIwMw0KcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI0Mw0K cG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDI4Mw0KcG5wX2lkZW50aWZ5OiBUcnlp bmcgUmVhZF9Qb3J0IGF0IDJjMw0KcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDMw Mw0KcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0IDM0Mw0KcG5wX2lkZW50aWZ5OiBU cnlpbmcgUmVhZF9Qb3J0IGF0IDM4Mw0KcG5wX2lkZW50aWZ5OiBUcnlpbmcgUmVhZF9Qb3J0IGF0 IDNjMw0KUE5QIElkZW50aWZ5IGNvbXBsZXRlDQppc2FfcHJvYmVfY2hpbGRyZW46IGRpc2FibGlu ZyBQblAgZGV2aWNlcw0KaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5vbi1QblAgZGV2aWNl cw0KcG10aW1lcjAgb24gaXNhMA0Kb3JtMDogPElTQSBPcHRpb24gUk9Ncz4gYXQgaW9tZW0gMHhj MDAwMC0weGNmZmZmLDB4ZDgwMDAtMHhkYmZmZiwweGRjMDAwLTB4ZGZmZmYgb24gaXNhMA0Kc2Mw OiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTANCnNjMDogVkdBIDwxNiB2 aXJ0dWFsIGNvbnNvbGVzLCBmbGFncz0weDMwMD4NCnNjMDogZmIwLCBrYmQwLCB0ZXJtaW5hbCBl bXVsYXRvcjogc2MgKHN5c2NvbnMgdGVybWluYWwpDQp2Z2EwOiA8R2VuZXJpYyBJU0EgVkdBPiBh dCBwb3J0IDB4M2MwLTB4M2RmIGlvbWVtIDB4YTAwMDAtMHhiZmZmZiBvbiBpc2EwDQphZHYwOiBu b3QgcHJvYmVkIChkaXNhYmxlZCkNCmFoYTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0KYWljMDog bm90IHByb2JlZCAoZGlzYWJsZWQpDQpidDA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0KY3MwOiBu b3QgcHJvYmVkIChkaXNhYmxlZCkNCmVkMDogbm90IHByb2JlZCAoZGlzYWJsZWQpDQpmZGMwIGZh aWxlZCB0byBwcm9iZSBhdCBwb3J0IDB4M2YwIGlycSA2IGRycSAyIG9uIGlzYTANCmZlMDogbm90 IHByb2JlZCAoZGlzYWJsZWQpDQppZTA6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0KbG5jMDogbm90 IHByb2JlZCAoZGlzYWJsZWQpDQpwY2ljMCBmYWlsZWQgdG8gcHJvYmUgYXQgcG9ydCAweDNlMCBp b21lbSAweGQwMDAwIG9uIGlzYTANCnBjaWMxOiBub3QgcHJvYmVkIChkaXNhYmxlZCkNCnBwYzAg ZmFpbGVkIHRvIHByb2JlIGF0IGlycSA3IG9uIGlzYTANCnNpbzA6IG5vdCBwcm9iZWQgKGRpc2Fi bGVkKQ0Kc2lvMTogbm90IHByb2JlZCAoZGlzYWJsZWQpDQpzaW8yOiBub3QgcHJvYmVkIChkaXNh YmxlZCkNCnNpbzM6IG5vdCBwcm9iZWQgKGRpc2FibGVkKQ0Kc24wOiBub3QgcHJvYmVkIChkaXNh YmxlZCkNCnZ0MDogbm90IHByb2JlZCAoZGlzYWJsZWQpDQppc2FfcHJvYmVfY2hpbGRyZW46IHBy b2JpbmcgUG5QIGRldmljZXMNCnVodWI0OiB2ZW5kb3IgMHgwNDUxIHByb2R1Y3QgMHgxNDQ2LCBj bGFzcyA5LzAsIHJldiAxLjEwLzEuMTAsIGFkZHIgMg0KdWh1YjQ6IDQgcG9ydHMgd2l0aCA0IHJl bW92YWJsZSwgc2VsZiBwb3dlcmVkDQp1a2JkMDogQlRDIFVTQiBLTXAsIHJldiAxLjAwLzEuMDAs IGFkZHIgMywgaWNsYXNzIDMvMQ0Ka2JkOiBuZXcgYXJyYXkgc2l6ZSA0DQprYmQxIGF0IHVrYmQw DQprYmQxOiB1a2JkMCwgZ2VuZXJpYyAoMCksIGNvbmZpZzoweDAsIGZsYWdzOjB4MWQwMDAwDQp1 bXMwOiBCVEMgVVNCIEtNcCwgcmV2IDEuMDAvMS4wMCwgYWRkciAzLCBpY2xhc3MgMy8xDQp1bXMw OiAzIGJ1dHRvbnMuDQp1bXMxOiBNaWNyb3NvZnQgTWljcm9zb2Z0IEludGVsbGlNb3VzZVxNLS4g RXhwbG9yZXIsIHJldiAxLjEwLzEuMTQsIGFkZHIgNCwgaWNsYXNzIDMvMQ0KdW1zMTogNSBidXR0 b25zIGFuZCBaIGRpci4NCnVidDA6IEFMUFMgVUdYLCByZXYgMS4xMC83LjgxLCBhZGRyIDINCnVi dDA6IEFMUFMgVUdYLCByZXYgMS4xMC83LjgxLCBhZGRyIDINCnVidDA6IEludGVyZmFjZSAwIGVu ZHBvaW50czogaW50ZXJydXB0PTB4ODEsIGJ1bGstaW49MHg4MiwgYnVsay1vdXQ9MHgyDQp1YnQw OiBJbnRlcmZhY2UgMSAoYWx0LmNvbmZpZyA1KSBlbmRwb2ludHM6IGlzb2MtaW49MHg4MywgaXNv Yy1vdXQ9MHgzOyB3TWF4UGFja2V0U2l6ZT00OTsgbmZyYW1lcz02LCBidWZmZXIgc2l6ZT0yOTQN CkRldmljZSBjb25maWd1cmF0aW9uIGZpbmlzaGVkLg0KcHJvY2ZzIHJlZ2lzdGVyZWQNClRpbWVj b3VudGVyICJUU0MiIGZyZXF1ZW5jeSAxNjg2OTY4MDAwIEh6IHF1YWxpdHkgODAwDQpUaW1lY291 bnRlcnMgdGljayBldmVyeSAxLjAwMCBtc2VjDQpEVU1NWU5FVCB3aXRoIElQdjYgaW5pdGlhbGl6 ZWQgKDA0MDgyNikNCmxvMDogYnBmIGF0dGFjaGVkDQppcGZ3MiAoK2lwdjYpIGluaXRpYWxpemVk LCBkaXZlcnQgbG9hZGFibGUsIHJ1bGUtYmFzZWQgZm9yd2FyZGluZyBlbmFibGVkLCBkZWZhdWx0 IHRvIGRlbnksIGxvZ2dpbmcgdW5saW1pdGVkDQphY3BpX2NtYmF0MDogYmF0dGVyeSBpbml0aWFs aXphdGlvbiBzdGFyYWNwaV9hY2FkMDogYWNsaW5lIGluaXRpYWxpemF0aW9uIHN0YXJ0DQphY3Bp X2FjYWQwOiBPbiBMaW5lDQphY3BpX2FjYWQwOiBhY2xpbmUgaW5pdGlhbGl6YXRpb24gZG9uZSwg dHJpZWQgMSB0aW1lcw0KdA0KYWNwaV9jbWJhdDA6IGJhdHRlcnkgaW5pdGlhbGl6YXRpb24gZG9u ZSwgdHJpZWQgMSB0aW1lcw0KYXRhMC1tYXN0ZXI6IHBpbz1QSU80IHdkbWE9V0RNQTIgdWRtYT1V RE1BMTAwIGNhYmxlPTgwIHdpcmUNCmFkMDogc2V0dGluZyBQSU80IG9uIEludGVsIElDSDQgY2hp cA0KYWQwOiBzZXR0aW5nIFVETUExMDAgb24gSW50ZWwgSUNINCBjaGlwDQphZDA6IDc2MzE5TUIg PEZVSklUU1UgTUhWMjA4MEFUIDAwMDAwMDk2PiBhdCBhdGEwLW1hc3RlciBVRE1BMTAwDQphZDA6 IDE1NjMwMTQ4OCBzZWN0b3JzIFsxNTUwNjFDLzE2SC82M1NdIDE2IHNlY3RvcnMvaW50ZXJydXB0 IDEgZGVwdGggcXVldWUNCkdFT006IG5ldyBkaXNrIGFkMA0KYXRhMTogcmVpbml0aW5nIGNoYW5u ZWwgLi4NCmF0YTE6IHJlc2V0IHRwMSBtYXNrPTAzIG9zdGF0MD0wMCBvc3RhdDE9MDANCmF0YTE6 IHN0YXQwPTB4MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWINCmF0YTE6IHN0YXQxPTB4MDAg ZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWINCmF0YTE6IHJlc2V0IHRwMiBzdGF0MD0wMCBzdGF0 MT0wMCBkZXZpY2VzPTB4YzxBVEFQSV9TTEFWRSxBVEFQSV9NQVNURVI+DQphdGExOiByZWluaXQg ZG9uZSAuLg0KYXRhMTogcmVpbml0aW5nIGNoYW5uZWwgLi4NCmF0YTE6IHJlc2V0IHRwMSBtYXNr PTAzIG9zdGF0MD0wMCBvc3RhdDE9MDANCmF0YTE6IHN0YXQwPTB4MDAgZXJyPTB4MDEgbHNiPTB4 MTQgbXNiPTB4ZWINCmF0YTE6IHN0YXQxPTB4MDAgZXJyPTB4MDEgbHNiPTB4MTQgbXNiPTB4ZWIN CmF0YTE6IHJlc2V0IHRwMiBzdGF0MD0wMCBzdGF0MT0wMCBkZXZpY2VzPTB4YzxBVEFQSV9TTEFW RSxBVEFQSV9NQVNURVI+DQphdGExOiByZWluaXQgZG9uZSAuLg0KYXRhMS1tYXN0ZXI6IHBpbz1Q SU80IHdkbWE9V0RNQTIgdWRtYT1VRE1BMzMgY2FibGU9NDAgd2lyZQ0KYWNkMDogc2V0dGluZyBQ SU80IG9uIEludGVsIElDSDQgY2hpcA0KYWNkMDogc2V0dGluZyBVRE1BMzMgb24gSW50ZWwgSUNI NCBjaGlwDQphY2QwOiA8VUpEQTc1NSBEVkQvQ0RSVy8xLjAxPiBDRFJXIGRyaXZlIGF0IGF0YTEg YXMgbWFzdGVyDQphY2QwOiByZWFkIDQxMzRLQi9zICg0MTM0S0Ivcykgd3JpdGUgNDEzNEtCL3Mg KDQxMzRLQi9zKSwgMjA0OEtCIGJ1ZmZlciwgVURNQTMzDQphY2QwOiBSZWFkczogQ0RSLCBDRFJX LCBDRERBIHN0cmVhbSwgRFZEUk9NLCBEVkRSLCBEVkRSQU0sIHBhY2tldA0KYWNkMDogV3JpdGVz OiBDRFIsIENEUlcsIHRlc3Qgd3JpdGUsIGJ1cm5wcm9vZg0KYWNkMDogQXVkaW86IHBsYXksIDI1 NiB2b2x1bWUgbGV2ZWxzDQphY2QwOiBNZWNoYW5pc206IGVqZWN0YWJsZSB0cmF5LCB1bmxvY2tl ZA0KYWNkMDogTWVkaXVtOiBuby9ibGFuayBkaXNjDQpwY20wOiBtZWFzdXJlZCBhYzk3IGxpbmsg cmF0ZSBhdCA0ODAxNCBIeiwgd2lsbCB1c2UgNDgwMDAgSHoNCihwcm9iZTE6c2JwMDowOjA6MCk6 IGVycm9yIDIyDQoocHJvYmUxOnNicDA6MDowOjApOiBVbnJldHJ5YWJsZSBFcnJvcg0KKHByb2Jl MjpzYnAwOjA6MTowKTogZXJyb3IgMjINCihwcm9iZTI6c2JwMDowOjE6MCk6IFVucmV0cnlhYmxl IEVycm9yDQoocHJvYmUzOnNicDA6MDoyOjApOiBlcnJvciAyMg0KKHByb2JlMzpzYnAwOjA6Mjow KTogVW5yZXRyeWFibGUgRXJyb3INCihwcm9iZTQ6c2JwMDowOjM6MCk6IGVycm9yIDIyDQoocHJv YmU0OnNicDA6MDozOjApOiBVbnJldHJ5YWJsZSBFcnJvcg0KKHByb2JlNTpzYnAwOjA6NDowKTog ZXJyb3IgMjINCihwcm9iZTU6c2JwMDowOjQ6MCk6IFVucmV0cnlhYmxlIEVycm9yDQoocHJvYmU2 OnNicDA6MDo1OjApOiBlcnJvciAyMg0KKHByb2JlNjpzYnAwOjA6NTowKTogVW5yZXRyeWFibGUg RXJyb3INCihwcm9iZTc6c2JwMDowOjY6MCk6IGVycm9yIDIyDQoocHJvYmU3OnNicDA6MDo2OjAp OiBVbnJldHJ5YWJsZSBFcnJvcg0KcGFzczAgYXQgdW1hc3Mtc2ltMCBidXMgMCB0YXJnZXQgMCBs dW4gMA0KcGFzczA6IDxTb255IE1TQy1VMDQgMy4wMD4gUmVtb3ZhYmxlIERpcmVjdCBBY2Nlc3Mg U0NTSS0wIGRldmljZSANCnBhc3MwOiBTZXJpYWwgTnVtYmVyIDMNCnBhc3MwOiA0MC4wMDBNQi9z IHRyYW5zZmVycw0KKGRhMDp1bWFzcy1zaW0wOjA6MDowKTogZXJyb3IgNg0KKGRhMDp1bWFzcy1z aW0wOjA6MDowKTogVW5yZXRyeWFibGUgRXJyb3INCmRhMCBhdCB1bWFzcy1zaW0wIGJ1cyAwIHRh cmdldCAwIGx1biAwDQpkYTA6IDxTb255IE1TQy1VMDQgMy4wMD4gUmVtb3ZhYmxlIERpcmVjdCBB Y2Nlc3MgU0NTSS0wIGRldmljZSANCmRhMDogU2VyaWFsIE51bWJlciAzDQpkYTA6IDQwLjAwME1C L3MgdHJhbnNmZXJzDQpkYTA6IEF0dGVtcHQgdG8gcXVlcnkgZGV2aWNlIHNpemUgZmFpbGVkOiBO T1QgUkVBRFksIE1lZGl1bSBub3QgcHJlc2VudA0KR0VPTTogbmV3IGRpc2sgZGEwDQooZGEwOnVt YXNzLXNpbTA6MDowOjApOiBSRUFEIENBUEFDSVRZLiBDREI6IDI1IDAgMCAwIDAgMCAwIDAgMCAw IA0KKGRhMDp1bWFzcy1zaW0wOjA6MDowKTogQ0FNIFN0YXR1czogU0NTSSBTdGF0dXMgRXJyb3IN CihkYTA6dW1hc3Mtc2ltMDowOjA6MCk6IFNDU0kgU3RhdHVzOiBDaGVjayBDb25kaXRpb24NCihk YTA6dW1hc3Mtc2ltMDowOjA6MCk6IE5PVCBSRUFEWSBhc2M6M2EsMA0KKGRhMDp1bWFzcy1zaW0w OjA6MDowKTogTWVkaXVtIG5vdCBwcmVzZW50DQooZGEwOnVtYXNzLXNpbTA6MDowOjApOiAoZGEw OnVtYXNzLXNpbTA6MDowOjApOiBSRUFEIENBUEFDSVRZLiBDREI6IDI1IDAgMCAwIDAgMCAwIDAg MCAwIA0KKGRhMDp1bWFzcy1zaW0wOjA6MDowKTogTk9UIFJFQURZIGFzYzozYSwwDQooZGEwOnVt YXNzLXNpbTA6MDowOjApOiBNZWRpdW0gbm90IHByZXNlbnQNClVucmV0cnlhYmxlIGVycm9yDQoo ZGEwOnVtYXNzLXNpbTA6MDowOjApOiBlcnJvciA2DQooZGEwOnVtYXNzLXNpbTA6MDowOjApOiBV bnJldHJ5YWJsZSBFcnJvcg0KT3BlbmVkIGRpc2sgZGEwIC0+IDYNCihkYTA6dW1hc3Mtc2ltMDow OjA6MCk6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgMCAwIDAgMCAwIDAgMCAwIDAgDQooZGEwOnVt YXNzLXNpbTA6MDowOjApOiBDQU0gU3RhdHVzOiBTQ1NJIFN0YXR1cyBFcnJvcg0KKGRhMDp1bWFz cy1zaW0wOjA6MDowKTogU0NTSSBTdGF0dXM6IENoZWNrIENvbmRpdGlvbg0KKGRhMDp1bWFzcy1z aW0wOjA6MDowKTogTk9UIFJFQURZIGFzYzozYSwwDQooZGEwOnVtYXNzLXNpbTA6MDowOjApOiBN ZWRpdW0gbm90IHByZXNlbnQNCihkYTA6dW1hc3Mtc2ltMDowOjA6MCk6IChkYTA6dW1hc3Mtc2lt MDowOjA6MCk6IFJFQUQgQ0FQQUNJVFkuIENEQjogMjUgMCAwIDAgMCAwIDAgMCAwIDAgDQooZGEw OnVtYXNzLXNpbTA6MDowOjApOiBOT1QgUkVBRFkgYXNjOjNhLDANCihkYTA6dW1hc3Mtc2ltMDow OjA6MCk6IE1lZGl1bSBub3QgcHJlc2VudA0KVW5yZXRyeWFibGUgZXJyb3INCihkYTA6dW1hc3Mt c2ltMDowOjA6MCk6IGVycm9yIDYNCihkYTA6dW1hc3Mtc2ltMDowOjA6MCk6IFVucmV0cnlhYmxl IEVycm9yDQpPcGVuZWQgZGlzayBkYTAgLT4gNg0KVHJ5aW5nIHRvIG1vdW50IHJvb3QgZnJvbSB1 ZnM6L2Rldi9hZDBzNGENCnN0YXJ0X2luaXQ6IHRyeWluZyAvc2Jpbi9pbml0DQpXQVJOSU5HOiBh dHRlbXB0IHRvIG5ldF9hZGRfZG9tYWluKGJsdWV0b290aCkgYWZ0ZXIgZG9tYWluZmluYWxpemUo KQ0KV0FSTklORzogYXR0ZW1wdCB0byBuZXRfYWRkX2RvbWFpbihuZXRncmFwaCkgYWZ0ZXIgZG9t YWluZmluYWxpemUoKQ0KYWNwaV9lYzA6IGluZm86IG5ldyBtYXggZGVsYXkgaXMgMTEwMDAgdXMN Cn== --=-C1Px2giEIuelF2g3mbPe Content-Disposition: attachment; filename=VBOOK Content-Type: text/plain; name=VBOOK; charset=KOI8-R Content-Transfer-Encoding: base64 DQptYWNoaW5lCQkiaTM4NiINCmlkZW50CQlWQk9PSw0KbWF4dXNlcnMJMA0KDQpvcHRpb25zICAg ICAgICAgU0NIRURfNEJTRA0KI29wdGlvbnMgICAgICAgICBTQ0hFRF9VTEUgICAgICAgICAgICAg ICAjVUxFIHNjaGVkdWxlciANCg0Kb3B0aW9ucyAgICAgICAgIElOQ0xVREVfQ09ORklHX0ZJTEUg ICAgICMgSW5jbHVkZSB0aGlzIGZpbGUgaW4ga2VybmVsDQoNCmNwdQkJIkk2ODZfQ1BVIgkJIyBh a2EgUGVudGl1bSBQcm8odG0pDQoNCm9wdGlvbnMJCUNPTVBBVF80Mw0Kb3B0aW9ucwkJQ09NUEFU X0ZSRUVCU0Q0CQkjIEVuYWJsZSBGcmVlQlNENCBjb21wYXRpYmlsaXR5IHN5c2NhbGxzDQoNCiNt YWtlb3B0aW9ucwlERUJVRz0tZyAgDQojbWFrZW9wdGlvbnMJS0VSTkVMPWF0YW5nDQoNCmRldmlj ZSAgICAgICAgICBtZW0gICAgICAgICAgICAgIyBNZW1vcnkgYW5kIGtlcm5lbCBtZW1vcnkgZGV2 aWNlcw0KZGV2aWNlICAgICAgICAgIGlvICAgICAgICAgICAgICAjIEkvTyBkZXZpY2UNCg0KZGV2 aWNlCQlhcGljDQpkZXZpY2UJCWFjcGkNCg0KDQpvcHRpb25zCQlJTkVUCQkJI0ludGVybmV0IGNv bW11bmljYXRpb25zIHByb3RvY29scw0KDQpkZXZpY2UJCWV0aGVyCQkJI0dlbmVyaWMgRXRoZXJu ZXQNCmRldmljZQkJbG9vcAkJCSNOZXR3b3JrIGxvb3BiYWNrIGRldmljZQ0KZGV2aWNlCQlicGYJ CQkjQmVya2VsZXkgcGFja2V0IGZpbHRlcg0KDQpvcHRpb25zICAgICAgICAgSVBGSVJFV0FMTCAg ICAgICAgICAgICAgI2ZpcmV3YWxsDQpvcHRpb25zICAgICAgICAgSVBGSVJFV0FMTF9WRVJCT1NF ICAgICAgI3ByaW50IGluZm9ybWF0aW9uIGFib3V0IGRyb3BwZWQgcGFja2V0cw0Kb3B0aW9ucwkJ SVBGSVJFV0FMTF9GT1JXQVJEDQojb3B0aW9ucwkiSVBGSVJFV0FMTF9WRVJCT1NFX0xJTUlUPTEw MCIgI2xpbWl0IHZlcmJvc2l0eQ0Kb3B0aW9ucwkJSVBESVZFUlQJCSNkaXZlcnQgc29ja2V0cw0K b3B0aW9ucwkJRFVNTVlORVQNCg0KI29wdGlvbnMJCUlQU0VDDQojb3B0aW9ucwkJSVBTRUNfRVNQ DQoNCm9wdGlvbnMJCUZGUwkJCSNGYXN0IGZpbGVzeXN0ZW0NCg0Kb3B0aW9ucwkJUFNFVURPRlMN Cm9wdGlvbnMJCVBST0NGUwkJCSNQcm9jZXNzIGZpbGVzeXN0ZW0NCg0Kb3B0aW9ucwkJU09GVFVQ REFURVMNCg0KIyBBbGxvdyB0aGlzIG1hbnkgc3dhcC1kZXZpY2VzLg0KZGV2aWNlCQlzY2J1cwkj YmFzZSBTQ1NJIGNvZGUNCmRldmljZQkJZGEJI1NDU0kgZGlyZWN0IGFjY2VzcyBkZXZpY2VzIChh a2EgZGlza3MpDQpkZXZpY2UJCXNhCSNTQ1NJIHRhcGVzDQpkZXZpY2UJCWNkCSNTQ1NJIENELVJP TXMNCmRldmljZQkJcGFzcwkjQ0FNIHBhc3N0aHJvdWdoIGRyaXZlcg0Kb3B0aW9ucwkJU0NTSV9E RUxBWT0xMDAwCQ0KDQpkZXZpY2UJCXB0eQkJI1BzZXVkbyB0dHlzIC0gY2FuIGdvIGFzIGhpZ2gg YXMgMjU2DQpkZXZpY2UJCXNwZWFrZXIJCSNQbGF5IElCTSBCQVNJQy1zdHlsZSBub2lzZXMgb3V0 IHlvdXIgc3BlYWtlcg0KDQpkZXZpY2UJCW1kICAgICAgICAgICAgICAjIE1lbW9yeSAiZGlza3Mi DQoNCmRldmljZQkJaXNhDQoNCmRldmljZQkJYXRrYmRjDQpkZXZpY2UJCWF0a2JkIA0KDQpkZXZp Y2UJCXBzbQ0KZGV2aWNlCQl2Z2ENCg0KZGV2aWNlCQlzYw0Kb3B0aW9ucwkJTUFYQ09OUz0xNgkJ IyBudW1iZXIgb2YgdmlydHVhbCBjb25zb2xlcw0KI29wdGlvbnMgCVNDX0RGTFRfRk9OVAkJIyBj b21waWxlIGZvbnQgaW4NCiNtYWtlb3B0aW9ucwlTQ19ERkxUX0ZPTlQ9ImNwODY2LXZpbyINCm9w dGlvbnMJCVNDX0hJU1RPUllfU0laRT0xMDI0CSMgbnVtYmVyIG9mIGhpc3RvcnkgYnVmZmVyIGxp bmVzDQojb3B0aW9ucwlTQ19ESVNBQkxFX1JFQk9PVAkjIGRpc2FibGUgcmVib290IGtleSBzZXF1 ZW5jZQ0KDQpvcHRpb25zCQlTQ19OT19TVVNQRU5EX1ZUWVNXSVRDSA0KDQpkZXZpY2UgICAgICAg ICAgbnB4DQojZGV2aWNlCQlhaGENCg0KZGV2aWNlCQlhdGENCmRldmljZQkJYXRhZGlzayAgICAg ICAgIyBBVEEgZGlzayBkcml2ZXMNCmRldmljZQkJYXRhcGljZCAgICAgICAgIyBBVEFQSSBDRFJP TSBkcml2ZXMNCiNkZXZpY2UJCWF0YXBpZmQgICAgICAgICMgQVRBUEkgZmxvcHB5IGRyaXZlcw0K I2RldmljZQkJYXRhcGlzdCAgICAgICAgIyBBVEFQSSB0YXBlIGRyaXZlcw0KI2RldmljZSAgICAg ICAgIGF0YXBpY2FtDQoNCiNkZXZpY2UJCWZkYwkNCmRldmljZQkJc2lvDQoNCmRldmljZQkJcGNp DQoNCiNkZXZpY2UJCWFwbQ0KDQpkZXZpY2UJCXNtYnVzDQpkZXZpY2UJCWludHBtDQpkZXZpY2UJ CXNtYg0KZGV2aWNlCQlpaWNidXMNCmRldmljZQkJaWljYmINCmRldmljZQkJaWMNCmRldmljZQkJ aWljDQpkZXZpY2UJCWlpY3NtYgkNCmRldmljZSAgICAgICAgICBwbXRpbWVyDQoNCg0KIyMgdG8g bW9kdWxlDQojZGV2aWNlCQlwcGJ1cw0KI2RldmljZQkJdnBvDQojZGV2aWNlCQlscHQNCiNkZXZp Y2UJCXBsaXANCiNkZXZpY2UJCXBwaQ0KIyNkZXZpY2UJcHBzDQojZGV2aWNlCQlscGJiDQojZGV2 aWNlCQlwcGMNCg0KI29wdGlvbnMgCUtUUkFDRQkJCSNrZXJuZWwgdHJhY2luZw0Kb3B0aW9ucyAJ RERCDQpvcHRpb25zIAlLREINCm9wdGlvbnMgCUdEQg0Kb3B0aW9ucyAgICAgICAgIEJSRUFLX1RP X0RFQlVHR0VSICAgICAgICNhIEJSRUFLIG9uIGEgY29tY29uc29sZSBnb2VzIHRvDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI0REQiwgaWYgYXZhaWxhYmxlLg0Kb3B0 aW9ucwkJU0NfUElYRUxfTU9ERQ0KDQojIE9MRENBUkQNCiNkZXZpY2UgICAgICAgICAgcGNpYw0K I2RldmljZSAgICAgICAgICBjYXJkIDENCg0KIyBORVdDQVJEDQojIFBjbWNpYSBhbmQgY2FyZGJ1 cyBicmlkZ2Ugc3VwcG9ydA0KI2RldmljZSAgICAgICAgICBjYmIgICAgICAgICAgICAgICAgICAg IyBjYXJkYnVzICh5ZW50YSkgYnJpZGdlDQojZGV2aWNlICAgICAgICAgIHBjY2FyZA0KI2Rldmlj ZSAgICAgICAgICBjYXJkYnVzDQoNCg0KI2RldmljZSAgICAgICAgICB3bGFuDQojZGV2aWNlICAg ICAgICAgIHdpDQoNCmRldmljZQkJcmFuZG9tDQoNCm9wdGlvbnMgICAgICAgICBfS1BPU0lYX1BS SU9SSVRZX1NDSEVEVUxJTkcNCg0KI2RldmljZSAgICAgICAgICBhY3BpY2ENCiNvcHRpb25zICAg ICAgICAgQUNQSV9ERUJVRw0KDQpvcHRpb25zIAlLQkRfSU5TVEFMTF9DREVWDQoNCiNkZXZpY2Ug ICAgICAgICAgdWhjaQ0KI2RldmljZSAgICAgICAgICBvaGNpDQojZGV2aWNlICAgICAgICAgIHVz Yg0KI2RldmljZSAgICAgICAgICB1Z2VuDQojZGV2aWNlICAgICAgICAgIHVoaWQNCiNkZXZpY2Ug ICAgICAgICAgdWtiZA0KI2RldmljZSAgICAgICAgICB1bHB0DQojZGV2aWNlICAgICAgICAgIHVt YXNzDQojZGV2aWNlICAgICAgICAgIHVtcw0KDQojZGV2aWNlIGZpcmV3aXJlDQojZGV2aWNlIGZ3 b2hjaQ0KI2RldmljZSBzYnANCg0Kb3B0aW9ucyAJUFJFRU1QVElPTg0KI29wdGlvbnMgCUZVTExf UFJFRU1QVElPTg0K --=-C1Px2giEIuelF2g3mbPe Content-Disposition: attachment; filename=loader.conf Content-Type: text/plain; name=loader.conf; charset=KOI8-R Content-Transfer-Encoding: base64 DQojYWNwaV9kc2R0X2xvYWQ9IllFUyINCiNhY3BpX2RzZHRfbmFtZT0iL2Jvb3QvdmJvb2suYW1s Ig0KDQprZXJuLmh6PTEwMDANCg0KdmVzYV9sb2FkPSJ5ZXMiDQoNCnNuZF9pY2hfbG9hZD0ieWVz Ig0KDQp1c2JfbG9hZD0iWUVTIiAgICAgICAgICAgICAgICAgICMgVVNCIHN1YnN5c3RlbQ0KdWti ZF9sb2FkPSJZRVMiICAgICAgICAgICAgICAgICAjIEtleWJvYXJkDQp1bHB0X2xvYWQ9IllFUyIg ICAgICAgICAgICAgICAgICMgUHJpbnRlcg0KdW1zX2xvYWQ9IllFUyIgICAgICAgICAgICAgICAg ICAjIE1vdXNlDQp1bWFzc19sb2FkPSJZRVMiICAgICAgICAgICAgICAgICMgTWFzcyBTdG9yYWdl IERldmljZXMNCg0Kc3lzdm1zZ19sb2FkPSJZRVMiDQpzeXN2c2VtX2xvYWQ9IllFUyINCnN5c3Zz aG1fbG9hZD0iWUVTIg0KDQojY2JiX2xvYWQ9IllFUyINCiNjYXJkYnVzX2xvYWQ9IllFUyINCg0K bXNkb3Nmc19sb2FkPSJZRVMiDQpzbWJmc19sb2FkPSJZRVMiICANCm50ZnNfbG9hZD0iWUVTIg0K DQpuZ191YnRfbG9hZD0iWUVTIg0KDQpmaXJld2FyZV9sb2FkPSJZRVMiDQpzYnBfbG9hZD0iWUVT Ig0KDQojbmRpc19sb2FkPSJZRVMiDQojaWZfbmRpc19sb2FkPSJZRVMiDQoNCiNpZl9pd2lfbG9h ZD0iWUVTIg0Kd2xhbl93ZXBfbG9hZD0iWUVTIg0KDQppZl9meHBfbG9hZD0iWUVTIg0KDQpiZWFz dGllX2Rpc2FibGU9IllFUyIgDQoNCmFjcGlfc29ueV9sb2FkPSJZRVMiDQoNCmFncF9sb2FkPSJZ RVMiDQojcmFkZW9uX2xvYWQ9IllFUyINCg0KI2Rjb25zX2xvYWQ9IllFUyINCiNkY29uc19jcm9t X2xvYWQ9IllFUyINCg0KY2JiX2xvYWQ9IllFUyINCnBjY2FyZF9sb2FkPSJZRVMiDQoNCiNody5h Y3BpLnJlc2V0X3ZpZGVvPTANCg== --=-C1Px2giEIuelF2g3mbPe-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 06:32: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 9403116A41C for ; Tue, 14 Jun 2005 06:32:13 +0000 (GMT) (envelope-from dikshie@ppk.itb.ac.id) Received: from mx-itb.geoph.ITB.ac.id (mx7.itb.ac.id [167.205.30.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id A35A843D1F for ; Tue, 14 Jun 2005 06:32:00 +0000 (GMT) (envelope-from dikshie@ppk.itb.ac.id) Received: from antivirus.itb.ac.id (antivirus.ITB.ac.id [167.205.108.137]) by mx-itb.geoph.ITB.ac.id (Postfix) with SMTP id 2E37720B0F for ; Tue, 14 Jun 2005 13:31:50 +0700 (WIT) Received: from ipv6.ppk.itb.ac.id (ipv6.ppk.itb.ac.id [167.205.30.228]) by mx-itb.geoph.ITB.ac.id (Postfix) with ESMTP id EE12D20AF9 for ; Tue, 14 Jun 2005 13:31:49 +0700 (WIT) Received: by ipv6.ppk.itb.ac.id (Postfix, from userid 1001) id E8D6C114D2; Tue, 14 Jun 2005 13:31:48 +0700 (WIT) Date: Tue, 14 Jun 2005 13:31:48 +0700 From: Dikshie To: freebsd-current@freebsd.org Message-ID: <20050614063148.GA22683@ppk.itb.ac.id> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Operating-System: (FreeBSD 5.4-STABLE i386) X-Uptime: 1:30PM up 1 day, 19:27, 1 user, load averages: 0.09, 0.13, 0.08 X-Organization: Pusat Penelitian Kelautan (PPK) X-Location: Labtek VI Building, Institute of Technology, Bandung, Indonesia X-Web-Site: http://ipv6.ppk.itb.ac.id/~dikshie X-Yahoo-ID: dikshie X-GnuPG-Key: http://ipv6.ppk.itb.ac.id/gpg/ X-FingerPrint: 19AC 2592 1394 6C96 BABB 9060 50B8 D244 88E3 B55D Subject: doadump () at pcpu.h:165 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, 14 Jun 2005 06:32:13 -0000 Dear All, I got self reboot my 6.0-CURRENT and able to get dumpfile: GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-marcel-freebsd". #0 doadump () at pcpu.h:165 in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc0526110 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 #2 0xc05263bb in panic (fmt=0xc06dc69f "cur != NULL") at /usr/src/sys/kern/kern_shutdown.c:553 #3 0xc05bd3ac in tcp_sack_option (tp=0xc2013000, th=0xd443eb14, cp=0xc1af2056 "\005\nwF\212|wF\217\0017\0010\0012\0010\0010\0010\0011\0010\0013\0010\0010\0010\0010\0013\001d\0010\00 11\0010\0010\0012\003ip6\004arpa", optlen=0) at /usr/src/sys/netinet/tcp_sack.c:478 #4 0xc05bb327 in tcp_dooptions (tp=0xc2013000, to=0xd443ec78, cp=0xc1af2056 "\005\nwF\212|wF\217\0017\0010\0012\0010\0010\0010\0011\0010\0013\0010\0010\0010\0010\0013\001d\0010\00 11\0010\0010\0012\003ip6\004arpa", cnt=10, is_syn=0, th=0xc1af2034) at /usr/src/sys/netinet/tcp_input.c:2647 #5 0xc05b8dfb in tcp_input (m=0xc1ad6600, off0=65800) at /usr/src/sys/netinet/tcp_input.c:1085 #6 0xc05adcd5 in ip_input (m=0xc1ad6600) at /usr/src/sys/netinet/ip_input.c:776 #7 0xc0597f42 in netisr_processqueue (ni=0xc0783318) at /usr/src/sys/net/netisr.c:235 #8 0xc059812a in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:348 #9 0xc0513940 in ithread_loop (arg=0xc19db180) at /usr/src/sys/kern/kern_intr.c:546 #10 0xc0512dd4 in fork_exit (callout=0xc0513820 , arg=0xc19db180, frame=0xd443ed38) at /usr/src/sys/kern/kern_fork.c:789 #11 0xc0685e3c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) quit regards, -dikshie- From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 07:46: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 8D16C16A41C for ; Tue, 14 Jun 2005 07:46:28 +0000 (GMT) (envelope-from martin.mato@wanadoo.fr) Received: from gama.univ-perp.fr (gama.univ-perp.fr [194.167.137.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 153B543D1D for ; Tue, 14 Jun 2005 07:46:27 +0000 (GMT) (envelope-from martin.mato@wanadoo.fr) Received: from [194.167.138.5] (pcmartino.univ-perp.fr [194.167.138.5]) by gama.univ-perp.fr (8.12.8/jtpda-5.4) with ESMTP id j5E7mTdB028758 for ; Tue, 14 Jun 2005 09:48:30 +0200 Message-ID: <42AE8B48.4020407@wanadoo.fr> Date: Tue, 14 Jun 2005 09:46:16 +0200 From: Martin MATO User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: fr, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <42ACE639.8030509@apache.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-MailScanner-gama: Found to be clean Mailscanner GAMA X-MailScanner-Information: Please contact the ISP for more information Subject: Re: Panic with nve X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.mato@wanadoo.fr List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 07:46:28 -0000 > > I'm seeing the same thing here on my NForce 2 board. It used to be > that I couldn't do a buildworld through SSH, but now I can trigger > the panic by simply loading up a remote X session. After using X for > about a minute, I get the following: > > %panic: nve_ifstart: attempted use of a free mbuf! > cpuid = 0 > KDB: enter: panic > [thread pid 571 tid 100087 ] > Stopped at kdb_enter+0x2b: nop > db> trace > Tracing pid 571 tid 100087 td 0xc2735000 > kdb_enter(c084ebd5) at kdb_enter+0x2b > panic(c08237f7,c080dffc,c2395100,350,e8cbaa98) at panic+0x127 > nve_ifstart(c2395000) at nve_ifstart+0x35a > if_start(c2395000) at if_start+0x7b > ether_output_frame(c2395000,c239ec00,0,0,0) at ether_output_frame+0x1d9 > ether_output(c2395000,c239ec00,eb12cad8,c273cbdc,c2732100) at > ether_output+0x3b4 > ip_output(c239ec00,0,eb12cad4,0,0) at ip_output+0x6fc > tcp_output(c274eac8) at tcp_output+0xfb2 > tcp_usr_rcvd(c2728a60,0,c2728ac8,0,c0855428) at tcp_usr_rcvd+0x82 > soreceive(c2728a60,0,eb12cc78,0,0) at soreceive+0xc63 > soo_read(c2690ab0,eb12cc78,c2691a00,0,c2735000) at soo_read+0x41 > dofileread(c2735000,c2690ab0,3,bfbf9e40,4000) at dofileread+0xad > read(c2735000,eb12cd04,3,2b,202) at read+0x3b > syscall(3b,3b,3b,bfbf9e40,8078b40) at syscall+0x22f > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (3, FreeBSD ELF32, read), eip = 0x282bc753, esp = > 0xbfbf9e2c, ebp = 0xbfbfde58 --- > db> > > Thanks, > Joel Diaz > > i have the same problem: i got a panic systematically if i try to transfert a file from an sftp session; from any host i have an abit nfs7 2.0 (Nforce2 ultra). From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 08:20: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 D871F16A41C for ; Tue, 14 Jun 2005 08:20:40 +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 A063C43D53 for ; Tue, 14 Jun 2005 08:20:40 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5E8Kdeb002113; Tue, 14 Jun 2005 01:20:39 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5E8KdHa002112; Tue, 14 Jun 2005 01:20:39 -0700 (PDT) (envelope-from obrien) Date: Tue, 14 Jun 2005 01:20:39 -0700 From: "David O'Brien" To: Ed Maste Message-ID: <20050614082039.GA2038@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ed Maste , freebsd-current@freebsd.org References: <20050613192308.GA87640@sandvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050613192308.GA87640@sandvine.com> 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 Subject: Re: savecore(8) increments /var/crash/bounds on each boot 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, 14 Jun 2005 08:20:41 -0000 On Mon, Jun 13, 2005 at 03:23:08PM -0400, Ed Maste wrote: > I notice that as of sbin/savecore/savecore.c 1.72 and in 5.4-RELEASE > savecore increments the number in /var/crash/bounds on each boot, > regardless of whether it rebooted due to panic or was a clean shutdown. > Is this the desired behaviour or an unintentional side effect? It is an unintentional side affect. If I wasn't constantly experiencing kernel landminds every time I sit down to do major FreeBSD, I would have gotten to this issue. -- -- David (who's spending his 4th hour tracking down new panics) From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 09:18: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 7877716A41C; Tue, 14 Jun 2005 09:18:12 +0000 (GMT) (envelope-from markus@brueffer.de) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1CF5A43D49; Tue, 14 Jun 2005 09:18:11 +0000 (GMT) (envelope-from markus@brueffer.de) Received: from fwd35.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1Di7Yg-0004FO-02; Tue, 14 Jun 2005 11:18:10 +0200 Received: from ramses.kicks-ass.net (b7d0W2ZbQe0BYC8lKbFDiN49H+YsB3yZf-TYvn2FZ02kKuO8-PLsUa@[80.143.193.92]) by fwd35.sul.t-online.de with esmtp id 1Di7YY-154HZo0; Tue, 14 Jun 2005 11:18:02 +0200 Received: from cheops.phoenix (cheops.phoenix [192.168.1.3]) by ramses.kicks-ass.net (Postfix) with ESMTP id 0BC67B843; Tue, 14 Jun 2005 11:21:16 +0200 (CEST) From: Markus Brueffer To: freebsd-current@freebsd.org, obrien@freebsd.org Date: Tue, 14 Jun 2005 11:16:46 +0200 User-Agent: KMail/1.8 References: <20050613175812.GA13200@dragon.NUXI.org> In-Reply-To: <20050613175812.GA13200@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2131611.DGxG0l7RJX"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506141116.58062.markus@brueffer.de> X-ID: b7d0W2ZbQe0BYC8lKbFDiN49H+YsB3yZf-TYvn2FZ02kKuO8-PLsUa@t-dialin.net X-TOI-MSGID: cb7abd26-2e71-443a-a58a-e39c633bfdbd Cc: Paul Richards Subject: Re: Immediate reboots on amd64 after upgrading to 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, 14 Jun 2005 09:18:12 -0000 --nextPart2131611.DGxG0l7RJX Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Monday 13 June 2005 19:58, David O'Brien wrote: > On Sun, Jun 12, 2005 at 12:37:43PM +0100, Paul Richards wrote: > > Is the 6-current broken at the moment? (unlikely as it seems like > > quite a severe break) > > Definitely. A June 10th 4am UTC kernel works fine for me. A June 11 > midnight UTC kernel, does an instana-reboot. I can trigger it by loading different subsets of modules on boot: snd_ich + ng_bt + smbus =3D instant reboot (as descibed above) If I only load 2 (regardless which) of the above the system boots fine. Markus =2D-=20 Markus Brueffer =A0 =A0| GPG-Key: http://people.FreeBSD.org/~markus/markus.= asc markus@brueffer.de | FP: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 markus@FreeBSD.org | FreeBSD: The Power to Serve! --nextPart2131611.DGxG0l7RJX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQBCrqCK1I0Qcnj4qNQRAnDZAJ4yozk30XJI1OD90DMxXr+6XnDnHwCg+pPa FyBORHuadrXmkac2Pq2eK/0= =AirD -----END PGP SIGNATURE----- --nextPart2131611.DGxG0l7RJX-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 13:30: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 2E1DC16A41C for ; Tue, 14 Jun 2005 13:30:04 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mrout1-b.corp.dcn.yahoo.com (mrout1-b.corp.dcn.yahoo.com [216.109.112.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id C686043D53 for ; Tue, 14 Jun 2005 13:30:03 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy8.corp.yahoo.com [216.145.48.13]) by mrout1-b.corp.dcn.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j5EDTRb6066266 for ; Tue, 14 Jun 2005 06:29:27 -0700 (PDT) Date: Tue, 14 Jun 2005 22:29:26 +0900 Message-ID: From: gnn@freebsd.org To: freebsd-current@freebsd.org User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Subject: Should I be able to run tinderbox as myself? 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, 14 Jun 2005 13:30:04 -0000 Howdy, I'm trying to use the tinderbox script at home to do nightly builds. I got a successful build but then could not install due to the touch: not found error which is supposed to be due to clock skew issues. I'm wondering if it's OK to run tinderbox as myself (i.e. not root) or if it really just is the clock on the box. The "box" in question is a vmware virtual machine so it might have timing issues. Thanks, George From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 14:10: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 057A316A41C for ; Tue, 14 Jun 2005 14:10:27 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id 82C2D43D1D for ; Tue, 14 Jun 2005 14:10:26 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id AB15150CFC for ; Tue, 14 Jun 2005 23:10:25 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 0B16350C75 for ; Tue, 14 Jun 2005 23:10:24 +0900 (JST) Date: Tue, 14 Jun 2005 23:10:24 +0900 Message-ID: <7mpsupni5r.wl%kuriyama@imgsrc.co.jp> From: Jun Kuriyama To: Current User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Cc: Subject: How to help debugging of lock-up 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, 14 Jun 2005 14:10:27 -0000 I'm using the current (minus recent ssouhlal@'s commit). This kernel usually locked up when daily backup begins (by invoked by amanda server), but sometimes locked up in other random situations. When locked up, no ping response, but I can enter to debugger from serial console. I'm not sure which process I should suspect. Is there something I can provide to help debugging about this? Currently, compiled with INVARIANTS, INVARIANT_SUPPORT, WITNESS, WITNESS_SKIPSPIN, DEBUG_VFS_LOCKS and debug.mpsafevfs="0". ----- KDB: enter: Break sequence on console [thread pid 12 tid 100005 ] Stopped at kdb_enter+0x2b: nop db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 2491 c186d400 91 2489 2483 0004000 [SLPQ piperd 0xc16cba80][SLP] sed 2490 c1802e00 91 2489 2483 0004000 [SLPQ piperd 0xc183e000][SLP] restore 2489 c1648a00 91 2487 2483 0004000 [SLPQ wait 0xc1648a00][SLP] sh 2488 c1648800 91 2484 2483 0004000 [SLPQ biord 0xc3a27da8][SLP] dump 2487 c15e4a00 91 2484 2483 0000000 [SLPQ piperd 0xc16f1d80][SLP] sendbackup 2486 c1871c00 91 2484 2483 0004000 [SLPQ piperd 0xc16ca000][SLP] gzip 2484 c1b12000 91 1 2483 0004000 [SLPQ piperd 0xc16f1c00][SLP] sendbackup 2454 c1802a00 91 2451 2440 0000000 [SLPQ pause 0xc1802a34][SLP] dump 2453 c1b11c00 91 2451 2440 0000000 [SLPQ pipdwt 0xc16cbc00][SLP] dump 2452 c1871400 91 2451 2440 0000000 [SLPQ pause 0xc1871434][SLP] dump 2451 c1b11000 91 2445 2440 0000000 [SLPQ sbwait 0xc186b9b0][SLP] dump 2445 c1b12200 91 2441 2440 0004000 [SLPQ wait 0xc1b12200][SLP] dump 2444 c15e4200 91 2441 2440 0000000 [SLPQ pipewr 0xc16f1900][SLP] sendbackup 2443 c1645e00 91 2441 2440 0004000 [SLPQ sbwait 0xc1a7e638][SLP] gzip 2441 c1b11400 91 1 2440 0004000 [SLPQ piperd 0xc16cb600][SLP] sendbackup 1033 c186de00 1021 1032 1033 0004002 [SLPQ ttyin 0xc15b9410][SLP] zsh 1032 c186da00 1021 1030 1030 0000100 [SLPQ select 0xc075cda4][SLP] sshd 1030 c1800200 0 583 1030 0004100 [SLPQ sbwait 0xc186c480][SLP] sshd 717 c1648e00 0 1 717 0004002 [SLPQ ttyin 0xc1541010][SLP] getty 716 c1800a00 0 1 716 0004002 [SLPQ ttyin 0xc153cc10][SLP] getty 715 c1871a00 0 1 715 0004002 [SLPQ ttyin 0xc155a810][SLP] getty 714 c1800600 0 1 714 0004002 [SLPQ ttyin 0xc153b010][SLP] getty 700 c1800000 0 1 700 0000000 [SLPQ select 0xc075cda4][SLP] inetd 679 c1871600 0 1 679 0000000 [SLPQ select 0xc075cda4][SLP] moused 656 c1871e00 0 1 655 0000000 [SLPQ select 0xc075cda4][SLP] snmpd 637 c1800400 0 1 637 0000000 [SLPQ select 0xc075cda4][SLP] pptpd 607 c1645800 0 1 607 0000000 [SLPQ nanslp 0xc070faac][SLP] cron 595 c1645600 25 1 595 0000100 [SLPQ pause 0xc1645634][SLP] sendmail 589 c186d200 0 1 589 0000100 [SLPQ select 0xc075cda4][SLP] sendmail 583 c15e4600 0 1 583 0000100 [SLPQ select 0xc075cda4][SLP] sshd 565 c186d000 0 1 565 0000000 [SLPQ select 0xc075cda4][SLP] ntpd 511 c1648000 0 1 511 0000000 [SLPQ select 0xc075cda4][SLP] usbd 492 c15e4400 0 490 490 0000100 [SLPQ nfslockd 0xc07654c8][SLP] rpc.lockd 490 c15e4800 0 1 490 0000000 [SLPQ select 0xc075cda4][SLP] rpc.lockd 485 c15e5c00 0 1 485 0000000 [SLPQ select 0xc075cda4][SLP] rpc.statd 479 c1648600 0 478 478 0000000 [SLPQ - 0xc15cb800][SLP] nfsd 478 c1645a00 0 1 478 0000000 [SLPQ select 0xc075cda4][SLP] nfsd 476 c1645400 0 1 476 0000000 [SLPQ select 0xc075cda4][SLP] mountd 398 c1648400 0 1 398 0000000 [SLPQ select 0xc075cda4][SLP] ypbind 395 c1645200 0 1 395 0000000 [SLPQ select 0xc075cda4][SLP] rpcbind 362 c1648200 0 1 362 0000000 [SLPQ biord 0xc3a14508][SLP] syslogd 325 c1645000 0 1 325 0000000 [SLPQ select 0xc075cda4][SLP] devd 218 c15e4000 0 1 218 0000000 [SLPQ pause 0xc15e4034][SLP] adjkerntz 62 c15e4c00 0 0 0 0000204 [SLPQ - 0xc83cfd04][SLP] schedcpu 61 c15e4e00 0 0 0 0000204 [SLPQ - 0xc076526c][SLP] nfsiod 3 60 c15e5000 0 0 0 0000204 [SLPQ - 0xc0765268][SLP] nfsiod 2 59 c15e5200 0 0 0 0000204 [SLPQ - 0xc0765264][SLP] nfsiod 1 58 c15e5400 0 0 0 0000204 [SLPQ - 0xc0765260][SLP] nfsiod 0 57 c15e5600 0 0 0 0000204 [SLPQ syncer 0xc070f81c][SLP] syncer 56 c15e5800 0 0 0 0000204 [SLPQ vlruwt 0xc15e5800][SLP] vnlru 55 c133e400 0 0 0 0000204 [SLPQ psleep 0xc075d2ec][SLP] bufdaemon 54 c133e600 0 0 0 000020c [SLPQ pgzero 0xc076b704][SLP] pagezero 53 c133e800 0 0 0 0000204 [SLPQ psleep 0xc076b254][SLP] vmdaemon 52 c133ea00 0 0 0 0000204 [SLPQ psleep 0xc076b210][SLP] pagedaemon 51 c133ec00 0 0 0 0000204 [SLPQ m:w2 0xc15b5d00][SLP] g_mirror data 50 c133ee00 0 0 0 0000204 [IWAIT] swi0: sio 49 c13ad000 0 0 0 0000204 [SLPQ - 0xc14c5a3c][SLP] fdc0 48 c13ad200 0 0 0 0000204 [SLPQ tzpoll 0xc0882694][SLP] acpi_thermal 47 c13ad400 0 0 0 0000204 [SLPQ usbevt 0xc1525210][SLP] usb2 db> trace 362 Tracing pid 362 tid 100081 td 0xc15e7c00 sched_switch(c15e7c00,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(c3a14508,cc6b99dc,c050da15,c3a14508,0) at sleepq_switch+0xe0 sleepq_wait(c3a14508,0,0,c06aec19,e52) at sleepq_wait+0x30 msleep(c3a14508,c075d3c0,4c,c06af341,0) at msleep+0x311 bwait(c3a14508,4c,c06af341) at bwait+0x47 bufwait(c3a14508,1,0,0,c16b2000) at bufwait+0x1a breadn(c1adedd0,0,0,800,0) at breadn+0x266 bread(c1adedd0,0,0,800,0) at bread+0x20 ffs_balloc_ufs2(c1adedd0,4f,0,57,c12f5a00) at ffs_balloc_ufs2+0xcbf ffs_write(cc6b9c40,c1a4a510,c1adedd0,cc6b9c8c,c0565fd6) at ffs_write+0x2b4 VOP_WRITE_APV(c06f7600,cc6b9c40) at VOP_WRITE_APV+0x9b vn_write(c1a4a510,c1bac100,c12f5a00,0,c15e7c00) at vn_write+0x1ea kern_writev(c15e7c00,8,c1bac100,c1bac100,0) at kern_writev+0x8e writev(c15e7c00,cc6b9d04,3,39,292) at writev+0x30 syscall(3b,3b,3b,8054cde,bfbfde70) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (121, FreeBSD ELF32, writev), eip = 0x280c9563, esp = 0xbfbfd8ac, ebp = 0xbfbfde98 --- db> trace 2451 Tracing pid 2451 tid 100120 td 0xc1803600 sched_switch(c1803600,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(c186b9b0,0,ccb6dbb4,c050da06,c186b9b0) at sleepq_switch+0xe0 sleepq_wait_sig(c186b9b0,0,100,c06adec5,3f1) at sleepq_wait_sig+0xc msleep(c186b9b0,c186b97c,158,c06ae15c,0) at msleep+0x302 sbwait(c186b964,c070f180,2,4,0) at sbwait+0x4b soreceive(c186b914,0,ccb6dc78,0,0) at soreceive+0x2da soo_read(c1a4a318,ccb6dc78,c1b01380,0,c1803600) at soo_read+0x41 dofileread(c1803600,c1a4a318,12,bfbee028,4) at dofileread+0xad read(c1803600,ccb6dd04,3,449,292) at read+0x3b syscall(3b,3b,bfbe003b,12,bfbee028) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip = 0x280c1e83, esp = 0xbfbedfdc, ebp = 0xbfbee008 --- -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 14:34: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 8075A16A41C for ; Tue, 14 Jun 2005 14:34:27 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 11F2243D58 for ; Tue, 14 Jun 2005 14:34:26 +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-1.free.fr (Postfix) with ESMTP id 05804317DB5 for ; Tue, 14 Jun 2005 16:34:25 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id F30B8407E; Tue, 14 Jun 2005 16:34:03 +0200 (CEST) Date: Tue, 14 Jun 2005 16:34:03 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20050614143403.GL30017@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: panic while mkdir(2) in msdosfs (deget()) 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, 14 Jun 2005 14:34:27 -0000 Hi, I got a panic on friday while I was uploading files through FTP at a high rate (100Mb/s). Given this panic occured while doing an mkdir(2), you understand that the msdosfs partition is where the FTP daemon was writing. The system is %%% jarjarbinks:tataz$ uname -a FreeBSD jarjarbinks.tataz.chchile.org 6.0-CURRENT FreeBSD 6.0-CURRENT #149: Thu Jun 9 00:25:52 CEST 2005 root@jarjarbinks.tataz.chchile.org:/usr/src/sys/i386/compile/JARJARBINKS i386 %%% Here is the stack trace: %%% #22 0xc055f075 in panic (fmt=0xc0729ff0 "wrong dirclust") at ../../../kern/kern_shutdown.c:537 #23 0xc050e207 in deget (pmp=0xc2914900, dirclust=366469, diroffset=0, depp=0xe50ecae8) at ../../../fs/msdosfs/msdosfs_denode.c:142 #24 0xc05122c1 in createde (dep=0xe50ecafc, ddep=0xc2b30400, depp=0xe50ecae8, cnp=0xe50ecc18) at ../../../fs/msdosfs/msdosfs_lookup.c:673 #25 0xc05170d0 in msdosfs_mkdir (ap=0xe50ecbb0) at ../../../fs/msdosfs/msdosfs_vnops.c:1375 #26 0xc07017ac in VOP_MKDIR_APV (vop=0x0, a=0xe50ecbb0) at vnode_if.c:1248 #27 0xc05ce054 in kern_mkdir (td=0xc2575190, path=0x8060360
, segflg=UIO_USERSPACE, mode=511) at vnode_if.h:653 #28 0xc05cdd19 in mkdir (td=0x0, uap=0x0) at ../../../kern/vfs_syscalls.c:3321 #29 0xc06e6540 in syscall (frame= {tf_fs = -1078001605, tf_es = -452067269, tf_ds = 59, tf_edi = 203, tf_esi = 134611360, tf_ebp = -1077943752, tf_isp = -452014748, tf_ebx = 134611808, tf_edx = 0, tf_ecx = 134684744, tf_eax = 136, tf_trapno = 0, tf_err = 2, tf_eip = 672334223, tf_cs = 51, tf_eflags = 582, tf_esp = -1077943780, tf_ss = 59}) at ../../../i386/i386/trap.c:976 #30 0xc06d219f in Xint0x80_syscall () at ../../../i386/i386/exception.s:200 %%% I checked the source code, but my skills are not as high as I'd like and I wasn't able to understand where this panic has its source. All I can see is that it has good chances to be related to phk's vfs_hash updates. A dump is available, if needed. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 16:23: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 D3B4916A41C for ; Tue, 14 Jun 2005 16:23:48 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id AE9E743D1D for ; Tue, 14 Jun 2005 16:23:48 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5EGNdZA020997; Tue, 14 Jun 2005 09:23:39 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5EGNcjW020996; Tue, 14 Jun 2005 09:23:38 -0700 Date: Tue, 14 Jun 2005 09:23:38 -0700 From: Brooks Davis To: Vladimir Grebenschikov Message-ID: <20050614162338.GA20371@odin.ac.hmc.edu> References: <20050607034620.GA32718@odin.ac.hmc.edu> <1118728905.939.5.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <1118728905.939.5.camel@localhost> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 14 Jun 2005 16:23:48 -0000 --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 14, 2005 at 10:01:45AM +0400, Vladimir Grebenschikov wrote: > ? ??, 06/06/2005 ? 20:46 -0700, Brooks Davis ?????: > > I'm about to start importing the OpenBSD dhclient and required > > support in /etc. I will unhook dhclient from the build while I work so > > there shouldn't be much breakage for most people >=20 > I have strange behavior of new dhclient + devd: >=20 > just after boot (with ethernet plugged) I have no devd events about > state of media and have interface down, but after first ifconfig (even > without parameters, even executed by any user) "link state chages to UP" > event appears and devd starts dhclient on interface. >=20 > I do not think that it is desired behavior. >=20 > my rc.conf, related to this:=20 >=20 > ifconfig_fxp0=3D"dhcp" > network_interfaces=3D"lo0" > devd_enable=3D"YES" >=20 > Probably I need to comment network_interfaces line, but anyway, now it > works strange. I'm not sure what you are claiming here. The dhclient should be being started by /etc/rc.d/netif which is well before devd. The link state message had nothing to do with devd other than being emitted by the same function that sends a notifaction to devd. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --bg08WKrSYDhXBjb5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCrwSKXY6L6fI4GtQRAheGAKDdZcawEDVJUz9O42SCEaPq7SUVMQCdFTbu 0Mq+bs5dVG2HSlwUic1Y8w4= =Unjv -----END PGP SIGNATURE----- --bg08WKrSYDhXBjb5-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 16:24: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 41E6B16A41C for ; Tue, 14 Jun 2005 16:24:22 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (imap.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 9EA7643D53 for ; Tue, 14 Jun 2005 16:24:21 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 14 Jun 2005 16:24:20 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp020) with SMTP; 14 Jun 2005 18:24:20 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Tue, 14 Jun 2005 18:24:07 +0200 User-Agent: KMail/1.8 References: <200504262010.49509@harrymail> <20050429200029.GC232@cirb503493.alcatel.com.au> In-Reply-To: X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart65810505.oWj21Pc7d2"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506141824.17451@harrymail> X-Y-GMX-Trusted: 0 Cc: Lyndon Nerenberg Subject: Re: groff alternative? 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, 14 Jun 2005 16:24:22 -0000 --nextPart65810505.oWj21Pc7d2 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Montag, 2. Mai 2005 23:44 schrieb Lyndon Nerenberg: > --On 2005-4-30 6:00 AM +1000 Peter Jeremy > > wrote: > > I don't believe the nroff in either 4.3BSD or 2.11BSD can support long > > names and neither include a mdoc(7) implementation. 4.4BSD includes > > mdoc(7) but also GNU groff - though a quick look at the tmac.mdoc* > > files suggests that it might work with an old (4.3 or 2.11) nroff. > > When the Solaris 10 source is released there will be an up-to-date > alternative to groff. I'm planning to switch over to the Solaris troff > ASAP. I've already started fixing mdoc to work with ditroff on another > Solaris 10 box. Dear Lyndon, today I read a news article (http://www.heise.de/newsticker/meldung/60600)= =20 about OpenSolaris beeing released, but is there also the groff alternative= =20 included? I'd love to see a lean replacment for our current gnu version. Thnaks, =2DHarry > > --lyndon > _______________________________________________ > 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" --nextPart65810505.oWj21Pc7d2 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCrwSxBylq0S4AzzwRAikpAKCQ19Fzj2tp/9mCPEVHfTOTgvPtugCeNwB4 x0C3h+ORm/gOr9s2DVar3rU= =BIHs -----END PGP SIGNATURE----- --nextPart65810505.oWj21Pc7d2-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 16:25:32 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 C230216A41C for ; Tue, 14 Jun 2005 16:25:32 +0000 (GMT) (envelope-from fmayhar@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 66CFF43D48 for ; Tue, 14 Jun 2005 16:25:32 +0000 (GMT) (envelope-from fmayhar@gmail.com) Received: by zproxy.gmail.com with SMTP id 18so68622nzp for ; Tue, 14 Jun 2005 09:25:31 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:reply-to:to:in-reply-to:references:content-type:organization:date:message-id:mime-version:x-mailer:content-transfer-encoding:from; b=YPi4sh8CbGXh7qY5aFZQDhMkpPqCmlrblpkXtH5Sgz4XE+7ekEQkiBurABEb7Y1fqU1Iil1LCkGb+WaSIjwlloupSFDVU8uDdm9xCIXcndchbgFpr2PkPom5U9daMmhJ8dSD7jxj2jAj19OBhO7qLaeuVAl+1zcoLRTuOs8Qk1E= Received: by 10.36.96.4 with SMTP id t4mr3459453nzb; Tue, 14 Jun 2005 09:25:31 -0700 (PDT) Received: from localhost.localdomain ([4.232.111.82]) by mx.gmail.com with ESMTP id 19sm1892880nzp.2005.06.14.09.25.27; Tue, 14 Jun 2005 09:25:31 -0700 (PDT) To: current@freebsd.org In-Reply-To: <1118593466.16330.1.camel@realtime.exit.com> References: <1118593466.16330.1.camel@realtime.exit.com> Content-Type: text/plain Organization: Exit Consulting Date: Tue, 14 Jun 2005 09:25:21 -0700 Message-Id: <1118766321.91310.3.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit From: Frank Mayhar Cc: Subject: Re: Silent ACPI-related reset booting latest kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 16:25:32 -0000 On Sun, 2005-06-12 at 09:24 -0700, Frank Mayhar wrote: > I just rebuilt with the latest bits as of this afternoon. Apparently, > some commit within the last 24 to 48 hours or so has broken ACPI on my > Inspiron 5160. Booting with ACPI I get as far as > and it silently reboots. Well, I re-cvsupped and rebuilt and things seem to be working just fine once more. I guess I caught some set of changes in the middle or just had bad timing. Although I notice that the gnome-netstatus applet is pretty confused now, but that's certainly not critical. Never mind, then. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 17:11: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 D9E0C16A41C for ; Tue, 14 Jun 2005 17:11:29 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 2F9F743D55 for ; Tue, 14 Jun 2005 17:11:28 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: (qmail invoked by alias); 14 Jun 2005 17:11:27 -0000 Received: from p5090D354.dip.t-dialin.net (EHLO klotz.local) [80.144.211.84] by mail.gmx.net (mp014) with SMTP; 14 Jun 2005 19:11:27 +0200 X-Authenticated: #989277 Received: from [127.0.0.1] (localhost [127.0.0.1]) by klotz.local (8.13.3/8.13.3) with ESMTP id j5EHAcqx002071 for ; Tue, 14 Jun 2005 19:10:39 +0200 (CEST) (envelope-from nakal@nurfuerspam.de) Message-ID: <42AF0F8E.20309@nurfuerspam.de> Date: Tue, 14 Jun 2005 19:10:38 +0200 From: Martin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050403) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Subject: Problems with latest ath(4) 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, 14 Jun 2005 17:11:30 -0000 Hi, I have problems with my Netgear WG511T on -CURRENT. It appears as if the driver works first, but then suddenly freezes the whole system for about a minute. The LEDs start to blink indicating that the lost connection to my hostap-box (running -STABLE with Netgear WG311T). -CURRENT gets more and more unresponsive, if you let it run a bit longer. The last known working kernel is of May 31st. The driver is compiled statically into the kernel. Martin From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 17:39: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 A451516A41C for ; Tue, 14 Jun 2005 17:39:29 +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 65F4143D49 for ; Tue, 14 Jun 2005 17:39:29 +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 j5EHc3De011489; Tue, 14 Jun 2005 13:38:03 -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 j5EHc3r2011486; Tue, 14 Jun 2005 13:38:03 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Tue, 14 Jun 2005 13:38:03 -0400 (EDT) From: Andre Guibert de Bruet To: frank@exit.com In-Reply-To: <1118766321.91310.3.camel@realtime.exit.com> Message-ID: <20050614133706.T42933@lexi.siliconlandmark.com> References: <1118593466.16330.1.camel@realtime.exit.com> <1118766321.91310.3.camel@realtime.exit.com> 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.533, required 6, autolearn=not spam, AWL 0.07, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: current@freebsd.org Subject: Re: Silent ACPI-related reset booting latest 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: Tue, 14 Jun 2005 17:39:29 -0000 On Tue, 14 Jun 2005, Frank Mayhar wrote: > Well, I re-cvsupped and rebuilt and things seem to be working just fine > once more. I guess I caught some set of changes in the middle or just > had bad timing. > > Although I notice that the gnome-netstatus applet is pretty confused > now, but that's certainly not critical. Have you tried rebuilding it? 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 Tue Jun 14 17:50: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 017F116A41F for ; Tue, 14 Jun 2005 17:50:30 +0000 (GMT) (envelope-from fmayhar@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9948743D4C for ; Tue, 14 Jun 2005 17:50:29 +0000 (GMT) (envelope-from fmayhar@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so124702nzp for ; Tue, 14 Jun 2005 10:50:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:reply-to:to:cc:in-reply-to:references:content-type:organization:date:message-id:mime-version:x-mailer:content-transfer-encoding:from; b=RRWhWqjookNFAZPv2PyqLB/XQG+PTqf7A9P3YHbzWvoAgEomYDA4oaS94Chw0SEt1edukqT8HXSnN3ASghzzVBP4qhMbCycz0lL+KQTqRBxtdD3bpJJLVEerAuQfM4pgx6KZMywdNKV9ZP/zirz6+9PL+tLKqto/Tw134IlQpMk= Received: by 10.36.56.10 with SMTP id e10mr3846448nza; Tue, 14 Jun 2005 10:50:22 -0700 (PDT) Received: from localhost.localdomain ([4.232.111.82]) by mx.gmail.com with ESMTP id 15sm2455576nzn.2005.06.14.10.50.21; Tue, 14 Jun 2005 10:50:22 -0700 (PDT) To: Andre Guibert de Bruet In-Reply-To: <20050614133706.T42933@lexi.siliconlandmark.com> References: <1118593466.16330.1.camel@realtime.exit.com> <1118766321.91310.3.camel@realtime.exit.com> <20050614133706.T42933@lexi.siliconlandmark.com> Content-Type: text/plain Organization: Exit Consulting Date: Tue, 14 Jun 2005 10:50:17 -0700 Message-Id: <1118771417.91607.5.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit From: Frank Mayhar Cc: current@freebsd.org Subject: Re: Silent ACPI-related reset booting latest kernel. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 17:50:30 -0000 On Tue, 2005-06-14 at 13:38 -0400, Andre Guibert de Bruet wrote: > On Tue, 14 Jun 2005, Frank Mayhar wrote: > > Although I notice that the gnome-netstatus applet is pretty confused > > now, but that's certainly not critical. > Have you tried rebuilding it? Ayup. First thing I tried. No dice. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 18:21: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 96D5E16A41C for ; Tue, 14 Jun 2005 18:21:29 +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 4C4A543D49 for ; Tue, 14 Jun 2005 18:21:29 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B0D4351355; Tue, 14 Jun 2005 14:21:27 -0400 (EDT) Date: Tue, 14 Jun 2005 14:21:27 -0400 From: Kris Kennaway To: Dikshie Message-ID: <20050614182127.GA22085@xor.obsecurity.org> References: <20050614063148.GA22683@ppk.itb.ac.id> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Nq2Wo0NMKNjxTN9z" Content-Disposition: inline In-Reply-To: <20050614063148.GA22683@ppk.itb.ac.id> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: doadump () at pcpu.h:165 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, 14 Jun 2005 18:21:29 -0000 --Nq2Wo0NMKNjxTN9z Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 14, 2005 at 01:31:48PM +0700, Dikshie wrote: > Dear All, > I got self reboot my 6.0-CURRENT and able to get=20 > dumpfile: >=20 >=20 > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you = are > welcome to change it and/or distribute copies of it under certain conditi= ons. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for detail= s. > This GDB was configured as "i386-marcel-freebsd". > #0 doadump () at pcpu.h:165 > in pcpu.h > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc0526110 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c= :397 > #2 0xc05263bb in panic (fmt=3D0xc06dc69f "cur !=3D NULL") > at /usr/src/sys/kern/kern_shutdown.c:553 > #3 0xc05bd3ac in tcp_sack_option (tp=3D0xc2013000, th=3D0xd443eb14, > cp=3D0xc1af2056 "\005\nwF\212|wF\217\0017\0010\0012\0010\0010\001= 0\0011\0010\0013\0010\0010\0010\0010\0013\001d\0010\00 > 11\0010\0010\0012\003ip6\004arpa", > optlen=3D0) at /usr/src/sys/netinet/tcp_sack.c:478 Here is the real panic, not the frame #0 as in your subject. I've seen this panic also and have reported it to ps and mohan. Kris > #4 0xc05bb327 in tcp_dooptions (tp=3D0xc2013000, to=3D0xd443ec78, > cp=3D0xc1af2056 "\005\nwF\212|wF\217\0017\0010\0012\0010\0010\001= 0\0011\0010\0013\0010\0010\0010\0010\0013\001d\0010\00 > 11\0010\0010\0012\003ip6\004arpa", > cnt=3D10, is_syn=3D0, th=3D0xc1af2034) at /usr/src/sys/netinet/tcp_in= put.c:2647 > #5 0xc05b8dfb in tcp_input (m=3D0xc1ad6600, off0=3D65800) > at /usr/src/sys/netinet/tcp_input.c:1085 > #6 0xc05adcd5 in ip_input (m=3D0xc1ad6600) > at /usr/src/sys/netinet/ip_input.c:776 > #7 0xc0597f42 in netisr_processqueue (ni=3D0xc0783318) > at /usr/src/sys/net/netisr.c:235 > #8 0xc059812a in swi_net (dummy=3D0x0) at /usr/src/sys/net/netisr.c:348 > #9 0xc0513940 in ithread_loop (arg=3D0xc19db180) > at /usr/src/sys/kern/kern_intr.c:546 > #10 0xc0512dd4 in fork_exit (callout=3D0xc0513820 , > arg=3D0xc19db180, frame=3D0xd443ed38) at /usr/src/sys/kern/kern_fork.= c:789 > #11 0xc0685e3c in fork_trampoline () at /usr/src/sys/i386/i386/exception.= s:208 > (kgdb) quit >=20 >=20 >=20 >=20 >=20 >=20 > regards, >=20 > -dikshie- > _______________________________________________ > 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" >=20 --Nq2Wo0NMKNjxTN9z Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCryAmWry0BWjoQKURAgtxAJ9sgEdU4G4Gw/969nFQr9kPf77bJwCgkIin F5AuPyuc1lLggZfo3VRr4Lw= =N2K9 -----END PGP SIGNATURE----- --Nq2Wo0NMKNjxTN9z-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 18:39: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 629C716A41C for ; Tue, 14 Jun 2005 18:39:46 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 9E26143D48 for ; Tue, 14 Jun 2005 18:39:45 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 14 Jun 2005 18:39:44 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp033) with SMTP; 14 Jun 2005 20:39:44 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org, Brooks Davis Date: Tue, 14 Jun 2005 20:39:30 +0200 User-Agent: KMail/1.8 References: <42A2D3B9.1050904@schmalzbauer.de> <20050605140206.GA68571@82-168-79-254-bbxl.xdsl.tiscali.nl> In-Reply-To: <20050605140206.GA68571@82-168-79-254-bbxl.xdsl.tiscali.nl> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1259189.jtReCW6UfV"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506142039.40112@harrymail> X-Y-GMX-Trusted: 0 Cc: Subject: Re: fxp LOR and ... 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, 14 Jun 2005 18:39:46 -0000 --nextPart1259189.jtReCW6UfV Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Sonntag, 5. Juni 2005 16:02 schrieb Rene Ladan: > On Sun, Jun 05, 2005 at 12:28:09PM +0200, Harald Schmalzbauer wrote: > > Dear best boys, > > > > writing on my emergency machine I can't check if this LOR is well > > known, to be sure I'd like to post it, please see the attachment.a > > [snip nvidia] > > > Thanks for any hint. > > > > -Harry > > > > lock order reversal > > 1st 0xc075af40 Giant (Giant) @ /usr/src/sys/kern/kern_timeout.c:263 > > 2nd 0xc1a82270 fxp0 (network driver) @ > > /usr/src/sys/dev/fxp/if_fxp.c:1193 KDB: stack backtrace: > > kdb_backtrace(0,ffffffff,c076a648,c0769130,c072e084) at > > kdb_backtrace+0x29 witness_checkorder(c1a82270,9,c06de442,4a9) at > > witness_checkorder+0x564 > > _mtx_lock_flags(c1a82270,0,c06de442,4a9,c1a82000) at > > _mtx_lock_flags+0x5b fxp_start(c1a82000) at fxp_start+0x22 > > if_start(c1a82000) at if_start+0x7b > > ether_output_frame(c1a82000,c1c29d00,0,0,0) at > > ether_output_frame+0x1d9 ether_output(c1a82000,c1c29d00,d447bbe0,0,0) > > at ether_output+0x384 > > nd6_output(c1a82000,c1a82000,c1c29d00,d447bbe0,0) at nd6_output+0x30a > > ip6_output(c1c29d00,0,d447bbdc,1,d447bc58,d447bc4c,0,c1c29d00,3a,28,0) > > at ip6_output+0xfd5 nd6_ns_output(c1a82000,0,c1c340a8,0,1) at > > nd6_ns_output+0x323 > > nd6_dad_ns_output(c1c360c0,c1c34000,c075af40,6,c1c34000) at > > nd6_dad_ns_output+0x32 nd6_dad_timer(c1c34000) at nd6_dad_timer+0x1a3 > > softclock(0) at softclock+0x1e7 > > ithread_loop(c19e7300,d447bd38,c19e7300,c05445b0,0) at > > ithread_loop+0x120 fork_exit(c05445b0,c19e7300,d447bd38) at > > fork_exit+0xa0 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip =3D 0, esp =3D 0xd447bd6c, ebp =3D 0 --- > > lock order reversal > > 1st 0xc1ce6924 rtentry (rtentry) @ > > /usr/src/sys/netinet/if_ether.c:445 2nd 0xc1a82270 fxp0 (network > > driver) @ /usr/src/sys/dev/fxp/if_fxp.c:1193 KDB: stack backtrace: > > kdb_backtrace(0,ffffffff,c076a3f0,c0769130,c072e084) at > > kdb_backtrace+0x29 witness_checkorder(c1a82270,9,c06de442,4a9) at > > witness_checkorder+0x564 > > _mtx_lock_flags(c1a82270,0,c06de442,4a9,c1a82000) at > > _mtx_lock_flags+0x5b fxp_start(c1a82000) at fxp_start+0x22 > > if_start(c1a82000) at if_start+0x7b > > ether_output_frame(c1a82000,c1c29800,d4481abc,ffffffff,0) at > > ether_output_frame+0x1d9 ether_output(c1a82000,c1c29800,d4481ad8,0,2) > > at ether_output+0x384 arprequest(c1a82000,c1c8b2c8,d4481ba8,c19884ac) > > at arprequest+0xd8 > > arpresolve(c1a82000,c1ce68c4,c1a93300,d4481ba4,d4481b48) at > > arpresolve+0x29c > > ether_output(c1a82000,c1a93300,d4481ba4,c1ce68c4,c1c8b200) at > > ether_output+0x66 ip_output(c1a93300,0,d4481ba0,0,0) at > > ip_output+0x6fc > > icmp_send(c1a93300,0,c1a93300) at icmp_send+0x55 > > icmp_reflect(c1a93300,c0760680,0,14,c1ad5034) at icmp_reflect+0x2d6 > > icmp_input(c1a93300,14,c1a93300,0,0) at icmp_input+0x384 > > ip_input(c1a93300) at ip_input+0x511 > > netisr_processqueue(c07a75f8) at netisr_processqueue+0x6e > > swi_net(0) at swi_net+0xc2 > > ithread_loop(c19e7200,d4481d38,c19e7200,c05445b0,0) at > > ithread_loop+0x120 fork_exit(c05445b0,c19e7200,d4481d38) at > > fork_exit+0xa0 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip =3D 0, esp =3D 0xd4481d6c, ebp =3D 0 --- > > lock order reversal > > 1st 0xc1ce4360 inp (udpinp) @ /usr/src/sys/netinet/udp_usrreq.c:762 > > 2nd 0xc1a82270 fxp0 (network driver) @ > > /usr/src/sys/dev/fxp/if_fxp.c:1193 KDB: stack backtrace: > > kdb_backtrace(0,ffffffff,c076a350,c0769130,c072e084) at > > kdb_backtrace+0x29 witness_checkorder(c1a82270,9,c06de442,4a9) at > > witness_checkorder+0x564 > > _mtx_lock_flags(c1a82270,0,c06de442,4a9,c1a82000) at > > _mtx_lock_flags+0x5b fxp_start(c1a82000) at fxp_start+0x22 > > if_start(c1a82000) at if_start+0x7b > > ether_output_frame(c1a82000,c1c29500,0,0,0) at > > ether_output_frame+0x1d9 > > ether_output(c1a82000,c1c29500,dab3ab04,c1ce68c4,c1c8b200) at > > ether_output+0x384 ip_output(c1c29500,0,dab3ab00,0,0) at > > ip_output+0x6fc > > udp_output(c1ce42d0,c1c29500,0,0,c1ee7780) at udp_output+0x4a7 > > udp_send(c1ce23e4,0,c1c29500,0,0) at udp_send+0x1a > > sosend(c1ce23e4,0,dab3ac3c,c1c29500,0) at sosend+0x5e3 > > kern_sendit(c1ee7780,4,dab3acbc,0,0) at kern_sendit+0x104 > > sendit(c1ee7780,4,dab3acbc,0,807b031) at sendit+0x163 > > sendto(c1ee7780,dab3ad04,6,0,216) at sendto+0x4d > > syscall(3b,3b,3b,2,0) at syscall+0x22f > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (133, FreeBSD ELF32, sendto), eip =3D 0x280d1def, esp =3D > > 0xbfbfd84c, ebp =3D 0xbfbfd878 --- lock order reversal > > 1st 0xc1d2bc84 inp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:372 > > 2nd 0xc1a82270 fxp0 (network driver) @ > > /usr/src/sys/dev/fxp/if_fxp.c:1193 KDB: stack backtrace: > > kdb_backtrace(0,ffffffff,c076a300,c0769130,c072e084) at > > kdb_backtrace+0x29 witness_checkorder(c1a82270,9,c06de442,4a9) at > > witness_checkorder+0x564 > > _mtx_lock_flags(c1a82270,0,c06de442,4a9,c1a82000) at > > _mtx_lock_flags+0x5b fxp_start(c1a82000) at fxp_start+0x22 > > if_start(c1a82000) at if_start+0x7b > > ether_output_frame(c1a82000,c1c25100,0,0,0) at > > ether_output_frame+0x1d9 > > ether_output(c1a82000,c1c25100,c1b76370,c1ce67bc,c1c8b200) at > > ether_output+0x384 ip_output(c1c25100,0,d9977b80,0,0) at > > ip_output+0x6fc > > tcp_output(c1d2d564,c1ee0000,25,c1c62780,d9977c98) at tcp_output+0xfb2 > > tcp_usr_connect(c1ee0000,c1c35a00,c1c62780) at tcp_usr_connect+0xe3 > > soconnect(c1ee0000,c1c35a00,c1c62780,0,c1d3e000) at soconnect+0x4e > > kern_connect(c1c62780,4,c1c35a00,c1c35a00,0) at kern_connect+0x74 > > connect(c1c62780,d9977d04,3,6,296) at connect+0x2f > > syscall(3b,3b,3b,280e3640,bfbfece0) at syscall+0x22f > > Xint0x80_syscall() at Xint0x80_syscall+0x1f > > --- syscall (98, FreeBSD ELF32, connect), eip =3D 0x2819502f, esp =3D > > 0xbfbfe52c, ebp =3D 0xbfbfe588 --- lock order reversal > > 1st 0xc07a836c tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:616 > > 2nd 0xc1a82270 fxp0 (network driver) @ > > /usr/src/sys/dev/fxp/if_fxp.c:1193 KDB: stack backtrace: > > kdb_backtrace(0,ffffffff,c076a328,c0769130,c072e084) at > > kdb_backtrace+0x29 witness_checkorder(c1a82270,9,c06de442,4a9) at > > witness_checkorder+0x564 > > _mtx_lock_flags(c1a82270,0,c06de442,4a9,c1a82000) at > > _mtx_lock_flags+0x5b fxp_start(c1a82000) at fxp_start+0x22 > > if_start(c1a82000) at if_start+0x7b > > ether_output_frame(c1a82000,c1a8f100,0,0,0) at > > ether_output_frame+0x1d9 > > ether_output(c1a82000,c1a8f100,c1b76370,c1ce67bc,c1c8b200) at > > ether_output+0x384 ip_output(c1a8f100,0,d4481b38,0,0,0) at > > ip_output+0x6fc > > tcp_respond(0,c1aaf820,c1aaf834,c1a8f100,0,78847350,4) at > > tcp_respond+0x3e1 tcp_input(c1a8f100,14,c1a8f100,0,0) at > > tcp_input+0x2d46 > > ip_input(c1a8f100) at ip_input+0x511 > > netisr_processqueue(c07a75f8) at netisr_processqueue+0x6e > > swi_net(0) at swi_net+0xc2 > > ithread_loop(c19e7200,d4481d38,c19e7200,c05445b0,0) at > > ithread_loop+0x120 fork_exit(c05445b0,c19e7200,d4481d38) at > > fork_exit+0xa0 > > fork_trampoline() at fork_trampoline+0x8 > > --- trap 0x1, eip =3D 0, esp =3D 0xd4481d6c, ebp =3D 0 --- > > Looks like a LOR (#73) which always pops up on RELENG_5 since March. > It seems harmless. Something obscure must be wrong with > FXP_LOCK() and/or FXP_UNLOCK(). Thanks for the info, it really looks like LOR#73. I still get this LOR after Brooks monster-changes. Perhaps he can have a=20 look at it while he's at this part? Thanks, =2DHarry=20 > > Regards, > Rene --nextPart1259189.jtReCW6UfV Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCryRsBylq0S4AzzwRAq9/AJ9JOK/nI5wUR0sdVeUVCb2RYtA1cwCeMDjc 61Gy+lbDvfCAjTRvSVEXqsM= =WAF6 -----END PGP SIGNATURE----- --nextPart1259189.jtReCW6UfV-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 18:49: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 B377E16A41C; Tue, 14 Jun 2005 18:49:46 +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 351D343D55; Tue, 14 Jun 2005 18:49:45 +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 j5EIni8s076174; Tue, 14 Jun 2005 22:49:44 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Tue, 14 Jun 2005 22:49:44 +0400 (MSD) From: Maxim Konovalov To: "David O'Brien" In-Reply-To: <20050614082039.GA2038@dragon.NUXI.org> Message-ID: <20050614224704.Y75797@mp2.macomnet.net> References: <20050613192308.GA87640@sandvine.com> <20050614082039.GA2038@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org, Ed Maste Subject: Re: savecore(8) increments /var/crash/bounds on each boot 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, 14 Jun 2005 18:49:46 -0000 On Tue, 14 Jun 2005, 01:20-0700, David O'Brien wrote: > On Mon, Jun 13, 2005 at 03:23:08PM -0400, Ed Maste wrote: > > I notice that as of sbin/savecore/savecore.c 1.72 and in 5.4-RELEASE > > savecore increments the number in /var/crash/bounds on each boot, > > regardless of whether it rebooted due to panic or was a clean shutdown. > > Is this the desired behaviour or an unintentional side effect? > > It is an unintentional side affect. If I wasn't constantly experiencing > kernel landminds every time I sit down to do major FreeBSD, I would have > gotten to this issue. I am going to ask re@ for permission to commit the fix if nobody beats me. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 18:59: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 615F616A41C for ; Tue, 14 Jun 2005 18:59:28 +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 345D443D1F for ; Tue, 14 Jun 2005 18:59:28 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5EIxNqL012876; Tue, 14 Jun 2005 11:59:23 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5EIxNr7012875; Tue, 14 Jun 2005 11:59:23 -0700 (PDT) (envelope-from obrien) Date: Tue, 14 Jun 2005 11:59:23 -0700 From: "David O'Brien" To: Emanuel Strobl Message-ID: <20050614185923.GA12375@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, Emanuel Strobl , Lyndon Nerenberg References: <200504262010.49509@harrymail> <20050429200029.GC232@cirb503493.alcatel.com.au> <200506141824.17451@harrymail> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506141824.17451@harrymail> 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, Lyndon Nerenberg Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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, 14 Jun 2005 18:59:28 -0000 On Tue, Jun 14, 2005 at 06:24:07PM +0200, Emanuel Strobl wrote: > today I read a news article (http://www.heise.de/newsticker/meldung/60600) > about OpenSolaris beeing released, but is there also the groff alternative > included? > I'd love to see a lean replacment for our current gnu version. Before everyone gets all happy thinking we can incorporate all kinds of bits from Open Solaris - one should read the license agrement first. COMMON DEVELOPMENT AND DISTRIBUTION LICENSE Version 1.0 .. 3.1. Availability of Source Code. Any Covered Software that You distribute or otherwise make available in Executable form must also be made available in Source Code form and that Source Code form must be distributed only under the terms of this License. this puts the CDDL1.0 in the same boat as GPL'ed code from a BSD stand point. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 19:08: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 DB6DC16A41C for ; Tue, 14 Jun 2005 19:08:55 +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 AFB3C43D5E for ; Tue, 14 Jun 2005 19:08:55 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5EJ8txr013291; Tue, 14 Jun 2005 12:08:55 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5EJ8sep013290; Tue, 14 Jun 2005 12:08:54 -0700 (PDT) (envelope-from obrien) Date: Tue, 14 Jun 2005 12:08:54 -0700 From: "David O'Brien" To: Maxim Konovalov Message-ID: <20050614190854.GA12928@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Maxim Konovalov , Ed Maste , freebsd-current@freebsd.org References: <20050613192308.GA87640@sandvine.com> <20050614082039.GA2038@dragon.NUXI.org> <20050614224704.Y75797@mp2.macomnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050614224704.Y75797@mp2.macomnet.net> 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, Ed Maste Subject: Re: savecore(8) increments /var/crash/bounds on each boot 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, 14 Jun 2005 19:08:56 -0000 On Tue, Jun 14, 2005 at 10:49:44PM +0400, Maxim Konovalov wrote: > On Tue, 14 Jun 2005, 01:20-0700, David O'Brien wrote: > > > On Mon, Jun 13, 2005 at 03:23:08PM -0400, Ed Maste wrote: > > > I notice that as of sbin/savecore/savecore.c 1.72 and in 5.4-RELEASE > > > savecore increments the number in /var/crash/bounds on each boot, > > > regardless of whether it rebooted due to panic or was a clean shutdown. > > > Is this the desired behaviour or an unintentional side effect? > > > > It is an unintentional side affect. If I wasn't constantly experiencing > > kernel landminds every time I sit down to do major FreeBSD, I would have > > gotten to this issue. > > I am going to ask re@ for permission to commit the fix if nobody beats > me. Are you sure its correct? Have you tested it with say bounds != 0 and a few core dumps in /var/crash? -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 19:15: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 7568B16A41C for ; Tue, 14 Jun 2005 19:15: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 3A60843D48 for ; Tue, 14 Jun 2005 19:15:43 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j5EJFems001458 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 14 Jun 2005 12:15:41 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42AF2DD9.4080503@errno.com> Date: Tue, 14 Jun 2005 12:19:53 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin References: <42AF0F8E.20309@nurfuerspam.de> In-Reply-To: <42AF0F8E.20309@nurfuerspam.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Problems with latest ath(4) 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, 14 Jun 2005 19:15:43 -0000 Martin wrote: > Hi, > > I have problems with my Netgear WG511T on -CURRENT. It appears > as if the driver works first, but then suddenly freezes the > whole system for about a minute. The LEDs start to blink indicating > that the lost connection to my hostap-box (running -STABLE with Netgear > WG311T). -CURRENT gets more and more unresponsive, if you let it run > a bit longer. > > The last known working kernel is of May 31st. The driver is compiled > statically into the kernel. ifconfig/setup? Sam From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 19:17: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 380D516A41F for ; Tue, 14 Jun 2005 19:17:04 +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 0B0F343D4C for ; Tue, 14 Jun 2005 19:17:04 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5EJGx0T013624; Tue, 14 Jun 2005 12:16:59 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5EJGwVI013623; Tue, 14 Jun 2005 12:16:58 -0700 (PDT) (envelope-from obrien) Date: Tue, 14 Jun 2005 12:16:58 -0700 From: "David O'Brien" To: Markus Brueffer Message-ID: <20050614191658.GC13306@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, Markus Brueffer , Paul Richards References: <20050613175812.GA13200@dragon.NUXI.org> <200506141116.58062.markus@brueffer.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506141116.58062.markus@brueffer.de> 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, Paul Richards Subject: Re: Immediate reboots on amd64 after upgrading to current X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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, 14 Jun 2005 19:17:04 -0000 On Tue, Jun 14, 2005 at 11:16:46AM +0200, Markus Brueffer wrote: > On Monday 13 June 2005 19:58, David O'Brien wrote: > > On Sun, Jun 12, 2005 at 12:37:43PM +0100, Paul Richards wrote: > > > Is the 6-current broken at the moment? (unlikely as it seems like > > > quite a severe break) > > > > Definitely. A June 10th 4am UTC kernel works fine for me. A June 11 > > midnight UTC kernel, does an instana-reboot. > > I can trigger it by loading different subsets of modules on boot: > > snd_ich + ng_bt + smbus = instant reboot (as descibed above) > > If I only load 2 (regardless which) of the above the system boots fine. I've tracked down my insta-reboot to marius's atkbdc commit of 2005-06-10 20:56:38 UTC. A kernel built just before that change is good (adding brooks' 2005-06-11 00:20:38 UTC mii.c commit). -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 19:19: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 32A8F16A41C; Tue, 14 Jun 2005 19:19:19 +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 96F9F43D58; Tue, 14 Jun 2005 19:19:18 +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 j5EJJHde076406; Tue, 14 Jun 2005 23:19:17 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Tue, 14 Jun 2005 23:19:17 +0400 (MSD) From: Maxim Konovalov To: current@freebsd.org Message-ID: <20050614231344.F76340@mp2.macomnet.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: brooks@freebsd.org Subject: ed(4) broken? 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, 14 Jun 2005 19:19:19 -0000 Hi, Latest GENERIC in qemu produces Jun 14 19:12:04 qemu6 kernel: ed_start(0xc12e5000) GONE Jun 14 19:12:07 qemu6 kernel: ed0: NIC memory corrupt - invalid packet length 45 No real hardware though. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 20:00: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 D7A9D16A420 for ; Tue, 14 Jun 2005 20:00:42 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from knight.ixsystems.net (afg.ixsystems.net [206.40.55.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72A7E43D55 for ; Tue, 14 Jun 2005 20:00:15 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from [192.168.1.111] (afg.ixsystems.net [206.40.55.73]) by knight.ixsystems.net (8.12.10/8.11.6) with ESMTP id j5EJb4gs021317; Tue, 14 Jun 2005 12:37:04 -0700 (PDT) (envelope-from dodell@offmyserver.com) Message-ID: <42AF374F.3000705@offmyserver.com> Date: Tue, 14 Jun 2005 13:00:15 -0700 From: "Devon H. O'Dell" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <200504262010.49509@harrymail> <20050429200029.GC232@cirb503493.alcatel.com.au> <200506141824.17451@harrymail> <20050614185923.GA12375@dragon.NUXI.org> In-Reply-To: <20050614185923.GA12375@dragon.NUXI.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Emanuel Strobl , Lyndon Nerenberg Subject: Re: groff alternative? 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, 14 Jun 2005 20:00:43 -0000 David O'Brien wrote: > On Tue, Jun 14, 2005 at 06:24:07PM +0200, Emanuel Strobl wrote: > >>today I read a news article (http://www.heise.de/newsticker/meldung/60600) >>about OpenSolaris beeing released, but is there also the groff alternative >>included? >>I'd love to see a lean replacment for our current gnu version. > > > Before everyone gets all happy thinking we can incorporate all kinds of > bits from Open Solaris - one should read the license agrement first. > > COMMON DEVELOPMENT AND DISTRIBUTION LICENSE Version 1.0 > .. > 3.1. Availability of Source Code. > Any Covered Software that You distribute or otherwise make available > in Executable form must also be made available in Source Code form > and that Source Code form must be distributed only under the terms of > this License. > > this puts the CDDL1.0 in the same boat as GPL'ed code from a BSD stand > point. Would troff/nroff/ps/pdf utilities from Plan 9 be usable? The license isn't as restrictive. They do compile, though I think there was a bit of weirdness with the ps/pdf conversion stuff the last time I heard from someone doing this for DragonFly. --Devon From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 20:01: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 16FCA16A41C for ; Tue, 14 Jun 2005 20:01:31 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 5DB4743D48 for ; Tue, 14 Jun 2005 20:01:30 +0000 (GMT) (envelope-from nakal@nurfuerspam.de) Received: (qmail invoked by alias); 14 Jun 2005 20:01:28 -0000 Received: from p5090D354.dip.t-dialin.net (EHLO klotz.local) [80.144.211.84] by mail.gmx.net (mp007) with SMTP; 14 Jun 2005 22:01:28 +0200 X-Authenticated: #989277 Received: from [127.0.0.1] (localhost [127.0.0.1]) by klotz.local (8.13.3/8.13.3) with ESMTP id j5EK0c6j003135; Tue, 14 Jun 2005 22:00:39 +0200 (CEST) (envelope-from nakal@nurfuerspam.de) Message-ID: <42AF3766.9060204@nurfuerspam.de> Date: Tue, 14 Jun 2005 22:00:38 +0200 From: Martin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050403) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Sam Leffler References: <42AF0F8E.20309@nurfuerspam.de> <42AF2DD9.4080503@errno.com> In-Reply-To: <42AF2DD9.4080503@errno.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-current@freebsd.org Subject: Re: Problems with latest ath(4) 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, 14 Jun 2005 20:01:31 -0000 Sam Leffler wrote: > ifconfig/setup? /etc/start_if.ath0: ------------------- ifconfig ath0 ssid "SSID" channel -1 wepmode on wepkey xxx mode 11b media DS/11Mbps It is configured with DHCP. Looks like this when it works: ath0: flags=8843 mtu 1500 inet6 xxx%ath0 prefixlen 64 scopeid 0x4 inet 192.168.0.2 netmask 0xffffff00 broadcast 192.168.1.255 ether xx:xx:xx:xx:xx:xx media: IEEE 802.11 Wireless Ethernet DS/11Mbps mode 11b status: associated ssid SSID channel 6 bssid xx:xx:xx:xx:xx:xx authmode OPEN privacy ON deftxkey UNDEF wepkey 1:104-bit txpowmax 14 protmode CTS bintval 1 Kernel configuration: --------------------- device ath device ath_hal device ath_rate_onoe device wlan device wlan_wep device wlan_ccmp device wlan_tkip device wlan_xauth pciconf -lv ----------- ath0@pci3:0:0: class=0x020000 card=0x4b001385 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'AR5212, AR5213 802.11a/b/g Wireless Adapter' class = network subclass = ethernet Kernel version: --------------- 6.0-CURRENT FreeBSD 6.0-CURRENT #1: Tue May 31 00:42:01 CEST 2005 i386 Did I forget anything? Martin From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 20:10: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 2888116A41C; Tue, 14 Jun 2005 20:10:10 +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 9A1C943D48; Tue, 14 Jun 2005 20:10:09 +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 j5EKA5sY076853; Wed, 15 Jun 2005 00:10:07 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Wed, 15 Jun 2005 00:10:05 +0400 (MSD) From: Maxim Konovalov To: "David O'Brien" In-Reply-To: <20050614190854.GA12928@dragon.NUXI.org> Message-ID: <20050614235132.L76669@mp2.macomnet.net> References: <20050613192308.GA87640@sandvine.com> <20050614082039.GA2038@dragon.NUXI.org> <20050614224704.Y75797@mp2.macomnet.net> <20050614190854.GA12928@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org, Ed Maste Subject: Re: savecore(8) increments /var/crash/bounds on each boot 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, 14 Jun 2005 20:10:10 -0000 On Tue, 14 Jun 2005, 12:08-0700, David O'Brien wrote: > On Tue, Jun 14, 2005 at 10:49:44PM +0400, Maxim Konovalov wrote: > > On Tue, 14 Jun 2005, 01:20-0700, David O'Brien wrote: > > > > > On Mon, Jun 13, 2005 at 03:23:08PM -0400, Ed Maste wrote: > > > > I notice that as of sbin/savecore/savecore.c 1.72 and in 5.4-RELEASE > > > > savecore increments the number in /var/crash/bounds on each boot, > > > > regardless of whether it rebooted due to panic or was a clean shutdown. > > > > Is this the desired behaviour or an unintentional side effect? > > > > > > It is an unintentional side affect. If I wasn't constantly experiencing > > > kernel landminds every time I sit down to do major FreeBSD, I would have > > > gotten to this issue. > > > > I am going to ask re@ for permission to commit the fix if nobody beats > > me. > > Are you sure its correct? Have you tested it with say bounds != 0 and a > few core dumps in /var/crash? No problems so far: qemu6# ls -l /var/crash total 336080 -rw-r--r-- 1 root wheel 3 Jun 14 20:02 bounds -rw------- 1 root wheel 426 Jun 14 19:22 info.10 -rw------- 1 root wheel 426 Jun 14 19:31 info.11 -rw------- 1 root wheel 425 Jun 14 19:49 info.12 -rw------- 1 root wheel 426 Jun 14 19:57 info.13 -rw------- 1 root wheel 462 Jun 14 20:02 info.14 -rw------- 1 root wheel 424 Jun 14 17:44 info.7 -rw-r--r-- 1 root wheel 5 May 8 07:05 minfree -rw------- 1 root wheel 134217728 Jun 14 19:23 vmcore.10 -rw------- 1 root wheel 134217728 Jun 14 19:31 vmcore.11 -rw------- 1 root wheel 134217728 Jun 14 19:50 vmcore.12 -rw------- 1 root wheel 134217728 Jun 14 19:58 vmcore.13 -rw------- 1 root wheel 134217728 Jun 14 20:03 vmcore.14 -rw------- 1 root wheel 134217728 Jun 14 17:45 vmcore.7 qemu6# cat /var/crash/bounds 15 -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 23:17:38 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 036CA16A41C for ; Tue, 14 Jun 2005 23:17:38 +0000 (GMT) (envelope-from ricardo_bsd@yahoo.com.br) Received: from web33102.mail.mud.yahoo.com (web33102.mail.mud.yahoo.com [68.142.206.83]) by mx1.FreeBSD.org (Postfix) with SMTP id B2D4C43D55 for ; Tue, 14 Jun 2005 23:17:37 +0000 (GMT) (envelope-from ricardo_bsd@yahoo.com.br) Received: (qmail 18673 invoked by uid 60001); 14 Jun 2005 23:17:37 -0000 Message-ID: <20050614231737.18671.qmail@web33102.mail.mud.yahoo.com> Received: from [201.1.106.26] by web33102.mail.mud.yahoo.com via HTTP; Tue, 14 Jun 2005 20:17:37 ART Date: Tue, 14 Jun 2005 20:17:37 -0300 (ART) From: "Ricardo A. Reis" To: current@freebsd.org, net@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Nat on last snapshot 6.0-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, 14 Jun 2005 23:17:38 -0000 Hi All, I`ve a strange problem on my desktop firewall, i test last netbsd-current and freebsd-current, last not nat with pf or ppp -nat or ipnat ;-( this ipnat.rules work in netbsd.. map tun0 192.168.0.0/24 -> 0/32 portmap tcp/udp 44000:49999 mssclamp 1440 map tun0 192.168.0.0/24 -> 0/32 mssclamp 1440 pf .... nat on $ext_if from $internal_net to any -> ($ext_if) rdr on $int_if proto tcp from any to any port 21 -> 127.0.0.1 port 8021 tcpdump in internal interface ..... 20:11:22.544615 IP 200.119.201.85.4662 > 192.168.0.2.3992: . ack 1 win 64240 20:11:24.119891 IP 192.168.0.2.3994 > 203.219.9.86.4662: S 2642123087:2642123087(0) win 65535 20:11:24.867689 IP 203.219.9.86.4662 > 192.168.0.2.3994: S 425571734:425571734(0) ack 2642123088 win 64240 20:11:24.867849 IP 192.168.0.2.3994 > 203.219.9.86.4662: . ack 1 win 65535 20:11:24.868044 IP 192.168.0.2.3994 > 203.219.9.86.4662: P 1:45(44) ack 1 win 65 pfctl -ss self tcp 192.168.0.2:3986 -> 201.1.106.26:53951 -> 82.6.184.50:4662 SYN_SENT:CLOSED self tcp 192.168.0.2:3994 -> 201.1.106.26:53854 -> 203.219.9.86:4662 FIN_WAIT_2:FIN_WAIT_2 self tcp 192.168.0.2:3982 -> 201.1.106.26:54863 -> 200.40.185.101:4662 CLOSING:CLOSED self tcp 192.168.0.2:3984 -> 201.1.106.26:57704 -> 172.180.84.194:4662 SYN_SENT:CLOSED self tcp 192.168.0.2:3988 -> 201.1.106.26:57664 -> 82.158.63.218:4662 SYN_SENT:CLOSED self tcp 192.168.0.2:3996 -> 201.1.106.26:62184 -> 85.137.17.234:4662 ESTABLISHED:ESTABLISHED self tcp 192.168.0.2:3990 -> 201.1.106.26:50582 -> 62.21.108.248:35165 SYN_SENT:CLOS On the 192.168.0.2 ping work, telnet on :80 work ... but firefox and emule not work!!! Sorry for english!! Thanks for advanced Ricardo A. Reis UNIFESP - SENAI System Admin __________________________________________________ Converse com seus amigos em tempo real com o Yahoo! Messenger http://br.download.yahoo.com/messenger/ From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 01:03: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 BC1B116A41C for ; Wed, 15 Jun 2005 01:03:36 +0000 (GMT) (envelope-from burpmaster@truffula.net) Received: from rwcrmhc12.comcast.net (rwcrmhc12.comcast.net [216.148.227.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id A036A43D1D for ; Wed, 15 Jun 2005 01:03:36 +0000 (GMT) (envelope-from burpmaster@truffula.net) Received: from [192.168.0.2] (c-67-169-200-31.hsd1.or.comcast.net[67.169.200.31]) by comcast.net (rwcrmhc12) with ESMTP id <2005061501033501400gh507e>; Wed, 15 Jun 2005 01:03:36 +0000 Message-ID: <42AF7E63.6090908@truffula.net> Date: Tue, 14 Jun 2005 18:03:31 -0700 From: Brian Rogers User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050401) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Disk cache causing swap usage 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, 15 Jun 2005 01:03:36 -0000 I have 1 GB of RAM and a 2 GB swap partition. Previously, I would almost never see swap used (or at least no more than 4k used) under normal use, but that appears to have changed recently. I am running FreeBSD 6.0-CURRENT #3: Tue Jun 14 14:25:20 PDT 2005 root@brian:/usr/obj/usr/src/sys/MYKERN My testcase for this problem is to run dd if=bigfile of=/dev/null and watch the free space drop. I expect that to happen, as the disk cache holds onto what has been read. But when free memory runs out, it starts paging out to the swap file, when it should have plenty of old cache to throw out first before resorting to the swap file. I'm pretty sure it didn't do this before, but I ran into the 20050609 issue in UPDATING when trying to run top on an old kernel to test it. This effect is also observed during normal use, and makes the system sluggish eventually. I found that setting vm.defer_swapspace_pageouts to 1 seems to prevent paging out, but I don't think it completely solves the problem, as during the dd test cursor movement still becomes erratic by the time free memory runs out. Is this a new bug in the kernel? Is anyone else seeing it? From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 02:11:05 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 8A0D216A41C for ; Wed, 15 Jun 2005 02:11:05 +0000 (GMT) (envelope-from mrl0lz@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4513743D53 for ; Wed, 15 Jun 2005 02:11:05 +0000 (GMT) (envelope-from mrl0lz@gmail.com) Received: by wproxy.gmail.com with SMTP id 69so1577492wra for ; Tue, 14 Jun 2005 19:11:04 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=fBG8ZbGgyG8zK2Ng4U7Vmngspr59/1NFszROWgzRw6SUQJ8HfVksaYk97DZuFlPBTEhBAYFgs6NjxUw+7oCbTEkH8vljZ19qVfgiIhRxYxJ6aXnj5p/foiabdrSaiLO+TcpR5WNIcIzwwYz2Nj90QgdVwM5x8WH56gXL2EE8A/s= Received: by 10.54.144.9 with SMTP id r9mr3590992wrd; Tue, 14 Jun 2005 19:11:04 -0700 (PDT) Received: by 10.54.98.6 with HTTP; Tue, 14 Jun 2005 19:11:04 -0700 (PDT) Message-ID: Date: Tue, 14 Jun 2005 19:11:04 -0700 From: Remington L To: questions@freebsd.org, current@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Xen status X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Remington L List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2005 02:11:05 -0000 Google search finds nothing I am interested in knowing the present state of Xen on FreeBSD. Is it=20 supported in 5.4 or just -CURRENT? Are there any setup guides avaliable? From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 02:24: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 2B8B816A41C for ; Wed, 15 Jun 2005 02:24:25 +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 F3BE243D49 for ; Wed, 15 Jun 2005 02:24:24 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id D301A72DDB; Tue, 14 Jun 2005 19:24:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id CD7A072DD4; Tue, 14 Jun 2005 19:24:24 -0700 (PDT) Date: Tue, 14 Jun 2005 19:24:24 -0700 (PDT) From: Doug White To: Ed Maste In-Reply-To: <20050613205052.GA91486@sandvine.com> Message-ID: <20050614191338.N24745@carver.gumbysoft.com> References: <20050613192308.GA87640@sandvine.com> <20050613130317.G2682@carver.gumbysoft.com> <20050613205052.GA91486@sandvine.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: savecore(8) increments /var/crash/bounds on each boot 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, 15 Jun 2005 02:24:25 -0000 On Mon, 13 Jun 2005, Ed Maste wrote: > On Mon, Jun 13, 2005 at 01:03:50PM -0700, Doug White wrote: > > > On Mon, 13 Jun 2005, Ed Maste wrote: > > > > > I notice that as of sbin/savecore/savecore.c 1.72 and in 5.4-RELEASE > > > savecore increments the number in /var/crash/bounds on each boot, > > > regardless of whether it rebooted due to panic or was a clean shutdown. > > > > > > Is this the desired behaviour or an unintentional side effect? > > > We've been monitoring the value in bounds to detect panics, which > > > of course doesn't work anymore. > > > > Its certainly not the historical behavior :-) > > > > Think you could submit a patch with the fix? > > The attached patch does the trick. In -vv mode the bounds used to > be included with the first/last dump header output -- I just replaced > it with -1. I don't see how this works. It should generate a bunch of use-uninitialized warning since bounds is used in a sprintf at line 376, in DoFile(): 376: sprintf(buf, "info.%d", bounds); plus additional sprintf's down the file, since the value of bounds is only set by that getbounds() call. The correct fix is to put a else goto done; just above the "newfile" label so it doesn't unconditionally rewrite the bounds file on every call. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 02:36: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 556B516A41C for ; Wed, 15 Jun 2005 02:36:02 +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 F2DDC43D1F for ; Wed, 15 Jun 2005 02:36:01 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5F2a1gf021019; Tue, 14 Jun 2005 19:36:01 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5F2a0NP021018; Tue, 14 Jun 2005 19:36:00 -0700 (PDT) (envelope-from obrien) Date: Tue, 14 Jun 2005 19:36:00 -0700 From: "David O'Brien" To: Maxim Konovalov Message-ID: <20050615023600.GA20721@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, Maxim Konovalov , Ed Maste References: <20050613192308.GA87640@sandvine.com> <20050614082039.GA2038@dragon.NUXI.org> <20050614224704.Y75797@mp2.macomnet.net> <20050614190854.GA12928@dragon.NUXI.org> <20050614235132.L76669@mp2.macomnet.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050614235132.L76669@mp2.macomnet.net> 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, Ed Maste Subject: Re: savecore(8) increments /var/crash/bounds on each boot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: Wed, 15 Jun 2005 02:36:02 -0000 On Wed, Jun 15, 2005 at 12:10:05AM +0400, Maxim Konovalov wrote: > On Tue, 14 Jun 2005, 12:08-0700, David O'Brien wrote: > > > On Tue, Jun 14, 2005 at 10:49:44PM +0400, Maxim Konovalov wrote: > > > On Tue, 14 Jun 2005, 01:20-0700, David O'Brien wrote: > > > > > > > On Mon, Jun 13, 2005 at 03:23:08PM -0400, Ed Maste wrote: > > > > > I notice that as of sbin/savecore/savecore.c 1.72 and in 5.4-RELEASE > > > > > savecore increments the number in /var/crash/bounds on each boot, > > > > > regardless of whether it rebooted due to panic or was a clean shutdown. > > > > > Is this the desired behaviour or an unintentional side effect? > > > > > > > > It is an unintentional side affect. If I wasn't constantly experiencing > > > > kernel landminds every time I sit down to do major FreeBSD, I would have > > > > gotten to this issue. > > > > > > I am going to ask re@ for permission to commit the fix if nobody beats > > > me. > > > > Are you sure its correct? Have you tested it with say bounds != 0 and a > > few core dumps in /var/crash? > > No problems so far: Do you understand the fix? How does lying in printheader() fix anything? Moving the call to getbounds() back to the original location is the "fix" but then it negates -vv. We shouldn't lie in printheader(). -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 02:48: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 8ECD316A41C for ; Wed, 15 Jun 2005 02:48:27 +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 690D143D48 for ; Wed, 15 Jun 2005 02:48:27 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 48B4072DDB; Tue, 14 Jun 2005 19:48:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 45CB272DD9; Tue, 14 Jun 2005 19:48:27 -0700 (PDT) Date: Tue, 14 Jun 2005 19:48:27 -0700 (PDT) From: Doug White To: Jun Kuriyama In-Reply-To: <7mpsupni5r.wl%kuriyama@imgsrc.co.jp> Message-ID: <20050614194742.U24745@carver.gumbysoft.com> References: <7mpsupni5r.wl%kuriyama@imgsrc.co.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Current Subject: Re: How to help debugging of lock-up 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, 15 Jun 2005 02:48:27 -0000 On Tue, 14 Jun 2005, Jun Kuriyama wrote: > > I'm using the current (minus recent ssouhlal@'s commit). > > This kernel usually locked up when daily backup begins (by invoked by > amanda server), but sometimes locked up in other random situations. > > When locked up, no ping response, but I can enter to debugger from > serial console. > > I'm not sure which process I should suspect. Is there something I can > provide to help debugging about this? The trace looks normal for something network- and disk-bound. Perhaps your NIC's overloaded or hung? Where is the amanda backup going -- back to the same system? > > Currently, compiled with INVARIANTS, INVARIANT_SUPPORT, WITNESS, > WITNESS_SKIPSPIN, DEBUG_VFS_LOCKS and debug.mpsafevfs="0". > > > ----- > KDB: enter: Break sequence on console > [thread pid 12 tid 100005 ] > Stopped at kdb_enter+0x2b: nop > db> ps > pid proc uid ppid pgrp flag stat wmesg wchan cmd > 2491 c186d400 91 2489 2483 0004000 [SLPQ piperd 0xc16cba80][SLP] sed > 2490 c1802e00 91 2489 2483 0004000 [SLPQ piperd 0xc183e000][SLP] restore > 2489 c1648a00 91 2487 2483 0004000 [SLPQ wait 0xc1648a00][SLP] sh > 2488 c1648800 91 2484 2483 0004000 [SLPQ biord 0xc3a27da8][SLP] dump > 2487 c15e4a00 91 2484 2483 0000000 [SLPQ piperd 0xc16f1d80][SLP] sendbackup > 2486 c1871c00 91 2484 2483 0004000 [SLPQ piperd 0xc16ca000][SLP] gzip > 2484 c1b12000 91 1 2483 0004000 [SLPQ piperd 0xc16f1c00][SLP] sendbackup > 2454 c1802a00 91 2451 2440 0000000 [SLPQ pause 0xc1802a34][SLP] dump > 2453 c1b11c00 91 2451 2440 0000000 [SLPQ pipdwt 0xc16cbc00][SLP] dump > 2452 c1871400 91 2451 2440 0000000 [SLPQ pause 0xc1871434][SLP] dump > 2451 c1b11000 91 2445 2440 0000000 [SLPQ sbwait 0xc186b9b0][SLP] dump > 2445 c1b12200 91 2441 2440 0004000 [SLPQ wait 0xc1b12200][SLP] dump > 2444 c15e4200 91 2441 2440 0000000 [SLPQ pipewr 0xc16f1900][SLP] sendbackup > 2443 c1645e00 91 2441 2440 0004000 [SLPQ sbwait 0xc1a7e638][SLP] gzip > 2441 c1b11400 91 1 2440 0004000 [SLPQ piperd 0xc16cb600][SLP] sendbackup > 1033 c186de00 1021 1032 1033 0004002 [SLPQ ttyin 0xc15b9410][SLP] zsh > 1032 c186da00 1021 1030 1030 0000100 [SLPQ select 0xc075cda4][SLP] sshd > 1030 c1800200 0 583 1030 0004100 [SLPQ sbwait 0xc186c480][SLP] sshd > 717 c1648e00 0 1 717 0004002 [SLPQ ttyin 0xc1541010][SLP] getty > 716 c1800a00 0 1 716 0004002 [SLPQ ttyin 0xc153cc10][SLP] getty > 715 c1871a00 0 1 715 0004002 [SLPQ ttyin 0xc155a810][SLP] getty > 714 c1800600 0 1 714 0004002 [SLPQ ttyin 0xc153b010][SLP] getty > 700 c1800000 0 1 700 0000000 [SLPQ select 0xc075cda4][SLP] inetd > 679 c1871600 0 1 679 0000000 [SLPQ select 0xc075cda4][SLP] moused > 656 c1871e00 0 1 655 0000000 [SLPQ select 0xc075cda4][SLP] snmpd > 637 c1800400 0 1 637 0000000 [SLPQ select 0xc075cda4][SLP] pptpd > 607 c1645800 0 1 607 0000000 [SLPQ nanslp 0xc070faac][SLP] cron > 595 c1645600 25 1 595 0000100 [SLPQ pause 0xc1645634][SLP] sendmail > 589 c186d200 0 1 589 0000100 [SLPQ select 0xc075cda4][SLP] sendmail > 583 c15e4600 0 1 583 0000100 [SLPQ select 0xc075cda4][SLP] sshd > 565 c186d000 0 1 565 0000000 [SLPQ select 0xc075cda4][SLP] ntpd > 511 c1648000 0 1 511 0000000 [SLPQ select 0xc075cda4][SLP] usbd > 492 c15e4400 0 490 490 0000100 [SLPQ nfslockd 0xc07654c8][SLP] rpc.lockd > 490 c15e4800 0 1 490 0000000 [SLPQ select 0xc075cda4][SLP] rpc.lockd > 485 c15e5c00 0 1 485 0000000 [SLPQ select 0xc075cda4][SLP] rpc.statd > 479 c1648600 0 478 478 0000000 [SLPQ - 0xc15cb800][SLP] nfsd > 478 c1645a00 0 1 478 0000000 [SLPQ select 0xc075cda4][SLP] nfsd > 476 c1645400 0 1 476 0000000 [SLPQ select 0xc075cda4][SLP] mountd > 398 c1648400 0 1 398 0000000 [SLPQ select 0xc075cda4][SLP] ypbind > 395 c1645200 0 1 395 0000000 [SLPQ select 0xc075cda4][SLP] rpcbind > 362 c1648200 0 1 362 0000000 [SLPQ biord 0xc3a14508][SLP] syslogd > 325 c1645000 0 1 325 0000000 [SLPQ select 0xc075cda4][SLP] devd > 218 c15e4000 0 1 218 0000000 [SLPQ pause 0xc15e4034][SLP] adjkerntz > 62 c15e4c00 0 0 0 0000204 [SLPQ - 0xc83cfd04][SLP] schedcpu > 61 c15e4e00 0 0 0 0000204 [SLPQ - 0xc076526c][SLP] nfsiod 3 > 60 c15e5000 0 0 0 0000204 [SLPQ - 0xc0765268][SLP] nfsiod 2 > 59 c15e5200 0 0 0 0000204 [SLPQ - 0xc0765264][SLP] nfsiod 1 > 58 c15e5400 0 0 0 0000204 [SLPQ - 0xc0765260][SLP] nfsiod 0 > 57 c15e5600 0 0 0 0000204 [SLPQ syncer 0xc070f81c][SLP] syncer > 56 c15e5800 0 0 0 0000204 [SLPQ vlruwt 0xc15e5800][SLP] vnlru > 55 c133e400 0 0 0 0000204 [SLPQ psleep 0xc075d2ec][SLP] bufdaemon > 54 c133e600 0 0 0 000020c [SLPQ pgzero 0xc076b704][SLP] pagezero > 53 c133e800 0 0 0 0000204 [SLPQ psleep 0xc076b254][SLP] vmdaemon > 52 c133ea00 0 0 0 0000204 [SLPQ psleep 0xc076b210][SLP] pagedaemon > 51 c133ec00 0 0 0 0000204 [SLPQ m:w2 0xc15b5d00][SLP] g_mirror data > 50 c133ee00 0 0 0 0000204 [IWAIT] swi0: sio > 49 c13ad000 0 0 0 0000204 [SLPQ - 0xc14c5a3c][SLP] fdc0 > 48 c13ad200 0 0 0 0000204 [SLPQ tzpoll 0xc0882694][SLP] acpi_thermal > 47 c13ad400 0 0 0 0000204 [SLPQ usbevt 0xc1525210][SLP] usb2 > db> trace 362 > Tracing pid 362 tid 100081 td 0xc15e7c00 > sched_switch(c15e7c00,0,1) at sched_switch+0x177 > mi_switch(1,0) at mi_switch+0x270 > sleepq_switch(c3a14508,cc6b99dc,c050da15,c3a14508,0) at sleepq_switch+0xe0 > sleepq_wait(c3a14508,0,0,c06aec19,e52) at sleepq_wait+0x30 > msleep(c3a14508,c075d3c0,4c,c06af341,0) at msleep+0x311 > bwait(c3a14508,4c,c06af341) at bwait+0x47 > bufwait(c3a14508,1,0,0,c16b2000) at bufwait+0x1a > breadn(c1adedd0,0,0,800,0) at breadn+0x266 > bread(c1adedd0,0,0,800,0) at bread+0x20 > ffs_balloc_ufs2(c1adedd0,4f,0,57,c12f5a00) at ffs_balloc_ufs2+0xcbf > ffs_write(cc6b9c40,c1a4a510,c1adedd0,cc6b9c8c,c0565fd6) at ffs_write+0x2b4 > VOP_WRITE_APV(c06f7600,cc6b9c40) at VOP_WRITE_APV+0x9b > vn_write(c1a4a510,c1bac100,c12f5a00,0,c15e7c00) at vn_write+0x1ea > kern_writev(c15e7c00,8,c1bac100,c1bac100,0) at kern_writev+0x8e > writev(c15e7c00,cc6b9d04,3,39,292) at writev+0x30 > syscall(3b,3b,3b,8054cde,bfbfde70) at syscall+0x22f > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (121, FreeBSD ELF32, writev), eip = 0x280c9563, esp = 0xbfbfd8ac, ebp = 0xbfbfde98 --- > db> trace 2451 > Tracing pid 2451 tid 100120 td 0xc1803600 > sched_switch(c1803600,0,1) at sched_switch+0x177 > mi_switch(1,0) at mi_switch+0x270 > sleepq_switch(c186b9b0,0,ccb6dbb4,c050da06,c186b9b0) at sleepq_switch+0xe0 > sleepq_wait_sig(c186b9b0,0,100,c06adec5,3f1) at sleepq_wait_sig+0xc > msleep(c186b9b0,c186b97c,158,c06ae15c,0) at msleep+0x302 > sbwait(c186b964,c070f180,2,4,0) at sbwait+0x4b > soreceive(c186b914,0,ccb6dc78,0,0) at soreceive+0x2da > soo_read(c1a4a318,ccb6dc78,c1b01380,0,c1803600) at soo_read+0x41 > dofileread(c1803600,c1a4a318,12,bfbee028,4) at dofileread+0xad > read(c1803600,ccb6dd04,3,449,292) at read+0x3b > syscall(3b,3b,bfbe003b,12,bfbee028) at syscall+0x22f > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (3, FreeBSD ELF32, read), eip = 0x280c1e83, esp = 0xbfbedfdc, ebp = 0xbfbee008 --- > > > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 02:51: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 3792D16A41C for ; Wed, 15 Jun 2005 02:51: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 1DA2C43D49 for ; Wed, 15 Jun 2005 02:51:48 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 0F79C72DDB; Tue, 14 Jun 2005 19:51:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 0D6C372DD9; Tue, 14 Jun 2005 19:51:48 -0700 (PDT) Date: Tue, 14 Jun 2005 19:51:48 -0700 (PDT) From: Doug White To: Jeremie Le Hen In-Reply-To: <20050614143403.GL30017@obiwan.tataz.chchile.org> Message-ID: <20050614195053.F24745@carver.gumbysoft.com> References: <20050614143403.GL30017@obiwan.tataz.chchile.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@FreeBSD.org Subject: Re: panic while mkdir(2) in msdosfs (deget()) 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, 15 Jun 2005 02:51:48 -0000 On Tue, 14 Jun 2005, Jeremie Le Hen wrote: > Hi, > > I got a panic on friday while I was uploading files through FTP at a > high rate (100Mb/s). Given this panic occured while doing an mkdir(2), > you understand that the msdosfs partition is where the FTP daemon > was writing. > > The system is > %%% > jarjarbinks:tataz$ uname -a > FreeBSD jarjarbinks.tataz.chchile.org 6.0-CURRENT FreeBSD 6.0-CURRENT #149: Thu Jun 9 00:25:52 CEST 2005 root@jarjarbinks.tataz.chchile.org:/usr/src/sys/i386/compile/JARJARBINKS i386 > %%% > > Here is the stack trace: > %%% > #22 0xc055f075 in panic (fmt=0xc0729ff0 "wrong dirclust") > at ../../../kern/kern_shutdown.c:537 > #23 0xc050e207 in deget (pmp=0xc2914900, dirclust=366469, diroffset=0, > depp=0xe50ecae8) at ../../../fs/msdosfs/msdosfs_denode.c:142 This is in a KASSERT so you must have INVARIANTS compiled in. What is the value of dirclust and (*depp)->de_dirclust in this frame? > #24 0xc05122c1 in createde (dep=0xe50ecafc, ddep=0xc2b30400, depp=0xe50ecae8, > cnp=0xe50ecc18) at ../../../fs/msdosfs/msdosfs_lookup.c:673 > #25 0xc05170d0 in msdosfs_mkdir (ap=0xe50ecbb0) > at ../../../fs/msdosfs/msdosfs_vnops.c:1375 > #26 0xc07017ac in VOP_MKDIR_APV (vop=0x0, a=0xe50ecbb0) at vnode_if.c:1248 > #27 0xc05ce054 in kern_mkdir (td=0xc2575190, > path=0x8060360
, segflg=UIO_USERSPACE, > mode=511) at vnode_if.h:653 > #28 0xc05cdd19 in mkdir (td=0x0, uap=0x0) at ../../../kern/vfs_syscalls.c:3321 > #29 0xc06e6540 in syscall (frame= > {tf_fs = -1078001605, tf_es = -452067269, tf_ds = 59, tf_edi = 203, tf_esi = 134611360, tf_ebp = -1077943752, tf_isp = -452014748, tf_ebx = 134611808, tf_edx = 0, tf_ecx = 134684744, tf_eax = 136, tf_trapno = 0, tf_err = 2, tf_eip = 672334223, tf_cs = 51, tf_eflags = 582, tf_esp = -1077943780, tf_ss = 59}) > at ../../../i386/i386/trap.c:976 > #30 0xc06d219f in Xint0x80_syscall () at ../../../i386/i386/exception.s:200 > %%% > > I checked the source code, but my skills are not as high as I'd like and > I wasn't able to understand where this panic has its source. All I can > see is that it has good chances to be related to phk's vfs_hash updates. > > A dump is available, if needed. > > Regards, > -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 02: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 0190416A41C for ; Wed, 15 Jun 2005 02:53:34 +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 E02FD43D49 for ; Wed, 15 Jun 2005 02:53:33 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id BFBCB72DDB; Tue, 14 Jun 2005 19:53:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id BE1F672DD9; Tue, 14 Jun 2005 19:53:33 -0700 (PDT) Date: Tue, 14 Jun 2005 19:53:33 -0700 (PDT) From: Doug White To: Brian Rogers In-Reply-To: <42AF7E63.6090908@truffula.net> Message-ID: <20050614195308.A24745@carver.gumbysoft.com> References: <42AF7E63.6090908@truffula.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: Disk cache causing swap usage 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, 15 Jun 2005 02:53:34 -0000 On Tue, 14 Jun 2005, Brian Rogers wrote: > I have 1 GB of RAM and a 2 GB swap partition. Previously, I would > almost never see swap used (or at least no more than 4k used) under > normal use, but that appears to have changed recently. > > I am running > FreeBSD 6.0-CURRENT #3: Tue Jun 14 14:25:20 PDT 2005 > root@brian:/usr/obj/usr/src/sys/MYKERN > > My testcase for this problem is to run > dd if=bigfile of=/dev/null > and watch the free space drop. I expect that to happen, as the disk > cache holds onto what has been read. But when free memory runs out, it > starts paging out to the swap file, when it should have plenty of old > cache to throw out first before resorting to the swap file. I'm pretty > sure it didn't do this before, but I ran into the 20050609 issue in > UPDATING when trying to run top on an old kernel to test it. This is a known bug in the bufcache work. phk is aware but an extra prod wouldn't hurt :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 03:23: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 5A04316A41C for ; Wed, 15 Jun 2005 03:23:35 +0000 (GMT) (envelope-from tmclaugh@sdf.lonestar.org) Received: from straycat.dhs.org (c-24-60-174-16.hsd1.ma.comcast.net [24.60.174.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 179AF43D48 for ; Wed, 15 Jun 2005 03:23:34 +0000 (GMT) (envelope-from tmclaugh@sdf.lonestar.org) Received: from compass.straycat.dhs.org (compass.straycat.dhs.org [192.168.1.48]) by straycat.dhs.org (8.13.0/8.13.0) with ESMTP id j5F3Pjvd026649 for ; Tue, 14 Jun 2005 23:25:45 -0400 (EDT) From: Tom McLaughlin To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 Date: Tue, 14 Jun 2005 23:23:35 -0400 Message-Id: <1118805815.77390.40.camel@compass.straycat.dhs.org> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Subject: vr0 and kernel 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: Wed, 15 Jun 2005 03:23:35 -0000 Hi, I'm running -CURRENT on an i386 box where it runs marcus@'s tinderbox. (Ports building similar to pointyhat.) Since my last update on June 4 I can't get through an entire build of all ports without a kernel panic. Below is the backtrace from the latest crash. It only happens while building ports in the tinderbox and it happens fairly reliably. I think the NFS usage between this box and the OpenBSD 3.6 NFS server is bringing this bug out. Please let me know if I can provide anything else. Thanks. Tom FreeBSD current.straycat.dhs.org 6.0-CURRENT FreeBSD 6.0-CURRENT #0: Sat Jun 4 21:31:32 EDT 2005 root@current.straycat.dhs.org:/usr/obj/usr/src/sys/GENERIC i386 (kgdb) bt full #0 doadump () at pcpu.h:165 No locals. #1 0xc0631c40 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:397 first_buf_printf = 1 #2 0xc0631f55 in panic ( fmt=0xc086ff1f "Duplicate free of item %p from zone %p(%s)\n") at /usr/src/sys/kern/kern_shutdown.c:553 td = (struct thread *) 0xc19bb180 bootopt = 260 newpanic = 1 ap = 0xd44b1aa4 "" buf = "Duplicate free of item 0xc2412800 from zone 0xc10429a0(Mbuf)\n", '\0' #3 0xc0782fbc in uma_dbg_free (zone=0xc10429a0, slab=0xc2412fa8, item=0xc2412800) at /usr/src/sys/vm/uma_dbg.c:301 keg = 0xc199b3c0 slabref = 0x0 freei = 8 #4 0xc0781daa in uma_zfree_arg (zone=0xc10429a0, item=0xc2412800, udata=0x0) at /usr/src/sys/vm/uma_core.c:2257 keg = 0xc199b3c0 cache = 0x5ea bucket = 0xc2414100 bflags = 0 cpu = 0 #5 0xc0667c56 in m_freem (mb=0x0) at uma.h:304 No locals. #6 0xc0669462 in m_defrag (m0=0xc2412800, how=1) at /usr/src/sys/kern/uipc_mbuf.c:1237 m_new = (struct mbuf *) 0x0 m_final = (struct mbuf *) 0xc3380300 progress = 1514 length = 1514 __func__ = "m_defrag" #7 0xc074a141 in vr_encap (sc=0xc1b0d000, c=0xc1b0d6a0, m_head=0xc2412800) at /usr/src/sys/pci/if_vr.c:1344 f = (struct vr_desc *) 0xc1b0d000 m = (struct mbuf *) 0x0 #8 0xc074a43a in vr_start_locked (ifp=0xc1b0d000) at /usr/src/sys/pci/if_vr.c:1404 sc = (struct vr_softc *) 0xc1b0d000 m_head = (struct mbuf *) 0xc2412800 cur_tx = (struct vr_chain *) 0xc1b0d6a0 __func__ = "vr_start_locked" #9 0xc074a240 in vr_start (ifp=0xc1b0d000) at /usr/src/sys/pci/if_vr.c:1383 No locals. #10 0xc069765b in if_start (ifp=0xc1b0d000) at /usr/src/sys/net/if.c:2044 No locals. #11 0xc0698819 in ether_output_frame (ifp=0xc1b0d000, m=0xc2412800) at /usr/src/sys/net/if_ethersubr.c:388 len = 1514 mflags = -30718 rule = (struct ip_fw *) 0x0 error = 0 #12 0xc0698638 in ether_output (ifp=0xc1b0d000, m=0xc2412800, dst=0xc24b2900, rt0=0x0) at /usr/src/sys/net/if_ethersubr.c:341 type = 8 error = -1035917262 hdrcmplt = 0 esrc = "ï¿¿ ï¿¿ï¿¿\001" edst = "\000\t[\vxï¿¿" eh = (struct ether_header *) 0xc2412832 loop_copy = 0 __func__ = "ether_output" #13 0xc06b8e9a in in_arpinput (m=0xc3bc1b00) at /usr/src/sys/netinet/if_ether.c:732 ah = (struct arphdr *) 0xc3bc1b50 ifp = (struct ifnet *) 0xc1b0d000 th = (struct iso88025_header *) 0xc096b3c0 trld = (struct iso88025_sockaddr_dl_data *) 0xc0653dae la = (struct llinfo_arp *) 0xc2bf4100 rt = (struct rtentry *) 0xc1cb2084 ifa = (struct ifaddr *) 0x0 ia = (struct in_ifaddr *) 0x0 sdl = (struct sockaddr_dl *) 0xc24b2910 sa = {sa_len = 132 '\204', sa_family = 160 'ï¿¿', sa_data = "bï¿¿\224ï¿¿\226ï¿¿\001\000\000\000ï¿¿M\205ï¿¿"} isaddr = {s_addr = 33663168} itaddr = {s_addr = 838969536} myaddr = {s_addr = 838969536} enaddr = (u_int8_t *) 0xc19adcab "" op = 2 rif_len = -1064153312 req_len = 0 #14 0xc06b88e6 in arpintr (m=0xc3bc1b00) at /usr/src/sys/netinet/if_ether.c:505 ar = (struct arphdr *) 0x0 #15 0xc069fd12 in netisr_processqueue (ni=0xc096c6b8) at /usr/src/sys/net/netisr.c:235 m = (struct mbuf *) 0xc3bc1b00 #16 0xc069fef6 in swi_net (dummy=0x0) at /usr/src/sys/net/netisr.c:348 ni = (struct netisr *) 0xc096c6b8 bits = 0 i = 0 #17 0xc061fd3c in ithread_loop (arg=0xc19fa580) at /usr/src/sys/kern/kern_intr.c:546 ithd = (struct ithd *) 0xc19fa580 ih = (struct intrhand *) 0xc1a18000 td = (struct thread *) 0xc19bb180 p = (struct proc *) 0xc1a01c00 count = 0 warned = 0 storming = 0 __func__ = "ithread_loop" #18 0xc061f16c in fork_exit (callout=0xc061fc1c , arg=0xc19fa580, frame=0xd44b1d38) at /usr/src/sys/kern/kern_fork.c:789 p = (struct proc *) 0xc1a01c00 td = (struct thread *) 0x0 #19 0xc07d84bc in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 No locals. -- BSD# Project - Mono on FreeBSD http://www.mono-project.com/Mono:FreeBSD From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 03:28:57 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 87E2F16A41C; Wed, 15 Jun 2005 03:28:57 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from mail.ijs.si (mail.ijs.si [193.2.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E81443D1D; Wed, 15 Jun 2005 03:28:57 +0000 (GMT) (envelope-from dejan.lesjak@ijs.si) Received: from localhost (mail.ijs.si [193.2.4.66]) by patsy.ijs.si (Postfix) with ESMTP id 76C1617B845; Wed, 15 Jun 2005 05:28:56 +0200 (CEST) Received: from patsy.ijs.si ([127.0.0.1]) by localhost (patsy.ijs.si [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 39595-02-8; Wed, 15 Jun 2005 05:28:54 +0200 (CEST) Received: from idefix.ijs.si (idefix.ijs.si [193.2.4.33]) by patsy.ijs.si (Postfix) with ESMTP id 201F417B836; Wed, 15 Jun 2005 05:28:54 +0200 (CEST) Received: from localhost.ijs.si (localhost.ijs.si [127.0.0.1]) by idefix.ijs.si (Postfix) with ESMTP id 172835C0A; Wed, 15 Jun 2005 05:28:54 +0200 (CEST) From: Dejan Lesjak To: ports@FreeBSD.org, x11@FreeBSD.org, current@FreeBSD.org Date: Wed, 15 Jun 2005 05:28:53 +0200 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506150528.53747.dejan.lesjak@ijs.si> X-Virus-Scanned: amavisd-new at ijs.si Cc: Subject: HEADSUP: Changes to X PREFIX mtree spec (BSD.x11-4.dist) 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, 15 Jun 2005 03:28:57 -0000 Hello, The mtree specification file (etc/mtree/BSD.x11-4.dist) got a bit cleaned up. A lot of directories that were previously there, but were only used by a few ports (mostly parts of either of X11 distribution) got moved to respective ports plists. Changes to ports were already tested, maintainers have been notified (If I somehow missed someone, it was completely unintentional and I apologise) so I don't expect any problems from this. More about this changes is here: http://lists.freebsd.org/pipermail/freebsd-x11/2005-February/001619.html One of notable changes is move of share/pixmaps to mtree, so if you have a new port in works that installs files there under X PREFIX, you don't need to put it in plist as mtree will handle this now. Note that for X_WINDOW_SYSTEM=xorg another mtree is used for now, though plan is to revert to using etc/mtree/BSD.x11-4.dist again at the next upgrade of Xorg ports. Dejan From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 03:37: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 4F47416A41C for ; Wed, 15 Jun 2005 03:37:51 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id C20DC43D53 for ; Wed, 15 Jun 2005 03:37:50 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Jun 2005 23:37:48 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id 7871913640; Tue, 14 Jun 2005 23:37:48 -0400 (EDT) Date: Tue, 14 Jun 2005 23:37:48 -0400 From: Ed Maste To: freebsd-current@freebsd.org, Maxim Konovalov Message-ID: <20050615033748.GA84053@sandvine.com> References: <20050613192308.GA87640@sandvine.com> <20050614082039.GA2038@dragon.NUXI.org> <20050614224704.Y75797@mp2.macomnet.net> <20050614190854.GA12928@dragon.NUXI.org> <20050614235132.L76669@mp2.macomnet.net> <20050615023600.GA20721@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050615023600.GA20721@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 15 Jun 2005 03:37:48.0643 (UTC) FILETIME=[99CFEB30:01C5715B] Cc: Subject: Re: savecore(8) increments /var/crash/bounds on each boot 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, 15 Jun 2005 03:37:51 -0000 On Tue, Jun 14, 2005 at 07:36:00PM -0700, David O'Brien wrote: > Do you understand the fix? How does lying in printheader() fix anything? > Moving the call to getbounds() back to the original location is the "fix" > but then it negates -vv. We shouldn't lie in printheader(). The problem is of course that getbounds() not only gets the count from the bounds file but also increments it. The decision to write a core hasn't been made at the time printheader is called for -vv. Thus the reported bounds might not correspond to a core. The newly added dump status is also meaningless in the -vv case, since the status may still be determined after the -vv printheader. How about just not showing the bounds for the -vv case? -- Ed Maste, Sandvine Incorporated From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 03:49: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 18FC716A41C for ; Wed, 15 Jun 2005 03:49:42 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id B9D9843D49 for ; Wed, 15 Jun 2005 03:49:41 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 14 Jun 2005 23:49:40 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id CA9EE13614; Tue, 14 Jun 2005 23:49:40 -0400 (EDT) Date: Tue, 14 Jun 2005 23:49:40 -0400 From: Ed Maste To: Doug White Message-ID: <20050615034940.GB84053@sandvine.com> References: <20050613192308.GA87640@sandvine.com> <20050613130317.G2682@carver.gumbysoft.com> <20050613205052.GA91486@sandvine.com> <20050614191338.N24745@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050614191338.N24745@carver.gumbysoft.com> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 15 Jun 2005 03:49:41.0007 (UTC) FILETIME=[426A09F0:01C5715D] Cc: freebsd-current@freebsd.org Subject: Re: savecore(8) increments /var/crash/bounds on each boot 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, 15 Jun 2005 03:49:42 -0000 On Tue, Jun 14, 2005 at 07:24:24PM -0700, Doug White wrote: > On Mon, 13 Jun 2005, Ed Maste wrote: > > > On Mon, Jun 13, 2005 at 01:03:50PM -0700, Doug White wrote: > > > > > On Mon, 13 Jun 2005, Ed Maste wrote: > > > > > > > I notice that as of sbin/savecore/savecore.c 1.72 and in 5.4-RELEASE > > > > savecore increments the number in /var/crash/bounds on each boot, > > > > regardless of whether it rebooted due to panic or was a clean shutdown. > > > > > > > > Is this the desired behaviour or an unintentional side effect? > > > > We've been monitoring the value in bounds to detect panics, which > > > > of course doesn't work anymore. > > > > > > Its certainly not the historical behavior :-) > > > > > > Think you could submit a patch with the fix? > > > > The attached patch does the trick. In -vv mode the bounds used to > > be included with the first/last dump header output -- I just replaced > > it with -1. > > I don't see how this works. It should generate a bunch of > use-uninitialized warning since bounds is used in a sprintf at line 376, > in DoFile(): > > 376: sprintf(buf, "info.%d", bounds); The patch I posted puts the getbounds() call back in the original location, which is just before this sprintf -- no uninitialized use. > plus additional sprintf's down the file, since the value of bounds is only > set by that getbounds() call. The correct fix is to put a > > else > goto done; I don't see how that helps -- if bounds already contains a valid number (the normal case) it will then skip over writing the new (incremented) value back to the bounds file. Won't all cores get written to the same file then? -- Ed Maste, Sandvine Incorporated From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 05:18: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 6B74116A41C for ; Wed, 15 Jun 2005 05:18:42 +0000 (GMT) (envelope-from dikshie@ppk.itb.ac.id) Received: from mx-itb.geoph.ITB.ac.id (mx7.itb.ac.id [167.205.30.13]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1910F43D1F for ; Wed, 15 Jun 2005 05:18:33 +0000 (GMT) (envelope-from dikshie@ppk.itb.ac.id) Received: from antivirus.itb.ac.id (antivirus.ITB.ac.id [167.205.108.137]) by mx-itb.geoph.ITB.ac.id (Postfix) with SMTP id B69C920B41 for ; Wed, 15 Jun 2005 12:18:10 +0700 (WIT) Received: from ipv6.ppk.itb.ac.id (ipv6.ppk.itb.ac.id [167.205.30.228]) by mx-itb.geoph.ITB.ac.id (Postfix) with ESMTP id 67A1720B18 for ; Wed, 15 Jun 2005 12:18:08 +0700 (WIT) Received: by ipv6.ppk.itb.ac.id (Postfix, from userid 1001) id 3E351114D4; Wed, 15 Jun 2005 12:18:07 +0700 (WIT) Date: Wed, 15 Jun 2005 12:18:07 +0700 From: Dikshie To: Kris Kennaway Message-ID: <20050615051807.GA5076@ppk.itb.ac.id> References: <20050614063148.GA22683@ppk.itb.ac.id> <20050614182127.GA22085@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050614182127.GA22085@xor.obsecurity.org> User-Agent: Mutt/1.4.2.1i X-Operating-System: (FreeBSD 5.4-STABLE i386) X-Uptime: 12:16PM up 2 days, 18:13, 1 user, load averages: 0.05, 0.05, 0.01 X-Organization: Pusat Penelitian Kelautan (PPK) X-Location: Labtek VI Building, Institute of Technology, Bandung, Indonesia X-Web-Site: http://ipv6.ppk.itb.ac.id/~dikshie X-Yahoo-ID: dikshie X-GnuPG-Key: http://ipv6.ppk.itb.ac.id/gpg/ X-FingerPrint: 19AC 2592 1394 6C96 BABB 9060 50B8 D244 88E3 B55D Cc: freebsd-current@freebsd.org Subject: ***SPAM Level 2*** Re: doadump () at pcpu.h:165 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, 15 Jun 2005 05:18:42 -0000 Kris Kennaway (kris@obsecurity.org) wrote: > > cp=0xc1af2056 "\005\nwF\212|wF\217\0017\0010\0012\0010\0010\0010\0011\0010\0013\0010\0010\0010\0010\0013\001d\0010\00 > > 11\0010\0010\0012\003ip6\004arpa", > > optlen=0) at /usr/src/sys/netinet/tcp_sack.c:478 > > Here is the real panic, not the frame #0 as in your subject. > > I've seen this panic also and have reported it to ps and mohan. thanks ! I've been disable sack via sysctl it seems solve the problem. regards, -dikshie- From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 05:47: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 0343216A41C for ; Wed, 15 Jun 2005 05:47:28 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from smtp-1.dlr.de (smtp-1.dlr.de [195.37.61.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 894F643D48 for ; Wed, 15 Jun 2005 05:47:26 +0000 (GMT) (envelope-from Hartmut.Brandt@dlr.de) Received: from beagle.kn.op.dlr.de ([129.247.173.6]) by smtp-1.dlr.de over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Wed, 15 Jun 2005 07:47:25 +0200 Date: Wed, 15 Jun 2005 05:47:26 +0000 (UTC) From: Harti Brandt X-X-Sender: brandt_h@beagle.kn.op.dlr.de To: freebsd-current@freebsd.org In-Reply-To: <20050614185923.GA12375@dragon.NUXI.org> Message-ID: <20050615054209.L29741@beagle.kn.op.dlr.de> References: <200504262010.49509@harrymail> <20050429200029.GC232@cirb503493.alcatel.com.au> <200506141824.17451@harrymail> <20050614185923.GA12375@dragon.NUXI.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-OriginalArrivalTime: 15 Jun 2005 05:47:25.0350 (UTC) FILETIME=[B5173C60:01C5716D] Cc: Emanuel Strobl , Lyndon Nerenberg Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Harti Brandt List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2005 05:47:28 -0000 On Tue, 14 Jun 2005, David O'Brien wrote: DO>On Tue, Jun 14, 2005 at 06:24:07PM +0200, Emanuel Strobl wrote: DO>> today I read a news article (http://www.heise.de/newsticker/meldung/60600) DO>> about OpenSolaris beeing released, but is there also the groff alternative DO>> included? DO>> I'd love to see a lean replacment for our current gnu version. DO> DO>Before everyone gets all happy thinking we can incorporate all kinds of DO>bits from Open Solaris - one should read the license agrement first. DO> DO> COMMON DEVELOPMENT AND DISTRIBUTION LICENSE Version 1.0 DO> .. DO> 3.1. Availability of Source Code. DO> Any Covered Software that You distribute or otherwise make available DO> in Executable form must also be made available in Source Code form DO> and that Source Code form must be distributed only under the terms of DO> this License. DO> DO>this puts the CDDL1.0 in the same boat as GPL'ed code from a BSD stand DO>point. I think that's not entirely correct. If you read the other statements you'll find that you can put together CDDL covered files with files covered by any other license (given that the other license allows this) and distributed that. In this case you don't need to distribute the pieces that are covered by the other license. Let's say you take a CDDL-ed program, add a function call in some of the files and put that function into a file with a closed license. You need to distribute only the file with the function call added. You don't need to distribute the new file with that function. Of course that new file will not be CDDL covered. harti From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 06:10: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 5558B16A41C for ; Wed, 15 Jun 2005 06:10:19 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2098143D1F for ; Wed, 15 Jun 2005 06:10:19 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5F6ABjI012422; Tue, 14 Jun 2005 23:10:11 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5F6A9JE012420; Tue, 14 Jun 2005 23:10:09 -0700 Date: Tue, 14 Jun 2005 23:10:09 -0700 From: Brooks Davis To: Vladimir Grebenschikov Message-ID: <20050615061009.GA11914@odin.ac.hmc.edu> References: <20050607034620.GA32718@odin.ac.hmc.edu> <1118728905.939.5.camel@localhost> <20050614162338.GA20371@odin.ac.hmc.edu> <20050614205537.D62878@gabby.gsicomp.on.ca> <1118806968.1003.9.camel@localhost> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <1118806968.1003.9.camel@localhost> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org, Matthew Emmerton Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 15 Jun 2005 06:10:19 -0000 --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 15, 2005 at 07:42:48AM +0400, Vladimir Grebenschikov wrote: > ? ??, 14/06/2005 ? 20:57 -0400, Matthew Emmerton ?????: > > On Tue, 14 Jun 2005, Brooks Davis wrote: > >=20 > > > On Tue, Jun 14, 2005 at 10:01:45AM +0400, Vladimir Grebenschikov wrot= e: > > >> ? ??, 06/06/2005 ? 20:46 -0700, Brooks Davis ?????: > > >>> I'm about to start importing the OpenBSD dhclient and required > > >>> support in /etc. I will unhook dhclient from the build while I wor= k so > > >>> there shouldn't be much breakage for most people > > >> > > >> I have strange behavior of new dhclient + devd: > > >> > > >> just after boot (with ethernet plugged) I have no devd events about > > >> state of media and have interface down, but after first ifconfig (ev= en > > >> without parameters, even executed by any user) "link state chages to= UP" > > >> event appears and devd starts dhclient on interface. > > >> > > >> I do not think that it is desired behavior. > > >> > > >> my rc.conf, related to this: > > >> > > >> ifconfig_fxp0=3D"dhcp" > > >> network_interfaces=3D"lo0" > > >> devd_enable=3D"YES" > > >> > > >> Probably I need to comment network_interfaces line, but anyway, now = it > > >> works strange. > >=20 > > Shouldn't you have network_interfaces=3D"lo0 fxp0" in order for the rc= =20 > > scripts to run the appropriate ifconfig or dhclient command for each=20 > > interface? >=20 > Probably yes (it works), but why first /sbin/ifconfig, issued by uid!=3D0 > triggers dhclient ? >=20 > I think behavior should be consistent, either rc.d/netif relay only on > devd events and does not depends on network_interfaces=3D or rc.d/netif > should relay on network_interfaces=3D and ignore not mentioned interfaces. >=20 > Also devd's IFUP event should not depend on user's /bin/ifconfig issued > (or not issued) by hands. There are two issues here. First, if we're going to keep network_interfaces around, /etc/rc.d/dhclient should honor it and not start dhclient on interfaces not in either network_interfaces or removable interfaces. Second, running ifconfig should not be triggering link events. That makes no sense. I'll have to see if can replicate that, I'm a bit dubious. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --T4sUOijqQbZv57TR Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCr8ZAXY6L6fI4GtQRAoxAAKCfe/AeLYU7+TJg/vT75VAX9j2OUACg3Wn9 OokYtBnycuIZiwekuhUIero= =ZxZ+ -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 06:57: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 DD54C16A41C for ; Wed, 15 Jun 2005 06:57:46 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51CC443D58 for ; Wed, 15 Jun 2005 06:57:46 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.51 (FreeBSD)) id 1DiIHo-0000Id-9a; Wed, 15 Jun 2005 00:45:28 +0400 From: Vladimir Grebenschikov To: Brooks Davis In-Reply-To: <20050614162338.GA20371@odin.ac.hmc.edu> References: <20050607034620.GA32718@odin.ac.hmc.edu> <1118728905.939.5.camel@localhost> <20050614162338.GA20371@odin.ac.hmc.edu> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Wed, 15 Jun 2005 00:45:27 +0400 Message-Id: <1118781927.1003.1.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: OpenBSD dhclient incoming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2005 06:57:47 -0000 =F7 =D7=D4, 14/06/2005 =D7 09:23 -0700, Brooks Davis =D0=C9=DB=C5=D4: > On Tue, Jun 14, 2005 at 10:01:45AM +0400, Vladimir Grebenschikov wrote: > > ? ??, 06/06/2005 ? 20:46 -0700, Brooks Davis ?????: > > > I'm about to start importing the OpenBSD dhclient and required > > > support in /etc. I will unhook dhclient from the build while I work = so > > > there shouldn't be much breakage for most people > >=20 > > I have strange behavior of new dhclient + devd: > >=20 > > just after boot (with ethernet plugged) I have no devd events about > > state of media and have interface down, but after first ifconfig (even > > without parameters, even executed by any user) "link state chages to UP= " > > event appears and devd starts dhclient on interface. > >=20 > > I do not think that it is desired behavior. > >=20 > > my rc.conf, related to this:=20 > >=20 > > ifconfig_fxp0=3D"dhcp" > > network_interfaces=3D"lo0" > > devd_enable=3D"YES" > >=20 > > Probably I need to comment network_interfaces line, but anyway, now it > > works strange. >=20 > I'm not sure what you are claiming here. The dhclient should be being > started by /etc/rc.d/netif which is well before devd. The link state > message had nothing to do with devd other than being emitted by the same > function that sends a notifaction to devd. I am claiming that first notification is triggered by ifconfig command (interface already detected). I guess it should be triggered by real module load/interface detection, but not by user's ifconfig. > -- Brooks >=20 --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 06:57: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 321B316A41C for ; Wed, 15 Jun 2005 06:57:48 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vbook.fbsd.ru (swsoft-mipt-nat.sw.ru [195.214.233.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D743E43D53 for ; Wed, 15 Jun 2005 06:57:47 +0000 (GMT) (envelope-from vova@vbook.fbsd.ru) Received: from vova by vbook.fbsd.ru with local (Exim 4.51 (FreeBSD)) id 1DiOng-0001sw-Oi; Wed, 15 Jun 2005 07:42:48 +0400 From: Vladimir Grebenschikov To: Matthew Emmerton In-Reply-To: <20050614205537.D62878@gabby.gsicomp.on.ca> References: <20050607034620.GA32718@odin.ac.hmc.edu> <1118728905.939.5.camel@localhost> <20050614162338.GA20371@odin.ac.hmc.edu> <20050614205537.D62878@gabby.gsicomp.on.ca> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: quoted-printable Organization: SWsoft Date: Wed, 15 Jun 2005 07:42:48 +0400 Message-Id: <1118806968.1003.9.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Sender: Vladimir Grebenschikov Cc: freebsd-current@freebsd.org Subject: Re: HEADSUP: OpenBSD dhclient incoming X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: vova@fbsd.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2005 06:57:48 -0000 =F7 =D7=D4, 14/06/2005 =D7 20:57 -0400, Matthew Emmerton =D0=C9=DB=C5=D4: > On Tue, 14 Jun 2005, Brooks Davis wrote: >=20 > > On Tue, Jun 14, 2005 at 10:01:45AM +0400, Vladimir Grebenschikov wrote: > >> ? ??, 06/06/2005 ? 20:46 -0700, Brooks Davis ?????: > >>> I'm about to start importing the OpenBSD dhclient and required > >>> support in /etc. I will unhook dhclient from the build while I work = so > >>> there shouldn't be much breakage for most people > >> > >> I have strange behavior of new dhclient + devd: > >> > >> just after boot (with ethernet plugged) I have no devd events about > >> state of media and have interface down, but after first ifconfig (even > >> without parameters, even executed by any user) "link state chages to U= P" > >> event appears and devd starts dhclient on interface. > >> > >> I do not think that it is desired behavior. > >> > >> my rc.conf, related to this: > >> > >> ifconfig_fxp0=3D"dhcp" > >> network_interfaces=3D"lo0" > >> devd_enable=3D"YES" > >> > >> Probably I need to comment network_interfaces line, but anyway, now it > >> works strange. >=20 > Shouldn't you have network_interfaces=3D"lo0 fxp0" in order for the rc=20 > scripts to run the appropriate ifconfig or dhclient command for each=20 > interface? Probably yes (it works), but why first /sbin/ifconfig, issued by uid!=3D0 triggers dhclient ? I think behavior should be consistent, either rc.d/netif relay only on devd events and does not depends on network_interfaces=3D or rc.d/netif should relay on network_interfaces=3D and ignore not mentioned interfaces. Also devd's IFUP event should not depend on user's /bin/ifconfig issued (or not issued) by hands. > -- > Matt Emmerton --=20 Vladimir B. Grebenschikov vova@fbsd.ru From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 07:04:17 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 350C216A41C; Wed, 15 Jun 2005 07:04: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 E483343D5F; Wed, 15 Jun 2005 07:04: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 j5F741WF061720; Wed, 15 Jun 2005 03:04:01 -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 j5F7412V061715; Wed, 15 Jun 2005 03:04:01 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Wed, 15 Jun 2005 03:04:01 -0400 (EDT) From: Andre Guibert de Bruet To: Remington L In-Reply-To: Message-ID: <20050615030046.X42933@lexi.siliconlandmark.com> References: 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.534, required 6, autolearn=not spam, AWL 0.07, BAYES_00 -2.60) X-MailScanner-From: andy@siliconlandmark.com Cc: questions@freebsd.org, current@freebsd.org Subject: Re: Xen status 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, 15 Jun 2005 07:04:17 -0000 On Tue, 14 Jun 2005, Remington L wrote: > Google search finds nothing > > I am interested in knowing the present state of Xen on FreeBSD. Is it > supported in 5.4 or just -CURRENT? Are there any setup guides avaliable? Please don't cross-post. I would recommend asking xen-related questions on IRC in the official channel, #xen on irc.oftc.net. 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 Wed Jun 15 07:33: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 9AC0616A41C; Wed, 15 Jun 2005 07:33:13 +0000 (GMT) (envelope-from rabe@p-i-n.com) Received: from aposerv.p-i-n.com (aposerv.p-i-n.com [145.253.185.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id A3BFE43D48; Wed, 15 Jun 2005 07:33:12 +0000 (GMT) (envelope-from rabe@p-i-n.com) Received: from p-i-n.com (inside.p-i-n.com [129.10.9.21]) by aposerv.p-i-n.com (8.12.11/8.12.11) with ESMTP id j5F7X9mt000539; Wed, 15 Jun 2005 09:33:09 +0200 (CEST) (envelope-from rabe@p-i-n.com) Received: (from rabe@localhost) by p-i-n.com (8.11.6/8.11.6) id j5F7X4491079; Wed, 15 Jun 2005 09:33:04 +0200 (CEST) (envelope-from rabe) Date: Wed, 15 Jun 2005 09:33:04 +0200 From: "Raphael H. Becker" To: "Kenneth D. Merry" Message-ID: <20050615093304.D25098@p-i-n.com> References: <20050608152459.BF24E16A45C@hub.freebsd.org> <1118248386.7479.10.camel@zappa.Chelsea-Ct.Org> <20050608171130.GA64736@over-yonder.net> <1118252322.7479.28.camel@zappa.Chelsea-Ct.Org> <20050609113616.I41471@p-i-n.com> <20050609130511.GA732@uk.tiscali.com> <20050610162814.A25098@p-i-n.com> <20050610150718.GA7005@nargothrond.kdm.org> <20050612002508.B25098@p-i-n.com> <20050612035440.GA21262@nargothrond.kdm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050612035440.GA21262@nargothrond.kdm.org>; from ken@freebsd.org on Sat, Jun 11, 2005 at 09:54:40PM -0600 Organization: PHOENIX Pharmahandel AG & Co KG, Mannheim, Deutschland Cc: freebsd-scsi@freebsd.org, freebsd-current@freebsd.org Subject: Re: Accessing SCSI-Devices >2TB 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, 15 Jun 2005 07:33:13 -0000 On Sat, Jun 11, 2005 at 09:54:40PM -0600, Kenneth D. Merry wrote: > On Sun, Jun 12, 2005 at 00:25:08 +0200, Raphael H. Becker wrote: > > The support told me, SuSE Linux is known to work with >2TB in one device, > > means they might have some patches to work around. I will try a SuSE > > live system next days just to get sure it works. But the System won't > > be SuSE in future. > > It would be interesting to see whether that works. That would help narrow > down the problem slightly. I had some things to seek out last days. First, it doesn't work with SuSE 9.2 Live system! See http://rabe.uugrn.org/temp/FreeBSD/bigraid/dmesg.suse92_onebig.txt [...] scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.2.36 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs (scsi1:A:0): 160.000MB/s transfers (80.000MHz DT, offset 127, 16bit) Vendor: IFT Model: A12U-G2421 Rev: 342D Type: Direct-Access ANSI SCSI revision: 03 scsi1:A:0:0: Tagged Queuing enabled. Depth 32 [...] sdb : very big device. try to use READ CAPACITY(16). sdb : READ CAPACITY(16) failed. sdb : status=0, message=00, host=5, driver=00 sdb : use 0xffffffff as device size SCSI device sdb: 4294967296 512-byte hdwr sectors (2199023 MB) SCSI device sdb: drive cache: write back sdb:<6>tg3.c:v3.9 (August 30, 2004) ACPI: PCI interrupt 0000:03:06.0[A] -> GSI 7 (level, low) -> IRQ 7 unknown partition table Attached scsi disk sdb at scsi1, channel 0, id 0, lun 0 [...] Some mail with the RAID's distributor and his manufacturers support I got the information in Linux(!) the support depends on the scsi controllers (kernel)driver and (just?) LSI cards are know to work with LBA64 under linux this time. So the manufacturers position is "it works if you support LBA64 on the host". > > # camcontrol debug -c 1:0 > > # camcontrol rescan 1 > > Re-scan of bus 1 was successful > > > > in /var/log/messages: > > Hmm, well, you're not going to see the problem CDB that way, because the > probe has already happened. To see it, you either need to compile in the > debugging flags, or do the following: > > - unplug the cable from the machine to the RAID array > - camcontrol rescan 1 > - plug the cable back in > - camcontrol rescan 1 Did: - remote disconnected the RAID via internal controller - camcontrol rescan 1 - camcontrol devlist (RAID disappeared) - remote attach the RAID - turn on debugging - camcontrol rescan 1 (needed some time) - camcontrol devlist (RAID reemerged) See http://rabe.uugrn.org/temp/FreeBSD/bigraid/freebsd54_camdebug_rescan.txt > It's either the RAID box or the ahc driver from what I can see at this > point. See below. [...] > So this pretty much means it is the 16 byte read capacity that is > triggering the problem. > > The question is, is this problem on the RAID box or in the ahc driver? I > would lean towards saying the RAID box has the issue, but Justin (CCed) may > be able to give a little more insight. According to the manufacturer it just depends on the controllers LBA64 support. Regards Raphael Becker From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 07:49:25 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 CB5D416A41C for ; Wed, 15 Jun 2005 07:49:25 +0000 (GMT) (envelope-from silby@silby.com) Received: from relay.pair.com (relay00.pair.com [209.68.1.20]) by mx1.FreeBSD.org (Postfix) with SMTP id 7913043D48 for ; Wed, 15 Jun 2005 07:49:25 +0000 (GMT) (envelope-from silby@silby.com) Received: (qmail 8599 invoked from network); 15 Jun 2005 07:49:24 -0000 Received: from unknown (HELO localhost) (unknown) by unknown with SMTP; 15 Jun 2005 07:49:24 -0000 X-pair-Authenticated: 209.68.2.70 Date: Wed, 15 Jun 2005 02:49:08 -0500 (CDT) From: Mike Silbersack To: current@freebsd.org Message-ID: <20050615024332.V660@odysseus.silby.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="0-1652050532-1118821685=:660" Content-ID: <20050615024806.W660@odysseus.silby.com> Cc: Bosko Milekic Subject: UMA mbuf allocator use after free detection 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, 15 Jun 2005 07:49:25 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --0-1652050532-1118821685=:660 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; format=flowed Content-ID: <20050615024806.L660@odysseus.silby.com> The attached patch uses the trash ctor/dtor routines from uma_dbg to help detect use after free conditions for mbufs, and mbuf clusters. It doesn't seem to cause any unexpected problems with xl, ath, or wi, but it does cause issues with iwi. That is good, because iwi has some problems that need to be resolved. I'd appreciate it if people could apply the patch and see if it causes any panics or unexpected behavior on their systems. If all mbuf usage is correct, there should be no visible effect. This code is of course only active when you have INVARIANTS compiled in so that it does not slow down performance otherwise. Thanks, Mike "Silby" Silbersack --0-1652050532-1118821685=:660 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII; NAME=kern_mbuf.c-trash.patch Content-Transfer-Encoding: BASE64 Content-ID: <20050615024805.G660@odysseus.silby.com> Content-Description: Content-Disposition: ATTACHMENT; FILENAME=kern_mbuf.c-trash.patch ZGlmZiAtdSAtciAvdXNyL3NyYy9zeXMub2xkL2tlcm4va2Vybl9tYnVmLmMg L3Vzci9zcmMvc3lzL2tlcm4va2Vybl9tYnVmLmMNCi0tLSAvdXNyL3NyYy9z eXMub2xkL2tlcm4va2Vybl9tYnVmLmMJU3VuIEp1biAxMiAxOTo0MzoxMiAy MDA1DQorKysgL3Vzci9zcmMvc3lzL2tlcm4va2Vybl9tYnVmLmMJV2VkIEp1 biAxNSAwMjoyNjo0NSAyMDA1DQpAQCAtNDYsNiArNDYsOCBAQA0KICNpbmNs dWRlIDx2bS92bS5oPg0KICNpbmNsdWRlIDx2bS92bV9wYWdlLmg+DQogI2lu Y2x1ZGUgPHZtL3VtYS5oPg0KKyNpbmNsdWRlIDx2bS91bWFfaW50Lmg+DQor I2luY2x1ZGUgPHZtL3VtYV9kYmcuaD4NCiANCiAvKg0KICAqIEluIEZyZWVC U0QsIE1idWZzIGFuZCBNYnVmIENsdXN0ZXJzIGFyZSBhbGxvY2F0ZWQgZnJv bSBVTUENCkBAIC0xMzQsOSArMTM2LDE3IEBADQogCSAqIENvbmZpZ3VyZSBV TUEgem9uZXMgZm9yIE1idWZzLCBDbHVzdGVycywgYW5kIFBhY2tldHMuDQog CSAqLw0KIAl6b25lX21idWYgPSB1bWFfemNyZWF0ZSgiTWJ1ZiIsIE1TSVpF LCBtYl9jdG9yX21idWYsIG1iX2R0b3JfbWJ1ZiwNCisjaWZkZWYgSU5WQVJJ QU5UUw0KKwkgICAgdHJhc2hfaW5pdCwgdHJhc2hfZmluaSwgTVNJWkUgLSAx LCBVTUFfWk9ORV9NQVhCVUNLRVQpOw0KKyNlbHNlDQogCSAgICBOVUxMLCBO VUxMLCBNU0laRSAtIDEsIFVNQV9aT05FX01BWEJVQ0tFVCk7DQorI2VuZGlm DQogCXpvbmVfY2x1c3QgPSB1bWFfemNyZWF0ZSgiTWJ1ZkNsdXN0IiwgTUNM QllURVMsIG1iX2N0b3JfY2x1c3QsDQorI2lmZGVmIElOVkFSSUFOVFMNCisJ ICAgIG1iX2R0b3JfY2x1c3QsIHRyYXNoX2luaXQsIHRyYXNoX2ZpbmksIFVN QV9BTElHTl9QVFIsIFVNQV9aT05FX1JFRkNOVCk7DQorI2Vsc2UNCiAJICAg IG1iX2R0b3JfY2x1c3QsIE5VTEwsIE5VTEwsIFVNQV9BTElHTl9QVFIsIFVN QV9aT05FX1JFRkNOVCk7DQorI2VuZGlmDQogCWlmIChubWJjbHVzdGVycyA+ IDApDQogCQl1bWFfem9uZV9zZXRfbWF4KHpvbmVfY2x1c3QsIG5tYmNsdXN0 ZXJzKTsNCiAJem9uZV9wYWNrID0gdW1hX3pzZWNvbmRfY3JlYXRlKCJQYWNr ZXQiLCBtYl9jdG9yX3BhY2ssIG1iX2R0b3JfcGFjaywNCkBAIC0xOTAsNiAr MjAwLDkgQEANCiAJaW50IGZsYWdzOw0KIAlzaG9ydCB0eXBlOw0KIA0KKyNp ZmRlZiBJTlZBUklBTlRTDQorCXRyYXNoX2N0b3IobWVtLCBzaXplLCBhcmcs IGhvdyk7DQorI2VuZGlmDQogCW0gPSAoc3RydWN0IG1idWYgKiltZW07DQog CWFyZ3MgPSAoc3RydWN0IG1iX2FyZ3MgKilhcmc7DQogCWZsYWdzID0gYXJn cy0+ZmxhZ3M7DQpAQCAtMjI3LDYgKzI0MCw5IEBADQogCW0gPSAoc3RydWN0 IG1idWYgKiltZW07DQogCWlmICgobS0+bV9mbGFncyAmIE1fUEtUSERSKSAh PSAwKQ0KIAkJbV90YWdfZGVsZXRlX2NoYWluKG0sIE5VTEwpOw0KKyNpZmRl ZiBJTlZBUklBTlRTDQorCXRyYXNoX2R0b3IobWVtLCBzaXplLCBhcmcpOw0K KyNlbmRpZg0KIAltYnN0YXQubV9tYnVmcyAtPSAxOwkvKiBYWFggKi8NCiB9 DQogDQpAQCAtMjM5LDYgKzI1NSw5IEBADQogCW0gPSAoc3RydWN0IG1idWYg KiltZW07DQogCWlmICgobS0+bV9mbGFncyAmIE1fUEtUSERSKSAhPSAwKQ0K IAkJbV90YWdfZGVsZXRlX2NoYWluKG0sIE5VTEwpOw0KKyNpZmRlZiBJTlZB UklBTlRTDQorCXRyYXNoX2R0b3IobS0+bV9leHQuZXh0X2J1ZiwgTUNMQllU RVMsIGFyZyk7DQorI2VuZGlmDQogCW1ic3RhdC5tX21idWZzIC09IDE7CS8q IFhYWCAqLw0KIAltYnN0YXQubV9tY2x1c3RzIC09IDE7CS8qIFhYWCAqLw0K IH0NCkBAIC0yNTQsNiArMjczLDkgQEANCiB7DQogCXN0cnVjdCBtYnVmICpt Ow0KIA0KKyNpZmRlZiBJTlZBUklBTlRTDQorCXRyYXNoX2N0b3IobWVtLCBz aXplLCBhcmcsIGhvdyk7DQorI2VuZGlmDQogCW0gPSAoc3RydWN0IG1idWYg Kilhcmc7DQogCW0tPm1fZXh0LmV4dF9idWYgPSAoY2FkZHJfdCltZW07DQog CW0tPm1fZGF0YSA9IG0tPm1fZXh0LmV4dF9idWY7DQpAQCAtMjcxLDYgKzI5 Myw5IEBADQogc3RhdGljIHZvaWQNCiBtYl9kdG9yX2NsdXN0KHZvaWQgKm1l bSwgaW50IHNpemUsIHZvaWQgKmFyZykNCiB7DQorI2lmZGVmIElOVkFSSUFO VFMNCisJdHJhc2hfZHRvcihtZW0sIHNpemUsIGFyZyk7DQorI2VuZGlmDQog CW1ic3RhdC5tX21jbHVzdHMgLT0gMTsJLyogWFhYICovDQogfQ0KIA0KQEAg LTI4OCw2ICszMTMsOSBAQA0KIAl1bWFfemFsbG9jX2FyZyh6b25lX2NsdXN0 LCBtLCBob3cpOw0KIAlpZiAobS0+bV9leHQuZXh0X2J1ZiA9PSBOVUxMKQ0K IAkJcmV0dXJuIChFTk9NRU0pOw0KKyNpZmRlZiBJTlZBUklBTlRTDQorCXRy YXNoX2luaXQobS0+bV9leHQuZXh0X2J1ZiwgTUNMQllURVMsIGhvdyk7DQor I2VuZGlmDQogCW1ic3RhdC5tX21jbHVzdHMgLT0gMTsJLyogWFhYICovDQog CXJldHVybiAoMCk7DQogfQ0KQEAgLTMwMiw2ICszMzAsOSBAQA0KIAlzdHJ1 Y3QgbWJ1ZiAqbTsNCiANCiAJbSA9IChzdHJ1Y3QgbWJ1ZiAqKW1lbTsNCisj aWZkZWYgSU5WQVJJQU5UUw0KKwl0cmFzaF9maW5pKG0tPm1fZXh0LmV4dF9i dWYsIE1DTEJZVEVTKTsNCisjZW5kaWYNCiAJdW1hX3pmcmVlX2FyZyh6b25l X2NsdXN0LCBtLT5tX2V4dC5leHRfYnVmLCBOVUxMKTsNCiAJbS0+bV9leHQu ZXh0X2J1ZiA9IE5VTEw7DQogCW1ic3RhdC5tX21jbHVzdHMgKz0gMTsJLyog WFhYICovDQpAQCAtMzI2LDYgKzM1Nyw5IEBADQogCWZsYWdzID0gYXJncy0+ ZmxhZ3M7DQogCXR5cGUgPSBhcmdzLT50eXBlOw0KIA0KKyNpZmRlZiBJTlZB UklBTlRTDQorCXRyYXNoX2N0b3IobS0+bV9leHQuZXh0X2J1ZiwgTUNMQllU RVMsIGFyZywgaG93KTsNCisjZW5kaWYNCiAJbS0+bV90eXBlID0gdHlwZTsN CiAJbS0+bV9uZXh0ID0gTlVMTDsNCiAJbS0+bV9uZXh0cGt0ID0gTlVMTDsN Cg== --0-1652050532-1118821685=:660-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 08:35:04 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 979BA16A423 for ; Wed, 15 Jun 2005 08:35:04 +0000 (GMT) (envelope-from ade@FreeBSD.org) Received: from mail.lovett.com (foo.lovett.com [67.134.38.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7634643D1D for ; Wed, 15 Jun 2005 08:35:04 +0000 (GMT) (envelope-from ade@FreeBSD.org) Received: from hellfire.lovett.com ([67.134.38.149]) by mail.lovett.com with esmtpa (Exim 4.51 (FreeBSD)) id 1DiTMW-00064f-6P for current@FreeBSD.org; Wed, 15 Jun 2005 01:35:04 -0700 Message-ID: <42AFE83B.9050305@FreeBSD.org> Date: Wed, 15 Jun 2005 01:35:07 -0700 From: Ade Lovett User-Agent: Mozilla Thunderbird 1.0.2 (Macintosh/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: current@FreeBSD.org X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Subject: USB mouse woes 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, 15 Jun 2005 08:35:04 -0000 Microsoft wireless USB mouse is completely non-responsive after boot. Moving the mouse will produce a mouse cursor on syscons, but no movement is observed. Same mouse operates successfully on Ubuntu Linux 5.04 and Windows XP, and also under FreeBSD with a USB-PS/2 adapter (via psm) System info: MSI KT800 Neo, VIA chipset FreeBSD 6.0-CURRENT #0: Wed Jun 15 01:00:33 PDT 2005 root@nail.lovett.com:/usr/obj/work/src.6/sys/NAIL [...] CPU: AMD Athlon(tm) 64 Processor 2800+ (1800.07-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0xfc0 Stepping = 0 [...] uhci0: port 0xc400-0xc41f irq 21 at device 16.0 on pci0 uhci0: [GIANT-LOCKED] usb0: on uhci0 usb0: USB revision 1.0 [...] [repeat for usb1, usb2, usb3] [...] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: VIA EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered [...] ums0: Microsoft Microsoft Wireless Optical Mouse\M-. 1.0A, rev 2.00/0.17, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. [...] "NAIL" kernel config is merely GENERIC with un-needed drivers. Makes no difference for any combinations of (uhci,ehci,usb,ums) compiled in to the kernel, or as modules with appropriate loader.conf magic. usbd is running (via /etc/rc.conf), and the appropriate moused on /dev/ums0 is also running. crw-r--r-- 1 root operator 7, 82 Jun 15 01:15 /dev/ums0 Any suggestions on further places to look to get the mouse working appreciated. Running under a base install of ports/x11/xorg reveals similar breakage, both either via the SysMouse protocol, or direct talking to /dev/ums0 as a USB mouse without usbd (and moused) running. A quick look through the archives reveals a few other reports of similar issues, but no resolution. Ideas? -aDe From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 08:39: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 E4C9E16A41C for ; Wed, 15 Jun 2005 08:39:11 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from r-dd.iij4u.or.jp (r-dd.iij4u.or.jp [210.130.0.70]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68BC743D4C for ; Wed, 15 Jun 2005 08:39:11 +0000 (GMT) (envelope-from demizu@dd.iij4u.or.jp) Received: from localhost (h183.p057.iij4u.or.jp [210.130.57.183]) by r-dd.iij4u.or.jp (4U-MR/r-dd) id j5F8cqcb027130; Wed, 15 Jun 2005 17:39:04 +0900 (JST) Date: Wed, 15 Jun 2005 17:38:04 +0900 (JST) Message-Id: <20050615.173804.85686621.Noritoshi@Demizu.ORG> From: Noritoshi Demizu To: Dikshie In-Reply-To: <20050615051807.GA5076@ppk.itb.ac.id> References: <20050614063148.GA22683@ppk.itb.ac.id> <20050614182127.GA22085@xor.obsecurity.org> <20050615051807.GA5076@ppk.itb.ac.id> X-Mailer: Mew version 4.1 on Emacs 21 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, Kris Kennaway Subject: Another panic in tcp_sack_option() (Re: ***SPAM Level 2*** Re: doadump () at pcpu.h:165) 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, 15 Jun 2005 08:39:12 -0000 > > > optlen=0) at /usr/src/sys/netinet/tcp_sack.c:478 > > Here is the real panic, not the frame #0 as in your subject. > > I've seen this panic also and have reported it to ps and mohan. > thanks ! I've been disable sack via sysctl it seems solve the problem. I am sorry for the inconvenience you experienced. The patch below is another work around of this problem. I'm working on the real fix. Wait for days, please. <<< details start >>> tcp_sack_option() assumes that, when SACK holes exist, (TAILQ_FIRST(&tp->snd_holes)->start == tp->snd_una) is always true. (i.e., the start of the first SACK hole is equal to SND.UNA) If this holds true, since all SACK blocks in sack_blocks[] satisfy sblkp->start > tp->snd_una, sack_blocks[] must be consumed earlier than SACK holes in the while-loop. I think the fail of the KASSERT() indicates that the formula above does not hold in some situation. The only case I can come up with for now is the follwoing. 1. A segment comes. 2. tcp_sack_option() is called without any problem. 3. tcp_del_sackholes() is called and TAILQ_FIRST(&tp->snd_holes)->start is advanced by the ack number on the segment. 3. The segment is dropped because it fails the PAWS test or some other check in tcp_input(). 4. Next segment comes. 5. tcp_sack_option() is called. Since TAILQ_FIRST(&tp->snd_holes)->start is higher than tp->snd_una, the KASSERT() in the while-loop fails. I'm working to move the calls of tcp_sack_option() and tcp_del_sackholes() from the current places to a place after the PAWS test and other checks. It works on my machine. But I need more tests and reviews. So, please wait for days. <<< details end >>> Thanks. Regards, Noritoshi Demizu Index: tcp_sack.c =================================================================== RCS file: /home/cvsup/FreeBSD/ncvs/src/sys/netinet/tcp_sack.c,v retrieving revision 1.24 diff -u -r1.24 tcp_sack.c --- tcp_sack.c 9 Jun 2005 17:55:29 -0000 1.24 +++ tcp_sack.c 15 Jun 2005 08:08:17 -0000 @@ -474,8 +474,7 @@ * Since the incoming sack blocks are sorted, we can process them * making one sweep of the scoreboard. */ - while (sblkp - sack_blocks >= 0) { - KASSERT(cur != NULL, ("cur != NULL")); + while (sblkp - sack_blocks >= 0 && cur != NULL) { if (SEQ_GEQ(sblkp->start, cur->end)) { /* * SACKs data beyond the current hole. From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 09:09: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 2474316A41C for ; Wed, 15 Jun 2005 09:09:31 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74A7F43D49 for ; Wed, 15 Jun 2005 09:09:27 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j5F6TCLQ017466; Wed, 15 Jun 2005 00:29:13 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 15 Jun 2005 00:30:20 -0600 (MDT) Message-Id: <20050615.003020.99022728.imp@bsdimp.com> To: brooks@one-eyed-alien.net From: "M. Warner Losh" In-Reply-To: <20050615061009.GA11914@odin.ac.hmc.edu> References: <20050614205537.D62878@gabby.gsicomp.on.ca> <1118806968.1003.9.camel@localhost> <20050615061009.GA11914@odin.ac.hmc.edu> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: vova@fbsd.ru, freebsd-current@FreeBSD.ORG, matt@gsicomp.on.ca Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 15 Jun 2005 09:09:31 -0000 In message: <20050615061009.GA11914@odin.ac.hmc.edu> Brooks Davis writes: : On Wed, Jun 15, 2005 at 07:42:48AM +0400, Vladimir Grebenschikov wrote: : > ? ??, 14/06/2005 ? 20:57 -0400, Matthew Emmerton ?????: : > > On Tue, 14 Jun 2005, Brooks Davis wrote: : > > : > > > On Tue, Jun 14, 2005 at 10:01:45AM +0400, Vladimir Grebenschikov wrote: : > > >> ? ??, 06/06/2005 ? 20:46 -0700, Brooks Davis ?????: : > > >>> I'm about to start importing the OpenBSD dhclient and required : > > >>> support in /etc. I will unhook dhclient from the build while I work so : > > >>> there shouldn't be much breakage for most people : > > >> : > > >> I have strange behavior of new dhclient + devd: : > > >> : > > >> just after boot (with ethernet plugged) I have no devd events about : > > >> state of media and have interface down, but after first ifconfig (even : > > >> without parameters, even executed by any user) "link state chages to UP" : > > >> event appears and devd starts dhclient on interface. : > > >> : > > >> I do not think that it is desired behavior. : > > >> : > > >> my rc.conf, related to this: : > > >> : > > >> ifconfig_fxp0="dhcp" : > > >> network_interfaces="lo0" : > > >> devd_enable="YES" : > > >> : > > >> Probably I need to comment network_interfaces line, but anyway, now it : > > >> works strange. : > > : > > Shouldn't you have network_interfaces="lo0 fxp0" in order for the rc : > > scripts to run the appropriate ifconfig or dhclient command for each : > > interface? : > : > Probably yes (it works), but why first /sbin/ifconfig, issued by uid!=0 : > triggers dhclient ? : > : > I think behavior should be consistent, either rc.d/netif relay only on : > devd events and does not depends on network_interfaces= or rc.d/netif : > should relay on network_interfaces= and ignore not mentioned interfaces. : > : > Also devd's IFUP event should not depend on user's /bin/ifconfig issued : > (or not issued) by hands. : : There are two issues here. First, if we're going to keep : network_interfaces around, /etc/rc.d/dhclient should honor it and : not start dhclient on interfaces not in either network_interfaces or : removable interfaces. Second, running ifconfig should not be triggering : link events. That makes no sense. I'll have to see if can replicate : that, I'm a bit dubious. ifconfig fxp0 1.2.3.4/24 will kill dhclient every time for me. I've also been seeing weirdness with the new dhclient when i move from network to network on boot when I have the 'old' lease around but no cable connected. I'll see if I can replicate this enough to submit a report. Warner From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 09:09:32 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 30AE616A41C; Wed, 15 Jun 2005 09:09:32 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 566E043D53; Wed, 15 Jun 2005 09:09:31 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j5F6Q4ER017439; Wed, 15 Jun 2005 00:26:05 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 15 Jun 2005 00:27:12 -0600 (MDT) Message-Id: <20050615.002712.123500387.imp@bsdimp.com> To: maxim@macomnet.ru From: "M. Warner Losh" In-Reply-To: <20050614231344.F76340@mp2.macomnet.net> References: <20050614231344.F76340@mp2.macomnet.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: brooks@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: ed(4) broken? 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, 15 Jun 2005 09:09:32 -0000 In message: <20050614231344.F76340@mp2.macomnet.net> Maxim Konovalov writes: : Latest GENERIC in qemu produces : Jun 14 19:12:04 qemu6 kernel: ed_start(0xc12e5000) GONE : Jun 14 19:12:07 qemu6 kernel: ed0: NIC memory corrupt - invalid packet length 45 : No real hardware though. ed works for me on all the real hardware I have. Maybe you could give me more details. Warner From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 09:41: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 E598216A41C for ; Wed, 15 Jun 2005 09:41:23 +0000 (GMT) (envelope-from current@dino.sk) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6322443D53 for ; Wed, 15 Jun 2005 09:41:22 +0000 (GMT) (envelope-from current@dino.sk) Received: from home.dino.sk ([213.215.74.194]) (AUTH: LOGIN milan) by bsd.dino.sk with esmtp; Wed, 15 Jun 2005 11:42:48 +0200 id 000000EB.42AFF818.00005F81 From: Milan Obuch To: freebsd-current@freebsd.org Date: Wed, 15 Jun 2005 11:40:55 +0200 User-Agent: KMail/1.8 References: <20050614205537.D62878@gabby.gsicomp.on.ca> <20050615061009.GA11914@odin.ac.hmc.edu> <20050615.003020.99022728.imp@bsdimp.com> In-Reply-To: <20050615.003020.99022728.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506151140.56908.current@dino.sk> Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 15 Jun 2005 09:41:24 -0000 On Wednesday 15 June 2005 08:30, M. Warner Losh wrote: ... > > ifconfig fxp0 1.2.3.4/24 > > will kill dhclient every time for me. > Well, I would consider this a feature, not a bug, and a convenient one. It happens on me from time to time that I have DHCP configured on one interface, then after move to another place I issue 'ifconfig fxp0 ....' and some time after network suddenly stops working due to dhclient running and deleting my manually entered setting. Where there also 'ifconfig fxp0 DHCP' for consistency... I know this could be easily done with some scripting, but I could not resist :) Milan From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 09:54: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 66C5216A41C for ; Wed, 15 Jun 2005 09:54:48 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41E9B43D1F for ; Wed, 15 Jun 2005 09:54:48 +0000 (GMT) (envelope-from rizzo@icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.11/8.12.11) with ESMTP id j5F9sl4d063094; Wed, 15 Jun 2005 02:54:47 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.11/8.12.3/Submit) id j5F9slh3063093; Wed, 15 Jun 2005 02:54:47 -0700 (PDT) (envelope-from rizzo) Date: Wed, 15 Jun 2005 02:54:47 -0700 From: Luigi Rizzo To: current@freebsd.org Message-ID: <20050615025447.A62971@xorpc.icir.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="+QahgC5+KEYLbs62" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i Cc: Subject: bug or feature in userland thread library (O_NONBLOCK) 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, 15 Jun 2005 09:54:48 -0000 --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Probably a known issue, but I thought it worthwhile reporting it, if nothing else for archival purposes. I think our userland thread library (libc_r) has some bugs in handling descriptors. I can reproduce the behaviour on -current and 4.x, and I believe it applies to 5.x too. Following is a description of the problem and some code to replicate it The code includes a workaround but it is not particularly nice. Any better ideas ? I am not sure on what to do, but perhaps the only sensible thing to do is to add a note with this workaround (or better ones, if available) to our pthreads manpage --- PROBLEM DESCRIPTION --- Basically, our libc_r keeps two views of i/o descriptors, one (external) is for threads and reflects the modes requested by the threads (blocking or not, etc.); the "internal" view instead is how descriptors are actually set in the kernel -- and there they should always be set as O_NONBLOCK to avoid blocking on a syscall. The bug occurs when a process does a fork(), and then either a close() or an exec() -- a similar thing also occurs with popen(). The relevant source code is in /usr/src/lib/libc_r/uthread/uthread_execve.c /usr/src/lib/libc_r/uthread/uthread_close.c Right before the exec(), the internal descriptors are put into blocking mode if the external one are blocking, and they are only reset to O_NONBLOCK after termination of the child (upon SIGCHLD). The same occurs for close(). Note that close() has hacks to leave pipes alone, but the same code is not present in the execve() case where instead I believe it would be necessary. Another thing to note is that there is some kind of 'fate sharing' among the stdio descriptors (0, 1, 2) which is not totally clear to me, but seems to require setting O_NONBLOCK on all 3 to make sure that they are not changed to blocking mode. Because descriptors are shared between parent and child, for the lifetime of the child descriptors in the parent will be blocking and the scheduling of threads will be completely broken. The only fix i have found is to act as follows: pipe(fd); /* create a pipe with the child */ p = fork(); if (p == 0) { /* child */ /* call fcntl() _before_ close() to avoid resetting * O_NONBLOCK on the internal descriptors. After that, * close the descriptors not needed in the child. */ for (i=0; i < getdtablesize(); i++) { long fl = fcntl(i, F_GETFL); if (fl != -1 && i != fd[0]) { /* open and must be closed in the child */ fcntl(i, F_SETFL, O_NONBLOCK | fl); close(i); } } /* standard stuff (dup2, exec*()... */ dup2(fd[0], STDOUT_FILENO); /* as an example */ execl(....); } else { /* parent */ close(fd[0]); /* close child end. */ ... } but of course this is rather unintuitive. On the other hand, I have no idea of a better way to address the problem, and being fairly new to threads programming maybe others know better. I am attaching two minimal programs to demonstrate the bug. simple.c is a simple program (linked against the regular C library) cc -o simple simple.c that only plays with blocking mode on the descriptors. thre.c is meant to be linked with libc_r. cc -o thre thre.c -lc_r It does a fork and exec of the other program. If you call it without arguments, it does not implement the above workaround, and you see how the 'internal' descriptor change to blocking mode. If you call it with an argument, it implements the workaround. enjoy luigi --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="thre.c" /* * test descriptor issues on threads. * * compile with cc -o thre -lc_r thre.c */ #include #include #include #include int dump_desc(char *s, int w) { int i; fprintf(stderr, "-- [pid %d thr %p] %s --\n", getpid(), pthread_self(), s); for (i=0; i<8; i++) { fprintf(stderr, "fd %d flags 0x%lx (system 0x%lx)\n", i, _thread_fd_getflags(i), __sys_fcntl(i, F_GETFL)); } sleep(w); return 0; } int main(int argc, char *argv[]) { pid_t p; int i, fd[2]; pipe(fd); fprintf(stderr, "child-end %d parent end %d max %d\n", fd[0], fd[1], getdtablesize()); dump_desc("start main", 0); p = fork(); if (p == 0) { /* child */ /* * close parent's end. It's a pipe so O_NONBLOCK remains. * You can also do it in the loop below. */ close(fd[1]); /* * First tell libc_r to leave O_NONBLOCK on the descriptors * even after a close() or exec(), * _After_ that, close() all descriptors you don't need * in the child, because they are shared and the child * could change their mode in unexpected way causing us * trouble. * You can limit the loop (getdtablesize() is often large) * but at least make sure to act on the descriptor you are * using on the parent threads in blocking mode. */ if (argc > 1) for (i=0; i < getdtablesize(); i++) { long fl = fcntl(i, F_GETFL); if (fl != -1 && i != fd[0]) { /* open and must be closed in the child */ fcntl(i, F_SETFL, O_NONBLOCK | fl); close(i); } } dup2(fd[0], STDOUT_FILENO); sleep(2); /* * now we can finally exec a process without risking * trouble. The process will only play with its own * side of the pipes, which is not shared by the parent * and so any action on it does not change the status * on the parent side. * The example process below does some weird things * with the descriptors, and we use it to show that it * does not harm us. */ execl("./simple", "simple", "2", NULL); } else { /* parent */ close(fd[0]); /* close child end of the pipe */ sleep(1); dump_desc("parent", 2); dump_desc("parent after exec done", 2); dump_desc("parent after child fcntl", 2); dump_desc("parent after child dead", 0); } return 0; } --+QahgC5+KEYLbs62 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="simple.c" /* * test descriptor issues on threads. * * compile with cc -o simple simple.c */ #include #include #include int main(int argc, char *argv[]) { pid_t p; int fd[2]; FILE *f; pipe(fd); sleep(atoi(argv[1])); dup2(fd[0], STDOUT_FILENO); fcntl(0, F_SETFL, ~O_NONBLOCK & fcntl(0, F_GETFL)); fcntl(1, F_SETFL, ~O_NONBLOCK & fcntl(1, F_GETFL)); fcntl(2, F_SETFL, ~O_NONBLOCK & fcntl(2, F_GETFL)); sleep(atoi(argv[1])); return 0; } --+QahgC5+KEYLbs62-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 10:05: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 37C0316A41C; Wed, 15 Jun 2005 10:05:51 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id EB7E143D48; Wed, 15 Jun 2005 10:05:50 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from yazzy.org (localhost [127.0.0.1]) by mail.yazzy.org (Postfix) with SMTP id E0E5939869; Wed, 15 Jun 2005 12:06:18 +0200 (CEST) Received: from 148.122.180.9 (SquirrelMail authenticated user lists@yazzy.org) by mail.yazzy.org with HTTP; Wed, 15 Jun 2005 12:06:18 +0200 (CEST) Message-ID: <58397.148.122.180.9.1118829978.squirrel@mail.yazzy.org> Date: Wed, 15 Jun 2005 12:06:18 +0200 (CEST) From: "M.Jessa" To: , X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Looking for networking solution. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: lists@yazzy.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2005 10:05:51 -0000 Hi guys. I am looking for solution I could implement on a link with a huge latency when ping replies can go up to a few hundred miliseconds, e.g sateliete links. What I was thinking about is some kind of virtual interface which could translate tcp to udp in one of the pears of the link and push the data it received from a 'normal' interface through the virtual interface without bothering about ack-timing. The receiving end would have a similar interface which would translate the udp data stream to tcp and then route it out to the internet. (normal network)tcp<-->virtual udp interface<-------->virtual udp interface<-->tcp(normal network) Is there something avaliable on FreeBSD that can be used for that purpose? Maybe someone is working on such a thing in CURRENT ? Any thoughts about that? Any sugestions for a solution? Regards, Marcin Jessa. From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 11:07: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 7C06F16A41C for ; Wed, 15 Jun 2005 11:07:54 +0000 (GMT) (envelope-from snort_sam@yahoo.com) Received: from web54408.mail.yahoo.com (web54408.mail.yahoo.com [68.142.225.164]) by mx1.FreeBSD.org (Postfix) with SMTP id 1799543D49 for ; Wed, 15 Jun 2005 11:07:53 +0000 (GMT) (envelope-from snort_sam@yahoo.com) Received: (qmail 11530 invoked by uid 60001); 15 Jun 2005 11:07:53 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Iss2cdRjXIdtcn5T1NdTLswk08AdTkUNfmhwzXbaTKswHizFGhbA5ZAEgL+3C1v7nA4sQ/P8i4jv0muFRq52hxoLeZzmO8o/Z2eIN/xT7mKErE6g8OSGZIxDIvtNp9XzCrbllIoj7M4f+j0S59Z+oZdrXAkgpouwokujDYkWBz0= ; Message-ID: <20050615110753.11528.qmail@web54408.mail.yahoo.com> Received: from [139.168.39.63] by web54408.mail.yahoo.com via HTTP; Wed, 15 Jun 2005 04:07:53 PDT Date: Wed, 15 Jun 2005 04:07:53 -0700 (PDT) From: snort Snort To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: ttys0 code freezes 5.4 release-p1 badly 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, 15 Jun 2005 11:07:54 -0000 Hi, The following ttys0 code freezes 5.4 release-p1 badly: #include /* Standard input/output definitions */ #include /* String function definitions */ #include /* UNIX standard function definitions */ #include /* File control definitions */ #include /* Error number definitions */ #include /* POSIX terminal control definitions */ /* * 'open_port()' - Open serial port 1. * * Returns the file descriptor on success or -1 on error. */ int open_port(void) { int fd; /* File descriptor for the port */ fd = open("/dev/ttyd0", O_RDWR | O_NOCTTY | O_NDELAY); if (fd == -1) { /* could not open the port. */ perror("open_port: Unable to open /dev/ttyS0 - "); } else fcntl(fd, F_SETFL, 0); return (fd); } int write_port(int fd) { int n = write(fd, "ATZ\r", 4); if (n < 0) { fputs("write() of 4 bytes failed!\n", stderr); return 0; } return n; } void read_port(int fd) { fcntl(fd, F_SETFL, FNDELAY); //fcntl(fd, F_SETFL, 0); } void close_port(int fd) { close(fd); } int main() { int fd = open_port(); if (write_port(fd) < 0) return 1; read_port(fd); close_port(fd); } Dose anyone know what is problem and how to fix it? Thanks Sam __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 11:19: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 5B11916A41C for ; Wed, 15 Jun 2005 11:19:16 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (pop.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id BC91843D49 for ; Wed, 15 Jun 2005 11:19:15 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 15 Jun 2005 11:19:13 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp012) with SMTP; 15 Jun 2005 13:19:13 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Wed, 15 Jun 2005 13:19:00 +0200 User-Agent: KMail/1.8 X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart8673889.0BNUX9gZ6G"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506151319.12518@harrymail> X-Y-GMX-Trusted: 0 Subject: PANIC: udf / lockmgr: locking against myself 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, 15 Jun 2005 11:19:16 -0000 --nextPart8673889.0BNUX9gZ6G Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I tried to read a backup DVD with UDF filesystem and I get the following=20 panick with yesterdays -current: mount_udf /dev/acd1 /mnt # cd /mnt # ls Various Artists # cd Various panic: lockmgr: locking against myself KDB: enter: panic [thread pid 59 tid 100065 ] Stopped at kdb_enter+0x32: leal 0(%esi),%esi db> where Tracing pid 59 tid 100065 td 0xc209b000 kdb_enter(c0779d0b,c07e7c20,c0777eb6,d9b46900,c209b000) at kdb_enter+0x32 panic(c0777eb6,0,c0777d84,b5,c078327c) at panic+0x14d lockmgr(c20c1168,3002,c20c118c,c209b000,d9b46958) at lockmgr+0x7c2 vop_stdlock(d9b46980,c209b078,1002,1002,c20c1110) at vop_stdlock+0x2f VOP_LOCK_APV(c07b1da0,d9b46980,c078327c,31f,800) at VOP_LOCK_APV+0x79 vn_lock(c20c1110,1002,c209b000,d9b469e8,c20ddbf4) at vn_lock+0x69 udf_lookup(d9b46a3c,c20c1110,d9b46c1c) at udf_lookup+0x283 VOP_CACHEDLOOKUP_APV(c07b1da0,d9b46a3c,d9b46c1c,c209b000,c1d63d80) at=20 VOP_CACHED LOOKUP_APV+0x71 vfs_cache_lookup(d9b46ae8,d9b46ae8,c20c1110,c20c1110,d9b46ae8) at=20 vfs_cache_look up+0xf3 VOP_LOOKUP_APV(c07b1da0,d9b46ae8,c209b000,c0782a9a,d9b46c08) at V x79 lookup(d9b46bf4,0,c078222d,b4,c078327c) at lookup+0x34a namei(d9b46bf4,c209b000,d9b46b94,246,0) at namei+0x329 kern_stat(c209b000,8068088,0,d9b46c68,3ea) at kern_stat+0x3d stat(c209b000,d9b46d04,8,16,2) at stat+0x2d syscall(3b,3b,3b,4,8068064) at syscall+0x13d Xint0x80_syscall() at Xint0x80_syscall+0x1f =2D-- syscall (188, FreeBSD ELF32, stat), eip =3D 0x2812bb5f, esp =3D 0xbfb= febbc,=20 ebp =3D 0xbfbfecc8 --- Tell me if you need more info. Thanks, =2DHarry --nextPart8673889.0BNUX9gZ6G Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCsA6wBylq0S4AzzwRAp0DAJ4wxp7SpjKXt3QfcmOAnHEOGYQhrQCdEVRj 27JSEB7ySpNSHMvBUOE1/oE= =Y86s -----END PGP SIGNATURE----- --nextPart8673889.0BNUX9gZ6G-- From owner-freebsd-current@FreeBSD.ORG Tue Jun 14 22:14: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 59D1816A41C for ; Tue, 14 Jun 2005 22:14:17 +0000 (GMT) (envelope-from lyndon@orthanc.ca) Received: from orthanc.ca (orthanc.ca [209.89.70.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0365843D1D for ; Tue, 14 Jun 2005 22:14:16 +0000 (GMT) (envelope-from lyndon@orthanc.ca) Received: from [192.168.15.2] (d216-232-211-96.bchsia.telus.net [216.232.211.96]) (authenticated bits=0) by orthanc.ca (8.13.3/8.13.3) with ESMTP id j5EMDo79099474; Tue, 14 Jun 2005 16:13:50 -0600 (MDT) (envelope-from lyndon@orthanc.ca) In-Reply-To: <42AF374F.3000705@offmyserver.com> References: <200504262010.49509@harrymail> <20050429200029.GC232@cirb503493.alcatel.com.au> <200506141824.17451@harrymail> <20050614185923.GA12375@dragon.NUXI.org> <42AF374F.3000705@offmyserver.com> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Lyndon Nerenberg Date: Tue, 14 Jun 2005 15:13:43 -0700 To: "Devon H. O'Dell" X-Mailer: Apple Mail (2.730) X-DCC-neonova-Metrics: orthanc.ca 1127; Body=1 Fuz1=1 Fuz2=1 X-Spam-Status: No, score=1.3 required=5.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.0.2 X-Spam-Level: * X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on orthanc.ca X-Mailman-Approved-At: Wed, 15 Jun 2005 11:44:48 +0000 Cc: freebsd-current@freebsd.org Subject: Re: groff alternative? 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, 14 Jun 2005 22:14:17 -0000 On Jun 14, 2005, at 1:00 PM, Devon H. O'Dell wrote: > Would troff/nroff/ps/pdf utilities from Plan 9 be usable? The > license isn't as restrictive. But probably better than what Sun is using. The Plan 9 troff has the advantage of being UTF-8 savvy. It has the disadvantage of requiring the Plan 9 runtime compatibility libraries be brought along. I don't have time right this minute to investigate further. Maybe in a week or two. From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 00:50: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 93D8F16A41C for ; Wed, 15 Jun 2005 00:50:53 +0000 (GMT) (envelope-from matt@gabby.gsicomp.on.ca) Received: from gabby.gsicomp.on.ca (CPE00062566c7bb-CM000039c69a66.cpe.net.cable.rogers.com [69.193.82.185]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2B8F143D1D for ; Wed, 15 Jun 2005 00:50:52 +0000 (GMT) (envelope-from matt@gabby.gsicomp.on.ca) Received: from gabby.gsicomp.on.ca (matt@localhost.gsicomp.on.ca [127.0.0.1]) by gabby.gsicomp.on.ca (8.12.9p2/8.12.9) with ESMTP id j5F0vDfs062892; Tue, 14 Jun 2005 20:57:14 -0400 (EDT) (envelope-from matt@gabby.gsicomp.on.ca) Received: from localhost (matt@localhost) by gabby.gsicomp.on.ca (8.12.9p2/8.12.9/Submit) with ESMTP id j5F0v3G2062886; Tue, 14 Jun 2005 20:57:11 -0400 (EDT) (envelope-from matt@gabby.gsicomp.on.ca) Date: Tue, 14 Jun 2005 20:57:02 -0400 (EDT) From: Matthew Emmerton To: Brooks Davis In-Reply-To: <20050614162338.GA20371@odin.ac.hmc.edu> Message-ID: <20050614205537.D62878@gabby.gsicomp.on.ca> References: <20050607034620.GA32718@odin.ac.hmc.edu> <1118728905.939.5.camel@localhost> <20050614162338.GA20371@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Mailman-Approved-At: Wed, 15 Jun 2005 11:44:48 +0000 Cc: Vladimir Grebenschikov , freebsd-current@freebsd.org Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 15 Jun 2005 00:50:53 -0000 On Tue, 14 Jun 2005, Brooks Davis wrote: > On Tue, Jun 14, 2005 at 10:01:45AM +0400, Vladimir Grebenschikov wrote: >> ? ??, 06/06/2005 ? 20:46 -0700, Brooks Davis ?????: >>> I'm about to start importing the OpenBSD dhclient and required >>> support in /etc. I will unhook dhclient from the build while I work so >>> there shouldn't be much breakage for most people >> >> I have strange behavior of new dhclient + devd: >> >> just after boot (with ethernet plugged) I have no devd events about >> state of media and have interface down, but after first ifconfig (even >> without parameters, even executed by any user) "link state chages to UP" >> event appears and devd starts dhclient on interface. >> >> I do not think that it is desired behavior. >> >> my rc.conf, related to this: >> >> ifconfig_fxp0="dhcp" >> network_interfaces="lo0" >> devd_enable="YES" >> >> Probably I need to comment network_interfaces line, but anyway, now it >> works strange. Shouldn't you have network_interfaces="lo0 fxp0" in order for the rc scripts to run the appropriate ifconfig or dhclient command for each interface? -- Matt Emmerton From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 12:14:02 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 1318216A41C for ; Wed, 15 Jun 2005 12:14:02 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id B350843D48 for ; Wed, 15 Jun 2005 12:14:01 +0000 (GMT) (envelope-from vladgalu@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so278813nzk for ; Wed, 15 Jun 2005 05:14:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=XZcDiAvT/v/e71lO+FMd5iDDWNTeJL9i1GGKjiRc3odANCcJPs4l6lNEEGmIUgkCZn1CzPHojGp22F9TXtK3mAhBB+cXmdK3kZOpFdSbxDmHiSY4fyKBtoTjjZclTRdHh/TKhYNMtC0oOPReK1p1Nwpz6CuF15S3kH46pQvo99Q= Received: by 10.36.37.19 with SMTP id k19mr4396nzk; Wed, 15 Jun 2005 05:14:01 -0700 (PDT) Received: by 10.36.86.4 with HTTP; Wed, 15 Jun 2005 05:14:01 -0700 (PDT) Message-ID: <79722fad05061505141b3ddb4c@mail.gmail.com> Date: Wed, 15 Jun 2005 15:14:01 +0300 From: Vlad GALU To: freebsd-net@freebsd.org, current@freebsd.org In-Reply-To: <58397.148.122.180.9.1118829978.squirrel@mail.yazzy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <58397.148.122.180.9.1118829978.squirrel@mail.yazzy.org> Cc: Subject: Re: Looking for networking solution. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vlad GALU List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2005 12:14:02 -0000 On 6/15/05, M.Jessa wrote: > Hi guys. >=20 > I am looking for solution I could implement on a link with a huge latency > when ping replies can go up to a few hundred miliseconds, e.g sateliete > links. > What I was thinking about is some kind of virtual interface which could > translate tcp to udp in one of the pears of the link and push the data it > received from a 'normal' interface through the virtual interface without > bothering about ack-timing. > The receiving end would have a similar interface which would translate th= e > udp data stream to tcp and then route it out to the internet. > (normal network)tcp<-->virtual udp interface<-------->virtual udp > interface<-->tcp(normal network) >=20 > Is there something avaliable on FreeBSD that can be used for that purpose= ? > Maybe someone is working on such a thing in CURRENT ? > Any thoughts about that? Any sugestions for a solution? I suppose you can use OpenVPN for that, which encapsulates all IP traffic into UDP datagrams. But still, your TCP implementation will time out as if there wasn't any tunnelling involved. >=20 >=20 > Regards, > Marcin Jessa. >=20 >=20 > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" >=20 --=20 If it's there, and you can see it, it's real. If it's not there, and you can see it, it's virtual. If it's there, and you can't see it, it's transparent. If it's not there, and you can't see it, you erased it. From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 12:16: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 0FD2C16A41C; Wed, 15 Jun 2005 12:16:27 +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 0F29C43D4C; Wed, 15 Jun 2005 12:16:24 +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 PAA05774; Wed, 15 Jun 2005 15:16:21 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <42B01C15.4060706@icyb.net.ua> Date: Wed, 15 Jun 2005 15:16:21 +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-current@freebsd.org, freebsd-stable@freebsd.org References: <42A7DE9B.9010702@icyb.net.ua> In-Reply-To: <42A7DE9B.9010702@icyb.net.ua> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: Subject: Re: LOR: "ata state lock" and "user map" 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, 15 Jun 2005 12:16:27 -0000 on 09.06.2005 09:15 Andriy Gapon said the following: > > NOTE: CURRENT was run under qemu emulation, CDROM was emulated from iso > image on HDD. > > Got this LOR today with CURRENT built 3 days ago while trying to execute > a linux program located on a CD. Several days ago trying to do the same > on 5.4-RELEASE (without any debug options in kernel) on real hardware > caused a hardlock. > > System: > 6.0-CURRENT i386 > debug.mpsafevm=1 > > LOR message had this information: > 1st 0xc0eb44e8 ATA state lock ata-all.c:297 > 2nd 0xc0c1f344 user map vm_map.c:2997 > > Sources: > ata-all.c 1.252 > /vm_map.c 1.366 > > Interesting part of stack trace (not sure how useful it is): > #18 0x0000000c in ?? () > #19 0x00000002 in ?? () > #20 0xc0455a15 in ata_pio_read (request=0xc107b0c8, length=2048) > at cpufunc.h:229 > #21 0xc045646c in ata_end_transaction (request=0xc107b0c8) > at /usr/src/sys/dev/ata/ata-lowlevel.c:393 > #22 0xc0447659 in ata_interrupt (data=0xc0eb4400) > at /usr/src/sys/dev/ata/ata-all.c:323 > #23 0xc04b5360 in ithread_loop (arg=0xc0eb9600) > at /usr/src/sys/kern/kern_intr.c:546 > #24 0xc04b46fd in fork_exit (callout=0xc04b51bc , > arg=0xc0eb9600, frame=0xc7b41d38) at /usr/src/sys/kern/kern_fork.c:789 > #25 0xc05df18c in fork_trampoline () at > /usr/src/sys/i386/i386/exception.s:208 > > Please let me know what additional information I can provide. > additional details - the problem is 100% percent reproducible with linux applications but is 0% producible with native applications. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 12:37: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 D96F416A41C for ; Wed, 15 Jun 2005 12:37:25 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 750A343D49 for ; Wed, 15 Jun 2005 12:37:25 +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-1.free.fr (Postfix) with ESMTP id 100F1317D3F; Wed, 15 Jun 2005 14:37:24 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 1AB35407E; Wed, 15 Jun 2005 14:37:00 +0200 (CEST) Date: Wed, 15 Jun 2005 14:37:00 +0200 From: Jeremie Le Hen To: Doug White Message-ID: <20050615123700.GR30017@obiwan.tataz.chchile.org> References: <20050614143403.GL30017@obiwan.tataz.chchile.org> <20050614195053.F24745@carver.gumbysoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050614195053.F24745@carver.gumbysoft.com> User-Agent: Mutt/1.5.9i Cc: freebsd-current@FreeBSD.org, Jeremie Le Hen Subject: Re: panic while mkdir(2) in msdosfs (deget()) 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, 15 Jun 2005 12:37:26 -0000 Hi Doug, > > %%% > > #22 0xc055f075 in panic (fmt=0xc0729ff0 "wrong dirclust") > > at ../../../kern/kern_shutdown.c:537 > > #23 0xc050e207 in deget (pmp=0xc2914900, dirclust=366469, diroffset=0, > > depp=0xe50ecae8) at ../../../fs/msdosfs/msdosfs_denode.c:142 > > This is in a KASSERT so you must have INVARIANTS compiled in. What is the > value of dirclust and (*depp)->de_dirclust in this frame? Yes indeed, I have INVARIANTS compiled in. %%% (kgdb) up 23 #23 0xc050e207 in deget (pmp=0xc2914900, dirclust=366469, diroffset=0, depp=0xe50ecae8) at ../../../fs/msdosfs/msdosfs_denode.c:142 142 KASSERT((*depp)->de_dirclust == dirclust, ("wrong dirclust")); (kgdb) print (*depp)->de_dirclust $1 = 1152901 (kgdb) print dirclust $2 = 366469 %%% And I case you need more informations : %%% (kgdb) up #24 0xc05122c1 in createde (dep=0xe50ecafc, ddep=0xc2b30400, depp=0xe50ecae8, cnp=0xe50ecc18) at ../../../fs/msdosfs/msdosfs_lookup.c:673 673 return deget(pmp, dirclust, diroffset, depp); (kgdb) print *dep $1 = {de_vnode = 0x0, de_flag = 32, de_dev = 0x0, de_dirclust = 0, de_diroffset = 0, de_fndoffset = 0, de_fndcnt = 0, de_refcnt = 0, de_pmp = 0xc2914900, de_Name = "ZWAN ", de_Attributes = 16 '\020', de_LowerCase = 0 '\0', de_CHun = 109 'm', de_CTime = 26196, de_CDate = 13002, de_ADate = 13002, de_MTime = 26196, de_MDate = 13002, de_StartCluster = 366469, de_FileSize = 0, de_fc = {{fc_frcn = 0, fc_fsrcn = 0}, {fc_frcn = 0, fc_fsrcn = 0}}, de_modrev = 0, de_lockf = 0x0, de_inode = 0} (kgdb) print *ddep $2 = {de_vnode = 0xc2b40110, de_flag = 0, de_dev = 0x0, de_dirclust = 1330114, de_diroffset = 0, de_fndoffset = 864, de_fndcnt = 0, de_refcnt = 1, de_pmp = 0xc2914900, de_Name = ". ", de_Attributes = 16 '\020', de_LowerCase = 0 '\0', de_CHun = 35 '#', de_CTime = 26090, de_CDate = 13002, de_ADate = 13002, de_MTime = 26090, de_MDate = 13002, de_StartCluster = 1330114, de_FileSize = 32768, de_fc = {{fc_frcn = 0, fc_fsrcn = 1330114}, {fc_frcn = 0, fc_fsrcn = 1330114}}, de_modrev = 6639049896983, de_lockf = 0x0, de_inode = 635502592} (kgdb) print *cnp $2 = {cn_nameiop = 1, cn_flags = 50908168, cn_thread = 0xc2575190, cn_cred = 0xc2bdc200, cn_lkflags = 2, cn_pnbuf = 0xc2589000 "/mnt/mp3/rock/zwan", cn_nameptr = 0xc258900e "zwan", cn_namelen = 4, cn_consume = 0} %%% Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 13:11:18 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 170AA16A41F for ; Wed, 15 Jun 2005 13:11:18 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 053F843D49; Wed, 15 Jun 2005 13:11:18 +0000 (GMT) (envelope-from davidxu@freebsd.org) Received: from [127.0.0.1] (davidxu@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5FDBGgK049534; Wed, 15 Jun 2005 13:11:17 GMT (envelope-from davidxu@freebsd.org) Message-ID: <42B028EA.2020901@freebsd.org> Date: Wed, 15 Jun 2005 21:11:06 +0800 From: David Xu User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.8) Gecko/20050605 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Luigi Rizzo References: <20050615025447.A62971@xorpc.icir.org> In-Reply-To: <20050615025447.A62971@xorpc.icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: current@freebsd.org Subject: Re: bug or feature in userland thread library (O_NONBLOCK) 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, 15 Jun 2005 13:11:18 -0000 Luigi Rizzo wrote: >Probably a known issue, but I thought it worthwhile reporting it, >if nothing else for archival purposes. > >I think our userland thread library (libc_r) has some bugs in >handling descriptors. I can reproduce the behaviour on -current >and 4.x, and I believe it applies to 5.x too. > >Following is a description of the problem and some code to replicate it >The code includes a workaround but it is not particularly nice. > >Any better ideas ? I am not sure on what to do, but perhaps the >only sensible thing to do is to add a note with this workaround >(or better ones, if available) to our pthreads manpage > > > libc_r is deprecated on -CURRENT, I think start from 6.0, libc_r really should be moved to ports. ;) David Xu From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 13:15: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 8D02716A41C for ; Wed, 15 Jun 2005 13:15:24 +0000 (GMT) (envelope-from grafan@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id 49BBF43D48 for ; Wed, 15 Jun 2005 13:15:24 +0000 (GMT) (envelope-from grafan@gmail.com) Received: by wproxy.gmail.com with SMTP id 50so2583771wri for ; Wed, 15 Jun 2005 06:15:23 -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=GoglSEnVV63+dUQs6TTbUA9jJYpnRKGX0g6E1dR8zYsz3NPyRwTVDoK9TUuwzXcAHQ87JGH4qmtP7QV5dLoDJIno5xw0Zd1xWuJHi9EwrI0r6IKkUhimcdLQFlRQmFlyC+Dxxx1NK8EfGZ74MEuAsWZKXgQf4p3uOIzIUlsy79w= Received: by 10.54.36.8 with SMTP id j8mr2233779wrj; Wed, 15 Jun 2005 06:15:23 -0700 (PDT) Received: by 10.54.7.20 with HTTP; Wed, 15 Jun 2005 06:15:23 -0700 (PDT) Message-ID: <6eb82e050615061535bcc722@mail.gmail.com> Date: Wed, 15 Jun 2005 21:15:23 +0800 From: Rong-En Fan To: FreeBSD Current In-Reply-To: <423212CC.90800@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <42313286.2060206@errno.com> <423212CC.90800@centtech.com> Cc: Sam Leffler Subject: Re: [Fwd: cvs commit: src/sys/modules Makefile src/sys/conf files src/sys/modules/ath_rate_sample Makefile src/sys/i386/conf NOTES] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rong-En Fan List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2005 13:15:24 -0000 On 3/12/05, Eric Anderson wrote: > Sam Leffler wrote: > > If you''re an ath user on current it'd be great to get John some > > feedback on his rate control algorithm as it might be made the default. > > I've not tested it with 5210 or 5211 cards and it's likely to have som= e > > issues with them so beware. To use it be sure you have up to date code > > and then specify > > > > device ath_rate_sample > > > > instead of the normal ath_rate_onoe. >=20 >=20 > So far, I see no additional performance, in fact, upload speeds are about= 15-20% less compared to the onoe stuff. It's stable and seems to work ok = for me however. I have an 5212 card on IBM X31. Setting at the same location, the windows Atheros driver works very well. However, using FreeBSD the network sometime= s hang and saw some 'ath0 device timeout' at console. But, when I switched to= =20 ath_sample (orig is onoe) it works very well. Althought I didn't check the speed, the ssh connection does not hang any more. BTW, ifconfig ath0 list ap shows that S:N is about 8:0 to 13:0. My current is Jun 15. Cheers, Rong-En Fan From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 13:46: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 C11C216A41C for ; Wed, 15 Jun 2005 13:46:28 +0000 (GMT) (envelope-from boynagar@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 43CA243D55 for ; Wed, 15 Jun 2005 13:46:28 +0000 (GMT) (envelope-from boynagar@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so2443967rng for ; Wed, 15 Jun 2005 06:46:27 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=l/eSBgx3N66sgYpVTW2XgY+VkewD/4pDrPOZexU4x06qr+LOa6khRbH87B2BHguIM+oNhPnstA6nWKY+D3XPqMIy2W8UZYt1spXJ3Kx018nRMZysdR2Pd2aGooS9Yh8oVJQ5F+prwq0dNa2J160w7FcOPPkh7zJMooceZj0Dpgg= Received: by 10.38.149.63 with SMTP id w63mr2040902rnd; Wed, 15 Jun 2005 06:46:27 -0700 (PDT) Received: by 10.38.74.80 with HTTP; Wed, 15 Jun 2005 06:46:27 -0700 (PDT) Message-ID: Date: Wed, 15 Jun 2005 18:46:27 +0500 From: Katu To: freebsd-current@freebsd.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_690_3762997.1118843187562" X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Subject: Cannot boot June snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Katu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2005 13:46:28 -0000 ------=_Part_690_3762997.1118843187562 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hi all, I have an old HP Kayak XU (dual PII 300 MHz) that was happily running Windows NT 4, then Linux with 2.4 kernel, then FreeBSD 5.2.1. Today I tried to install 6-CURRENT snapshot from June, and during boot it repeats the same error messages regarding ahc0 over and over. Please see attached verbose boot log. What is the problem? Is it a hardware issue or something else? I still have the machine connected to serial console if you need more information. Thanks, Arthur ------=_Part_690_3762997.1118843187562-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 14:08: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 E474816A41C for ; Wed, 15 Jun 2005 14:08:44 +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 50DEF43D1F for ; Wed, 15 Jun 2005 14:08:44 +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 j5FE8Qtt090624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2005 18:08:31 +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 j5FE8P38008236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2005 18:08:26 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j5FE8OjZ008235; Wed, 15 Jun 2005 18:08:24 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 15 Jun 2005 18:08:24 +0400 From: Gleb Smirnoff To: Miguel Mendez Message-ID: <20050615140824.GA8060@cell.sick.ru> References: <20050608174408.551a0f79.flynn@energyhq.es.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050608174408.551a0f79.flynn@energyhq.es.eu.org> 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: xl0 and SNAP004 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, 15 Jun 2005 14:08:45 -0000 On Wed, Jun 08, 2005 at 05:44:08PM +0200, Miguel Mendez wrote: M> Hi all, M> M> I cvsuped my tree to HEAD last Sunday but the resulting kernel panic'ed M> as soon as ifconfig xl0 was ran. I have the vmcore saved but had to M> revert to 5.4 as I needed to use the box. I've downloaded the SNAP004 M> iso and copied the kernel from base to test it before attempting a real M> install, and this what I've seen. No panic but some kernel messages M> have poped up: This warning is a known problem. But the panic you are speaking about is not known. Do you have core saved? can you please show backtrace. -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 14:10:57 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 6DEFD16A41C for ; Wed, 15 Jun 2005 14:10:57 +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 D615D43D4C for ; Wed, 15 Jun 2005 14:10:56 +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 j5FEAsh1090688 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2005 18:10:55 +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 j5FEAst9008283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2005 18:10:54 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j5FEAm5K008282; Wed, 15 Jun 2005 18:10:48 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 15 Jun 2005 18:10:48 +0400 From: Gleb Smirnoff To: Stephan Uphoff Message-ID: <20050615141048.GB8060@cell.sick.ru> References: <20050609183835.GA9451@xor.obsecurity.org> <1118427576.27369.54212.camel@palm> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <1118427576.27369.54212.camel@palm> 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" , Kris Kennaway Subject: Re: mutex still spinning while in DDB on UP machine 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, 15 Jun 2005 14:10:57 -0000 On Fri, Jun 10, 2005 at 02:19:37PM -0400, Stephan Uphoff wrote: S> the following patch should help as it disables interrupts before S> entering the debugger. (amd64 probably has the same problems and I will S> take a look later today ) S> Could you give it a spin? I would like to check it in ASAP. Stephan, several of my panics have the same problem, as Kris described. If I again bump into this problem, I will test your patch and report. Thanks! -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 14:14: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 9DC2616A41F for ; Wed, 15 Jun 2005 14:14:57 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from mailserver.sandvine.com (sandvine.com [199.243.201.138]) by mx1.FreeBSD.org (Postfix) with ESMTP id A678643D48 for ; Wed, 15 Jun 2005 14:14:53 +0000 (GMT) (envelope-from emaste@phaedrus.sandvine.ca) Received: from labgw2.phaedrus.sandvine.com ([192.168.3.11]) by mailserver.sandvine.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 15 Jun 2005 10:14:47 -0400 Received: by labgw2.phaedrus.sandvine.com (Postfix, from userid 12627) id CAEC613631; Wed, 15 Jun 2005 10:14:47 -0400 (EDT) Date: Wed, 15 Jun 2005 10:14:47 -0400 From: Ed Maste To: freebsd-current@freebsd.org Message-ID: <20050615141447.GD95217@sandvine.com> References: <20050613192308.GA87640@sandvine.com> <20050614082039.GA2038@dragon.NUXI.org> <20050614224704.Y75797@mp2.macomnet.net> <20050614190854.GA12928@dragon.NUXI.org> <20050614235132.L76669@mp2.macomnet.net> <20050615023600.GA20721@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="NDin8bjvE/0mNLFQ" Content-Disposition: inline In-Reply-To: <20050615023600.GA20721@dragon.NUXI.org> User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 15 Jun 2005 14:14:48.0058 (UTC) FILETIME=[965BD5A0:01C571B4] Subject: Re: savecore(8) increments /var/crash/bounds on each boot 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, 15 Jun 2005 14:14:57 -0000 --NDin8bjvE/0mNLFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Jun 14, 2005 at 07:36:00PM -0700, David O'Brien wrote: > Do you understand the fix? How does lying in printheader() fix anything? > Moving the call to getbounds() back to the original location is the "fix" > but then it negates -vv. We shouldn't lie in printheader(). Fair enough, on dwhite's suggestion here's another try that splits the increment-and-write out from getbounds() so that the bounds value can be shown with -vv. -- Ed Maste, Sandvine Incorporated --NDin8bjvE/0mNLFQ Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="savecore.patch" --- savecore.c.orig 2005-06-13 16:19:41.000000000 -0400 +++ savecore.c 2005-06-15 09:41:52.000000000 -0400 @@ -145,35 +145,36 @@ if ((fp = fopen("bounds", "r")) == NULL) { syslog(LOG_WARNING, "unable to open bounds file, using 0"); - goto newfile; + return (ret); } if (fgets(buf, sizeof buf, fp) == NULL) { syslog(LOG_WARNING, "unable to read from bounds, using 0"); fclose(fp); - goto newfile; + return (ret); } errno = 0; ret = (int)strtol(buf, NULL, 10); if (ret == 0 && (errno == EINVAL || errno == ERANGE)) syslog(LOG_WARNING, "invalid value found in bounds, using 0"); + return (ret); +} -newfile: +static void +writebounds(int bounds) { + FILE *fp; if ((fp = fopen("bounds", "w")) == NULL) { syslog(LOG_WARNING, "unable to write to bounds file: %m"); - goto done; + return; } if (verbose) - printf("bounds number: %d\n", ret); + printf("bounds number: %d\n", bounds); - fprintf(fp, "%d\n", (ret + 1)); + fprintf(fp, "%d\n", bounds); fclose(fp); - -done: - return (ret); } /* @@ -373,6 +374,8 @@ goto closefd; } + writebounds(bounds+1); + sprintf(buf, "info.%d", bounds); /* --NDin8bjvE/0mNLFQ-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 14:51: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 CEEAB16A41C for ; Wed, 15 Jun 2005 14:51:54 +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 9BC3743D1D for ; Wed, 15 Jun 2005 14:51:52 +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 RAA10094; Wed, 15 Jun 2005 17:51:45 +0300 (EEST) (envelope-from avg@icyb.net.ua) Message-ID: <42B04080.9090504@icyb.net.ua> Date: Wed, 15 Jun 2005 17:51:44 +0300 From: Andriy Gapon User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050328) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Emanuel Strobl References: <1118845416.00316114.1118834401@10.7.7.3> In-Reply-To: <1118845416.00316114.1118834401@10.7.7.3> Content-Type: text/plain; charset=KOI8-U Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: PANIC: udf / lockmgr: locking against myself 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, 15 Jun 2005 14:51:54 -0000 on 15.06.2005 14:19 Emanuel Strobl said the following: > Hello, > > I tried to read a backup DVD with UDF filesystem and I get the following > panick with yesterdays -current: > > mount_udf /dev/acd1 /mnt > # cd /mnt > # ls > Various Artists > # cd Various > panic: lockmgr: locking against myself I can reproduce this panic on week old current under qemu emulation. Simple mount and ls do it. -- Andriy Gapon From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 15:10:39 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 A43E016A41C for ; Wed, 15 Jun 2005 15:10:39 +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 5CCA343D1F for ; Wed, 15 Jun 2005 15:10:39 +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 j5FFFBLw019073; Wed, 15 Jun 2005 09:15:11 -0600 (MDT) (envelope-from scottl@samsco.org) Message-ID: <42B04457.1070103@samsco.org> Date: Wed, 15 Jun 2005 09:08:07 -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: Andriy Gapon References: <1118845416.00316114.1118834401@10.7.7.3> <42B04080.9090504@icyb.net.ua> In-Reply-To: <42B04080.9090504@icyb.net.ua> 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: Emanuel Strobl , freebsd-current@freebsd.org Subject: Re: PANIC: udf / lockmgr: locking against myself 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, 15 Jun 2005 15:10:39 -0000 Andriy Gapon wrote: > on 15.06.2005 14:19 Emanuel Strobl said the following: > >>Hello, >> >>I tried to read a backup DVD with UDF filesystem and I get the following >>panick with yesterdays -current: >> >>mount_udf /dev/acd1 /mnt >># cd /mnt >># ls >>Various Artists >># cd Various >>panic: lockmgr: locking against myself > > > I can reproduce this panic on week old current under qemu emulation. > Simple mount and ls do it. > Probably fallout from the VFS work. I'll look at it =-( Scott From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 15:49:52 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 5FED816A41C for ; Wed, 15 Jun 2005 15:49:52 +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 C8F8143D67 for ; Wed, 15 Jun 2005 15:49:51 +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 j5FFnnb5092934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 15 Jun 2005 19:49:50 +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 j5FFnm4V009606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2005 19:49:49 +0400 (MSD) (envelope-from glebius@FreeBSD.org) Received: (from glebius@localhost) by cell.sick.ru (8.13.1/8.13.1/Submit) id j5FFnm7j009605; Wed, 15 Jun 2005 19:49:48 +0400 (MSD) (envelope-from glebius@FreeBSD.org) X-Authentication-Warning: cell.sick.ru: glebius set sender to glebius@FreeBSD.org using -f Date: Wed, 15 Jun 2005 19:49:48 +0400 From: Gleb Smirnoff To: Stephan Uphoff Message-ID: <20050615154948.GA9561@cell.sick.ru> References: <20050609183835.GA9451@xor.obsecurity.org> <1118427576.27369.54212.camel@palm> <20050615141048.GB8060@cell.sick.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20050615141048.GB8060@cell.sick.ru> 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" , Kris Kennaway Subject: Re: mutex still spinning while in DDB on UP machine 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, 15 Jun 2005 15:49:52 -0000 On Wed, Jun 15, 2005 at 06:10:48PM +0400, Gleb Smirnoff wrote: T> On Fri, Jun 10, 2005 at 02:19:37PM -0400, Stephan Uphoff wrote: T> S> the following patch should help as it disables interrupts before T> S> entering the debugger. (amd64 probably has the same problems and I will T> S> take a look later today ) T> S> Could you give it a spin? I would like to check it in ASAP. T> T> Stephan, several of my panics have the same problem, as Kris described. T> If I again bump into this problem, I will test your patch and report. T> T> Thanks! Stephan, the patch works fine! Thanks again! -- Totus tuus, Glebius. GLEBIUS-RIPN GLEB-RIPE From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 16:07: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 444AC16A41C; Wed, 15 Jun 2005 16:07:42 +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 EB0CA43D68; Wed, 15 Jun 2005 16:07:41 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5FG7fv0055301; Wed, 15 Jun 2005 09:07:41 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5FG7fUJ055300; Wed, 15 Jun 2005 09:07:41 -0700 (PDT) (envelope-from obrien) Date: Wed, 15 Jun 2005 09:07:41 -0700 From: "David O'Brien" To: Harti Brandt Message-ID: <20050615160741.GA55062@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Harti Brandt , freebsd-current@freebsd.org, Emanuel Strobl , Lyndon Nerenberg References: <200504262010.49509@harrymail> <20050429200029.GC232@cirb503493.alcatel.com.au> <200506141824.17451@harrymail> <20050614185923.GA12375@dragon.NUXI.org> <20050615054209.L29741@beagle.kn.op.dlr.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050615054209.L29741@beagle.kn.op.dlr.de> 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: Emanuel Strobl , freebsd-current@freebsd.org, Lyndon Nerenberg Subject: Re: groff alternative? 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: Wed, 15 Jun 2005 16:07:42 -0000 On Wed, Jun 15, 2005 at 05:47:26AM +0000, Harti Brandt wrote: > On Tue, 14 Jun 2005, David O'Brien wrote: > > DO>On Tue, Jun 14, 2005 at 06:24:07PM +0200, Emanuel Strobl wrote: > DO>> today I read a news article (http://www.heise.de/newsticker/meldung/60600) > DO>> about OpenSolaris beeing released, but is there also the groff alternative > DO>> included? > DO>> I'd love to see a lean replacment for our current gnu version. > DO> > DO>Before everyone gets all happy thinking we can incorporate all kinds of > DO>bits from Open Solaris - one should read the license agrement first. > DO> > DO> COMMON DEVELOPMENT AND DISTRIBUTION LICENSE Version 1.0 > DO> .. > DO> 3.1. Availability of Source Code. > DO> Any Covered Software that You distribute or otherwise make available > DO> in Executable form must also be made available in Source Code form > DO> and that Source Code form must be distributed only under the terms of > DO> this License. > DO> > DO>this puts the CDDL1.0 in the same boat as GPL'ed code from a BSD stand > DO>point. > > I think that's not entirely correct. .. > In this case you don't need to distribute the pieces > that are covered by the other license. .. > You don't need to distribute the new file > with that function. Of course that new file will not be CDDL covered. I never said CDDL was viral. It is like the GPL (LGPL if you like) in that you must deliver the source with the binary. For key userland pieces or kernel subsystems this goes against our philosophy. For complete utilities, such as groff, CDDL is >< better than GPL as the end result is the 99.9% same. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 16:59: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 5A33E16A41C for ; Wed, 15 Jun 2005 16:59:35 +0000 (GMT) (envelope-from boynagar@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id C03BC43D48 for ; Wed, 15 Jun 2005 16:59:34 +0000 (GMT) (envelope-from boynagar@gmail.com) Received: by rproxy.gmail.com with SMTP id a41so2511100rng for ; Wed, 15 Jun 2005 09:59:34 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:references; b=sP9CHVLuIJdPdVxFlTzEd7M1zgz+baVfMYfjy/SvUpCi460GiFPJNXik9BnRkwLMBjFj7ypTQiBqLMq+qht7KsGWd9lQwpZU5SVIg+281Se5WmmIqjVFF9r91NNYfvWnG4SpwCeHlZmYnIwUZk0Gr8ltn6UKfG6HtqlF+ZuhLBU= Received: by 10.38.24.21 with SMTP id 21mr2133169rnx; Wed, 15 Jun 2005 09:59:34 -0700 (PDT) Received: by 10.38.74.80 with HTTP; Wed, 15 Jun 2005 09:59:34 -0700 (PDT) Message-ID: Date: Wed, 15 Jun 2005 21:59:34 +0500 From: Katu To: freebsd-current@freebsd.org In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_890_22892878.1118854774097" References: Subject: Re: Cannot boot June snapshot X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Katu List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2005 16:59:35 -0000 ------=_Part_890_22892878.1118854774097 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline >=20 > I have an old HP Kayak XU (dual PII 300 MHz) that was happily running > Windows NT 4, then Linux with 2.4 kernel, then FreeBSD 5.2.1. Today I > tried to install 6-CURRENT snapshot from June, and during boot it > repeats the same error messages regarding ahc0 over and over. Please > see attached verbose boot log. >=20 > What is the problem? Is it a hardware issue or something else? I still > have the machine connected to serial console if you need more > information. >=20 > Thanks, >=20 > Arthur >=20 I just tried with 5.4-RELEASE, it didn't work too, so I guess something changed between 5.2.1 and 5.3. Attached is the boot log from 6.0 snapshot ------=_Part_890_22892878.1118854774097 Content-Type: application/octet-stream; name="boot.log" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="boot.log" T0sgYm9vdCAtdgpHREI6IG5vIGRlYnVnIHBvcnRzIHByZXNlbnQKS0RCOiBkZWJ1Z2dlciBiYWNr ZW5kczogZGRiCktEQjogY3VycmVudCBiYWNrZW5kOiBkZGIKU01BUCB0eXBlPTAxIGJhc2U9MDAw MDAwMDAwMDAwMDAwMCBsZW49MDAwMDAwMDAwMDA5ZTQwMApTTUFQIHR5cGU9MDIgYmFzZT0wMDAw MDAwMDAwMDllNDAwIGxlbj0wMDAwMDAwMDAwMDAxYzAwClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAw MDAwMDAwZjBjMDAgbGVuPTAwMDAwMDAwMDAwMGY0MDAKU01BUCB0eXBlPTAxIGJhc2U9MDAwMDAw MDAwMDEwMDAwMCBsZW49MDAwMDAwMDAwN2YwMDAwMApTTUFQIHR5cGU9MDIgYmFzZT0wMDAwMDAw MGZlYzAwMDAwIGxlbj0wMDAwMDAwMDAwMDEwMDAwClNNQVAgdHlwZT0wMiBiYXNlPTAwMDAwMDAw ZmVlMDAwMDAgbGVuPTAwMDAwMDAwMDAwMDEwMDAKU01BUCB0eXBlPTAyIGJhc2U9MDAwMDAwMDBm ZmZlMDAwMCBsZW49MDAwMDAwMDAwMDAyMDAwMApDb3B5cmlnaHQgKGMpIDE5OTItMjAwNSBUaGUg RnJlZUJTRCBQcm9qZWN0LgpDb3B5cmlnaHQgKGMpIDE5NzksIDE5ODAsIDE5ODMsIDE5ODYsIDE5 ODgsIDE5ODksIDE5OTEsIDE5OTIsIDE5OTMsIDE5OTQKICAgICAgICBUaGUgUmVnZW50cyBvZiB0 aGUgVW5pdmVyc2l0eSBvZiBDYWxpZm9ybmlhLiBBbGwgcmlnaHRzIHJlc2VydmVkLgpGcmVlQlNE IDYuMC1DVVJSRU5ULVNOQVAwMDQgIzA6IFRodSBKdW4gIDIgMDY6MTI6NTEgVVRDIDIwMDUKICAg IHJvb3RAd3YxdS5zYW1zY28uaG9tZTovdXNyL29iai91c3Ivc3JjL3N5cy9HRU5FUklDCldBUk5J Tkc6IFdJVE5FU1Mgb3B0aW9uIGVuYWJsZWQsIGV4cGVjdCByZWR1Y2VkIHBlcmZvcm1hbmNlLgpQ cmVsb2FkZWQgZWxmIGtlcm5lbCAiL2Jvb3Qva2VybmVsL2tlcm5lbCIgYXQgMHhjMGViMjAwMC4K UHJlbG9hZGVkIG1mc19yb290ICIvYm9vdC9tZnNyb290IiBhdCAweGMwZWIyMTZjLgpNUCBDb25m aWd1cmF0aW9uIFRhYmxlIHZlcnNpb24gMS40IGZvdW5kIGF0IDB4YzAwOWU1NjAKQVBJQzogVXNp bmcgdGhlIE1QVGFibGUgZW51bWVyYXRvci4KU01QOiBBZGRlZCBDUFUgMSAoQlNQKQpTTVA6IEFk ZGVkIENQVSAwIChBUCkKTVBUYWJsZTogPEhQICAgICAgIFhVL1hXICAgICAgID4KQ2FsaWJyYXRp bmcgY2xvY2socykgLi4uIGk4MjU0IGNsb2NrOiAxMTkzMTk0IEh6CkNMS19VU0VfSTgyNTRfQ0FM SUJSQVRJT04gbm90IHNwZWNpZmllZCAtIHVzaW5nIGRlZmF1bHQgZnJlcXVlbmN5ClRpbWVjb3Vu dGVyICJpODI1NCIgZnJlcXVlbmN5IDExOTMxODIgSHogcXVhbGl0eSAwCkNhbGlicmF0aW5nIFRT QyBjbG9jayAuLi4gVFNDIGNsb2NrOiAzMDAwMTI0NTIgSHoKQ1BVOiBQZW50aXVtIElJL1BlbnRp dW0gSUkgWGVvbi9DZWxlcm9uICgzMDAuMDEtTUh6IDY4Ni1jbGFzcyBDUFUpCiAgT3JpZ2luID0g IkdlbnVpbmVJbnRlbCIgIElkID0gMHg2MzQgIFN0ZXBwaW5nID0gNAogIEZlYXR1cmVzPTB4ODBm YmZmPEZQVSxWTUUsREUsUFNFLFRTQyxNU1IsUEFFLE1DRSxDWDgsQVBJQyxTRVAsTVRSUixQR0Us TUNBLENNTwpWLE1NWD4KcmVhbCBtZW1vcnkgID0gMTM0MjE3NzI4ICgxMjggTUIpClBoeXNpY2Fs IG1lbW9yeSBjaHVuayhzKToKMHgwMDAwMDAwMDAwMDAxMDAwIC0gMHgwMDAwMDAwMDAwMDlkZmZm LCA2NDMwNzIgYnl0ZXMgKDE1NyBwYWdlcykKMHgwMDAwMDAwMDAwMTAwMDAwIC0gMHgwMDAwMDAw MDAwM2ZmZmZmLCAzMTQ1NzI4IGJ5dGVzICg3NjggcGFnZXMpCjB4MDAwMDAwMDAwMTAyODAwMCAt IDB4MDAwMDAwMDAwN2Q4ZmZmZiwgMTE0NzIwNzY4IGJ5dGVzICgyODAwOCBwYWdlcykKYXZhaWwg bWVtb3J5ID0gMTE3NjkwMzY4ICgxMTIgTUIpCkFQSUMgSUQ6IHBoeXNpY2FsIDAsIGxvZ2ljYWwg MDowCkFQSUMgSUQ6IHBoeXNpY2FsIDEsIGxvZ2ljYWwgMDoxCkZyZWVCU0QvU01QOiBNdWx0aXBy b2Nlc3NvciBTeXN0ZW0gRGV0ZWN0ZWQ6IDIgQ1BVcwogY3B1MCAoQlNQKTogQVBJQyBJRDogIDEK IGNwdTEgKEFQKTogQVBJQyBJRDogIDAKYmlvczMyOiBGb3VuZCBCSU9TMzIgU2VydmljZSBEaXJl Y3RvcnkgaGVhZGVyIGF0IDB4YzAwZjc3YzAKYmlvczMyOiBFbnRyeSA9IDB4ZmQ3N2QgKGMwMGZk NzdkKSAgUmV2ID0gMCAgTGVuID0gMQpwY2liaW9zOiBQQ0kgQklPUyBlbnRyeSBhdCAweGZkNzEw KzB4Mjg5CnBucGJpb3M6IEZvdW5kIFBuUCBCSU9TIGRhdGEgYXQgMHhjMDBmNzdmMApwbnBiaW9z OiBFbnRyeSA9IGYwMDAwOmI2ZWUgIFJldiA9IDEuMApPdGhlciBCSU9TIHNpZ25hdHVyZXMgZm91 bmQ6CmlvYXBpYzA6IEFzc3VtaW5nIGludGJhc2Ugb2YgMAppb2FwaWMwOiBSb3V0aW5nIGV4dGVy bmFsIDgyNTlBJ3MgLT4gaW50cGluIDAKaW9hcGljMDogaW50cGluIDAgLT4gRXh0SU5UIChlZGdl LCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMSAtPiBJU0EgSVJRIDEgKGVkZ2UsIGhpZ2gpCmlvYXBp YzA6IGludHBpbiAyIC0+IElTQSBJUlEgMiAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDMg LT4gSVNBIElSUSAzIChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gNCAtPiBJU0EgSVJRIDQg KGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiA1IC0+IElTQSBJUlEgNSAoZWRnZSwgaGlnaCkK aW9hcGljMDogaW50cGluIDYgLT4gSVNBIElSUSA2IChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRw aW4gNyAtPiBJU0EgSVJRIDcgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiA4IC0+IElTQSBJ UlEgOCAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDkgLT4gSVNBIElSUSA5IChlZGdlLCBo aWdoKQppb2FwaWMwOiBpbnRwaW4gMTAgLT4gSVNBIElSUSAxMCAoZWRnZSwgaGlnaCkKaW9hcGlj MDogaW50cGluIDExIC0+IElTQSBJUlEgMTEgKGVkZ2UsIGhpZ2gpCmlvYXBpYzA6IGludHBpbiAx MiAtPiBJU0EgSVJRIDEyIChlZGdlLCBoaWdoKQppb2FwaWMwOiBpbnRwaW4gMTMgLT4gSVNBIElS USAxMyAoZWRnZSwgaGlnaCkKaW9hcGljMDogaW50cGluIDE0IC0+IElTQSBJUlEgMTQgKGVkZ2Us IGhpZ2gpCmlvYXBpYzA6IGludHBpbiAxNSAtPiBJU0EgSVJRIDE1IChlZGdlLCBoaWdoKQppb2Fw aWMwOiBpbnRwaW4gMTYgLT4gUENJIElSUSAxNiAobGV2ZWwsIGxvdykKaW9hcGljMDogaW50cGlu IDE3IC0+IFBDSSBJUlEgMTcgKGxldmVsLCBsb3cpCmlvYXBpYzA6IGludHBpbiAxOCAtPiBQQ0kg SVJRIDE4IChsZXZlbCwgbG93KQppb2FwaWMwOiBpbnRwaW4gMTkgLT4gUENJIElSUSAxOSAobGV2 ZWwsIGxvdykKaW9hcGljMDogaW50cGluIDIwIC0+IFBDSSBJUlEgMjAgKGxldmVsLCBsb3cpCmlv YXBpYzA6IGludHBpbiAyMSAtPiBQQ0kgSVJRIDIxIChsZXZlbCwgbG93KQppb2FwaWMwOiBpbnRw aW4gMjIgLT4gUENJIElSUSAyMiAobGV2ZWwsIGxvdykKaW9hcGljMDogaW50cGluIDIzIC0+IFBD SSBJUlEgMjMgKGxldmVsLCBsb3cpCmlvYXBpYzA6IGludHBpbiAxIGJ1cyBJU0EKaW9hcGljMDog aW50cGluIDEgdHJpZ2dlcjogZWRnZQppb2FwaWMwOiBpbnRwaW4gMSBwb2xhcml0eTogaGlnaApp b2FwaWMwOiBpbnRwaW4gMiBidXMgSVNBCmlvYXBpYzA6IFJvdXRpbmcgSVJRIDAgLT4gaW50cGlu IDIKaW9hcGljMDogaW50cGluIDIgdHJpZ2dlcjogZWRnZQppb2FwaWMwOiBpbnRwaW4gMiBwb2xh cml0eTogaGlnaAppb2FwaWMwOiBpbnRwaW4gMyBidXMgSVNBCmlvYXBpYzA6IGludHBpbiAzIHRy aWdnZXI6IGVkZ2UKaW9hcGljMDogaW50cGluIDMgcG9sYXJpdHk6IGhpZ2gKaW9hcGljMDogaW50 cGluIDQgYnVzIElTQQppb2FwaWMwOiBpbnRwaW4gNCB0cmlnZ2VyOiBlZGdlCmlvYXBpYzA6IGlu dHBpbiA0IHBvbGFyaXR5OiBoaWdoCmlvYXBpYzA6IGludHBpbiA1IGJ1cyBJU0EKaW9hcGljMDog aW50cGluIDUgdHJpZ2dlcjogZWRnZQppb2FwaWMwOiBpbnRwaW4gNSBwb2xhcml0eTogaGlnaApp b2FwaWMwOiBpbnRwaW4gNiBidXMgSVNBCmlvYXBpYzA6IGludHBpbiA2IHRyaWdnZXI6IGVkZ2UK aW9hcGljMDogaW50cGluIDYgcG9sYXJpdHk6IGhpZ2gKaW9hcGljMDogaW50cGluIDcgYnVzIElT QQppb2FwaWMwOiBpbnRwaW4gNyB0cmlnZ2VyOiBlZGdlCmlvYXBpYzA6IGludHBpbiA3IHBvbGFy aXR5OiBoaWdoCmlvYXBpYzA6IGludHBpbiA4IGJ1cyBJU0EKaW9hcGljMDogaW50cGluIDggdHJp Z2dlcjogZWRnZQppb2FwaWMwOiBpbnRwaW4gOCBwb2xhcml0eTogaGlnaAppb2FwaWMwOiBpbnRw aW4gMTYgYnVzIFBDSQppb2FwaWMwOiBpbnRwaW4gMTYgdHJpZ2dlcjogbGV2ZWwKaW9hcGljMDog aW50cGluIDE2IHBvbGFyaXR5OiBsb3cKaW9hcGljMDogaW50cGluIDE5IGJ1cyBQQ0kKaW9hcGlj MDogaW50cGluIDE5IHRyaWdnZXI6IGxldmVsCmlvYXBpYzA6IGludHBpbiAxOSBwb2xhcml0eTog bG93CmlvYXBpYzA6IGludHBpbiAxMSBidXMgSVNBCmlvYXBpYzA6IGludHBpbiAxMSB0cmlnZ2Vy OiBlZGdlCmlvYXBpYzA6IGludHBpbiAxMSBwb2xhcml0eTogaGlnaAppb2FwaWMwOiBpbnRwaW4g MTIgYnVzIElTQQppb2FwaWMwOiBpbnRwaW4gMTIgdHJpZ2dlcjogZWRnZQppb2FwaWMwOiBpbnRw aW4gMTIgcG9sYXJpdHk6IGhpZ2gKaW9hcGljMDogaW50cGluIDEzIGJ1cyBJU0EKaW9hcGljMDog aW50cGluIDEzIHRyaWdnZXI6IGVkZ2UKaW9hcGljMDogaW50cGluIDEzIHBvbGFyaXR5OiBoaWdo CmlvYXBpYzA6IGludHBpbiAxNCBidXMgSVNBCmlvYXBpYzA6IGludHBpbiAxNCB0cmlnZ2VyOiBl ZGdlCmlvYXBpYzA6IGludHBpbiAxNCBwb2xhcml0eTogaGlnaAppb2FwaWMwOiBpbnRwaW4gMTUg YnVzIElTQQppb2FwaWMwOiBpbnRwaW4gMTUgdHJpZ2dlcjogZWRnZQppb2FwaWMwOiBpbnRwaW4g MTUgcG9sYXJpdHk6IGhpZ2gKaW9hcGljMDogaW50cGluIDE5IGJ1cyBQQ0kKaW9hcGljMDogaW50 cGluIDE5IHRyaWdnZXI6IGxldmVsCmlvYXBpYzA6IGludHBpbiAxOSBwb2xhcml0eTogbG93Cmlv YXBpYzA6IGludHBpbiAxOCBidXMgUENJCmlvYXBpYzA6IGludHBpbiAxOCB0cmlnZ2VyOiBsZXZl bAppb2FwaWMwOiBpbnRwaW4gMTggcG9sYXJpdHk6IGxvdwppb2FwaWMwOiBpbnRwaW4gMTYgYnVz IFBDSQppb2FwaWMwOiBpbnRwaW4gMTYgdHJpZ2dlcjogbGV2ZWwKaW9hcGljMDogaW50cGluIDE2 IHBvbGFyaXR5OiBsb3cKaW9hcGljMDogaW50cGluIDE4IGJ1cyBQQ0kKaW9hcGljMDogaW50cGlu IDE4IHRyaWdnZXI6IGxldmVsCmlvYXBpYzA6IGludHBpbiAxOCBwb2xhcml0eTogbG93CmxhcGlj OiBSb3V0aW5nIEV4dElOVCAtPiBMSU5UMApsYXBpYzogTElOVDAgdHJpZ2dlcjogZWRnZQpsYXBp YzogTElOVDAgcG9sYXJpdHk6IGhpZ2gKbGFwaWM6IFJvdXRpbmcgTk1JIC0+IExJTlQxCmxhcGlj OiBMSU5UMSB0cmlnZ2VyOiBlZGdlCmxhcGljOiBMSU5UMSBwb2xhcml0eTogaGlnaAppb2FwaWMw IDxWZXJzaW9uIDEuMT4gaXJxcyAwLTIzIG9uIG1vdGhlcmJvYXJkCmNwdTAgQlNQOgogICAgIElE OiAweDAxMDAwMDAwICAgVkVSOiAweDAwMDQwMDExIExEUjogMHgwMjAwMDAwMCBERlI6IDB4MGZm ZmZmZmYKICBsaW50MDogMHgwMDAxMDcwMCBsaW50MTogMHgwMDAwMDQwMCBUUFI6IDB4MDAwMDAw MDAgU1ZSOiAweDAwMDAwMWZmCiAgdGltZXI6IDB4MDAwMTAwZWYgdGhlcm06IDB4MDAwMDAwMDAg ZXJyOiAweDAwMDEwMDAwIHBjbTogMHgwMDAxMDAwMAp3bGFuOiA8ODAyLjExIExpbmsgTGF5ZXI+ Cm1lbTogPG1lbW9yeT4KUGVudGl1bSBQcm8gTVRSUiBzdXBwb3J0IGVuYWJsZWQKbnVsbDogPG51 bGwgZGV2aWNlLCB6ZXJvIGRldmljZT4KcmFuZG9tOiA8ZW50cm9weSBzb3VyY2UsIFNvZnR3YXJl LCBZYXJyb3c+Cm5mc2xvY2s6IHBzZXVkby1kZXZpY2UKaW86IDxJL08+Cm5weDA6IFtGQVNUXQpu cHgwOiA8bWF0aCBwcm9jZXNzb3I+IG9uIG1vdGhlcmJvYXJkCm5weDA6IElOVCAxNiBpbnRlcmZh Y2UKY3B1MCBvbiBtb3RoZXJib2FyZApjcHUxIG9uIG1vdGhlcmJvYXJkCnBjaV9vcGVuKDEpOiAg ICBtb2RlIDEgYWRkciBwb3J0ICgweDBjZjgpIGlzIDB4ODAwMDAwNWMKcGNpX29wZW4oMWEpOiAg IG1vZGUxcmVzPTB4ODAwMDAwMDAgKDB4ODAwMDAwMDApCnBjaV9jZmdjaGVjazogICBkZXZpY2Ug MCBbY2xhc3M9MDYwMDAwXSBbaGRyPTAwXSBpcyB0aGVyZSAoaWQ9NzE4MDgwODYpCnBjaWJpb3M6 IEJJT1MgdmVyc2lvbiAyLjEwCkZvdW5kICRQSVIgdGFibGUsIDEwIGVudHJpZXMgYXQgMHhjMDBm ZGYyMApQQ0ktT25seSBJbnRlcnJ1cHRzOiBub25lCkxvY2F0aW9uICBCdXMgRGV2aWNlIFBpbiAg TGluayAgSVJRcwpzbG90IDEgICAgICAwICAgMTYgICAgQSAgIDB4NjEgIDMgNCA1IDYgNyA5IDEw IDExIDEyIDE0IDE1CnNsb3QgMSAgICAgIDAgICAxNiAgICBCICAgMHg2MiAgMyA0IDUgNiA3IDkg MTAgMTEgMTIgMTQgMTUKc2xvdCAxICAgICAgMCAgIDE2ICAgIEMgICAweDYzICAzIDQgNSA2IDcg OSAxMCAxMSAxMiAxNCAxNQpzbG90IDEgICAgICAwICAgMTYgICAgRCAgIDB4NjAgIDMgNCA1IDYg NyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMiAgICAgIDAgICAxNyAgICBBICAgMHg2MiAgMyA0IDUg NiA3IDkgMTAgMTEgMTIgMTQgMTUKc2xvdCAyICAgICAgMCAgIDE3ICAgIEIgICAweDYzICAzIDQg NSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpzbG90IDIgICAgICAwICAgMTcgICAgQyAgIDB4NjAgIDMg NCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMiAgICAgIDAgICAxNyAgICBEICAgMHg2MSAg MyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKc2xvdCAzICAgICAgMCAgIDE4ICAgIEEgICAweDYw ICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpzbG90IDMgICAgICAwICAgMTggICAgQiAgIDB4 NjEgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgMyAgICAgIDAgICAxOCAgICBDICAg MHg2MiAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKc2xvdCAzICAgICAgMCAgIDE4ICAgIEQg ICAweDYzICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpzbG90IDQgICAgICAwICAgMTkgICAg QSAgIDB4NjEgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CnNsb3QgNCAgICAgIDAgICAxOSAg ICBCICAgMHg2MiAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKc2xvdCA0ICAgICAgMCAgIDE5 ICAgIEMgICAweDYzICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpzbG90IDQgICAgICAwICAg MTkgICAgRCAgIDB4NjAgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVkICAgIDAg ICAgNyAgICBBICAgMHg2MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKZW1iZWRkZWQgICAg MCAgICA3ICAgIEIgICAweDYxICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQplbWJlZGRlZCAg ICAwICAgIDcgICAgQyAgIDB4NjIgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CmVtYmVkZGVk ICAgIDAgICAgNyAgICBEICAgMHg2MyAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUKc2xvdCAz MyAgICAgMSAgICAwICAgIEEgICAweDYyICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAxNQpzbG90 IDMzICAgICAxICAgIDAgICAgQiAgIDB4NjMgIDMgNCA1IDYgNyA5IDEwIDExIDEyIDE0IDE1CmVt YmVkZGVkICAgIDAgICAgOCAgICBBICAgMHg2MCAgMyA0IDUgNiA3IDkgMTAgMTEgMTIgMTQgMTUK ZW1iZWRkZWQgICAgMCAgICA5ICAgIEEgICAweDYzICAzIDQgNSA2IDcgOSAxMCAxMSAxMiAxNCAx NQpwY2liMDogPE1QVGFibGUgSG9zdC1QQ0kgYnJpZGdlPiBwY2lidXMgMCBvbiBtb3RoZXJib2Fy ZApwY2kwOiA8UENJIGJ1cz4gb24gcGNpYjAKcGNpMDogcGh5c2ljYWwgYnVzPTAKZm91bmQtPiB2 ZW5kb3I9MHg4MDg2LCBkZXY9MHg3MTgwLCByZXZpZD0weDAzCiAgICAgICAgYnVzPTAsIHNsb3Q9 MCwgZnVuYz0wCiAgICAgICAgY2xhc3M9MDYtMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZkZXY9MAog ICAgICAgIGNtZHJlZz0weDAxMDYsIHN0YXRyZWc9MHgyMjkwLCBjYWNoZWxuc3o9MCAoZHdvcmRz KQogICAgICAgIGxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwMCAoMCBucyksIG1h eGxhdD0weDAwICgwIG5zKQogICAgICAgIG1hcFsxMF06IHR5cGUgMywgcmFuZ2UgMzIsIGJhc2Ug ZjgwMDAwMDAsIHNpemUgMjYsIGVuYWJsZWQKZm91bmQtPiB2ZW5kb3I9MHg4MDg2LCBkZXY9MHg3 MTgxLCByZXZpZD0weDAzCiAgICAgICAgYnVzPTAsIHNsb3Q9MSwgZnVuYz0wCiAgICAgICAgY2xh c3M9MDYtMDQtMDAsIGhkcnR5cGU9MHgwMSwgbWZkZXY9MAogICAgICAgIGNtZHJlZz0weDAwMGYs IHN0YXRyZWc9MHgwMmEwLCBjYWNoZWxuc3o9MCAoZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4 NjAgKDI4ODAgbnMpLCBtaW5nbnQ9MHgwYyAoMzAwMCBucyksIG1heGxhdD0weDAwICgwIG5zKQpm b3VuZC0+IHZlbmRvcj0weDgwODYsIGRldj0weDcxMTAsIHJldmlkPTB4MDEKICAgICAgICBidXM9 MCwgc2xvdD03LCBmdW5jPTAKICAgICAgICBjbGFzcz0wNi0wMS0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0xCiAgICAgICAgY21kcmVnPTB4MDEwZiwgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0w IChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5z KSwgbWF4bGF0PTB4MDAgKDAgbnMpCmZvdW5kLT4gdmVuZG9yPTB4ODA4NiwgZGV2PTB4NzExMSwg cmV2aWQ9MHgwMQogICAgICAgIGJ1cz0wLCBzbG90PTcsIGZ1bmM9MQogICAgICAgIGNsYXNzPTAx LTAxLTgwLCBoZHJ0eXBlPTB4MDAsIG1mZGV2PTAKICAgICAgICBjbWRyZWc9MHgwMDA1LCBzdGF0 cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTAgKGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDQwICgx OTIwIG5zKSwgbWluZ250PTB4MDAgKDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKICAgICAgICBt YXBbMjBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBmY2IwLCBzaXplICA0LCBlbmFibGVk CmZvdW5kLT4gdmVuZG9yPTB4ODA4NiwgZGV2PTB4NzExMiwgcmV2aWQ9MHgwMQogICAgICAgIGJ1 cz0wLCBzbG90PTcsIGZ1bmM9MgogICAgICAgIGNsYXNzPTBjLTAzLTAwLCBoZHJ0eXBlPTB4MDAs IG1mZGV2PTAKICAgICAgICBjbWRyZWc9MHgwMDAxLCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6 PTAgKGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDAg KDAgbnMpLCBtYXhsYXQ9MHgwMCAoMCBucykKICAgICAgICBpbnRwaW49ZCwgaXJxPTEwCiAgICAg ICAgbWFwWzIwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwZmNlMCwgc2l6ZSAgNSwgZW5h YmxlZApwY2liMDogc2xvdCA3IElOVEQgcm91dGVkIHRvIGlycSAxOQpmb3VuZC0+IHZlbmRvcj0w eDgwODYsIGRldj0weDcxMTMsIHJldmlkPTB4MDEKICAgICAgICBidXM9MCwgc2xvdD03LCBmdW5j PTMKICAgICAgICBjbGFzcz0wNi04MC0wMCwgaGRydHlwZT0weDAwLCBtZmRldj0wCiAgICAgICAg Y21kcmVnPTB4MDAwMywgc3RhdHJlZz0weDAyODAsIGNhY2hlbG5zej0wIChkd29yZHMpCiAgICAg ICAgbGF0dGltZXI9MHgwMCAoMCBucyksIG1pbmdudD0weDAwICgwIG5zKSwgbWF4bGF0PTB4MDAg KDAgbnMpCiAgICAgICAgbWFwWzkwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwODgwMCwg c2l6ZSAgNCwgZW5hYmxlZApmb3VuZC0+IHZlbmRvcj0weDkwMDQsIGRldj0weDgzNzgsIHJldmlk PTB4MDEKICAgICAgICBidXM9MCwgc2xvdD04LCBmdW5jPTAKICAgICAgICBjbGFzcz0wMS0wMC0w MCwgaGRydHlwZT0weDAwLCBtZmRldj0wCiAgICAgICAgY21kcmVnPTB4MDAxNywgc3RhdHJlZz0w eDAyOTAsIGNhY2hlbG5zej04IChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9MHg0MCAoMTkyMCBu cyksIG1pbmdudD0weDA4ICgyMDAwIG5zKSwgbWF4bGF0PTB4MDggKDIwMDAgbnMpCiAgICAgICAg aW50cGluPWEsIGlycT05CiAgICAgICAgcG93ZXJzcGVjIDEgIHN1cHBvcnRzIEQwIEQzICBjdXJy ZW50IEQwCiAgICAgICAgbWFwWzEwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwZjgwMCwg c2l6ZSAgOCwgZW5hYmxlZAogICAgICAgIG1hcFsxNF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2Ug ZmVkZmYwMDAsIHNpemUgMTIsIGVuYWJsZWQKcGNpYjA6IHNsb3QgOCBJTlRBIHJvdXRlZCB0byBp cnEgMTYKZm91bmQtPiB2ZW5kb3I9MHg5MDA0LCBkZXY9MHg2MDc4LCByZXZpZD0weDAzCiAgICAg ICAgYnVzPTAsIHNsb3Q9OSwgZnVuYz0wCiAgICAgICAgY2xhc3M9MDEtMDAtMDAsIGhkcnR5cGU9 MHgwMCwgbWZkZXY9MAogICAgICAgIGNtZHJlZz0weDAwMTcsIHN0YXRyZWc9MHgwMjkwLCBjYWNo ZWxuc3o9OCAoZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9 MHgwNCAoMTAwMCBucyksIG1heGxhdD0weDA0ICgxMDAwIG5zKQogICAgICAgIGludHBpbj1hLCBp cnE9MTAKICAgICAgICBwb3dlcnNwZWMgMSAgc3VwcG9ydHMgRDAgRDMgIGN1cnJlbnQgRDAKICAg ICAgICBtYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBmNDAwLCBzaXplICA4LCBl bmFibGVkCiAgICAgICAgbWFwWzE0XTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmZWRmZTAwMCwg c2l6ZSAxMiwgZW5hYmxlZApwY2liMDogc2xvdCA5IElOVEEgcm91dGVkIHRvIGlycSAxOQpmb3Vu ZC0+IHZlbmRvcj0weDEwMjIsIGRldj0weDIwMDAsIHJldmlkPTB4MjUKICAgICAgICBidXM9MCwg c2xvdD0xNywgZnVuYz0wCiAgICAgICAgY2xhc3M9MDItMDAtMDAsIGhkcnR5cGU9MHgwMCwgbWZk ZXY9MAogICAgICAgIGNtZHJlZz0weDAwNDcsIHN0YXRyZWc9MHgwMjgwLCBjYWNoZWxuc3o9MCAo ZHdvcmRzKQogICAgICAgIGxhdHRpbWVyPTB4NDAgKDE5MjAgbnMpLCBtaW5nbnQ9MHgwNiAoMTUw MCBucyksIG1heGxhdD0weGZmICg2Mzc1MCBucykKICAgICAgICBpbnRwaW49YSwgaXJxPTkKICAg ICAgICBtYXBbMTBdOiB0eXBlIDQsIHJhbmdlIDMyLCBiYXNlIDAwMDBmY2MwLCBzaXplICA1LCBl bmFibGVkCiAgICAgICAgbWFwWzE0XTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmZWRmZGMwMCwg c2l6ZSAgNSwgZW5hYmxlZApwY2liMDogc2xvdCAxNyBJTlRBIHJvdXRlZCB0byBpcnEgMTgKZm91 bmQtPiB2ZW5kb3I9MHg5MDA0LCBkZXY9MHgxNDc4LCByZXZpZD0weDAxCiAgICAgICAgYnVzPTAs IHNsb3Q9MTgsIGZ1bmM9MAogICAgICAgIGNsYXNzPTA1LTgwLTAwLCBoZHJ0eXBlPTB4MDAsIG1m ZGV2PTAKICAgICAgICBjbWRyZWc9MHgwMDE3LCBzdGF0cmVnPTB4MDI4MCwgY2FjaGVsbnN6PTgg KGR3b3JkcykKICAgICAgICBsYXR0aW1lcj0weDQwICgxOTIwIG5zKSwgbWluZ250PTB4MDIgKDUw MCBucyksIG1heGxhdD0weDAyICg1MDAgbnMpCiAgICAgICAgaW50cGluPWEsIGlycT05CiAgICAg ICAgbWFwWzEwXTogdHlwZSA0LCByYW5nZSAzMiwgYmFzZSAwMDAwZjAwMCwgc2l6ZSAgOCwgZW5h YmxlZAogICAgICAgIG1hcFsxNF06IHR5cGUgMSwgcmFuZ2UgMzIsIGJhc2UgZmVkZmMwMDAsIHNp emUgMTIsIGVuYWJsZWQKICAgICAgICBtYXBbMThdOiB0eXBlIDMsIHJhbmdlIDMyLCBiYXNlIGZj MDAwMDAwLCBzaXplIDI1LCBlbmFibGVkCnBjaWIwOiBzbG90IDE4IElOVEEgcm91dGVkIHRvIGly cSAxNgphZ3AwOiA8SW50ZWwgODI0NDNMWCAoNDQwIExYKSBob3N0IHRvIFBDSSBicmlkZ2U+IG1l bSAweGY4MDAwMDAwLTB4ZmJmZmZmZmYgYXQgZApldmljZSAwLjAgb24gcGNpMAphZ3AwOiBSZXNl cnZlZCAweDQwMDAwMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgMyBhdCAweGY4MDAwMDAwCmFn cDA6IGFsbG9jYXRpbmcgR0FUVCBmb3IgYXBlcnR1cmUgb2Ygc2l6ZSA2NE0KcGNpYjE6IDxNUFRh YmxlIFBDSS1QQ0kgYnJpZGdlPiBhdCBkZXZpY2UgMS4wIG9uIHBjaTAKcGNpYjE6ICAgc2Vjb25k YXJ5IGJ1cyAgICAgMQpwY2liMTogICBzdWJvcmRpbmF0ZSBidXMgICAxCnBjaWIxOiAgIEkvTyBk ZWNvZGUgICAgICAgIDB4ZjAwMC0weGZmZgpwY2liMTogICBtZW1vcnkgZGVjb2RlICAgICAweGZl MDAwMDAwLTB4ZmViZmZmZmYKcGNpYjE6ICAgcHJlZmV0Y2hlZCBkZWNvZGUgMHhmNjAwMDAwMC0w eGY2ZmZmZmZmCnBjaTE6IDxQQ0kgYnVzPiBvbiBwY2liMQpwY2kxOiBwaHlzaWNhbCBidXM9MQpm b3VuZC0+IHZlbmRvcj0weDEwMmIsIGRldj0weDA1MWYsIHJldmlkPTB4MDAKICAgICAgICBidXM9 MSwgc2xvdD0wLCBmdW5jPTAKICAgICAgICBjbGFzcz0wMy0wMC0wMCwgaGRydHlwZT0weDAwLCBt ZmRldj0wCiAgICAgICAgY21kcmVnPTB4MDAwNywgc3RhdHJlZz0weDAyYjAsIGNhY2hlbG5zej0w IChkd29yZHMpCiAgICAgICAgbGF0dGltZXI9MHg0MCAoMTkyMCBucyksIG1pbmdudD0weDAwICgw IG5zKSwgbWF4bGF0PTB4MDAgKDAgbnMpCiAgICAgICAgaW50cGluPWEsIGlycT05CiAgICAgICAg bWFwWzEwXTogdHlwZSAzLCByYW5nZSAzMiwgYmFzZSBmNjAwMDAwMCwgc2l6ZSAyNCwgZW5hYmxl ZApwY2liMTogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2UgMHhmNjAwMDAwMC0weGY2ZmZm ZmZmOiBnb29kCiAgICAgICAgbWFwWzE0XTogdHlwZSAxLCByYW5nZSAzMiwgYmFzZSBmZWJmODAw MCwgc2l6ZSAxNCwgZW5hYmxlZApwY2liMTogKG51bGwpIHJlcXVlc3RlZCBtZW1vcnkgcmFuZ2Ug MHhmZWJmODAwMC0weGZlYmZiZmZmOiBnb29kCiAgICAgICAgbWFwWzE4XTogdHlwZSAxLCByYW5n ZSAzMiwgYmFzZSBmZTAwMDAwMCwgc2l6ZSAyMywgZW5hYmxlZApwY2liMTogKG51bGwpIHJlcXVl c3RlZCBtZW1vcnkgcmFuZ2UgMHhmZTAwMDAwMC0weGZlN2ZmZmZmOiBnb29kCnBjaWIxOiBzbG90 IDAgSU5UQSByb3V0ZWQgdG8gaXJxIDE4CnBjaTE6IDxkaXNwbGF5LCBWR0E+IGF0IGRldmljZSAw LjAgKG5vIGRyaXZlciBhdHRhY2hlZCkKaXNhYjA6IDxQQ0ktSVNBIGJyaWRnZT4gYXQgZGV2aWNl IDcuMCBvbiBwY2kwCmlzYTA6IDxJU0EgYnVzPiBvbiBpc2FiMAphdGFwY2kwOiA8SW50ZWwgUElJ WDQgVURNQTMzIGNvbnRyb2xsZXI+IHBvcnQgMHgxZjAtMHgxZjcsMHgzZjYsMHgxNzAtMHgxNzcs MHgzNwo2LDB4ZmNiMC0weGZjYmYgYXQgZGV2aWNlIDcuMSBvbiBwY2kwCmF0YXBjaTA6IFJlc2Vy dmVkIDB4MTAgYnl0ZXMgZm9yIHJpZCAweDIwIHR5cGUgNCBhdCAweGZjYjAKYXRhMDogPEFUQSBj aGFubmVsIDA+IG9uIGF0YXBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5dGVzIGZvciByaWQg MHgxMCB0eXBlIDQgYXQgMHgxZjAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxIGJ5dGVzIGZvciByaWQg MHgxNCB0eXBlIDQgYXQgMHgzZjYKYXRhMDogcmVzZXQgdHAxIG1hc2s9MDMgb3N0YXQwPTUwIG9z dGF0MT0wMAphdGEwOiBzdGF0MD0weDAwIGVycj0weDAxIGxzYj0weDE0IG1zYj0weGViCmF0YTA6 IHN0YXQxPTB4MDAgZXJyPTB4MDQgbHNiPTB4MDAgbXNiPTB4MDAKYXRhMDogcmVzZXQgdHAyIHN0 YXQwPTAwIHN0YXQxPTAwIGRldmljZXM9MHg0PEFUQVBJX01BU1RFUj4KYXRhMDogW01QU0FGRV0K YXRhMTogPEFUQSBjaGFubmVsIDE+IG9uIGF0YXBjaTAKYXRhcGNpMDogUmVzZXJ2ZWQgMHg4IGJ5 dGVzIGZvciByaWQgMHgxOCB0eXBlIDQgYXQgMHgxNzAKYXRhcGNpMDogUmVzZXJ2ZWQgMHgxIGJ5 dGVzIGZvciByaWQgMHgxYyB0eXBlIDQgYXQgMHgzNzYKYXRhMTogcmVzZXQgdHAxIG1hc2s9MDAg b3N0YXQwPWZmIG9zdGF0MT1mZgphdGExOiBbTVBTQUZFXQp1aGNpMDogPEludGVsIDgyMzcxQUIv RUIgKFBJSVg0KSBVU0IgY29udHJvbGxlcj4gcG9ydCAweGZjZTAtMHhmY2ZmIGlycSAxOSBhdCBk ZQp2aWNlIDcuMiBvbiBwY2kwCnVoY2kwOiBSZXNlcnZlZCAweDIwIGJ5dGVzIGZvciByaWQgMHgy MCB0eXBlIDQgYXQgMHhmY2UwCnVoY2kwOiBbR0lBTlQtTE9DS0VEXQp1c2IwOiA8SW50ZWwgODIz NzFBQi9FQiAoUElJWDQpIFVTQiBjb250cm9sbGVyPiBvbiB1aGNpMAp1c2IwOiBVU0IgcmV2aXNp b24gMS4wCnVodWIwOiBJbnRlbCBVSENJIHJvb3QgaHViLCBjbGFzcyA5LzAsIHJldiAxLjAwLzEu MDAsIGFkZHIgMQp1aHViMDogMiBwb3J0cyB3aXRoIDIgcmVtb3ZhYmxlLCBzZWxmIHBvd2VyZWQK cGlpeDA6IDxQSUlYIFRpbWVjb3VudGVyPiBwb3J0IDB4ODgwMC0weDg4MGYgYXQgZGV2aWNlIDcu MyBvbiBwY2kwClRpbWVjb3VudGVyICJQSUlYIiBmcmVxdWVuY3kgMzU3OTU0NSBIeiBxdWFsaXR5 IDAKYWhjMDogPEFkYXB0ZWMgMzk4WCBVbHRyYSBTQ1NJIFJBSUQgYWRhcHRlcj4gcG9ydCAweGY4 MDAtMHhmOGZmIG1lbSAweGZlZGZmMDAwLTAKeGZlZGZmZmZmIGlycSAxNiBhdCBkZXZpY2UgOC4w IG9uIHBjaTAKYWhjMDogRGVmYXVsdGluZyB0byBNRU1JTyBvZmYKYWhjMDogUmVzZXJ2ZWQgMHgx MDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweGY4MDAKYWhjMDogUmVhZGluZyBTRUVQ Uk9NLi4uZG9uZS4KYWhjMDogaW50ZXJuYWwgNTAgY2FibGUgbm90IHByZXNlbnQsIGludGVybmFs IDY4IGNhYmxlIG5vdCBwcmVzZW50CmFoYzA6IGV4dGVybmFsIGNhYmxlIG5vdCBwcmVzZW50CmFo YzA6IEJJT1MgZWVwcm9tIGlzIHByZXNlbnQKYWhjMDogSGlnaCBieXRlIHRlcm1pbmF0aW9uIEVu YWJsZWQKYWhjMDogTG93IGJ5dGUgdGVybWluYXRpb24gRW5hYmxlZAphaGMwOiBEb3dubG9hZGlu ZyBTZXF1ZW5jZXIgUHJvZ3JhbS4uLiA0NDEgaW5zdHJ1Y3Rpb25zIGRvd25sb2FkZWQKYWhjMDog RmVhdHVyZXMgMHgxMDAwNSwgQnVncyAweDExLCBGbGFncyAweDIwNDg1NTYzCmFoYzA6IFtHSUFO VC1MT0NLRURdCmFpYzc4ODA6IFVsdHJhIFdpZGUgQ2hhbm5lbCBCLCBTQ1NJIElkPTE1LCAxNi8y NTMgU0NCcwphaGMxOiA8QWRhcHRlYyBhaWM3ODYwIFVsdHJhIFNDU0kgYWRhcHRlcj4gcG9ydCAw eGY0MDAtMHhmNGZmIG1lbSAweGZlZGZlMDAwLTB4ZgplZGZlZmZmIGlycSAxOSBhdCBkZXZpY2Ug OS4wIG9uIHBjaTAKYWhjMTogRGVmYXVsdGluZyB0byBNRU1JTyBvZmYKYWhjMTogUmVzZXJ2ZWQg MHgxMDAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5cGUgNCBhdCAweGY0MDAKYWhjMTogUmVhZGluZyBT RUVQUk9NLi4uZG9uZS4KYWhjMTogTG93IGJ5dGUgdGVybWluYXRpb24gZW5hYmxlZAphaGMxOiBE b3dubG9hZGluZyBTZXF1ZW5jZXIgUHJvZ3JhbS4uLiA0NjAgaW5zdHJ1Y3Rpb25zIGRvd25sb2Fk ZWQKYWhjMTogRmVhdHVyZXMgMHgxMDEwMSwgQnVncyAweDM1LCBGbGFncyAweDg0ODU1NjAKYWhj MTogW0dJQU5ULUxPQ0tFRF0KYWljNzg2MDogVWx0cmEgU2luZ2xlIENoYW5uZWwgQSwgU0NTSSBJ ZD03LCAzLzI1MyBTQ0JzCnBjbjA6IFJlc2VydmVkIDB4MjAgYnl0ZXMgZm9yIHJpZCAweDEwIHR5 cGUgNCBhdCAweGZjYzAKcGNuMDogPEFNRCBQQ25ldC9QQ0kgMTAvMTAwQmFzZVRYPiBwb3J0IDB4 ZmNjMC0weGZjZGYgbWVtIDB4ZmVkZmRjMDAtMHhmZWRmZGMxZgppcnEgMTggYXQgZGV2aWNlIDE3 LjAgb24gcGNpMApwY24wOiBDaGlwIElEIDI2MjMgKEFtNzlDOTcxKQptaWlidXMwOiA8TUlJIGJ1 cz4gb24gcGNuMApseHRwaHkwOiA8TFhUOTcwIDEwLzEwMCBtZWRpYSBpbnRlcmZhY2U+IG9uIG1p aWJ1czAKbHh0cGh5MDogIDEwMGJhc2VGWCwgMTAwYmFzZUZYLUZEWCwgMTBiYXNlVCwgMTBiYXNl VC1GRFgsIDEwMGJhc2VUWCwgMTAwYmFzZVRYLUYKRFgsIGF1dG8KcGNuMDogYnBmIGF0dGFjaGVk CnBjbjA6IEV0aGVybmV0IGFkZHJlc3M6IDAwOjYwOmIwOmMzOmE5OjdlCnBjbjA6IGlmX3N0YXJ0 IHJ1bm5pbmcgZGVmZXJyZWQgZm9yIEdpYW50CnBjbjA6IFtHSUFOVC1MT0NLRURdCnBjaTA6IDxt ZW1vcnk+IGF0IGRldmljZSAxOC4wIChubyBkcml2ZXIgYXR0YWNoZWQpCmF0YTogYXRhMCBhbHJl YWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKYXRhOiBhdGExIGFscmVhZHkgZXhpc3RzOyBza2lwcGlu ZyBpdApwbnBfaWRlbnRpZnk6IFRyeWluZyBSZWFkX1BvcnQgYXQgMjAzCkFEUzcxODA6IHN0YXJ0 IGRlcGVuZGVudCAoMCkKQURTNzE4MDogYWRkaW5nIGlycSBtYXNrIDB4YTAKQURTNzE4MDogYWRk aW5nIGRtYSBtYXNrIDB4MgpBRFM3MTgwOiBhZGRpbmcgZG1hIG1hc2sgMHhiCkFEUzcxODA6IGFk ZGluZyBpbyByYW5nZSAweDIyMC0weDI0Ziwgc2l6ZT0weDEwLCBhbGlnbj0weDIwCkFEUzcxODA6 IGFkZGluZyBpbyByYW5nZSAweDM4OC0weDM4Yiwgc2l6ZT0weDQsIGFsaWduPTB4OApBRFM3MTgw OiBhZGRpbmcgaW8gcmFuZ2UgMHg1MDAtMHg1NmYsIHNpemU9MHgxMCwgYWxpZ249MHgxMApBRFM3 MTgwOiBzdGFydCBkZXBlbmRlbnQgKDEpCkFEUzcxODA6IGFkZGluZyBpcnEgbWFzayAweDRhMApB RFM3MTgwOiBhZGRpbmcgZG1hIG1hc2sgMHhiCkFEUzcxODA6IGFkZGluZyBkbWEgbWFzayAweGIK QURTNzE4MDogYWRkaW5nIGlvIHJhbmdlIDB4MjIwLTB4MjRmLCBzaXplPTB4MTAsIGFsaWduPTB4 MjAKQURTNzE4MDogYWRkaW5nIGlvIHJhbmdlIDB4Mzg4LTB4MzhiLCBzaXplPTB4NCwgYWxpZ249 MHg4CkFEUzcxODA6IGFkZGluZyBpbyByYW5nZSAweDUwMC0weDU2Ziwgc2l6ZT0weDEwLCBhbGln bj0weDEwCkFEUzcxODA6IHN0YXJ0IGRlcGVuZGVudCAoMSkKQURTNzE4MDogYWRkaW5nIGlycSBt YXNrIDB4OGVhMApBRFM3MTgwOiBhZGRpbmcgZG1hIG1hc2sgMHhiCkFEUzcxODA6IGFkZGluZyBk bWEgbWFzayAweGIKQURTNzE4MDogYWRkaW5nIGlvIHJhbmdlIDB4MjIwLTB4MmVmLCBzaXplPTB4 MTAsIGFsaWduPTB4MjAKQURTNzE4MDogYWRkaW5nIGlvIHJhbmdlIDB4Mzg4LTB4M2JiLCBzaXpl PTB4NCwgYWxpZ249MHg4CkFEUzcxODA6IGFkZGluZyBpbyByYW5nZSAweDUwMC0weDU2Ziwgc2l6 ZT0weDEwLCBhbGlnbj0weDEwCkFEUzcxODA6IHN0YXJ0IGRlcGVuZGVudCAoMikKQURTNzE4MDog YWRkaW5nIGlycSBtYXNrIDB4OGVhMApBRFM3MTgwOiBhZGRpbmcgZG1hIG1hc2sgMHhiCkFEUzcx ODA6IGFkZGluZyBpbyByYW5nZSAweDIyMC0weDJlZiwgc2l6ZT0weDEwLCBhbGlnbj0weDIwCkFE UzcxODA6IGFkZGluZyBpbyByYW5nZSAweDM4OC0weDNiYiwgc2l6ZT0weDQsIGFsaWduPTB4OApB RFM3MTgwOiBhZGRpbmcgaW8gcmFuZ2UgMHg1MDAtMHg1NmYsIHNpemU9MHgxMCwgYWxpZ249MHgx MApBRFM3MTgwOiBlbmQgZGVwZW5kZW50CkFEUzcxODE6IHN0YXJ0IGRlcGVuZGVudCAoMCkKQURT NzE4MTogYWRkaW5nIGlycSBtYXNrIDB4YWEwCkFEUzcxODE6IGFkZGluZyBpbyByYW5nZSAweDMw MC0weDMzMSwgc2l6ZT0weDIsIGFsaWduPTB4MzAKQURTNzE4MTogc3RhcnQgZGVwZW5kZW50ICgx KQpBRFM3MTgxOiBhZGRpbmcgaXJxIG1hc2sgMHg4ZWEwCkFEUzcxODE6IGFkZGluZyBpbyByYW5n ZSAweDMwMC0weDQyMSwgc2l6ZT0weDIsIGFsaWduPTB4MzAKQURTNzE4MTogZW5kIGRlcGVuZGVu dApBRFM3MTgyOiBzdGFydCBkZXBlbmRlbnQgKDApCkFEUzcxODI6IGFkZGluZyBpbyByYW5nZSAw eDIwMC0weDIwNywgc2l6ZT0weDgsIGFsaWduPTB4OApBRFM3MTgyOiBzdGFydCBkZXBlbmRlbnQg KDEpCkFEUzcxODI6IGFkZGluZyBpbyByYW5nZSAweDIwMC0weDIwZiwgc2l6ZT0weDgsIGFsaWdu PTB4OApBRFM3MTgyOiBlbmQgZGVwZW5kZW50ClBOUCBJZGVudGlmeSBjb21wbGV0ZQpleF9pc2Ff aWRlbnRpZnkoKQpwbnBiaW9zOiAxNyBkZXZpY2VzLCBsYXJnZXN0IDE4NCBieXRlcwpQTlAwYzAx OiBhZGRpbmcgZml4ZWQgbWVtb3J5MzIgcmFuZ2UgMC0weDlmZmZmLCBzaXplPTB4YTAwMDAKUE5Q MGMwMTogYWRkaW5nIGZpeGVkIG1lbW9yeTMyIHJhbmdlIDB4ZGMwMDAtMHhmZmZmZiwgc2l6ZT0w eDI0MDAwClBOUDBjMDE6IGFkZGluZyBmaXhlZCBtZW1vcnkzMiByYW5nZSAweDEwMDAwMC0weDdm ZmZmZmYsIHNpemU9MHg3ZjAwMDAwCnBucGJpb3M6IGhhbmRsZSAwIGRldmljZSBJRCBQTlAwYzAx ICgwMTBjZDA0MSkKUE5QMGMwMjogYWRkaW5nIGlvIHJhbmdlIDB4OTYtMHg5Nywgc2l6ZT0weDIs IGFsaWduPTB4MQpQTlAwYzAyOiBhZGRpbmcgZml4ZWQgaW8gcmFuZ2UgMHgyZS0weDJmLCBzaXpl PTB4MiwgYWxpZ249MHgxClBOUDBjMDI6IGFkZGluZyBpbyByYW5nZSAweGUwLTB4ZTcsIHNpemU9 MHg4LCBhbGlnbj0weDEKUE5QMGMwMjogYWRkaW5nIGlvIHJhbmdlIDB4ZTgtMHhlOSwgc2l6ZT0w eDIsIGFsaWduPTB4MQpQTlAwYzAyOiBhZGRpbmcgaW8gcmFuZ2UgMHg4NDAwLTB4ODQwMywgc2l6 ZT0weDQsIGFsaWduPTB4MQpQTlAwYzAyOiBhZGRpbmcgaW8gcmFuZ2UgMHg4NDA0LTB4ODQwNywg c2l6ZT0weDQsIGFsaWduPTB4MQpQTlAwYzAyOiBhZGRpbmcgaW8gcmFuZ2UgMHg4NDA4LTB4ODQw OSwgc2l6ZT0weDIsIGFsaWduPTB4MQpQTlAwYzAyOiBhZGRpbmcgaW8gcmFuZ2UgMHg4NDEwLTB4 ODQxZiwgc2l6ZT0weDEwLCBhbGlnbj0weDEKUE5QMGMwMjogYWRkaW5nIGlvIHJhbmdlIDB4ODAt MHg4MCwgc2l6ZT0weDEsIGFsaWduPTB4MQpQTlAwYzAyOiBhZGRpbmcgZml4ZWQgbWVtb3J5MzIg cmFuZ2UgMHhmZmZlMDAwMC0weGZmZmZmZmZmLCBzaXplPTB4MjAwMDAKcG5wYmlvczogaGFuZGxl IDEgZGV2aWNlIElEIFBOUDBjMDIgKDAyMGNkMDQxKQpQTlAwMjAwOiBhZGRpbmcgaW8gcmFuZ2Ug MC0weGYsIHNpemU9MHgxMCwgYWxpZ249MHgxClBOUDAyMDA6IGFkZGluZyBpbyByYW5nZSAweDgx LTB4OGYsIHNpemU9MHhmLCBhbGlnbj0weDEKUE5QMDIwMDogYWRkaW5nIGlvIHJhbmdlIDB4YzAt MHhkZiwgc2l6ZT0weDIwLCBhbGlnbj0weDEKUE5QMDIwMDogYWRkaW5nIGRtYSBtYXNrIDB4MTAK cG5wYmlvczogaGFuZGxlIDIgZGV2aWNlIElEIFBOUDAyMDAgKDAwMDJkMDQxKQpQTlAwMTAwOiBh ZGRpbmcgaW8gcmFuZ2UgMHg0MC0weDQzLCBzaXplPTB4NCwgYWxpZ249MHgxClBOUDAxMDA6IGFk ZGluZyBpcnEgbWFzayAweDEKcG5wYmlvczogaGFuZGxlIDQgZGV2aWNlIElEIFBOUDAxMDAgKDAw MDFkMDQxKQpQTlAwYjAwOiBhZGRpbmcgaW8gcmFuZ2UgMHg3MC0weDcxLCBzaXplPTB4MiwgYWxp Z249MHgxClBOUDBiMDA6IGFkZGluZyBpcnEgbWFzayAweDEwMApwbnBiaW9zOiBoYW5kbGUgNSBk ZXZpY2UgSUQgUE5QMGIwMCAoMDAwYmQwNDEpClBOUDAzMDM6IGFkZGluZyBpbyByYW5nZSAweDYw LTB4NjAsIHNpemU9MHgxLCBhbGlnbj0weDEKUE5QMDMwMzogYWRkaW5nIGlvIHJhbmdlIDB4NjQt MHg2NCwgc2l6ZT0weDEsIGFsaWduPTB4MQpQTlAwMzAzOiBhZGRpbmcgaXJxIG1hc2sgMHgyCnBu cGJpb3M6IGhhbmRsZSA2IGRldmljZSBJRCBQTlAwMzAzICgwMzAzZDA0MSkKUE5QMGMwNDogYWRk aW5nIGlvIHJhbmdlIDB4ZjAtMHhmZiwgc2l6ZT0weDEwLCBhbGlnbj0weDEKUE5QMGMwNDogYWRk aW5nIGlycSBtYXNrIDB4MjAwMApwbnBiaW9zOiBoYW5kbGUgNyBkZXZpY2UgSUQgUE5QMGMwNCAo MDQwY2QwNDEpClBOUDA4MDA6IGFkZGluZyBpbyByYW5nZSAweDYxLTB4NjEsIHNpemU9MHgxLCBh bGlnbj0weDEKcG5wYmlvczogaGFuZGxlIDggZGV2aWNlIElEIFBOUDA4MDAgKDAwMDhkMDQxKQpQ TlAwYTAzOiBhZGRpbmcgaW8gcmFuZ2UgMHhjZjgtMHhjZmYsIHNpemU9MHg4LCBhbGlnbj0weDEK cG5wYmlvczogaGFuZGxlIDEwIGRldmljZSBJRCBQTlAwYTAzICgwMzBhZDA0MSkKUE5QMGMwMjog YWRkaW5nIGlvIHJhbmdlIDB4NGQwLTB4NGQxLCBzaXplPTB4MiwgYWxpZ249MHgxClBOUDBjMDI6 IGFkZGluZyBpbyByYW5nZSAweDgwMDAtMHg4MDNmLCBzaXplPTB4NDAsIGFsaWduPTB4MQpQTlAw YzAyOiBhZGRpbmcgaW8gcmFuZ2UgMHg4ODAwLTB4ODgwZiwgc2l6ZT0weDEwLCBhbGlnbj0weDEK cG5wYmlvczogaGFuZGxlIDExIGRldmljZSBJRCBQTlAwYzAyICgwMjBjZDA0MSkKUE5QMGMwMjog YWRkaW5nIGZpeGVkIG1lbW9yeTMyIHJhbmdlIDB4ZmVjMDAwMDAtMHhmZWMwZmZmZiwgc2l6ZT0w eDEwMDAwClBOUDBjMDI6IGFkZGluZyBmaXhlZCBtZW1vcnkzMiByYW5nZSAweGZlZTAwMDAwLTB4 ZmVlMDBmZmYsIHNpemU9MHgxMDAwCnBucGJpb3M6IGhhbmRsZSAxMiBkZXZpY2UgSUQgUE5QMGMw MiAoMDIwY2QwNDEpClBOUDA1MDE6IGFkZGluZyBpbyByYW5nZSAweDNmOC0weDNmZiwgc2l6ZT0w eDgsIGFsaWduPTB4OApQTlAwNTAxOiBhZGRpbmcgaXJxIG1hc2sgMHgxMApwbnBiaW9zOiBoYW5k bGUgMTMgZGV2aWNlIElEIFBOUDA1MDEgKDAxMDVkMDQxKQpQTlAwNDAxOiBhZGRpbmcgaW8gcmFu Z2UgMHgzNzgtMHgzN2YsIHNpemU9MHg4LCBhbGlnbj0weDgKUE5QMDQwMTogYWRkaW5nIGlvIHJh bmdlIDB4Nzc4LTB4NzdmLCBzaXplPTB4OCwgYWxpZ249MHg4ClBOUDA0MDE6IGFkZGluZyBpcnEg bWFzayAweDgwClBOUDA0MDE6IGFkZGluZyBkbWEgbWFzayAweDIKcG5wYmlvczogaGFuZGxlIDE0 IGRldmljZSBJRCBQTlAwNDAxICgwMTA0ZDA0MSkKUE5QMDcwMDogYWRkaW5nIGlvIHJhbmdlIDB4 M2YwLTB4M2Y1LCBzaXplPTB4NiwgYWxpZ249MHg4ClBOUDA3MDA6IGFkZGluZyBpbyByYW5nZSAw eDNmNy0weDNmNywgc2l6ZT0weDEsIGFsaWduPTB4MQpQTlAwNzAwOiBhZGRpbmcgaXJxIG1hc2sg MHg0MApQTlAwNzAwOiBhZGRpbmcgZG1hIG1hc2sgMHg0CnBucGJpb3M6IGhhbmRsZSAxNiBkZXZp Y2UgSUQgUE5QMDcwMCAoMDAwN2QwNDEpClBOUDA1MDE6IGFkZGluZyBpbyByYW5nZSAweDJmOC0w eDJmZiwgc2l6ZT0weDgsIGFsaWduPTB4OApQTlAwNTAxOiBhZGRpbmcgaXJxIG1hc2sgMHg4CnBu cGJpb3M6IGhhbmRsZSAxNyBkZXZpY2UgSUQgUE5QMDUwMSAoMDEwNWQwNDEpCnBucGJpb3M6IGhh bmRsZSAxOCBkZXZpY2UgSUQgUE5QMGYxMyAoMTMwZmQwNDEpCnVua25vd246IHN0YXR1cyByZWcg dGVzdCBmYWlsZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3du OiBzdGF0dXMgcmVnIHRlc3QgZmFpbGVkIGZmCnVua25vd246IHN0YXR1cyByZWcgdGVzdCBmYWls ZWQgZmYKdW5rbm93bjogc3RhdHVzIHJlZyB0ZXN0IGZhaWxlZCBmZgp1bmtub3duOiBzdGF0dXMg cmVnIHRlc3QgZmFpbGVkIGZmCnNjOiBzYzAgYWxyZWFkeSBleGlzdHM7IHNraXBwaW5nIGl0CnZn YTogdmdhMCBhbHJlYWR5IGV4aXN0czsgc2tpcHBpbmcgaXQKaXNhX3Byb2JlX2NoaWxkcmVuOiBk aXNhYmxpbmcgUG5QIGRldmljZXMKaXNhX3Byb2JlX2NoaWxkcmVuOiBwcm9iaW5nIG5vbi1QblAg ZGV2aWNlcwpwbXRpbWVyMCBvbiBpc2EwCm9ybTA6IDxJU0EgT3B0aW9uIFJPTXM+IGF0IGlvbWVt IDB4YzAwMDAtMHhjN2ZmZiwweGM4MDAwLTB4ZDZmZmYgb24gaXNhMAphZHYwOiBub3QgcHJvYmVk IChkaXNhYmxlZCkKYWhhMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmFpYzA6IG5vdCBwcm9iZWQg KGRpc2FibGVkKQphdGtiZGMwOiA8S2V5Ym9hcmQgY29udHJvbGxlciAoaTgwNDIpPiBhdCBwb3J0 IDB4NjAsMHg2NCBvbiBpc2EwCmF0a2JkMDogPEFUIEtleWJvYXJkPiBpcnEgMSBvbiBhdGtiZGMw CmF0a2JkOiB0aGUgY3VycmVudCBrYmQgY29udHJvbGxlciBjb21tYW5kIGJ5dGUgMDA0NQphdGti ZDoga2V5Ym9hcmQgSUQgMHg0MWFiICgyKQprYmRjOiBSRVNFVF9LQkQgcmV0dXJuIGNvZGU6MDBm YQprYmRjOiBSRVNFVF9LQkQgc3RhdHVzOjAwYWEKa2JkMCBhdCBhdGtiZDAKa2JkMDogYXRrYmQw LCBBVCAxMDEvMTAyICgyKSwgY29uZmlnOjB4MCwgZmxhZ3M6MHgxZDAwMDAKYXRrYmQwOiBbR0lB TlQtTE9DS0VEXQpwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTowMDQ1CmtiZGM6IFRFU1RfQVVY X1BPUlQgc3RhdHVzOjAwMDAKa2JkYzogUkVTRVRfQVVYIHJldHVybiBjb2RlOjAwZmUKa2JkYzog UkVTRVRfQVVYIHJldHVybiBjb2RlOjAwZmUKa2JkYzogUkVTRVRfQVVYIHJldHVybiBjb2RlOjAw ZmUKa2JkYzogRElBR05PU0Ugc3RhdHVzOjAwNTUKa2JkYzogVEVTVF9LQkRfUE9SVCBzdGF0dXM6 MDAwMApwc20wOiBmYWlsZWQgdG8gcmVzZXQgdGhlIGF1eCBkZXZpY2UuCmJ0MDogbm90IHByb2Jl ZCAoZGlzYWJsZWQpCmNzMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmVkMDogbm90IHByb2JlZCAo ZGlzYWJsZWQpCmZkYzA6IGljX3R5cGUgOTAgcGFydF9pZCA3MwpmZGMwOiA8RW5oYW5jZWQgZmxv cHB5IGNvbnRyb2xsZXI+IGF0IHBvcnQgMHgzZjAtMHgzZjUsMHgzZjcgaXJxIDYgZHJxIDIgb24g aXNhMApmZGMwOiBpY190eXBlIDkwIHBhcnRfaWQgNzMKZmRjMDogW01QU0FGRV0KZmRjMDogW0ZB U1RdCmZkMDogPDE0NDAtS0IgMy41IiBkcml2ZT4gb24gZmRjMCBkcml2ZSAwCmZlMDogbm90IHBy b2JlZCAoZGlzYWJsZWQpCmllMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCmxuYzA6IG5vdCBwcm9i ZWQgKGRpc2FibGVkKQpwcGMwOiBwYXJhbGxlbCBwb3J0IGZvdW5kIGF0IDB4Mzc4CnBwYzA6IHVz aW5nIGV4dGVuZGVkIEkvTyBwb3J0IHJhbmdlCnBwYzA6IEVDUCBTUFAgRUNQK0VQUCBTUFAKcHBj MDogPFBhcmFsbGVsIHBvcnQ+IGF0IHBvcnQgMHgzNzgtMHgzN2YgaXJxIDcgb24gaXNhMApwcGMw OiBTTUMtbGlrZSBjaGlwc2V0IChFQ1AvRVBQL1BTMi9OSUJCTEUpIGluIENPTVBBVElCTEUgbW9k ZQpwcGMwOiBGSUZPIHdpdGggMTYvMTYvOCBieXRlcyB0aHJlc2hvbGQKcHBidXMwOiA8UGFyYWxs ZWwgcG9ydCBidXM+IG9uIHBwYzAKcGxpcDA6IDxQTElQIG5ldHdvcmsgaW50ZXJmYWNlPiBvbiBw cGJ1czAKcGxpcDA6IGJwZiBhdHRhY2hlZApscHQwOiA8UHJpbnRlcj4gb24gcHBidXMwCmxwdDA6 IEludGVycnVwdC1kcml2ZW4gcG9ydApwcGkwOiA8UGFyYWxsZWwgSS9PPiBvbiBwcGJ1czAKc2Mw OiA8U3lzdGVtIGNvbnNvbGU+IGF0IGZsYWdzIDB4MTAwIG9uIGlzYTAKc2MwOiBWR0EgPDE2IHZp cnR1YWwgY29uc29sZXMsIGZsYWdzPTB4MTAwPgpzYzA6IGZiMCwga2JkMCwgdGVybWluYWwgZW11 bGF0b3I6IHNjIChzeXNjb25zIHRlcm1pbmFsKQpzaW8wOiBpcnEgbWFwczogMHg2OGExIDB4Njhi MSAweDY4YTEgMHg2OGExCnNpbzAgYXQgcG9ydCAweDNmOC0weDNmZiBpcnEgNCBmbGFncyAweDEw IG9uIGlzYTAKc2lvMDogdHlwZSAxNjU1MEEsIGNvbnNvbGUKc2lvMTogaXJxIG1hcHM6IDB4Njhh MSAweDY4YTkgMHg2OGExIDB4NjhhMQpzaW8xIGF0IHBvcnQgMHgyZjgtMHgyZmYgaXJxIDMgb24g aXNhMApzaW8xOiB0eXBlIDE2NTUwQQpzaW8yOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKc2lvMzog bm90IHByb2JlZCAoZGlzYWJsZWQpCnNuMDogbm90IHByb2JlZCAoZGlzYWJsZWQpCnZnYTA6IDxH ZW5lcmljIElTQSBWR0E+IGF0IHBvcnQgMHgzYzAtMHgzZGYgaW9tZW0gMHhhMDAwMC0weGJmZmZm IG9uIGlzYTAKdnQwOiBub3QgcHJvYmVkIChkaXNhYmxlZCkKaXNhX3Byb2JlX2NoaWxkcmVuOiBw cm9iaW5nIFBuUCBkZXZpY2VzCnVua25vd246IDxQTlAwYzAyPiBjYW4ndCBhc3NpZ24gcmVzb3Vy Y2VzIChtZW1vcnkpCnVua25vd246IDxQTlAwYzAyPiBvbiBpc2EwCmFkdjE6IEludmFsaWQgYmFz ZXBvcnQgb2YgMHgwIHNwZWNpZmllZC4gTmVhcmVzdCB2YWxpZCBiYXNlcG9ydCBpcyAweDEwMC4g IEZhaWxpCm5nIHByb2JlLgphZHYxOiBJbnZhbGlkIGJhc2Vwb3J0IG9mIDB4NDAgc3BlY2lmaWVk LiBOZWFyZXN0IHZhbGlkIGJhc2Vwb3J0IGlzIDB4MTAwLiAgRmFpbAppbmcgcHJvYmUuCmFkdjE6 IEludmFsaWQgYmFzZXBvcnQgb2YgMHg3MCBzcGVjaWZpZWQuIE5lYXJlc3QgdmFsaWQgYmFzZXBv cnQgaXMgMHgxMDAuICBGYWlsCmluZyBwcm9iZS4KdW5rbm93bjogPFBOUDAzMDM+IGNhbid0IGFz c2lnbiByZXNvdXJjZXMgKHBvcnQpCnVua25vd246IDxQTlAwMzAzPiBhdCBwb3J0IDB4NjAgb24g aXNhMAphZHYxOiBJbnZhbGlkIGJhc2Vwb3J0IG9mIDB4ZjAgc3BlY2lmaWVkLiBOZWFyZXN0IHZh bGlkIGJhc2Vwb3J0IGlzIDB4MTAwLiAgRmFpbAppbmcgcHJvYmUuCmFkdjE6IEludmFsaWQgYmFz ZXBvcnQgb2YgMHg2MSBzcGVjaWZpZWQuIE5lYXJlc3QgdmFsaWQgYmFzZXBvcnQgaXMgMHgxMDAu ICBGYWlsCmluZyBwcm9iZS4KdW5rbm93bjogPFBOUDA4MDA+IGZhaWxlZCB0byBwcm9iZSBhdCBw b3J0IDB4NjEgb24gaXNhMAphZHYxOiBJbnZhbGlkIGJhc2Vwb3J0IG9mIDB4Y2Y4IHNwZWNpZmll ZC4gTmVhcmVzdCB2YWxpZCBiYXNlcG9ydCBpcyAweDMzMC4gIEZhaQpsaW5nIHByb2JlLgp1bmtu b3duOiA8UE5QMGMwMj4gY2FuJ3QgYXNzaWduIHJlc291cmNlcyAocG9ydCkKdW5rbm93bjogPFBO UDBjMDI+IGF0IHBvcnQgMHg0ZDAtMHg0ZDEgb24gaXNhMAp1bmtub3duOiA8UE5QMDUwMT4gY2Fu J3QgYXNzaWduIHJlc291cmNlcyAocG9ydCkKdW5rbm93bjogPFBOUDA1MDE+IGF0IHBvcnQgMHgz ZjgtMHgzZmYgb24gaXNhMAp1bmtub3duOiA8UE5QMDQwMT4gY2FuJ3QgYXNzaWduIHJlc291cmNl cyAocG9ydCkKdW5rbm93bjogPFBOUDA0MDE+IGF0IHBvcnQgMHgzNzgtMHgzN2Ygb24gaXNhMAp1 bmtub3duOiA8UE5QMDcwMD4gY2FuJ3QgYXNzaWduIHJlc291cmNlcyAocG9ydCkKdW5rbm93bjog PFBOUDA3MDA+IGF0IHBvcnQgMHgzZjAtMHgzZjUgb24gaXNhMAp1bmtub3duOiA8UE5QMDUwMT4g Y2FuJ3QgYXNzaWduIHJlc291cmNlcyAocG9ydCkKdW5rbm93bjogPFBOUDA1MDE+IGF0IHBvcnQg MHgyZjgtMHgyZmYgb24gaXNhMApwc21jcG5wMDogaXJxIHJlc291cmNlIGluZm8gaXMgbWlzc2lu ZzsgYXNzdW1pbmcgaXJxIDEyCnBzbWNwbnAwOiA8UFMvMiBtb3VzZSBwb3J0PiBhdCBpcnEgMTIg b24gaXNhMApwc20wOiBjdXJyZW50IGNvbW1hbmQgYnl0ZTowMDQ1CmtiZGM6IFRFU1RfQVVYX1BP UlQgc3RhdHVzOjAwMDAKa2JkYzogUkVTRVRfQVVYIHJldHVybiBjb2RlOjAwZmUKa2JkYzogUkVT RVRfQVVYIHJldHVybiBjb2RlOjAwZmUKa2JkYzogUkVTRVRfQVVYIHJldHVybiBjb2RlOjAwZmUK a2JkYzogRElBR05PU0Ugc3RhdHVzOjAwNTUKa2JkYzogVEVTVF9LQkRfUE9SVCBzdGF0dXM6MDAw MApwc20wOiBmYWlsZWQgdG8gcmVzZXQgdGhlIGF1eCBkZXZpY2UuCmFkdjE6IEludmFsaWQgYmFz ZXBvcnQgb2YgMHgyMjAgc3BlY2lmaWVkLiBOZWFyZXN0IHZhbGlkIGJhc2Vwb3J0IGlzIDB4MjMw LiAgRmFpCmxpbmcgcHJvYmUuCnVua25vd246IDxBbmFsb2cgRGV2aWNlcyBBRDE4MTZBPiBmYWls ZWQgdG8gcHJvYmUgYXQgcG9ydCAweDIyMC0weDIyZiwweDM4OC0weDM4CmIsMHg1MDAtMHg1MGYg aXJxIDUgZHJxIDEsMCBvbiBpc2EwCmFkdjE6IEludmFsaWQgYmFzZXBvcnQgb2YgMHgzMDAgc3Bl Y2lmaWVkLiBOZWFyZXN0IHZhbGlkIGJhc2Vwb3J0IGlzIDB4MzMwLiAgRmFpCmxpbmcgcHJvYmUu CnVua25vd246IDxBbmFsb2cgRGV2aWNlcyBBRDE4MTZBPiBmYWlsZWQgdG8gcHJvYmUgYXQgcG9y dCAweDMwMC0weDMwMSBpcnEgOSBvbiBpCnNhMAphZHYxOiBJbnZhbGlkIGJhc2Vwb3J0IG9mIDB4 MjAwIHNwZWNpZmllZC4gTmVhcmVzdCB2YWxpZCBiYXNlcG9ydCBpcyAweDIxMC4gIEZhaQpsaW5n IHByb2JlLgp1bmtub3duOiA8QW5hbG9nIERldmljZXMgQUQxODE2QT4gZmFpbGVkIHRvIHByb2Jl IGF0IHBvcnQgMHgyMDAtMHgyMDcgb24gaXNhMApEZXZpY2UgY29uZmlndXJhdGlvbiBmaW5pc2hl ZC4KcHJvY2ZzIHJlZ2lzdGVyZWQKbGFwaWM6IERpdmlzb3IgMiwgRnJlcXVlbmN5IDMzMzM0NjQ4 IGh6ClRpbWVjb3VudGVyICJUU0MiIGZyZXF1ZW5jeSAzMDAwMTI0NTIgSHogcXVhbGl0eSAtMTAw ClRpbWVjb3VudGVycyB0aWNrIGV2ZXJ5IDEuMDAwIG1zZWMKbG8wOiBicGYgYXR0YWNoZWQKV2Fp dGluZyAxNSBzZWNvbmRzIGZvciBTQ1NJIGRldmljZXMgdG8gc2V0dGxlCihub3BlcmlwaDphaGMw OjA6LTE6LTEpOiBTQ1NJIGJ1cyByZXNldCBkZWxpdmVyZWQuIDAgU0NCcyBhYm9ydGVkLgoobm9w ZXJpcGg6YWhjMTowOi0xOi0xKTogU0NTSSBidXMgcmVzZXQgZGVsaXZlcmVkLiAwIFNDQnMgYWJv cnRlZC4KbWQwOiBQcmVsb2FkZWQgaW1hZ2UgPC9ib290L21mc3Jvb3Q+IDQ0MjM2ODAgYnl0ZXMg YXQgMHhjMGE3OGRjNAphdGEwLW1hc3RlcjogcGlvPVBJTzMgd2RtYT1XRE1BMSB1ZG1hPUJJT1NE TUEgY2FibGU9NDAgd2lyZQphY2QwOiBzZXR0aW5nIFBJTzMgb24gSW50ZWwgUElJWDQgY2hpcAph Y2QwOiA8TUFUU0hJVEEgQ1ItNTg1L1pQMTg+IENEUk9NIGRyaXZlIGF0IGF0YTAgYXMgbWFzdGVy CmFjZDA6IHJlYWQgNDEyNUtCL3MgKDQxMjVLQi9zKSwgMTI4S0IgYnVmZmVyLCBQSU8zCmFjZDA6 IFJlYWRzOiBDRFIsIENEUlcsIENEREEgc3RyZWFtLCBwYWNrZXQKYWNkMDogV3JpdGVzOgphY2Qw OiBBdWRpbzogcGxheSwgMjU2IHZvbHVtZSBsZXZlbHMKYWNkMDogTWVjaGFuaXNtOiBlamVjdGFi bGUgdHJheSwgdW5sb2NrZWQKYWNkMDogTWVkaXVtOiBDRC1ST00gdW5rbm93bgphaGMxOiBTZWxl Y3Rpb24gVGltZW91dCBvbiBBOjAuIDAgU0NCcyBhYm9ydGVkCmFoYzE6IFNlbGVjdGlvbiBUaW1l b3V0IG9uIEE6MS4gMCBTQ0JzIGFib3J0ZWQKYWhjMTogU2VsZWN0aW9uIFRpbWVvdXQgb24gQToy LiAwIFNDQnMgYWJvcnRlZAphaGMxOiBTZWxlY3Rpb24gVGltZW91dCBvbiBBOjMuIDAgU0NCcyBh Ym9ydGVkCmFoYzE6IFNlbGVjdGlvbiBUaW1lb3V0IG9uIEE6NC4gMCBTQ0JzIGFib3J0ZWQKYWhj MTogU2VsZWN0aW9uIFRpbWVvdXQgb24gQTo1LiAwIFNDQnMgYWJvcnRlZAphaGMxOiBTZWxlY3Rp b24gVGltZW91dCBvbiBBOjYuIDAgU0NCcyBhYm9ydGVkCmFoYzA6IFJlY292ZXJ5IEluaXRpYXRl ZAo+Pj4+Pj4+Pj4+Pj4+Pj4+Pj4gRHVtcCBDYXJkIFN0YXRlIEJlZ2lucyA8PDw8PDw8PDw8PDw8 PDw8PAphaGMwOiBEdW1waW5nIENhcmQgU3RhdGUgd2hpbGUgaWRsZSwgYXQgU0VRQUREUiAweDE3 ZgpDYXJkIHdhcyBwYXVzZWQKQUNDVU0gPSAweDAsIFNJTkRFWCA9IDB4MjAsIERJTkRFWCA9IDB4 YTAsIEFSR18yID0gMHgyCkhDTlQgPSAweDIwIFNDQlBUUiA9IDB4MApTQ1NJU0lHSVsweDBdIEVS Uk9SWzB4NDBdOihQQ0lFUlJTVEFUKSBTQ1NJQlVTTFsweDBdCkxBU1RQSEFTRVsweDFdOihQX0JV U0ZSRUUpIFNDU0lTRVFbMHgxMl06KEVOQVVUT0FUTlB8RU5SU0VMSSkKU0JMS0NUTFsweDJdOihT RUxXSURFKSBTQ1NJUkFURVsweDBdIFNFUUNUTFsweDEwXTooRkFTVE1PREUpClNFUV9GTEFHU1sw eGMwXTooTk9fQ0RCX1NFTlR8Tk9UX0lERU5USUZJRUQpIFNTVEFUMFsweDRdOihTRE9ORSkKU1NU QVQxWzB4MF0gU1NUQVQyWzB4MF0gU1NUQVQzWzB4MF0gU0lNT0RFMFsweDBdIFNJTU9ERTFbMHhh NF06KEVOU0NTSVBFUlJ8RU5TQ1MKSVJTVHxFTlNFTFRJTU8pClNYRlJDVEwwWzB4ODBdOihERk9O KSBERkNOVFJMWzB4Y106KERJUkVDVElPTnxIRE1BRU4pCkRGU1RBVFVTWzB4NzFdOihGSUZPRU1Q fE1SRVFQRU5EfEZJRk9RV0RFTVB8REZDQUNIRVRIKQpTVEFDSzogMHhlIDB4MCAweDAgMHgxNzQK U0NCIGNvdW50ID0gMjAKS2VybmVsIE5FWFRRU0NCID0gMTQKQ2FyZCBORVhUUVNDQiA9IDkKUUlO RklGTyBlbnRyaWVzOiA5IDggNyA2IDUgNCAzIDIgMSAwIDE5IDE4IDE3IDE2IDE1CldhaXRpbmcg UXVldWUgZW50cmllczoKRGlzY29ubmVjdGVkIFF1ZXVlIGVudHJpZXM6ClFPVVRGSUZPIGVudHJp ZXM6ClNlcXVlbmNlciBGcmVlIFNDQiBMaXN0OiAxIDIgMyA0IDUgNiA3IDggOSAxMCAxMSAxMiAx MyAxNCAxNQpTZXF1ZW5jZXIgU0NCIEluZm86CiAgMCBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAgMSBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAgMiBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAgMyBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAgNCBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAgNSBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAgNiBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAgNyBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAgOCBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAgOSBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAxMCBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAxMSBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAxMiBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAxMyBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAxNCBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdCiAxNSBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJ SURbMHhmZl06KFRXSU5fQ0hOTEJ8T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZF UkxFTl9PRER8TElEKSBTQ0JfVEFHWzB4ZmZdClBlbmRpbmcgbGlzdDoKIDE1IFNDQl9DT05UUk9M WzB4MF0gU0NCX1NDU0lJRFsweGVmXTooVFdJTl9DSE5MQnxPSUQpIFNDQl9MVU5bMHgwXQogMTYg U0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4Y2ZdOihUV0lOX0NITkxCfE9JRCkgU0NCX0xV TlsweDBdCiAxNyBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhiZl06KFRXSU5fQ0hOTEJ8 T0lEKSBTQ0JfTFVOWzB4MF0KIDE4IFNDQl9DT05UUk9MWzB4MF0gU0NCX1NDU0lJRFsweDlmXToo VFdJTl9DSE5MQnxPSUQpIFNDQl9MVU5bMHgwXQogMTkgU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NT SUlEWzB4NWZdOihPSUQpIFNDQl9MVU5bMHgwXQogIDAgU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NT SUlEWzB4MmZdOihPSUQpIFNDQl9MVU5bMHgwXQogIDEgU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NT SUlEWzB4MWZdOihPSUQpIFNDQl9MVU5bMHgwXQogIDIgU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NT SUlEWzB4ZGZdOihUV0lOX0NITkxCfE9JRCkgU0NCX0xVTlsweDBdCiAgMyBTQ0JfQ09OVFJPTFsw eDBdIFNDQl9TQ1NJSURbMHhhZl06KFRXSU5fQ0hOTEJ8T0lEKSBTQ0JfTFVOWzB4MF0KICA0IFND Ql9DT05UUk9MWzB4MF0gU0NCX1NDU0lJRFsweDhmXTooVFdJTl9DSE5MQnxPSUQpIFNDQl9MVU5b MHgwXQogIDUgU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4N2ZdOihPSUR8VFdJTl9USUQp IFNDQl9MVU5bMHgwXQogIDYgU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4NmZdOihPSUQp IFNDQl9MVU5bMHgwXQogIDcgU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4NGZdOihPSUQp IFNDQl9MVU5bMHgwXQogIDggU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4M2ZdOihPSUQp IFNDQl9MVU5bMHgwXQogIDkgU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4Zl06KE9JRCkg U0NCX0xVTlsweDBdCktlcm5lbCBGcmVlIFNDQiBsaXN0OiAxMyAxMiAxMSAxMApVbnRhZ2dlZCBR KDApOiA5ClVudGFnZ2VkIFEoMSk6IDEKVW50YWdnZWQgUSgyKTogMApVbnRhZ2dlZCBRKDMpOiA4 ClVudGFnZ2VkIFEoNCk6IDcKVW50YWdnZWQgUSg1KTogMTkKVW50YWdnZWQgUSg2KTogNgpVbnRh Z2dlZCBRKDcpOiA1ClVudGFnZ2VkIFEoOCk6IDQKVW50YWdnZWQgUSg5KTogMTgKVW50YWdnZWQg USgxMCk6IDMKVW50YWdnZWQgUSgxMSk6IDE3ClVudGFnZ2VkIFEoMTIpOiAxNgpVbnRhZ2dlZCBR KDEzKTogMgpVbnRhZ2dlZCBRKDE0KTogMTUKCjw8PDw8PDw8PDw8PDw8PDw8IER1bXAgQ2FyZCBT dGF0ZSBFbmRzID4+Pj4+Pj4+Pj4+Pj4+Pj4+PgoocHJvYmUxMzphaGMwOjA6MTM6MCk6IFNDQiAw eDIgLSB0aW1lZCBvdXQKc2dbMF0gLSBBZGRyIDB4N2FlZTI4NCA6IExlbmd0aCAzNgoocHJvYmUx MzphaGMwOjA6MTM6MCk6IFNDQiAyOiBJbW1lZGlhdGUgcmVzZXQuICBGbGFncyA9IDB4NjIwCihw cm9iZTEzOmFoYzA6MDoxMzowKTogbm8gbG9uZ2VyIGluIHRpbWVvdXQsIHN0YXR1cyA9IDI1Ygph aGMwOiBJc3N1ZWQgQ2hhbm5lbCBBIEJ1cyBSZXNldC4gMTUgU0NCcyBhYm9ydGVkCihwcm9iZTA6 YWhjMDowOjA6MCk6IFJlcXVlc3QgUmVxdWV1ZWQKKHByb2JlMDphaGMwOjA6MDowKTogUmV0cnlp bmcgQ29tbWFuZAoocHJvYmUzOmFoYzA6MDozOjApOiBSZXF1ZXN0IFJlcXVldWVkCihwcm9iZTM6 YWhjMDowOjM6MCk6IFJldHJ5aW5nIENvbW1hbmQKKHByb2JlNDphaGMwOjA6NDowKTogUmVxdWVz dCBSZXF1ZXVlZAoocHJvYmU0OmFoYzA6MDo0OjApOiBSZXRyeWluZyBDb21tYW5kCihwcm9iZTY6 YWhjMDowOjY6MCk6IFJlcXVlc3QgUmVxdWV1ZWQKKHByb2JlNjphaGMwOjA6NjowKTogUmV0cnlp bmcgQ29tbWFuZAoocHJvYmU3OmFoYzA6MDo3OjApOiBSZXF1ZXN0IFJlcXVldWVkCihwcm9iZTc6 YWhjMDowOjc6MCk6IFJldHJ5aW5nIENvbW1hbmQKKHByb2JlODphaGMwOjA6ODowKTogUmVxdWVz dCBSZXF1ZXVlZAoocHJvYmU4OmFoYzA6MDo4OjApOiBSZXRyeWluZyBDb21tYW5kCihwcm9iZTEw OmFoYzA6MDoxMDowKTogUmVxdWVzdCBSZXF1ZXVlZAoocHJvYmUxMDphaGMwOjA6MTA6MCk6IFJl dHJ5aW5nIENvbW1hbmQKKHByb2JlMTM6YWhjMDowOjEzOjApOiBSZXF1ZXN0IFJlcXVldWVkCihw cm9iZTEzOmFoYzA6MDoxMzowKTogUmV0cnlpbmcgQ29tbWFuZAoocHJvYmUxOmFoYzA6MDoxOjAp OiBSZXF1ZXN0IFJlcXVldWVkCihwcm9iZTE6YWhjMDowOjE6MCk6IFJldHJ5aW5nIENvbW1hbmQK KHByb2JlMjphaGMwOjA6MjowKTogUmVxdWVzdCBSZXF1ZXVlZAoocHJvYmUyOmFoYzA6MDoyOjAp OiBSZXRyeWluZyBDb21tYW5kCihwcm9iZTU6YWhjMDowOjU6MCk6IFJlcXVlc3QgUmVxdWV1ZWQK KHByb2JlNTphaGMwOjA6NTowKTogUmV0cnlpbmcgQ29tbWFuZAoocHJvYmU5OmFoYzA6MDo5OjAp OiBSZXF1ZXN0IFJlcXVldWVkCihwcm9iZTk6YWhjMDowOjk6MCk6IFJldHJ5aW5nIENvbW1hbmQK KHByb2JlMTE6YWhjMDowOjExOjApOiBSZXF1ZXN0IFJlcXVldWVkCihwcm9iZTExOmFoYzA6MDox MTowKTogUmV0cnlpbmcgQ29tbWFuZAoocHJvYmUxMjphaGMwOjA6MTI6MCk6IFJlcXVlc3QgUmVx dWV1ZWQKKHByb2JlMTI6YWhjMDowOjEyOjApOiBSZXRyeWluZyBDb21tYW5kCihwcm9iZTE0OmFo YzA6MDoxNDowKTogUmVxdWVzdCBSZXF1ZXVlZAoocHJvYmUxNDphaGMwOjA6MTQ6MCk6IFJldHJ5 aW5nIENvbW1hbmQKYWhjMDogUmVjb3ZlcnkgSW5pdGlhdGVkCj4+Pj4+Pj4+Pj4+Pj4+Pj4+PiBE dW1wIENhcmQgU3RhdGUgQmVnaW5zIDw8PDw8PDw8PDw8PDw8PDw8CmFoYzA6IER1bXBpbmcgQ2Fy ZCBTdGF0ZSB3aGlsZSBpZGxlLCBhdCBTRVFBRERSIDB4MTdmCkNhcmQgd2FzIHBhdXNlZApBQ0NV TSA9IDB4MCwgU0lOREVYID0gMHgyMCwgRElOREVYID0gMHhhMCwgQVJHXzIgPSAweDMKSENOVCA9 IDB4MjAgU0NCUFRSID0gMHgwClNDU0lTSUdJWzB4MF0gRVJST1JbMHg0MF06KFBDSUVSUlNUQVQp IFNDU0lCVVNMWzB4MF0KTEFTVFBIQVNFWzB4MV06KFBfQlVTRlJFRSkgU0NTSVNFUVsweDEyXToo RU5BVVRPQVROUHxFTlJTRUxJKQpTQkxLQ1RMWzB4Ml06KFNFTFdJREUpIFNDU0lSQVRFWzB4MF0g U0VRQ1RMWzB4MTBdOihGQVNUTU9ERSkKU0VRX0ZMQUdTWzB4YzBdOihOT19DREJfU0VOVHxOT1Rf SURFTlRJRklFRCkgU1NUQVQwWzB4NF06KFNET05FKQpTU1RBVDFbMHgwXSBTU1RBVDJbMHgwXSBT U1RBVDNbMHgwXSBTSU1PREUwWzB4MF0gU0lNT0RFMVsweGE0XTooRU5TQ1NJUEVSUnxFTlNDUwpJ UlNUfEVOU0VMVElNTykKU1hGUkNUTDBbMHg4MF06KERGT04pIERGQ05UUkxbMHhjXTooRElSRUNU SU9OfEhETUFFTikKREZTVEFUVVNbMHg3MV06KEZJRk9FTVB8TVJFUVBFTkR8RklGT1FXREVNUHxE RkNBQ0hFVEgpClNUQUNLOiAweGUgMHhlIDB4MCAweDE3NApTQ0IgY291bnQgPSAyMApLZXJuZWwg TkVYVFFTQ0IgPSA5CkNhcmQgTkVYVFFTQ0IgPSAxNApRSU5GSUZPIGVudHJpZXM6IDE0IDE1IDE2 IDE3IDE4IDE5IDAgMSAyIDMgNCA1IDYgNyA4CldhaXRpbmcgUXVldWUgZW50cmllczoKRGlzY29u bmVjdGVkIFF1ZXVlIGVudHJpZXM6ClFPVVRGSUZPIGVudHJpZXM6ClNlcXVlbmNlciBGcmVlIFND QiBMaXN0OiAxIDIgMyA0IDUgNiA3IDggOSAxMCAxMSAxMiAxMyAxNCAxNQpTZXF1ZW5jZXIgU0NC IEluZm86CiAgMCBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAgMSBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAgMiBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAgMyBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAgNCBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAgNSBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAgNiBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAgNyBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAgOCBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAgOSBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAxMCBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAxMSBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAxMiBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAxMyBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAxNCBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdCiAxNSBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhmZl06KFRXSU5fQ0hOTEJ8 T0lEfFRXSU5fVElEKQpTQ0JfTFVOWzB4ZmZdOihTQ0JfWEZFUkxFTl9PRER8TElEKSBTQ0JfVEFH WzB4ZmZdClBlbmRpbmcgbGlzdDoKICA4IFNDQl9DT05UUk9MWzB4MF0gU0NCX1NDU0lJRFsweGVm XTooVFdJTl9DSE5MQnxPSUQpIFNDQl9MVU5bMHgwXQogIDcgU0NCX0NPTlRST0xbMHgwXSBTQ0Jf U0NTSUlEWzB4Y2ZdOihUV0lOX0NITkxCfE9JRCkgU0NCX0xVTlsweDBdCiAgNiBTQ0JfQ09OVFJP TFsweDBdIFNDQl9TQ1NJSURbMHhiZl06KFRXSU5fQ0hOTEJ8T0lEKSBTQ0JfTFVOWzB4MF0KICA1 IFNDQl9DT05UUk9MWzB4MF0gU0NCX1NDU0lJRFsweDlmXTooVFdJTl9DSE5MQnxPSUQpIFNDQl9M VU5bMHgwXQogIDQgU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4NWZdOihPSUQpIFNDQl9M VU5bMHgwXQogIDMgU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4MmZdOihPSUQpIFNDQl9M VU5bMHgwXQogIDIgU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4MWZdOihPSUQpIFNDQl9M VU5bMHgwXQogIDEgU0NCX0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4ZGZdOihUV0lOX0NITkxC fE9JRCkgU0NCX0xVTlsweDBdCiAgMCBTQ0JfQ09OVFJPTFsweDBdIFNDQl9TQ1NJSURbMHhhZl06 KFRXSU5fQ0hOTEJ8T0lEKSBTQ0JfTFVOWzB4MF0KIDE5IFNDQl9DT05UUk9MWzB4MF0gU0NCX1ND U0lJRFsweDhmXTooVFdJTl9DSE5MQnxPSUQpIFNDQl9MVU5bMHgwXQogMTggU0NCX0NPTlRST0xb MHgwXSBTQ0JfU0NTSUlEWzB4N2ZdOihPSUR8VFdJTl9USUQpIFNDQl9MVU5bMHgwXQogMTcgU0NC X0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4NmZdOihPSUQpIFNDQl9MVU5bMHgwXQogMTYgU0NC X0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4NGZdOihPSUQpIFNDQl9MVU5bMHgwXQogMTUgU0NC X0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4M2ZdOihPSUQpIFNDQl9MVU5bMHgwXQogMTQgU0NC X0NPTlRST0xbMHgwXSBTQ0JfU0NTSUlEWzB4Zl06KE9JRCkgU0NCX0xVTlsweDBdCktlcm5lbCBG cmVlIFNDQiBsaXN0OiAxMyAxMiAxMSAxMApVbnRhZ2dlZCBRKDApOiAxNApVbnRhZ2dlZCBRKDEp OiAyClVudGFnZ2VkIFEoMik6IDMKVW50YWdnZWQgUSgzKTogMTUKVW50YWdnZWQgUSg0KTogMTYK VW50YWdnZWQgUSg1KTogNApVbnRhZ2dlZCBRKDYpOiAxNwpVbnRhZ2dlZCBRKDcpOiAxOApVbnRh Z2dlZCBRKDgpOiAxOQpVbnRhZ2dlZCBRKDkpOiA1ClVudGFnZ2VkIFEoMTApOiAwClVudGFnZ2Vk IFEoMTEpOiA2ClVudGFnZ2VkIFEoMTIpOiA3ClVudGFnZ2VkIFEoMTMpOiAxClVudGFnZ2VkIFEo MTQpOiA4Cgo8PDw8PDw8PDw8PDw8PDw8PCBEdW1wIENhcmQgU3RhdGUgRW5kcyA+Pj4+Pj4+Pj4+ Pj4+Pj4+Pj4KKHByb2JlMTA6YWhjMDowOjEwOjApOiBTQ0IgMHgwIC0gdGltZWQgb3V0CnNnWzBd IC0gQWRkciAweDdhZWU4ODQgOiBMZW5ndGggMzYKKHByb2JlMTA6YWhjMDowOjEwOjApOiBTQ0Ig MDogSW1tZWRpYXRlIHJlc2V0LiAgRmxhZ3MgPSAweDYyMAoocHJvYmUxMDphaGMwOjA6MTA6MCk6 IG5vIGxvbmdlciBpbiB0aW1lb3V0LCBzdGF0dXMgPSAyNWIKYWhjMDogSXNzdWVkIENoYW5uZWwg QSBCdXMgUmVzZXQuIDE1IFNDQnMgYWJvcnRlZAoocHJvYmUwOmFoYzA6MDowOjApOiBSZXF1ZXN0 IFJlcXVldWVkCihwcm9iZTA6YWhjMDowOjA6MCk6IFJldHJ5aW5nIENvbW1hbmQKKHByb2JlMzph aGMwOjA6MzowKTogUmVxdWVzdCBSZXF1ZXVlZAoocHJvYmUzOmFoYzA6MDozOjApOiBSZXRyeWlu ZyBDb21tYW5kCihwcm9iZTQ6YWhjMDowOjQ6MCk6IFJlcXVlc3QgUmVxdWV1ZWQKKHByb2JlNDph aGMwOjA6NDowKTogUmV0cnlpbmcgQ29tbWFuZAoocHJvYmU2OmFoYzA6MDo2OjApOiBSZXF1ZXN0 IFJlcXVldWVkCihwcm9iZTY6YWhjMDowOjY6MCk6IFJldHJ5aW5nIENvbW1hbmQKKHByb2JlNzph aGMwOjA6NzowKTogUmVxdWVzdCBSZXF1ZXVlZAoocHJvYmU3OmFoYzA6MDo3OjApOiBSZXRyeWlu ZyBDb21tYW5kCihwcm9iZTg6YWhjMDowOjg6MCk6IFJlcXVlc3QgUmVxdWV1ZWQKKHByb2JlODph aGMwOjA6ODowKTogUmV0cnlpbmcgQ29tbWFuZAoocHJvYmUxMDphaGMwOjA6MTA6MCk6IFJlcXVl c3QgUmVxdWV1ZWQKKHByb2JlMTA6YWhjMDowOjEwOjApOiBSZXRyeWluZyBDb21tYW5kCihwcm9i ZTEzOmFoYzA6MDoxMzowKTogUmVxdWVzdCBSZXF1ZXVlZAoocHJvYmUxMzphaGMwOjA6MTM6MCk6 IFJldHJ5aW5nIENvbW1hbmQKKHByb2JlMTphaGMwOjA6MTowKTogUmVxdWVzdCBSZXF1ZXVlZAoo cHJvYmUxOmFoYzA6MDoxOjApOiBSZXRyeWluZyBDb21tYW5kCihwcm9iZTI6YWhjMDowOjI6MCk6 IFJlcXVlc3QgUmVxdWV1ZWQKKHByb2JlMjphaGMwOjA6MjowKTogUmV0cnlpbmcgQ29tbWFuZAoo cHJvYmU1OmFoYzA6MDo1OjApOiBSZXF1ZXN0IFJlcXVldWVkCihwcm9iZTU6YWhjMDowOjU6MCk6 IFJldHJ5aW5nIENvbW1hbmQKKHByb2JlOTphaGMwOjA6OTowKTogUmVxdWVzdCBSZXF1ZXVlZAoo cHJvYmU5OmFoYzA6MDo5OjApOiBSZXRyeWluZyBDb21tYW5kCihwcm9iZTExOmFoYzA6MDoxMTow KTogUmVxdWVzdCBSZXF1ZXVlZAoocHJvYmUxMTphaGMwOjA6MTE6MCk6IFJldHJ5aW5nIENvbW1h bmQKKHByb2JlMTI6YWhjMDowOjEyOjApOiBSZXF1ZXN0IFJlcXVldWVkCihwcm9iZTEyOmFoYzA6 MDoxMjowKTogUmV0cnlpbmcgQ29tbWFuZAoocHJvYmUxNDphaGMwOjA6MTQ6MCk6IFJlcXVlc3Qg UmVxdWV1ZWQKKHByb2JlMTQ6YWhjMDowOjE0OjApOiBSZXRyeWluZyBDb21tYW5kCmFoYzA6IFRp bWVkb3V0IFNDQnMgYWxyZWFkeSBjb21wbGV0ZS4gSW50ZXJydXB0cyBtYXkgbm90IGJlIGZ1bmN0 aW9uaW5nLgo= ------=_Part_890_22892878.1118854774097-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 18:29: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 DF87116A41C; Wed, 15 Jun 2005 18:29:17 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from smtpout.mac.com (smtpout.mac.com [17.250.248.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id C554F43D4C; Wed, 15 Jun 2005 18:29:17 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from mac.com (smtpin02-en2 [10.13.10.147]) by smtpout.mac.com (Xserve/8.12.11/smtpout06/MantshX 4.0) with ESMTP id j5FITHAT017907; Wed, 15 Jun 2005 11:29:17 -0700 (PDT) Received: from [10.1.1.153] (nfw1.codefab.com [199.103.21.225]) (authenticated bits=0) by mac.com (Xserve/smtpin02/MantshX 4.0) with ESMTP id j5FITFIX015058; Wed, 15 Jun 2005 11:29:16 -0700 (PDT) In-Reply-To: <20050615160741.GA55062@dragon.NUXI.org> References: <200504262010.49509@harrymail> <20050429200029.GC232@cirb503493.alcatel.com.au> <200506141824.17451@harrymail> <20050614185923.GA12375@dragon.NUXI.org> <20050615054209.L29741@beagle.kn.op.dlr.de> <20050615160741.GA55062@dragon.NUXI.org> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <88862BDF-ED45-42CE-9B24-DEEED2E66C2C@mac.com> Content-Transfer-Encoding: 7bit From: Charles Swiger Date: Wed, 15 Jun 2005 14:29:35 -0400 To: obrien@freebsd.org X-Mailer: Apple Mail (2.730) Cc: freebsd-current@freebsd.org Subject: Re: groff alternative? 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, 15 Jun 2005 18:29:18 -0000 On Jun 15, 2005, at 12:07 PM, David O'Brien wrote: >> You don't need to distribute the new file >> with that function. Of course that new file will not be CDDL covered. > > I never said CDDL was viral. It is like the GPL (LGPL if you like) in > that you must deliver the source with the binary. For key userland > pieces or kernel subsystems this goes against our philosophy. For > complete utilities, such as groff, CDDL is >< better than GPL as > the end > result is the 99.9% same. The OSI discussion on the CDDL counted it as a MPL derivative which is free, fair, reciprocal (or "copyleft", if you prefer that term), contains narrowly-crafted patent grant and patent defense clauses. My impression is that FreeBSD could redistribute code under this license and/or mix it with BSD-licensed code with less risk of conflict than one assumes with the GPL (due to GPL clause 7), as even the 3-clause variant of the BSD license-- which requires attribution of the authors-- conflicts with GPL #7. If the sole criterion is whether the CDDL permits one to redistribute private modifications in binary form without source, you're right that the CDDL is in the same boat as the GPL. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 18: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 3A87816A41C for ; Wed, 15 Jun 2005 18:40:42 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from knight.ixsystems.net (afg.ixsystems.net [206.40.55.73]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1DB9E43D1F for ; Wed, 15 Jun 2005 18:40:42 +0000 (GMT) (envelope-from dodell@offmyserver.com) Received: from [192.168.1.111] (afg.ixsystems.net [206.40.55.73]) by knight.ixsystems.net (8.12.10/8.11.6) with ESMTP id j5FIHQgs036178; Wed, 15 Jun 2005 11:17:27 -0700 (PDT) (envelope-from dodell@offmyserver.com) Message-ID: <42B0762D.8040202@offmyserver.com> Date: Wed, 15 Jun 2005 11:40:45 -0700 From: "Devon H. O'Dell" User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Lyndon Nerenberg References: <200504262010.49509@harrymail> <20050429200029.GC232@cirb503493.alcatel.com.au> <200506141824.17451@harrymail> <20050614185923.GA12375@dragon.NUXI.org> <42AF374F.3000705@offmyserver.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: groff alternative? 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, 15 Jun 2005 18:40:42 -0000 Lyndon Nerenberg wrote: > > On Jun 14, 2005, at 1:00 PM, Devon H. O'Dell wrote: > >> Would troff/nroff/ps/pdf utilities from Plan 9 be usable? The license >> isn't as restrictive. > > > But probably better than what Sun is using. The Plan 9 troff has the > advantage of being UTF-8 savvy. It has the disadvantage of requiring > the Plan 9 runtime compatibility libraries be brought along. The disadvantages to not having a standard libc :(. Perhaps the ones from Russ Cox's Plan 9 From User Space would be a better start? (A.K.A. plan9port) > I don't have time right this minute to investigate further. Maybe in a > week or two. I know Sascha Wildner (DragonFly syscons extraordinaire, among other things) was interested in porting this in that camp. If you're going to take a look at it, perhaps it would be a good idea to talk to him. I'd be interested in helping as well. --Devon From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 19:04: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 5EE6216A41C; Wed, 15 Jun 2005 19:04:24 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail11.syd.optusnet.com.au (mail11.syd.optusnet.com.au [211.29.132.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id DF0BF43D49; Wed, 15 Jun 2005 19:04:23 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-8-51.belrs4.nsw.optusnet.com.au [220.239.8.51]) by mail11.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j5FJ4Kr0010819 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 16 Jun 2005 05:04:21 +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 j5FJ4KRx056418; Thu, 16 Jun 2005 05:04: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 j5FJ4Jl3056417; Thu, 16 Jun 2005 05:04:19 +1000 (EST) (envelope-from pjeremy) Date: Thu, 16 Jun 2005 05:04:19 +1000 From: Peter Jeremy To: "M.Jessa" Message-ID: <20050615190418.GD50157@cirb503493.alcatel.com.au> References: <58397.148.122.180.9.1118829978.squirrel@mail.yazzy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58397.148.122.180.9.1118829978.squirrel@mail.yazzy.org> User-Agent: Mutt/1.4.2i Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: Looking for networking solution. 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, 15 Jun 2005 19:04:24 -0000 On Wed, 2005-Jun-15 12:06:18 +0200, M.Jessa wrote: >I am looking for solution I could implement on a link with a huge latency >when ping replies can go up to a few hundred miliseconds, e.g sateliete >links. What is the problem you are trying to solve? Satellite links have a fairly constant round-trip delay and the RTT calculations built into TCP will happily compensate for this. As long as the TCP window size is larger than the delay*bandwidth and the packet loss probability is well below 1 packet per window, TCP should work fine. >What I was thinking about is some kind of virtual interface which could >translate tcp to udp in one of the pears of the link and push the data it >received from a 'normal' interface through the virtual interface without >bothering about ack-timing. How does the transmitter confirm that the receiver has received packets and can therefore drop them from its transmit buffer (or resend them if they are not received)? In particular, if there is no traffic for a period, the only way that the last packet (before the break) can be confirmed is via acknowledge timeouts. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 19:15:11 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 D841916A41C; Wed, 15 Jun 2005 19:15:11 +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 5E54443D1D; Wed, 15 Jun 2005 19:15:06 +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 j5FJEqS2062964; Wed, 15 Jun 2005 23:14:53 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Wed, 15 Jun 2005 23:14:52 +0400 (MSD) From: Maxim Konovalov To: "M. Warner Losh" In-Reply-To: <20050615.002712.123500387.imp@bsdimp.com> Message-ID: <20050615230844.G61956@mp2.macomnet.net> References: <20050614231344.F76340@mp2.macomnet.net> <20050615.002712.123500387.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: brooks@freebsd.org, current@freebsd.org Subject: Re: ed(4) broken? 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, 15 Jun 2005 19:15:12 -0000 On Wed, 15 Jun 2005, 00:27-0600, M. Warner Losh wrote: > In message: <20050614231344.F76340@mp2.macomnet.net> > Maxim Konovalov writes: > : Latest GENERIC in qemu produces > : Jun 14 19:12:04 qemu6 kernel: ed_start(0xc12e5000) GONE > : Jun 14 19:12:07 qemu6 kernel: ed0: NIC memory corrupt - invalid packet length 45 > : No real hardware though. > > ed works for me on all the real hardware I have. Maybe you could give > me more details. Something between 2005/06/10 00:00 UTC and 2005/06/11 00:00 UTC broke qemu's ed(4). I'm still not sure it's not qemu problem. No additional info so far, sorry. -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 19:58: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 8C0B116A41C; Wed, 15 Jun 2005 19:58:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53D2F43D48; Wed, 15 Jun 2005 19:58:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5FJtqdB027698; Wed, 15 Jun 2005 13:55:52 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 15 Jun 2005 13:55:52 -0600 (MDT) Message-Id: <20050615.135552.74722719.imp@bsdimp.com> To: maxim@macomnet.ru From: Warner Losh In-Reply-To: <20050615230844.G61956@mp2.macomnet.net> References: <20050614231344.F76340@mp2.macomnet.net> <20050615.002712.123500387.imp@bsdimp.com> <20050615230844.G61956@mp2.macomnet.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: brooks@FreeBSD.ORG, current@FreeBSD.ORG Subject: Re: ed(4) broken? 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, 15 Jun 2005 19:58:48 -0000 From: Maxim Konovalov Subject: Re: ed(4) broken? Date: Wed, 15 Jun 2005 23:14:52 +0400 (MSD) > On Wed, 15 Jun 2005, 00:27-0600, M. Warner Losh wrote: > > > In message: <20050614231344.F76340@mp2.macomnet.net> > > Maxim Konovalov writes: > > : Latest GENERIC in qemu produces > > : Jun 14 19:12:04 qemu6 kernel: ed_start(0xc12e5000) GONE > > : Jun 14 19:12:07 qemu6 kernel: ed0: NIC memory corrupt - invalid packet length 45 > > : No real hardware though. > > > > ed works for me on all the real hardware I have. Maybe you could give > > me more details. > > Something between 2005/06/10 00:00 UTC and 2005/06/11 00:00 UTC broke > qemu's ed(4). I'm still not sure it's not qemu problem. No > additional info so far, sorry. That's when the big, jumbo ifnet patch went in. I eyeballed the changes and can see nothing wrong by visual inspection. Warner From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 20:14:01 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 5785516A41C; Wed, 15 Jun 2005 20:14:01 +0000 (GMT) (envelope-from hans@lambermont.dyndns.org) Received: from lambermont.dyndns.org (lambermont.dyndns.org [82.93.47.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id F375943D1F; Wed, 15 Jun 2005 20:14:00 +0000 (GMT) (envelope-from hans@lambermont.dyndns.org) Received: by lambermont.dyndns.org (Postfix, from userid 1001) id 8DC5995B17; Wed, 15 Jun 2005 22:13:59 +0200 (CEST) Date: Wed, 15 Jun 2005 22:13:59 +0200 To: Peter Jeremy Message-ID: <20050615201359.GC16227@leia.lambermont.dyndns.org> References: <58397.148.122.180.9.1118829978.squirrel@mail.yazzy.org> <20050615190418.GD50157@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050615190418.GD50157@cirb503493.alcatel.com.au> User-Agent: Mutt/1.4.2.1i From: hans@lambermont.dyndns.org (Hans Lambermont) Cc: freebsd-net@freebsd.org, "M.Jessa" , current@freebsd.org Subject: Re: Looking for networking solution. 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, 15 Jun 2005 20:14:01 -0000 Peter Jeremy wrote: > On Wed, 2005-Jun-15 12:06:18 +0200, M.Jessa wrote: >> I am looking for solution I could implement on a link with a huge >> latency when ping replies can go up to a few hundred miliseconds, e.g >> sateliete links. > > What is the problem you are trying to solve? Satellite links have a > fairly constant round-trip delay and the RTT calculations built into > TCP will happily compensate for this. As long as the TCP window size > is larger than the delay*bandwidth and the packet loss probability is > well below 1 packet per window, TCP should work fine. There's a lot to improve on in this situation, See f.i. http://www.tellitec.be/tellinet/enhanced.html -- Hans Disclaimer: I have a business relation to Tellitec. -- http://hans.dse.nl/ () ASCII-ribbon campaign against vCards, /\ HTML-mail and proprietary formats. From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 20:23:58 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 576BB16A41F for ; Wed, 15 Jun 2005 20:23:58 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FADD43D58 for ; Wed, 15 Jun 2005 20:23:57 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5FKNtXG015251; Wed, 15 Jun 2005 13:23:55 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5FKNtkN015250; Wed, 15 Jun 2005 13:23:55 -0700 Date: Wed, 15 Jun 2005 13:23:55 -0700 From: Brooks Davis To: Warner Losh Message-ID: <20050615202355.GA12986@odin.ac.hmc.edu> References: <20050614231344.F76340@mp2.macomnet.net> <20050615.002712.123500387.imp@bsdimp.com> <20050615230844.G61956@mp2.macomnet.net> <20050615.135552.74722719.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="mP3DRpeJDSE+ciuQ" Content-Disposition: inline In-Reply-To: <20050615.135552.74722719.imp@bsdimp.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@FreeBSD.ORG Subject: Re: ed(4) broken? 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, 15 Jun 2005 20:23:58 -0000 --mP3DRpeJDSE+ciuQ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 15, 2005 at 01:55:52PM -0600, Warner Losh wrote: > From: Maxim Konovalov > Subject: Re: ed(4) broken? > Date: Wed, 15 Jun 2005 23:14:52 +0400 (MSD) >=20 > > On Wed, 15 Jun 2005, 00:27-0600, M. Warner Losh wrote: > >=20 > > > In message: <20050614231344.F76340@mp2.macomnet.net> > > > Maxim Konovalov writes: > > > : Latest GENERIC in qemu produces > > > : Jun 14 19:12:04 qemu6 kernel: ed_start(0xc12e5000) GONE > > > : Jun 14 19:12:07 qemu6 kernel: ed0: NIC memory corrupt - invalid pac= ket length 45 > > > : No real hardware though. > > > > > > ed works for me on all the real hardware I have. Maybe you could give > > > me more details. > >=20 > > Something between 2005/06/10 00:00 UTC and 2005/06/11 00:00 UTC broke > > qemu's ed(4). I'm still not sure it's not qemu problem. No > > additional info so far, sorry. >=20 > That's when the big, jumbo ifnet patch went in. I eyeballed the > changes and can see nothing wrong by visual inspection. I've looked to code over closely again and I'm supprised it works for anyone. I found four instances of casts of sc to get ifp including one if sc_xmit. I must have missed them when reconverting the driver after your cleanup. :( I've commited a fix for them. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --mP3DRpeJDSE+ciuQ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCsI5aXY6L6fI4GtQRAjUPAKCOFVEqi9gbzY0kG9pcIBvVLDwrJQCfSAcb t93q2fW1q4Huhe8/tq+Ogwc= =5Luw -----END PGP SIGNATURE----- --mP3DRpeJDSE+ciuQ-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 22:24: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 8AA2216A41C for ; Wed, 15 Jun 2005 22:24:18 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (afields.ca [216.194.67.132]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5F15F43D48 for ; Wed, 15 Jun 2005 22:24:18 +0000 (GMT) (envelope-from afields@afields.ca) Received: from afields.ca (localhost.afields.ca [127.0.0.1]) by afields.ca (8.12.11/8.12.11) with ESMTP id j5FMOHLe096021 for ; Wed, 15 Jun 2005 18:24:17 -0400 (EDT) (envelope-from afields@afields.ca) Received: (from afields@localhost) by afields.ca (8.12.11/8.12.11/Submit) id j5FMOHNI096020 for freebsd-current@freebsd.org; Wed, 15 Jun 2005 18:24:17 -0400 (EDT) (envelope-from afields) Date: Wed, 15 Jun 2005 18:24:17 -0400 From: Allan Fields To: freebsd-current@freebsd.org Message-ID: <20050615222417.GA95979@afields.ca> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="YZ5djTAD1cGYuMQK" Content-Disposition: inline User-Agent: Mutt/1.4i Subject: ddb(4) manpage: kill 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, 15 Jun 2005 22:24:18 -0000 --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Kill entry for ddb(4) manpage. -- Allan Fields --YZ5djTAD1cGYuMQK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ddb.diff" --- ddb.4.orig Wed Jun 15 16:36:40 2005 +++ ddb.4 Wed Jun 15 18:04:00 2005 @@ -409,6 +409,20 @@ .Li m modifier will alter the display to show VM map addresses for the process and not show other info. +.It Xo Cm kill +.Ar sig Ns , Ns +.Ar pid +.Xc +Send a signal to a process. +Send signal +.Ar sig +to process +.Ar pid Ns +, which is acted upon returning from the debugger. +Can be used to kill a process causing resource contention in the case of a hung system. +See: +.Xr signal 3 +for a list of signals. .It Cm show registers Ns Op Cm /u Display the register set. If the --YZ5djTAD1cGYuMQK-- From owner-freebsd-current@FreeBSD.ORG Wed Jun 15 23:18: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 C362516A41C for ; Wed, 15 Jun 2005 23:18:10 +0000 (GMT) (envelope-from tataz@tataz.chchile.org) Received: from postfix4-1.free.fr (postfix4-1.free.fr [213.228.0.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 88A1D43D1D for ; Wed, 15 Jun 2005 23:18:10 +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-1.free.fr (Postfix) with ESMTP id 2A8A829B1F6 for ; Thu, 16 Jun 2005 01:18:09 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 49F8A407E; Thu, 16 Jun 2005 01:18:23 +0200 (CEST) Date: Thu, 16 Jun 2005 01:18:23 +0200 From: Jeremie Le Hen To: freebsd-current@FreeBSD.org Message-ID: <20050615231823.GB2239@obiwan.tataz.chchile.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Cc: Subject: incorrect ping(8) interval with powerd(8) 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, 15 Jun 2005 23:18:10 -0000 Hi list, as the subjects state, when powerd(8) is running and has set a lower frequency than the processor's natural one, interval between each packets are too long. When my laptop is plugged, I told powerd(8) to run the processor at maximum speed (-a max). Let's have a look at this : %%% jarjarbinks:root# sysctl hw.acpi.acline hw.acpi.acline: 1 jarjarbinks:root# sysctl dev.cpu.0.freq dev.cpu.0.freq: 1735 jarjarbinks:root# time ping -qc 2 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes --- 192.168.1.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.266/0.269/0.271/0.002 ms real 0m1.003s user 0m0.001s sys 0m0.001s jarjarbinks:root# sysctl hw.acpi.acline hw.acpi.acline: 0 jarjarbinks:root# sysctl dev.cpu.0.freq dev.cpu.0.freq: 216 jarjarbinks:root# time ping -qc 2 192.168.1.1 PING 192.168.1.1 (192.168.1.1): 56 data bytes --- 192.168.1.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.637/0.814/0.991/0.177 ms real 0m2.252s user 0m0.004s sys 0m0.021s %%% I check ping(8) source code and it appears it uses select(8) to wait the desired amount of time. I don't think this is the intended behaviour. Where does this bug (feature?) come from ? Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 00:38: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 16D5B16A41C for ; Thu, 16 Jun 2005 00:38:13 +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 CA4B443D1D for ; Thu, 16 Jun 2005 00:38:13 +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 9160E19F3B; Wed, 15 Jun 2005 17:39:41 -0700 (PDT) From: "Darren Pilgrim" To: "'Brooks Davis'" , "'Vladimir Grebenschikov'" Date: Wed, 15 Jun 2005 17:38:10 -0700 Message-ID: <001501c5720b$aceb84d0$0b2a15ac@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: <20050615061009.GA11914@odin.ac.hmc.edu> Importance: Normal Cc: freebsd-current@freebsd.org, 'Matthew Emmerton' Subject: RE: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 00:38:14 -0000 From: Brooks Davis > There are two issues here. First, if we're going to keep > network_interfaces around, /etc/rc.d/dhclient should honor > it and not start dhclient on interfaces not in either > network_interfaces or removable interfaces. I think network_interfaces should be gotten rid of entirely for two reasons: 1: It creates a synchronization issue between it and the ifconfig_* lines and duplicates functionality. IIRC, rc.conf being out of sync in this way has tripped up users in the past. 2: There are real configurations in which some interfaces are not available when netif is run at boot. One example is the many newer mini-PCI wireless NICs that require a firmware upload. Devd is the accepted tool for performing such tasks, but rcordering puts devd after NETWORKING. The actions taken by devd must therefore include steps taken by netif. Calling the rc.d scripts directly from devd avoids local scripts that duplicate rc.d functionality. A similar situation occurs for removable interfaces. From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 00:41: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 4D0F316A41C for ; Thu, 16 Jun 2005 00:41:33 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Received: from web80606.mail.yahoo.com (web80606.mail.yahoo.com [66.218.79.95]) by mx1.FreeBSD.org (Postfix) with SMTP id 2729443D48 for ; Thu, 16 Jun 2005 00:41:33 +0000 (GMT) (envelope-from mohan_srinivasan@yahoo.com) Received: (qmail 34624 invoked by uid 60001); 16 Jun 2005 00:41:32 -0000 Message-ID: <20050616004132.34622.qmail@web80606.mail.yahoo.com> Received: from [64.168.22.148] by web80606.mail.yahoo.com via HTTP; Wed, 15 Jun 2005 17:41:32 PDT Date: Wed, 15 Jun 2005 17:41:32 -0700 (PDT) From: Mohan Srinivasan To: current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Cc: Subject: Kernel lockmgr races LK_UPGRADE against LK_SHARED... 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, 16 Jun 2005 00:41:33 -0000 This is on 4.x, but I'm posting to current, it's likely also an issue on current. Posting here hoping someone can shed more info on this lockmgr race. I've into a bug where process 1 successfully LK_UPGRADEs a vnode lock (from shared to excl) and process 2 successfully acquires the shared lock on that same vnode. I am not sure what order the locks were acquired, it's not possible to infer that from the core. Does this bug ring a bell with anyone ? If it does, can they shed any light/info they might have on this ? thanks mohan From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 01:07:58 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 2A29716A41F for ; Thu, 16 Jun 2005 01:07:58 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id E1BA143D49 for ; Thu, 16 Jun 2005 01:07:57 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5G16vHW030582; Wed, 15 Jun 2005 19:06:58 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 15 Jun 2005 14:34:03 -0600 (MDT) Message-Id: <20050615.143403.58435323.imp@bsdimp.com> To: brooks@one-eyed-alien.net From: "M. Warner Losh" In-Reply-To: <20050615202355.GA12986@odin.ac.hmc.edu> References: <20050615230844.G61956@mp2.macomnet.net> <20050615.135552.74722719.imp@bsdimp.com> <20050615202355.GA12986@odin.ac.hmc.edu> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: current@FreeBSD.ORG Subject: Re: ed(4) broken? 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, 16 Jun 2005 01:07:58 -0000 In message: <20050615202355.GA12986@odin.ac.hmc.edu> Brooks Davis writes: : On Wed, Jun 15, 2005 at 01:55:52PM -0600, Warner Losh wrote: : > From: Maxim Konovalov : > Subject: Re: ed(4) broken? : > Date: Wed, 15 Jun 2005 23:14:52 +0400 (MSD) : > : > > On Wed, 15 Jun 2005, 00:27-0600, M. Warner Losh wrote: : > > : > > > In message: <20050614231344.F76340@mp2.macomnet.net> : > > > Maxim Konovalov writes: : > > > : Latest GENERIC in qemu produces : > > > : Jun 14 19:12:04 qemu6 kernel: ed_start(0xc12e5000) GONE : > > > : Jun 14 19:12:07 qemu6 kernel: ed0: NIC memory corrupt - invalid packet length 45 : > > > : No real hardware though. : > > > : > > > ed works for me on all the real hardware I have. Maybe you could give : > > > me more details. : > > : > > Something between 2005/06/10 00:00 UTC and 2005/06/11 00:00 UTC broke : > > qemu's ed(4). I'm still not sure it's not qemu problem. No : > > additional info so far, sorry. : > : > That's when the big, jumbo ifnet patch went in. I eyeballed the : > changes and can see nothing wrong by visual inspection. : : I've looked to code over closely again and I'm supprised it works for : anyone. I found four instances of casts of sc to get ifp including one : if sc_xmit. I must have missed them when reconverting the driver after : your cleanup. :( I've commited a fix for them. I don't think I've actually tested it on real hardware since June 8th, so this isn't surprising... Warner From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 01:33:10 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 683D316A420; Thu, 16 Jun 2005 01:33:09 +0000 (GMT) (envelope-from julian@elischer.org) Received: from bigwoop.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4E9A643D1F; Thu, 16 Jun 2005 01:33:09 +0000 (GMT) (envelope-from julian@elischer.org) Received: from [208.206.78.97] (julian.vicor-nb.com [208.206.78.97]) by bigwoop.vicor-nb.com (Postfix) with ESMTP id 053477A403; Wed, 15 Jun 2005 18:33:09 -0700 (PDT) Message-ID: <42B0D6D5.8050801@elischer.org> Date: Wed, 15 Jun 2005 18:33:09 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.7) Gecko/20050423 X-Accept-Language: en, hu MIME-Version: 1.0 To: Olivier Nicole References: <58397.148.122.180.9.1118829978.squirrel@mail.yazzy.org> <200506160035.j5G0ZPZH022536@banyan.cs.ait.ac.th> In-Reply-To: <200506160035.j5G0ZPZH022536@banyan.cs.ait.ac.th> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-net@freebsd.org, lists@yazzy.org, current@freebsd.org Subject: Re: Looking for networking solution. 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, 16 Jun 2005 01:33:10 -0000 Olivier Nicole wrote: >>I am looking for solution I could implement on a link with a huge latency >>when ping replies can go up to a few hundred miliseconds, e.g sateliete >>links. >>Etc. >> >> > >One way we have been thinking was to use some NAT on both end of the >satellite connection and change the window size on the satellite link. >That way you can push more data on the link before the first ack is due. > >I do not see how you can do only local ack, if a packet is lost on the >"normal network" you have to have a way to inform the other end and do >retransmission. If you can do only local retransmission, then you are >talking about full satellite accelerator box :) > > I think that's what he wants.. I was considerring using TCP over TCP with the transmission boxes encapsulating a stream of other packets. But I got over it.. >Olivier >_______________________________________________ >freebsd-net@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-net >To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > > From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 01:50: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 44CED16A41C for ; Thu, 16 Jun 2005 01:50:51 +0000 (GMT) (envelope-from ups@tree.com) Received: from smtp.speedfactory.net (smtp.speedfactory.net [66.23.216.216]) by mx1.FreeBSD.org (Postfix) with ESMTP id F284543D48 for ; Thu, 16 Jun 2005 01:50:50 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 6792 invoked from network); 16 Jun 2005 01:50:58 +0000 Received: from 66-23-216-49.clients.speedfactory.net (HELO palm.tree.com) (66.23.216.49) by smtp.speedfactory.net with AES256-SHA encrypted SMTP; 16 Jun 2005 01:50:58 +0000 Received: from [127.0.0.1] (ups@localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j5G1okpP032230; Wed, 15 Jun 2005 21:50:47 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Mohan Srinivasan In-Reply-To: <20050616004132.34622.qmail@web80606.mail.yahoo.com> References: <20050616004132.34622.qmail@web80606.mail.yahoo.com> Content-Type: text/plain Message-Id: <1118886645.27369.128919.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Wed, 15 Jun 2005 21:50:46 -0400 Content-Transfer-Encoding: 7bit Cc: "current@freebsd.org" Subject: Re: Kernel lockmgr races LK_UPGRADE against LK_SHARED... 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, 16 Jun 2005 01:50:51 -0000 On Wed, 2005-06-15 at 20:41, Mohan Srinivasan wrote: > This is on 4.x, but I'm posting to current, it's likely also > an issue on current. Posting here hoping someone can shed > more info on this lockmgr race. > > I've into a bug where process 1 successfully LK_UPGRADEs a > vnode lock (from shared to excl) and process 2 successfully > acquires the shared lock on that same vnode. I am not sure > what order the locks were acquired, it's not possible to > infer that from the core. > > Does this bug ring a bell with anyone ? If it does, can they > shed any light/info they might have on this ? > > thanks > > mohan Reminds me of: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/69934 Stephan From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 03:20: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 915DB16A41C for ; Thu, 16 Jun 2005 03:20:12 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 53C6043D48 for ; Thu, 16 Jun 2005 03:20:12 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5G3II6f031579; Wed, 15 Jun 2005 21:18:20 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 15 Jun 2005 21:19:29 -0600 (MDT) Message-Id: <20050615.211929.103236830.imp@bsdimp.com> To: current@dino.sk From: "M. Warner Losh" In-Reply-To: <200506151140.56908.current@dino.sk> References: <20050615061009.GA11914@odin.ac.hmc.edu> <20050615.003020.99022728.imp@bsdimp.com> <200506151140.56908.current@dino.sk> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 03:20:12 -0000 In message: <200506151140.56908.current@dino.sk> Milan Obuch writes: : On Wednesday 15 June 2005 08:30, M. Warner Losh wrote: : ... : > : > ifconfig fxp0 1.2.3.4/24 : > : > will kill dhclient every time for me. : > : : Well, I would consider this a feature, not a bug, and a convenient one. It : happens on me from time to time that I have DHCP configured on one interface, : then after move to another place I issue 'ifconfig fxp0 ....' and some time : after network suddenly stops working due to dhclient running and deleting my : manually entered setting. : Where there also 'ifconfig fxp0 DHCP' for consistency... : I know this could be easily done with some scripting, but I could not : resist :) The problem that I have with it is that if I then unplug and plug the cable in (say press-ganging my laptop into service to test static IP addresses) causes dhclient to run again. I'm not sure that's a bug, but it is a behavior change from the old dhclient. It is doing what I told it to do, but much more enthusiastically. I'm not sure what to suggest to fix it, however... Warner From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 03:23: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 9B41316A41C; Thu, 16 Jun 2005 03:23:00 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 64A1F43D1D; Thu, 16 Jun 2005 03:23:00 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5G3MRId031633; Wed, 15 Jun 2005 21:22:28 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 15 Jun 2005 21:23:37 -0600 (MDT) Message-Id: <20050615.212337.108191340.imp@bsdimp.com> To: cswiger@mac.com From: "M. Warner Losh" In-Reply-To: <88862BDF-ED45-42CE-9B24-DEEED2E66C2C@mac.com> References: <20050615054209.L29741@beagle.kn.op.dlr.de> <20050615160741.GA55062@dragon.NUXI.org> <88862BDF-ED45-42CE-9B24-DEEED2E66C2C@mac.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: groff alternative? 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, 16 Jun 2005 03:23:00 -0000 In message: <88862BDF-ED45-42CE-9B24-DEEED2E66C2C@mac.com> Charles Swiger writes: : If the sole criterion is whether the CDDL permits one to redistribute : private modifications in binary form without source, you're right : that the CDDL is in the same boat as the GPL. Wearing my system integration hat, I can tell you that this is a PITA to comply with. One or two isn't so bad, but when you get dozens of these things here and there it becomes burdonsome to comply with and creates more work for each distribution that we do. There's also the whole 'does putting it in an embedded system count as distribution or not' question that remains unanswered, even in the CDDL. WRT the GPL, some say it does (Stallman) while other say it doesn't (Torvalds). Anyway, since we don't ship groff/roff/etc with the systems we create, this specific program doesn't matter much... Warner From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 03:25: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 3310C16A41C for ; Thu, 16 Jun 2005 03:25:50 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D656043D1D for ; Thu, 16 Jun 2005 03:25:49 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5G3NaE4031655; Wed, 15 Jun 2005 21:23:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 15 Jun 2005 21:24:46 -0600 (MDT) Message-Id: <20050615.212446.29494502.imp@bsdimp.com> To: jeremie@le-hen.org From: "M. Warner Losh" In-Reply-To: <20050615231823.GB2239@obiwan.tataz.chchile.org> References: <20050615231823.GB2239@obiwan.tataz.chchile.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: incorrect ping(8) interval with powerd(8) 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, 16 Jun 2005 03:25:50 -0000 In message: <20050615231823.GB2239@obiwan.tataz.chchile.org> Jeremie Le Hen writes: : Hi list, : : as the subjects state, when powerd(8) is running and has set a lower : frequency than the processor's natural one, interval between each : packets are too long. When my laptop is plugged, I told powerd(8) to : run the processor at maximum speed (-a max). : : Let's have a look at this : : %%% : jarjarbinks:root# sysctl hw.acpi.acline : hw.acpi.acline: 1 : jarjarbinks:root# sysctl dev.cpu.0.freq : dev.cpu.0.freq: 1735 : jarjarbinks:root# time ping -qc 2 192.168.1.1 : PING 192.168.1.1 (192.168.1.1): 56 data bytes : : --- 192.168.1.1 ping statistics --- : 2 packets transmitted, 2 packets received, 0% packet loss : round-trip min/avg/max/stddev = 0.266/0.269/0.271/0.002 ms : : real 0m1.003s : user 0m0.001s : sys 0m0.001s : : jarjarbinks:root# sysctl hw.acpi.acline : hw.acpi.acline: 0 : jarjarbinks:root# sysctl dev.cpu.0.freq : dev.cpu.0.freq: 216 : jarjarbinks:root# time ping -qc 2 192.168.1.1 : PING 192.168.1.1 (192.168.1.1): 56 data bytes : : --- 192.168.1.1 ping statistics --- : 2 packets transmitted, 2 packets received, 0% packet loss : round-trip min/avg/max/stddev = 0.637/0.814/0.991/0.177 ms : : real 0m2.252s : user 0m0.004s : sys 0m0.021s : %%% : : I check ping(8) source code and it appears it uses select(8) to wait : the desired amount of time. I don't think this is the intended : behaviour. Where does this bug (feature?) come from ? Those numbers look about right for a 200MHz CPU. Warner From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 03:30: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 4409216A423 for ; Thu, 16 Jun 2005 03:30:22 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id AD74143D58 for ; Thu, 16 Jun 2005 03:30:11 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5G3PnIl031661; Wed, 15 Jun 2005 21:25:49 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 15 Jun 2005 21:26:59 -0600 (MDT) Message-Id: <20050615.212659.86621150.imp@bsdimp.com> To: dmp@bitfreak.org From: "M. Warner Losh" In-Reply-To: <001501c5720b$aceb84d0$0b2a15ac@SMILEY> References: <20050615061009.GA11914@odin.ac.hmc.edu> <001501c5720b$aceb84d0$0b2a15ac@SMILEY> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: vova@fbsd.ru, freebsd-current@freebsd.org, matt@gsicomp.on.ca Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 03:30:22 -0000 In message: <001501c5720b$aceb84d0$0b2a15ac@SMILEY> "Darren Pilgrim" writes: : From: Brooks Davis : > There are two issues here. First, if we're going to keep : > network_interfaces around, /etc/rc.d/dhclient should honor : > it and not start dhclient on interfaces not in either : > network_interfaces or removable interfaces. : : I think network_interfaces should be gotten rid of entirely for two : reasons: : : 1: It creates a synchronization issue between it and the ifconfig_* : lines and duplicates functionality. IIRC, rc.conf being out of sync in : this way has tripped up users in the past. This can be good. I have ifconfig_fxp1 lines in my rc scripts for when I setup temprary networks as a reminder to what to use. I specifically set network_interfaces to exclude them from being run. : 2: There are real configurations in which some interfaces are not : available when netif is run at boot. One example is the many newer : mini-PCI wireless NICs that require a firmware upload. Devd is the : accepted tool for performing such tasks, but rcordering puts devd after : NETWORKING. The actions taken by devd must therefore include steps : taken by netif. Calling the rc.d scripts directly from devd avoids : local scripts that duplicate rc.d functionality. A similar situation : occurs for removable interfaces. This is really not an issue. If I insert my network card, I want it configured in the manner that it would have been configured on boot. devd and /etc/pccard_ether (poorly named, I know) already takes care of that situation... Warner From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 03:40:52 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 337AE16A41C for ; Thu, 16 Jun 2005 03:40:52 +0000 (GMT) (envelope-from smckay@internode.on.net) Received: from ash25e.internode.on.net (ash25e.internode.on.net [203.16.214.182]) by mx1.FreeBSD.org (Postfix) with ESMTP id B00FD43D49 for ; Thu, 16 Jun 2005 03:40:51 +0000 (GMT) (envelope-from smckay@internode.on.net) Received: from dungeon.home (ppp116-218.lns1.bne3.internode.on.net [59.167.116.218]) by ash25e.internode.on.net (8.12.9/8.12.6) with ESMTP id j5G3emSH080210; Thu, 16 Jun 2005 13:10:49 +0930 (CST) (envelope-from smckay@internode.on.net) Received: from dungeon.home (localhost [127.0.0.1]) by dungeon.home (8.13.1/8.11.6) with ESMTP id j5G3eNDJ007737; Thu, 16 Jun 2005 13:40:24 +1000 (EST) (envelope-from mckay) Message-Id: <200506160340.j5G3eNDJ007737@dungeon.home> To: Luigi Rizzo To: Stephen McKay , current@freebsd.org References: <20050615025447.A62971@xorpc.icir.org> In-Reply-To: <20050615025447.A62971@xorpc.icir.org> from Luigi Rizzo at "Wed, 15 Jun 2005 09:54:47 +0000" Date: Thu, 16 Jun 2005 13:40:23 +1000 From: Stephen McKay Cc: Subject: Re: bug or feature in userland thread library (O_NONBLOCK) 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, 16 Jun 2005 03:40:52 -0000 On Wednesday, 15th June 2005, Luigi Rizzo wrote: >I think our userland thread library (libc_r) has some bugs in >handling descriptors. I can reproduce the behaviour on -current >and 4.x, and I believe it applies to 5.x too. While you are fixing this one, can you also fix another one? :-) The O_NONBLOCK hack causes problems when used on file descriptors that refer to ttys. In particular, when you run a program linked with libc_r in the background without redirecting all of stdin, stdout and stderr, the tty is set to non-blocking (since O_NONBLOCK applies to file table entries, not individual file descriptors, and all such tty file descriptors are dup'd from the invoking shell). Many ordinary programs die when stdin, stdout or stderr become non-blocking outside their control. This includes, for example, "cat", "tail" and "nvi". I have "solved" this problem on my system by making it impossible for programs to set their controlling terminal to non-blocking when they are in the background. I haven't gotten around to sending my proposed changes to -arch for review (ENOTIME), but I can't think of any valid reason why a process should expect to be able to set O_NONBLOCK on its tty when it is not in the foreground. A solution that may be more pleasing to others is to make libc_r not set O_NONBLOCK on ttys when it's in the background. If you are already finding weird special cases for descriptors 0, 1 and 2, perhaps you can see where this additional change would fit in. Then again, there is talk of just deleting libc_r. In my view, this could happen today. Stephen. From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 04:11:23 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 81F3A16A41C for ; Thu, 16 Jun 2005 04:11:23 +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 E573843D1D for ; Thu, 16 Jun 2005 04:11:20 +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 j5G4BCP6058852; Thu, 16 Jun 2005 08:11:16 +0400 (MSD) (envelope-from maxim@macomnet.ru) Date: Thu, 16 Jun 2005 08:11:12 +0400 (MSD) From: Maxim Konovalov To: Brooks Davis In-Reply-To: <20050615202355.GA12986@odin.ac.hmc.edu> Message-ID: <20050616081029.S58702@mp2.macomnet.net> References: <20050614231344.F76340@mp2.macomnet.net> <20050615.002712.123500387.imp@bsdimp.com> <20050615230844.G61956@mp2.macomnet.net> <20050615.135552.74722719.imp@bsdimp.com> <20050615202355.GA12986@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: current@FreeBSD.ORG, Warner Losh Subject: Re: ed(4) broken? 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, 16 Jun 2005 04:11:23 -0000 [...] > I've looked to code over closely again and I'm supprised it works for > anyone. I found four instances of casts of sc to get ifp including one > if sc_xmit. I must have missed them when reconverting the driver after > your cleanup. :( I've commited a fix for them. Great, it works now. Thanks! -- Maxim Konovalov From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 05:01: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 A727B16A41C; Thu, 16 Jun 2005 05:01:00 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3DCC443D53; Thu, 16 Jun 2005 05:01:00 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 3D3BD5CEA; Thu, 16 Jun 2005 01:00:59 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61419-08; Thu, 16 Jun 2005 01:00:58 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-69-6.ny325.east.verizon.net [68.161.69.6]) by pi.codefab.com (Postfix) with ESMTP id A6F075CB2; Thu, 16 Jun 2005 01:00:57 -0400 (EDT) Message-ID: <42B10804.2010308@mac.com> Date: Thu, 16 Jun 2005 01:03:00 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20050615054209.L29741@beagle.kn.op.dlr.de> <20050615160741.GA55062@dragon.NUXI.org> <88862BDF-ED45-42CE-9B24-DEEED2E66C2C@mac.com> <20050615.212337.108191340.imp@bsdimp.com> In-Reply-To: <20050615.212337.108191340.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-current@freebsd.org Subject: Re: groff alternative? 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, 16 Jun 2005 05:01:00 -0000 M. Warner Losh wrote: > In message: <88862BDF-ED45-42CE-9B24-DEEED2E66C2C@mac.com> > Charles Swiger writes: >: If the sole criterion is whether the CDDL permits one to redistribute >: private modifications in binary form without source, you're right >: that the CDDL is in the same boat as the GPL. > > Wearing my system integration hat, I can tell you that this is a PITA > to comply with. One or two isn't so bad, but when you get dozens of > these things here and there it becomes burdonsome to comply with and > creates more work for each distribution that we do. Perhaps there won't be a rush of code adoption from OpenSolaris into FreeBSD, but it would be a surprise and a pity if there was nothing to be learned. I'd imagine that the Solaris NFS code would be worth looking at, for instance. Lots of license flavors are handled OK via src/contrib and throughout the entire ports collection now. It's not as if CDDL-licensed code is going to sneak up and infect existing BSD-licensed code; the two licenses are miscible. > There's also the whole 'does putting it in an embedded system count as > distribution or not' question that remains unanswered, even in the CDDL. > WRT the GPL, some say it does (Stallman) while other say it doesn't (Torvalds). Ah, whether the (re)distribution is a derivative work, or whether it is a mere compilation or aggregation. Yes. There's case law for art works and book anthologies, but not anything I know about for software. Well, there's no shortage of wacky opinions about people running proprietary code on top of GPLed systems. For example, Eben Moglen and Bruce Perens would like to sue ATI and nVidia for releasing proprietary drivers for Linux. [1] Fortunately, the only opinions which really count about these things come from the judges. I'd rather deal with code than with a lawyer, any day of the week... :-) > Anyway, since we don't ship groff/roff/etc with the systems we create, > this specific program doesn't matter much... 4-sec% /usr/bin/nroff --version GNU nroff (groff) version 1.19 5-sec% uname -a FreeBSD sec.pkix.net 4.11-STABLE FreeBSD 4.11-STABLE #0: Sat Jun 11 00:25:38 EDT 2005 root@sec.pkix.net:/usr/obj/usr/src/sys/NORMAL i386 This seems to be from src/contrib/groff? -- -Chuck [1]: Message-ID: <425881DE.1050501@perens.com>. From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 05:40: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 033D116A422 for ; Thu, 16 Jun 2005 05:40:31 +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 DC06843E73 for ; Thu, 16 Jun 2005 05:31:44 +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.13.4/8.13.4) with ESMTP id j5G5UwbB062144; Thu, 16 Jun 2005 15:00:59 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Thu, 16 Jun 2005 15:00:57 +0930 User-Agent: KMail/1.8 References: <20050615061009.GA11914@odin.ac.hmc.edu> <001501c5720b$aceb84d0$0b2a15ac@SMILEY> <20050615.212659.86621150.imp@bsdimp.com> In-Reply-To: <20050615.212659.86621150.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2950762.TuzF4OnsSm"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506161500.58150.doconnor@gsoft.com.au> X-Spam-Score: -2.4 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: vova@fbsd.ru, dmp@bitfreak.org, "M. Warner Losh" , matt@gsicomp.on.ca Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 05:40:32 -0000 --nextPart2950762.TuzF4OnsSm Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 16 Jun 2005 12:56, M. Warner Losh wrote: > : 1: It creates a synchronization issue between it and the ifconfig_* > : lines and duplicates functionality. IIRC, rc.conf being out of sync in > : this way has tripped up users in the past. > > This can be good. I have ifconfig_fxp1 lines in my rc scripts for > when I setup temprary networks as a reminder to what to use. I > specifically set network_interfaces to exclude them from being run. Surely you could just comment them out.. =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 --nextPart2950762.TuzF4OnsSm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD0DBQBCsQ6S5ZPcIHs/zowRAkohAJwIiU4UpOGse8t+MIAMlVzbsdgmjQCPdP9R jcDLlqBmmPnKA8QJf3Th =A2f4 -----END PGP SIGNATURE----- --nextPart2950762.TuzF4OnsSm-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 05:48: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 F0AA516A41C for ; Thu, 16 Jun 2005 05:48:14 +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 BD00B43D53 for ; Thu, 16 Jun 2005 05:48:14 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.94] ([66.127.85.94]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j5G5mDms011302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2005 22:48:13 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42B112AF.8050708@errno.com> Date: Wed, 15 Jun 2005 22:48:31 -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: Rong-En Fan References: <42313286.2060206@errno.com> <423212CC.90800@centtech.com> <6eb82e050615061535bcc722@mail.gmail.com> In-Reply-To: <6eb82e050615061535bcc722@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: FreeBSD Current Subject: Re: [Fwd: cvs commit: src/sys/modules Makefile src/sys/conf files src/sys/modules/ath_rate_sample Makefile src/sys/i386/conf NOTES] 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, 16 Jun 2005 05:48:15 -0000 Rong-En Fan wrote: > On 3/12/05, Eric Anderson wrote: > >>Sam Leffler wrote: >> >>>If you''re an ath user on current it'd be great to get John some >>>feedback on his rate control algorithm as it might be made the default. >>> I've not tested it with 5210 or 5211 cards and it's likely to have some >>>issues with them so beware. To use it be sure you have up to date code >>>and then specify >>> >>>device ath_rate_sample >>> >>>instead of the normal ath_rate_onoe. >> >> >>So far, I see no additional performance, in fact, upload speeds are about 15-20% less compared to the onoe stuff. It's stable and seems to work ok for me however. > > > I have an 5212 card on IBM X31. Setting at the same location, the windows > Atheros driver works very well. However, using FreeBSD the network sometimes > hang and saw some 'ath0 device timeout' at console. But, when I switched to > ath_sample (orig is onoe) it works very well. Althought I didn't > check the speed, > the ssh connection does not hang any more. BTW, ifconfig ath0 list ap shows > that S:N is about 8:0 to 13:0. My current is Jun 15. The sample rate control algorithm is much more responsive than the onoe algorithm. Can't comment on the timeouts w/o more info. Comparing the Atheros ndis driver isn't entirely fair as it will automatically switch between normal operation and XR mode at those signal levels. Sam From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 05:56: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 D302A16A41C for ; Thu, 16 Jun 2005 05:56:01 +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 8C0F743D1D for ; Thu, 16 Jun 2005 05:56:01 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.94] ([66.127.85.94]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j5G5tbms011329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Jun 2005 22:55:38 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42B1146C.6070508@errno.com> Date: Wed, 15 Jun 2005 22:55:56 -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: "M. Warner Losh" References: <20050614205537.D62878@gabby.gsicomp.on.ca> <1118806968.1003.9.camel@localhost> <20050615061009.GA11914@odin.ac.hmc.edu> <20050615.003020.99022728.imp@bsdimp.com> In-Reply-To: <20050615.003020.99022728.imp@bsdimp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: vova@fbsd.ru, freebsd-current@freebsd.org, matt@gsicomp.on.ca Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 05:56:02 -0000 M. Warner Losh wrote: > In message: <20050615061009.GA11914@odin.ac.hmc.edu> > Brooks Davis writes: > : On Wed, Jun 15, 2005 at 07:42:48AM +0400, Vladimir Grebenschikov wrote: > : > ? ??, 14/06/2005 ? 20:57 -0400, Matthew Emmerton ?????: > : > > On Tue, 14 Jun 2005, Brooks Davis wrote: > : > > > : > > > On Tue, Jun 14, 2005 at 10:01:45AM +0400, Vladimir Grebenschikov wrote: > : > > >> ? ??, 06/06/2005 ? 20:46 -0700, Brooks Davis ?????: > : > > >>> I'm about to start importing the OpenBSD dhclient and required > : > > >>> support in /etc. I will unhook dhclient from the build while I work so > : > > >>> there shouldn't be much breakage for most people > : > > >> > : > > >> I have strange behavior of new dhclient + devd: > : > > >> > : > > >> just after boot (with ethernet plugged) I have no devd events about > : > > >> state of media and have interface down, but after first ifconfig (even > : > > >> without parameters, even executed by any user) "link state chages to UP" > : > > >> event appears and devd starts dhclient on interface. > : > > >> > : > > >> I do not think that it is desired behavior. > : > > >> > : > > >> my rc.conf, related to this: > : > > >> > : > > >> ifconfig_fxp0="dhcp" > : > > >> network_interfaces="lo0" > : > > >> devd_enable="YES" > : > > >> > : > > >> Probably I need to comment network_interfaces line, but anyway, now it > : > > >> works strange. > : > > > : > > Shouldn't you have network_interfaces="lo0 fxp0" in order for the rc > : > > scripts to run the appropriate ifconfig or dhclient command for each > : > > interface? > : > > : > Probably yes (it works), but why first /sbin/ifconfig, issued by uid!=0 > : > triggers dhclient ? > : > > : > I think behavior should be consistent, either rc.d/netif relay only on > : > devd events and does not depends on network_interfaces= or rc.d/netif > : > should relay on network_interfaces= and ignore not mentioned interfaces. > : > > : > Also devd's IFUP event should not depend on user's /bin/ifconfig issued > : > (or not issued) by hands. > : > : There are two issues here. First, if we're going to keep > : network_interfaces around, /etc/rc.d/dhclient should honor it and > : not start dhclient on interfaces not in either network_interfaces or > : removable interfaces. Second, running ifconfig should not be triggering > : link events. That makes no sense. I'll have to see if can replicate > : that, I'm a bit dubious. > > ifconfig fxp0 1.2.3.4/24 > > will kill dhclient every time for me. There are several drivers that have issues with reliably generating LINK state up/down events. The bge driver does not work right for me with a 5704 (I think) part--the gige part in my Dell 600m. I tried discussing this this with wpaul but he's out of touch these days. > > I've also been seeing weirdness with the new dhclient when i move from > network to network on boot when I have the 'old' lease around but no > cable connected. I'll see if I can replicate this enough to submit a > report. I've noticed one issue. If you mark an interface down then dhclient exits but any assigned ip address is not removed. This is a change from the previous dhclient and something I thought I'd fixed (but clearly not). OTOH brooks pointed out that leaving the ip address around means tcp sessions don't immediately die so if you reconnect and reacquire the same lease your sessions can be revived if they were idle. Sam From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 06:02: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 3DDC116A41C for ; Thu, 16 Jun 2005 06:02:30 +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 158F043D1F for ; Thu, 16 Jun 2005 06:02:30 +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 2CECB19F3B; Wed, 15 Jun 2005 23:03:59 -0700 (PDT) From: "Darren Pilgrim" To: "'M. Warner Losh'" Date: Wed, 15 Jun 2005 23:02:28 -0700 Message-ID: <000e01c57238$fa215270$0b2a15ac@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 In-Reply-To: <20050615.212659.86621150.imp@bsdimp.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal Cc: freebsd-current@freebsd.org Subject: RE: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 06:02:30 -0000 From: M. Warner Losh [mailto:imp@bsdimp.com] > In message: <001501c5720b$aceb84d0$0b2a15ac@SMILEY> > "Darren Pilgrim" writes: > : 2: There are real configurations in which some interfaces are not > : available when netif is run at boot. One example is the many newer > : mini-PCI wireless NICs that require a firmware upload. Devd is the > : accepted tool for performing such tasks, but rcordering puts devd > : after NETWORKING. The actions taken by devd must therefore include > : steps taken by netif. Calling the rc.d scripts directly from devd > : avoids local scripts that duplicate rc.d functionality. A similar > : situation occurs for removable interfaces. > > This is really not an issue. If I insert my network card, I want it > configured in the manner that it would have been configured on boot. > devd and /etc/pccard_ether (poorly named, I know) already takes care > of that situation... *takes crash course in network.subr, pccard_ether and netif* Yeah, ok. Shame on me for not keeping up on the reading. :) From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 06:39: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 580B416A41C for ; Thu, 16 Jun 2005 06:39:31 +0000 (GMT) (envelope-from snort_sam@yahoo.com) Received: from web54409.mail.yahoo.com (web54409.mail.yahoo.com [68.142.225.165]) by mx1.FreeBSD.org (Postfix) with SMTP id 0A5C043D1F for ; Thu, 16 Jun 2005 06:39:30 +0000 (GMT) (envelope-from snort_sam@yahoo.com) Received: (qmail 77680 invoked by uid 60001); 16 Jun 2005 06:39:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GvaYXr7RyDV2WAKjdOHGuambD/wnhY+88S/xxbylOSJIu+eYPYPO1KXuCgoetzE0pik+F7hTWDwDmhIfqkQ636gqG/3rGdKj/mtui9BcgWvhorlyS0mF5PXRnMo9MvuNYofuAfa/wkkzS/daJxxZZGUIU687505Dyc3VC2DbMas= ; Message-ID: <20050616063930.77678.qmail@web54409.mail.yahoo.com> Received: from [139.168.37.39] by web54409.mail.yahoo.com via HTTP; Wed, 15 Jun 2005 23:39:30 PDT Date: Wed, 15 Jun 2005 23:39:30 -0700 (PDT) From: snort Snort To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: usb disc device is not present in 5.4-p1 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, 16 Jun 2005 06:39:31 -0000 Hi, After upgraded to 5.4-p1 from 5.3 stable, the insertion of the usb disc is no longer able to activate the creation of the usb device. In my case, when the usb disc inserted in the usb port, the kernel system assigned /dev/da0s? to the usb disc when it was in 5.3, but now this is not happened any more, and there is error being logged to the /var/log/messages file as shown below: Jun 16 16:28:22 laptop kernel: umass0: vendor 0x1043 product 0x8006, rev 1.10/1.00, addr 3 Jun 16 16:28:23 laptop kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Jun 16 16:28:23 laptop kernel: da0: Removable Direct Access SCSI-2 device Jun 16 16:28:23 laptop kernel: da0: 1.000MB/s transfers Jun 16 16:28:23 laptop kernel: da0: Attempt to query device size failed: NOT READY, Medium not present Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): SCSI Status: Check Condition Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): Medium not present Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): Unretryable error Jun 16 16:28:23 laptop kernel: Opened disk da0 -> 6 Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): SCSI Status: Check Condition Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): Medium not present Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): Unretryable error Jun 16 16:28:23 laptop kernel: Opened disk da0 -> 6 Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): READ CAPACITY. CDB: 25 0 0 0 0 0 0 0 0 0 Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): CAM Status: SCSI Status Error Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): SCSI Status: Check Condition Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): NOT READY asc:3a,0 Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): Medium not present Jun 16 16:28:23 laptop kernel: (da0:umass-sim0:0:0:0): Unretryable error Jun 16 16:28:23 laptop kernel: Opened disk da0 -> 6 ls shown that there is only one device exist: # ls -l /dev/da0* crw-r----- 1 root operator 4, 23 Jun 16 14:35 /dev/da0 Mount command failed with the following message: # mount_msdosfs /dev/da0 /mnt mount_msdosfs: /dev/da0: Device not configured How can I fix this error? Thanks Sam __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 07: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 3AB0316A41C for ; Thu, 16 Jun 2005 07:02:10 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0306D43D48 for ; Thu, 16 Jun 2005 07:02:09 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5G701RQ033845; Thu, 16 Jun 2005 01:00:06 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 16 Jun 2005 01:01:12 -0600 (MDT) Message-Id: <20050616.010112.69931740.imp@bsdimp.com> To: doconnor@gsoft.com.au From: "M. Warner Losh" In-Reply-To: <200506161500.58150.doconnor@gsoft.com.au> References: <001501c5720b$aceb84d0$0b2a15ac@SMILEY> <20050615.212659.86621150.imp@bsdimp.com> <200506161500.58150.doconnor@gsoft.com.au> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: vova@fbsd.ru, freebsd-current@FreeBSD.org, matt@gsicomp.on.ca, dmp@bitfreak.org Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 07:02:10 -0000 In message: <200506161500.58150.doconnor@gsoft.com.au> "Daniel O'Connor" writes: : On Thu, 16 Jun 2005 12:56, M. Warner Losh wrote: : > : 1: It creates a synchronization issue between it and the ifconfig_* : > : lines and duplicates functionality. IIRC, rc.conf being out of sync in : > : this way has tripped up users in the past. : > : > This can be good. I have ifconfig_fxp1 lines in my rc scripts for : > when I setup temprary networks as a reminder to what to use. I : > specifically set network_interfaces to exclude them from being run. : : Surely you could just comment them out.. I could. But I'm lazy. :-) Warner From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 07:04: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 507D116A41C for ; Thu, 16 Jun 2005 07:04:32 +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 127E643D49 for ; Thu, 16 Jun 2005 07:04:31 +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 4417B173496; Thu, 16 Jun 2005 09:04:30 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id DC227407E; Thu, 16 Jun 2005 09:04:45 +0200 (CEST) Date: Thu, 16 Jun 2005 09:04:45 +0200 From: Jeremie Le Hen To: "M. Warner Losh" Message-ID: <20050616070445.GD2239@obiwan.tataz.chchile.org> References: <20050615231823.GB2239@obiwan.tataz.chchile.org> <20050615.212446.29494502.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050615.212446.29494502.imp@bsdimp.com> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, jeremie@le-hen.org Subject: Re: incorrect ping(8) interval with powerd(8) 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, 16 Jun 2005 07:04:32 -0000 Hi Warner, > : %%% > : jarjarbinks:root# sysctl hw.acpi.acline > : hw.acpi.acline: 1 > : jarjarbinks:root# sysctl dev.cpu.0.freq > : dev.cpu.0.freq: 1735 > : jarjarbinks:root# time ping -qc 2 192.168.1.1 > : PING 192.168.1.1 (192.168.1.1): 56 data bytes > : > : --- 192.168.1.1 ping statistics --- > : 2 packets transmitted, 2 packets received, 0% packet loss > : round-trip min/avg/max/stddev = 0.266/0.269/0.271/0.002 ms > : > : real 0m1.003s > : user 0m0.001s > : sys 0m0.001s > : > : jarjarbinks:root# sysctl hw.acpi.acline > : hw.acpi.acline: 0 > : jarjarbinks:root# sysctl dev.cpu.0.freq > : dev.cpu.0.freq: 216 > : jarjarbinks:root# time ping -qc 2 192.168.1.1 > : PING 192.168.1.1 (192.168.1.1): 56 data bytes > : > : --- 192.168.1.1 ping statistics --- > : 2 packets transmitted, 2 packets received, 0% packet loss > : round-trip min/avg/max/stddev = 0.637/0.814/0.991/0.177 ms > : > : real 0m2.252s > : user 0m0.004s > : sys 0m0.021s > : %%% > : > : I check ping(8) source code and it appears it uses select(8) to wait > : the desired amount of time. I don't think this is the intended > : behaviour. Where does this bug (feature?) come from ? > > Those numbers look about right for a 200MHz CPU. May you delve into this a little bit more please ? The ping(8) manual page states that the -i flags makes ping(8) to wait a given couple of seconds. If I use the flags "-i 1", I expect ECHO Requests to be sent with one second between each, whatever the AC line status is. (Note that I didn't explicitely specified "-i 1" in the above example, but this doesn't change the behaviour.) Thank you. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 07:22: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 2465316A41C for ; Thu, 16 Jun 2005 07:22:56 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id C16F843D1F for ; Thu, 16 Jun 2005 07:22:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5G7LqDQ033980; Thu, 16 Jun 2005 01:21:52 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 16 Jun 2005 01:23:02 -0600 (MDT) Message-Id: <20050616.012302.48201645.imp@bsdimp.com> To: jeremie@le-hen.org From: "M. Warner Losh" In-Reply-To: <20050616070445.GD2239@obiwan.tataz.chchile.org> References: <20050615231823.GB2239@obiwan.tataz.chchile.org> <20050615.212446.29494502.imp@bsdimp.com> <20050616070445.GD2239@obiwan.tataz.chchile.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: incorrect ping(8) interval with powerd(8) 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, 16 Jun 2005 07:22:56 -0000 In message: <20050616070445.GD2239@obiwan.tataz.chchile.org> Jeremie Le Hen writes: : Hi Warner, : : > : %%% : > : jarjarbinks:root# sysctl hw.acpi.acline : > : hw.acpi.acline: 1 : > : jarjarbinks:root# sysctl dev.cpu.0.freq : > : dev.cpu.0.freq: 1735 : > : jarjarbinks:root# time ping -qc 2 192.168.1.1 : > : PING 192.168.1.1 (192.168.1.1): 56 data bytes : > : : > : --- 192.168.1.1 ping statistics --- : > : 2 packets transmitted, 2 packets received, 0% packet loss : > : round-trip min/avg/max/stddev = 0.266/0.269/0.271/0.002 ms : > : : > : real 0m1.003s : > : user 0m0.001s : > : sys 0m0.001s : > : : > : jarjarbinks:root# sysctl hw.acpi.acline : > : hw.acpi.acline: 0 : > : jarjarbinks:root# sysctl dev.cpu.0.freq : > : dev.cpu.0.freq: 216 : > : jarjarbinks:root# time ping -qc 2 192.168.1.1 : > : PING 192.168.1.1 (192.168.1.1): 56 data bytes : > : : > : --- 192.168.1.1 ping statistics --- : > : 2 packets transmitted, 2 packets received, 0% packet loss : > : round-trip min/avg/max/stddev = 0.637/0.814/0.991/0.177 ms : > : : > : real 0m2.252s : > : user 0m0.004s : > : sys 0m0.021s : > : %%% : > : : > : I check ping(8) source code and it appears it uses select(8) to wait : > : the desired amount of time. I don't think this is the intended : > : behaviour. Where does this bug (feature?) come from ? : > : > Those numbers look about right for a 200MHz CPU. : : May you delve into this a little bit more please ? The ping(8) manual : page states that the -i flags makes ping(8) to wait a given couple of : seconds. If I use the flags "-i 1", I expect ECHO Requests to be sent : with one second between each, whatever the AC line status is. : (Note that I didn't explicitely specified "-i 1" in the above example, : but this doesn't change the behaviour.) Well, the rount trip times went way up (3x longer). That's normal for a 200MHz CPU... My 333MHz EISA machine can't do much better than that. But the 2.252s run time is a little longish. Do you see this consistantly? If you ran it a second time would you get identical results. I've seen ARP take a while... What else do you have running on the system? Maybe a daemon that takes almost no time at 1.7GHz takes a lot longer at 200Mhz and that's starving the ping process... Or some driver has gone insane... Warner From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 07:34: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 6DFB416A41C for ; Thu, 16 Jun 2005 07:34:33 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 20EF343D48 for ; Thu, 16 Jun 2005 07:34:32 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=h311r4z3r) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1Diot7-0000F3-1g for freebsd-current@freebsd.org; Thu, 16 Jun 2005 09:34:12 +0200 Date: Thu, 16 Jun 2005 09:34:29 +0200 From: Marcin Jessa To: freebsd-current@freebsd.org Message-Id: <20050616093429.5da97cc1.lists@yazzy.org> In-Reply-To: <42B1146C.6070508@errno.com> References: <20050614205537.D62878@gabby.gsicomp.on.ca> <1118806968.1003.9.camel@localhost> <20050615061009.GA11914@odin.ac.hmc.edu> <20050615.003020.99022728.imp@bsdimp.com> <42B1146C.6070508@errno.com> Organization: YazzY.org X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 07:34:33 -0000 On Wed, 15 Jun 2005 22:55:56 -0700 Sam Leffler wrote: > M. Warner Losh wrote: > > In message: <20050615061009.GA11914@odin.ac.hmc.edu> > > Brooks Davis writes: > > : On Wed, Jun 15, 2005 at 07:42:48AM +0400, Vladimir Grebenschikov wrote: > > : > ? ??, 14/06/2005 ? 20:57 -0400, Matthew Emmerton ?????: > > : > > On Tue, 14 Jun 2005, Brooks Davis wrote: > > : > > > > : > > > On Tue, Jun 14, 2005 at 10:01:45AM +0400, Vladimir Grebenschikov wrote: > > : > > >> ? ??, 06/06/2005 ? 20:46 -0700, Brooks Davis ?????: > > : > > >>> I'm about to start importing the OpenBSD dhclient and required > > : > > >>> support in /etc. I will unhook dhclient from the build while I work so > > : > > >>> there shouldn't be much breakage for most people > > : > > >> > > : > > >> I have strange behavior of new dhclient + devd: > > : > > >> > > : > > >> just after boot (with ethernet plugged) I have no devd events about > > : > > >> state of media and have interface down, but after first ifconfig (even > > : > > >> without parameters, even executed by any user) "link state chages to UP" > > : > > >> event appears and devd starts dhclient on interface. > > : > > >> > > : > > >> I do not think that it is desired behavior. > > : > > >> > > : > > >> my rc.conf, related to this: > > : > > >> > > : > > >> ifconfig_fxp0="dhcp" > > : > > >> network_interfaces="lo0" > > : > > >> devd_enable="YES" > > : > > >> > > : > > >> Probably I need to comment network_interfaces line, but anyway, now it > > : > > >> works strange. > > : > > > > : > > Shouldn't you have network_interfaces="lo0 fxp0" in order for the rc > > : > > scripts to run the appropriate ifconfig or dhclient command for each > > : > > interface? > > : > > > : > Probably yes (it works), but why first /sbin/ifconfig, issued by uid!=0 > > : > triggers dhclient ? > > : > > > : > I think behavior should be consistent, either rc.d/netif relay only on > > : > devd events and does not depends on network_interfaces= or rc.d/netif > > : > should relay on network_interfaces= and ignore not mentioned interfaces. > > : > > > : > Also devd's IFUP event should not depend on user's /bin/ifconfig issued > > : > (or not issued) by hands. > > : > > : There are two issues here. First, if we're going to keep > > : network_interfaces around, /etc/rc.d/dhclient should honor it and > > : not start dhclient on interfaces not in either network_interfaces or > > : removable interfaces. Second, running ifconfig should not be triggering > > : link events. That makes no sense. I'll have to see if can replicate > > : that, I'm a bit dubious. > > > > ifconfig fxp0 1.2.3.4/24 > > > > will kill dhclient every time for me. > > There are several drivers that have issues with reliably generating LINK > state up/down events. The bge driver does not work right for me with a > 5704 (I think) part--the gige part in my Dell 600m. I tried discussing > this this with wpaul but he's out of touch these days. > > > > > I've also been seeing weirdness with the new dhclient when i move from > > network to network on boot when I have the 'old' lease around but no > > cable connected. I'll see if I can replicate this enough to submit a > > report. > > I've noticed one issue. If you mark an interface down then dhclient > exits but any assigned ip address is not removed. This is a change from > the previous dhclient and something I thought I'd fixed (but clearly > not). OTOH brooks pointed out that leaving the ip address around means > tcp sessions don't immediately die so if you reconnect and reacquire the > same lease your sessions can be revived if they were idle. > > Sam > One small thing. Pressing CTR+C during boot to stop dhclient not only stops it but prevents system from assigning any other IP's, loopback included. From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 07:57: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 0517216A41C for ; Thu, 16 Jun 2005 07:57:31 +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 BA34B43D49 for ; Thu, 16 Jun 2005 07:57:30 +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 2738FC074; Thu, 16 Jun 2005 09:57:29 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 498FC407E; Thu, 16 Jun 2005 09:57:43 +0200 (CEST) Date: Thu, 16 Jun 2005 09:57:43 +0200 From: Jeremie Le Hen To: "M. Warner Losh" Message-ID: <20050616075743.GE2239@obiwan.tataz.chchile.org> References: <20050615231823.GB2239@obiwan.tataz.chchile.org> <20050615.212446.29494502.imp@bsdimp.com> <20050616070445.GD2239@obiwan.tataz.chchile.org> <20050616.012302.48201645.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050616.012302.48201645.imp@bsdimp.com> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, jeremie@le-hen.org Subject: Re: incorrect ping(8) interval with powerd(8) 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, 16 Jun 2005 07:57:31 -0000 > : May you delve into this a little bit more please ? The ping(8) manual > : page states that the -i flags makes ping(8) to wait a given couple of > : seconds. If I use the flags "-i 1", I expect ECHO Requests to be sent > : with one second between each, whatever the AC line status is. > : (Note that I didn't explicitely specified "-i 1" in the above example, > : but this doesn't change the behaviour.) > > Well, the rount trip times went way up (3x longer). That's normal for > a 200MHz CPU... My 333MHz EISA machine can't do much better than > that. > > But the 2.252s run time is a little longish. Do you see this > consistantly? If you ran it a second time would you get identical > results. I've seen ARP take a while... What else do you have running > on the system? Maybe a daemon that takes almost no time at 1.7GHz > takes a lot longer at 200Mhz and that's starving the ping process... > Or some driver has gone insane... Yes, I ran this test multiple times, and I almost get always this same result although I got 2.208s sometimes, but I don't think this is significant. FYI, my powerd(8) is configured to tastes AC-line four times per seconds. I tried reducing it's freqency from 4 to 1, but it doesn't change anything. ARP is not the culprit, the MAC address is already in cache. My kernel is compiled with INVARIANTS, but I don't have WITNESS. My network interface uses the bge(4) driver. No firewall rule or complex network setup. Anyway this doesn't hurt much. Thanks for lightening me. Best regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 08:01: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 9687C16A41C for ; Thu, 16 Jun 2005 08:01:11 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4FC1443D58 for ; Thu, 16 Jun 2005 08:01:11 +0000 (GMT) (envelope-from daniel_k_eriksson@telia.com) Received: from royal64.emp.zapto.org (195.198.193.104) by pne-smtpout2-sn2.hy.skanova.net (7.2.059.6) id 429C53B600383D47 for freebsd-current@freebsd.org; Thu, 16 Jun 2005 10:01:10 +0200 Date: Thu, 16 Jun 2005 10:01:09 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <4F9C9299A10AE74E89EA580D14AA10A6028579@royal64.emp.zapto.org> Content-Transfer-Encoding: quoted-printable X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-class: urn:content-classes:message Thread-Topic: IPI_PREEMPTION, something to test for normal users? X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Thread-Index: AcVySY5CQ3g84cBhT/WRO5ZdCuxxDw== From: "Daniel Eriksson" To: Subject: IPI_PREEMPTION, something to test for normal 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: Thu, 16 Jun 2005 08:01:11 -0000 On a regular SMP server running 6-CURRENT, is IPI_PREEMPTION something to try? I've looked around for an explanation of what it does and what possible pitfalls there are, but I haven't really found anything. It's only in NOTES at the moment, indicating that it isn't for general consumption yet(?). /Daniel Eriksson From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 08: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 1A0E016A41C for ; Thu, 16 Jun 2005 08:04:56 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D0B6E43D48 for ; Thu, 16 Jun 2005 08:04:55 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5G83WVI034267; Thu, 16 Jun 2005 02:03:32 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 16 Jun 2005 02:04:42 -0600 (MDT) Message-Id: <20050616.020442.31252848.imp@bsdimp.com> To: jeremie@le-hen.org From: "M. Warner Losh" In-Reply-To: <20050616075743.GE2239@obiwan.tataz.chchile.org> References: <20050616070445.GD2239@obiwan.tataz.chchile.org> <20050616.012302.48201645.imp@bsdimp.com> <20050616075743.GE2239@obiwan.tataz.chchile.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: incorrect ping(8) interval with powerd(8) 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, 16 Jun 2005 08:04:56 -0000 In message: <20050616075743.GE2239@obiwan.tataz.chchile.org> Jeremie Le Hen writes: : > : May you delve into this a little bit more please ? The ping(8) manual : > : page states that the -i flags makes ping(8) to wait a given couple of : > : seconds. If I use the flags "-i 1", I expect ECHO Requests to be sent : > : with one second between each, whatever the AC line status is. : > : (Note that I didn't explicitely specified "-i 1" in the above example, : > : but this doesn't change the behaviour.) : > : > Well, the rount trip times went way up (3x longer). That's normal for : > a 200MHz CPU... My 333MHz EISA machine can't do much better than : > that. : > : > But the 2.252s run time is a little longish. Do you see this : > consistantly? If you ran it a second time would you get identical : > results. I've seen ARP take a while... What else do you have running : > on the system? Maybe a daemon that takes almost no time at 1.7GHz : > takes a lot longer at 200Mhz and that's starving the ping process... : > Or some driver has gone insane... : : Yes, I ran this test multiple times, and I almost get always this same : result although I got 2.208s sometimes, but I don't think this is : significant. : : FYI, : my powerd(8) is configured to tastes AC-line four times per seconds. : I tried reducing it's freqency from 4 to 1, but it doesn't change : anything. : : ARP is not the culprit, the MAC address is already in cache. : : My kernel is compiled with INVARIANTS, but I don't have WITNESS. My : network interface uses the bge(4) driver. No firewall rule or complex : network setup. : : Anyway this doesn't hurt much. Thanks for lightening me. Dang, I was hoping it was one of the easy explainations.... Maybe it is the idle code not waking up fast enough when it has been asleep for a bit. But that's pure speculation at this point... Warner From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 08:09: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 38AE516A41C for ; Thu, 16 Jun 2005 08:09:45 +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 EFABD43D1D for ; Thu, 16 Jun 2005 08:09:44 +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 5C82B3201C8; Thu, 16 Jun 2005 10:09:44 +0200 (CEST) Received: by tatooine.tataz.chchile.org (Postfix, from userid 1000) id 6EDA3407E; Thu, 16 Jun 2005 10:09:59 +0200 (CEST) Date: Thu, 16 Jun 2005 10:09:59 +0200 From: Jeremie Le Hen To: "M. Warner Losh" Message-ID: <20050616080958.GG2239@obiwan.tataz.chchile.org> References: <20050616070445.GD2239@obiwan.tataz.chchile.org> <20050616.012302.48201645.imp@bsdimp.com> <20050616075743.GE2239@obiwan.tataz.chchile.org> <20050616.020442.31252848.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050616.020442.31252848.imp@bsdimp.com> User-Agent: Mutt/1.5.9i Cc: freebsd-current@freebsd.org, jeremie@le-hen.org Subject: Re: incorrect ping(8) interval with powerd(8) 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, 16 Jun 2005 08:09:45 -0000 > : FYI, > : my powerd(8) is configured to tastes AC-line four times per seconds. > : I tried reducing it's freqency from 4 to 1, but it doesn't change > : anything. > : > : ARP is not the culprit, the MAC address is already in cache. > : > : My kernel is compiled with INVARIANTS, but I don't have WITNESS. My > : network interface uses the bge(4) driver. No firewall rule or complex > : network setup. > : > : Anyway this doesn't hurt much. Thanks for lightening me. > > Dang, I was hoping it was one of the easy explainations.... Maybe it > is the idle code not waking up fast enough when it has been asleep for > a bit. But that's pure speculation at this point... You mean FreeBSD needs a hackathon ? :-D Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 09:05: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 B229C16A41C; Thu, 16 Jun 2005 09:05:18 +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 E5F0A43D1F; Thu, 16 Jun 2005 09:05:17 +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 04BAAEB14C4; Thu, 16 Jun 2005 17:05:10 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 81AFD131FDA; Thu, 16 Jun 2005 17:04:27 +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 40094-07; Thu, 16 Jun 2005 17:04: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 770E3131336; Thu, 16 Jun 2005 17:04:18 +0800 (CST) From: Xin LI To: freebsd-current@FreeBSD.org Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-Q8RPkZo9v1VhNPn5u4st" Organization: The FreeBSD Simplified Chinese Project Date: Thu, 16 Jun 2005 17:04:11 +0800 Message-Id: <1118912651.860.17.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at frontfree.net Cc: jeff@FreeBSD.org Subject: Recent VFS locking vs kqueue 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: Thu, 16 Jun 2005 09:05:18 -0000 --=-Q8RPkZo9v1VhNPn5u4st Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Hi, Jeff and -current@, With a fresh -CURRENT kernel (today's source) I got the following messages from console and /var/log/messages on my laptop, with a "cvs -R up -PdA 2>/dev/null" running on one console (which results in disk/fs activities) and "tail -F /var/log/messages" (which uses kqueue events). The kernel is built with ULE scheduler, PREEMPTION+FULL_PREEMPTION enabled, and all debugging options, like INVARIANTS and WITESS turned on. BTW. I have found something that can lead to panic: Negative nice count, which indicates that there are some races in our code, but it seems that the bug is not easy to exercise. Will report more information/patches once I got some findings. Thanks in advance! Jun 16 16:44:09 spirit kernel: Acquiring lockmgr lock "ufs" with the following non-sleepable locks held: Jun 16 16:44:09 spirit kernel: exclusive sleep mutex kqueue r =3D 0 (0xc1b60a00) locked @ /usr/src/sys/kern/kern_event.c:1524 Jun 16 16:44:09 spirit kernel: exclusive sleep mutex vnode pollinfo r =3D 0 (0xc2074000) locked @ /usr/src/sys/kern/kern_event.c:1512 Jun 16 16:44:09 spirit kernel: KDB: stack backtrace: Jun 16 16:44:09 spirit kernel: kdb_backtrace(2,3001,c1a8e29c,c17fdaf0,de75aa08) at kdb_backtrace+0x29 Jun 16 16:44:09 spirit kernel: witness_warn(5,c06df974,c067daa2,c06867e6) at witness_warn+0x18e Jun 16 16:44:09 spirit kernel: lockmgr(c1a8e278,3001,c1a8e29c,c17fdaf0,de75aa34) at lockmgr+0x8d Jun 16 16:44:09 spirit kernel: vop_stdlock(de75aa78,c06c8be0,de75aa78,de75aa44,c05ee068) at vop_stdlock +0x1e Jun 16 16:44:09 spirit kernel: VOP_LOCK_APV(c06c92e0,de75aa78,de75aa58,c0653697,de75aa78) at VOP_LOCK_APV+0x87 Jun 16 16:44:09 spirit kernel: ffs_lock(de75aa78,1001,c1a8e220,de75aa94,c0576628) at ffs_lock+0x10 Jun 16 16:44:09 spirit kernel: VOP_LOCK_APV(c06c8be0,de75aa78) at VOP_LOCK_APV+0x87 Jun 16 16:44:09 spirit kernel: vn_lock(c1a8e220,1001,c17fdaf0) at vn_lock+0xa8 Jun 16 16:44:09 spirit kernel: filt_vfsread(c1ae4c7c,6) at filt_vfsread +0x3a Jun 16 16:44:09 spirit kernel: knote(c2074030,6,0) at knote+0x90 Jun 16 16:44:09 spirit kernel: VOP_WRITE_APV(c06c8be0,de75ac40) at VOP_WRITE_APV+0x18c Jun 16 16:44:09 spirit kernel: vn_write(c17c3360,c1e50580,c157bd80,0,c17fdaf0) at vn_write+0x1ea Jun 16 16:44:09 spirit kernel: kern_writev(c17fdaf0,9,c1e50580,c1e50580,0) at kern_writev+0x8e Jun 16 16:44:09 spirit kernel: writev(c17fdaf0,de75ad04,3,43,246) at writev+0x30 Jun 16 16:44:09 spirit kernel: syscall(bfbf003b,bfbf003b,bfbf003b,8056cdb,bfbfd5d0) at syscall+0x22f Jun 16 16:44:09 spirit kernel: Xint0x80_syscall() at Xint0x80_syscall +0x1f Jun 16 16:44:09 spirit kernel: --- syscall (121, FreeBSD ELF32, writev), eip =3D 0x280c8d4b, esp =3D 0xbfbfceec, ebp =3D 0xbfbfd5f8 --- Jun 16 16:44:09 spirit kernel: Acquiring lockmgr lock "ufs" with the following non-sleepable locks held: Jun 16 16:44:09 spirit kernel: exclusive sleep mutex kqueue r =3D 0 (0xc1b60a00) locked @ /usr/src/sys/kern/kern_event.c:1524 Jun 16 16:44:09 spirit kernel: exclusive sleep mutex vnode pollinfo r =3D 0 (0xc2074000) locked @ /usr/src/sys/kern/kern_event.c:1512 Jun 16 16:44:09 spirit kernel: KDB: stack backtrace: Jun 16 16:44:09 spirit kernel: kdb_backtrace(2,3001,c1a8e29c,c17fdaf0,de75aa08) at kdb_backtrace+0x29 Jun 16 16:44:09 spirit kernel: witness_warn(5,c06df974,c067daa2,c06867e6) at witness_warn+0x18e Jun 16 16:44:09 spirit kernel: lockmgr(c1a8e278,3001,c1a8e29c,c17fdaf0,de75aa34) at lockmgr+0x8d Jun 16 16:44:09 spirit kernel: vop_stdlock(de75aa78,c06c8be0,de75aa78,de75aa44,c05ee068) at vop_stdlock +0x1e Jun 16 16:44:09 spirit kernel: VOP_LOCK_APV(c06c92e0,de75aa78,de75aa58,c0653697,de75aa78) at VOP_LOCK_APV+0x87 Jun 16 16:44:09 spirit kernel: ffs_lock(de75aa78,1001,c1a8e220,de75aa94,c0576628) at ffs_lock+0x10 Jun 16 16:44:09 spirit kernel: VOP_LOCK_APV(c06c8be0,de75aa78) at VOP_LOCK_APV+0x87 Jun 16 16:44:09 spirit kernel: vn_lock(c1a8e220,1001,c17fdaf0) at vn_lock+0xa8 Jun 16 16:44:09 spirit kernel: filt_vfsread(c1ae4c7c,6) at filt_vfsread +0x3a Jun 16 16:44:09 spirit kernel: knote(c2074030,6,0) at knote+0x90 Jun 16 16:44:09 spirit kernel: VOP_WRITE_APV(c06c8be0,de75ac40) at VOP_WRITE_APV+0x18c Jun 16 16:44:09 spirit kernel: vn_write(c17c3360,c1e51480,c157bd80,0,c17fdaf0) at vn_write+0x1ea Jun 16 16:44:09 spirit kernel: kern_writev(c17fdaf0,9,c1e51480,c1e51480,0) at kern_writev+0x8e Jun 16 16:44:09 spirit kernel: writev(c17fdaf0,de75ad04,3,45,246) at writev+0x30 Jun 16 16:44:09 spirit kernel: syscall(bfbf003b,bfbf003b,bfbf003b,8056cdb,bfbfd5d0) at syscall+0x22f Jun 16 16:44:09 spirit kernel: Xint0x80_syscall() at Xint0x80_syscall +0x1f Jun 16 16:44:09 spirit kernel: --- syscall (121, FreeBSD ELF32, writev), eip =3D 0x280c8d4b, esp =3D 0xbfbfceec, ebp =3D 0xbfbfd5f8 --- Jun 16 16:44:09 spirit kernel: Acquiring lockmgr lock "ufs" with the following non-sleepable locks held: Jun 16 16:44:09 spirit kernel: exclusive sleep mutex kqueue r =3D 0 (0xc1b60a00) locked @ /usr/src/sys/kern/kern_event.c:1524 Jun 16 16:44:09 spirit kernel: exclusive sleep mutex vnode pollinfo r =3D 0 (0xc2074000) locked @ /usr/src/sys/kern/kern_event.c:1512 Jun 16 16:44:09 spirit kernel: KDB: stack backtrace: Jun 16 16:44:09 spirit kernel: kdb_backtrace(2,3001,c1a8e29c,c17fdaf0,de75aa08) at kdb_backtrace+0x29 Jun 16 16:44:09 spirit kernel: witness_warn(5,c06df974,c067daa2,c06867e6) at witness_warn+0x18e Jun 16 16:44:09 spirit kernel: lockmgr(c1a8e278,3001,c1a8e29c,c17fdaf0,de75aa34) at lockmgr+0x8d Jun 16 16:44:09 spirit kernel: vop_stdlock(de75aa78,c06c8be0,de75aa78,de75aa44,c05ee068) at vop_stdlock +0x1e Jun 16 16:44:09 spirit kernel: VOP_LOCK_APV(c06c92e0,de75aa78,de75aa58,c0653697,de75aa78) at VOP_LOCK_APV+0x87 Jun 16 16:44:09 spirit kernel: ffs_lock(de75aa78,1001,c1a8e220,de75aa94,c0576628) at ffs_lock+0x10 Jun 16 16:44:09 spirit kernel: VOP_LOCK_APV(c06c8be0,de75aa78) at VOP_LOCK_APV+0x87 Jun 16 16:44:09 spirit kernel: vn_lock(c1a8e220,1001,c17fdaf0) at vn_lock+0xa8 Jun 16 16:44:09 spirit kernel: filt_vfsread(c1ae4c7c,6) at filt_vfsread +0x3a Jun 16 16:44:09 spirit kernel: knote(c2074030,6,0) at knote+0x90 Jun 16 16:44:09 spirit kernel: VOP_WRITE_APV(c06c8be0,de75ac40) at VOP_WRITE_APV+0x18c Jun 16 16:44:09 spirit kernel: vn_write(c17c3360,c1bafe80,c157bd80,0,c17fdaf0) at vn_write+0x1ea Jun 16 16:44:09 spirit kernel: kern_writev(c17fdaf0,9,c1bafe80,c1bafe80,0) at kern_writev+0x8e Jun 16 16:44:09 spirit kernel: writev(c17fdaf0,de75ad04,3,47,246) at writev+0x30 Jun 16 16:44:09 spirit kernel: syscall(bfbf003b,bfbf003b,bfbf003b,8056cdb,bfbfd5d0) at syscall+0x22f Jun 16 16:44:09 spirit kernel: Xint0x80_syscall() at Xint0x80_syscall +0x1f Jun 16 16:44:09 spirit kernel: --- syscall (121, FreeBSD ELF32, writev), eip =3D 0x280c8d4b, esp =3D 0xbfbfceec, ebp =3D 0xbfbfd5f8 --- Cheers, --=20 Xin LI http://www.delphij.net/ --=-Q8RPkZo9v1VhNPn5u4st 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) iD8DBQBCsUCL/cVsHxFZiIoRAiovAJ9T2Drjtn7i73zHz9MyBBAwBCAPHQCfReFp numYkjMaT5OkUidVNmAsvjw= =czZG -----END PGP SIGNATURE----- --=-Q8RPkZo9v1VhNPn5u4st-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 09:24:47 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 0538A16A41C; Thu, 16 Jun 2005 09:24:47 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from lapdance.yazzy.net (217-13-2-82.dd.nextgentel.com [217.13.2.82]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5DEB543D48; Thu, 16 Jun 2005 09:24:43 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from localhost (localhost [127.0.0.1]) by lapdance.yazzy.net (8.13.4/8.13.4) with SMTP id j5F9jvs0001313; Wed, 15 Jun 2005 11:45:57 +0200 (CEST) (envelope-from lists@yazzy.org) Date: Wed, 15 Jun 2005 11:45:56 +0200 From: Marcin Jessa To: FreeBSD-net , FreeBSD-Current Message-Id: <20050615114556.6df96e8c.lists@yazzy.org> Organization: YazzY.org X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Subject: Looking for networking solution. 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, 16 Jun 2005 09:24:47 -0000 Hi guys. I am looking for solution I could implement on a link with a huge latency when ping replies can go up to a few hundred miliseconds, e.g sateliete links. What I was thinking about is some kind of virtual interface which could translate tcp to udp in one of the pears of the link and push the data it received from a 'normal' interface through the virtual interface without bothering about ack-timing. The receiving end would have a similar interface which would translate the udp data stream to tcp and then route it out to the internet. (normal network)tcp<-->virtual udp interface<-------->virtual udp interface<-->tcp(normal network) Is there something avaliable on FreeBSD that can be used for that purpose? Maybe someone is working on such a thing in CURRENT ? Any thoughts about that? Any sugestions for a solution? Regards, Marcin Jessa. From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 09:46: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 F324B16A41C for ; Thu, 16 Jun 2005 09:46:04 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id 747F943D4C for ; Thu, 16 Jun 2005 09:46:04 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by zproxy.gmail.com with SMTP id 18so312181nzp for ; Thu, 16 Jun 2005 02:46:03 -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=Vps1+FggmQ7YimaVhN5isqbE6zKgtuVbIN7+1n90I6sFELniT/+MzJGQaAcuzbxBh/8wQXHbw0zrINIBDz1k0OtZ8cFihkBfFDyJu7AYZjwQKKvbg/b6va7+wGWY9tS3RWG1TYAk07Dk+uG8qGE1hIGK6awamU0E73GKn78zNI4= Received: by 10.36.43.9 with SMTP id q9mr364023nzq; Thu, 16 Jun 2005 02:46:03 -0700 (PDT) Received: by 10.36.88.8 with HTTP; Thu, 16 Jun 2005 02:46:03 -0700 (PDT) Message-ID: Date: Thu, 16 Jun 2005 17:46:03 +0800 From: Jiawei Ye To: delphij@delphij.net In-Reply-To: <1118912651.860.17.camel@spirit> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1118912651.860.17.camel@spirit> Cc: freebsd-current@freebsd.org Subject: Re: Recent VFS locking vs kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jiawei Ye List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2005 09:46:05 -0000 On 6/16/05, Xin LI wrote: > Hi, Jeff and -current@, >=20 > With a fresh -CURRENT kernel (today's source) I got the following > messages from console and /var/log/messages on my laptop, with a "cvs -R > up -PdA 2>/dev/null" running on one console (which results in disk/fs > activities) and "tail -F /var/log/messages" (which uses kqueue events). >=20 > The kernel is built with ULE scheduler, PREEMPTION+FULL_PREEMPTION > enabled, and all debugging options, like INVARIANTS and WITESS turned > on. >=20 > BTW. I have found something that can lead to panic: Negative nice > count, which indicates that there are some races in our code, but it > seems that the bug is not easy to exercise. Will report more > information/patches once I got some findings. >=20 > Thanks in advance! Perhaps you could try compling Apache2 with KQUEUE and THREADS support, then try exercise the httpd server with 'webbench -c 1000'. I got several panics (alas, not dump available) during the last week with such setup. After turning off KQUEUE and THREADS support in Apache2, things calmed down. Jiawei --=20 "Without the userland, the kernel is useless." --inspired by The Tao of Programming From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 09:51:39 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 54CC016A41C for ; Thu, 16 Jun 2005 09:51:39 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from grunt9.ihug.co.nz (grunt9.ihug.co.nz [203.109.254.51]) by mx1.FreeBSD.org (Postfix) with ESMTP id C474E43D48 for ; Thu, 16 Jun 2005 09:51:38 +0000 (GMT) (envelope-from mjl@luckie.org.nz) Received: from 203-173-150-184.bliink.ihug.co.nz (lycra.luckie.org.nz) [203.173.150.184] by grunt9.ihug.co.nz with esmtp (Exim 3.35 #1 (Debian)) id 1Dir27-0004e1-00; Thu, 16 Jun 2005 21:51:35 +1200 Received: from 203-173-146-91.bliink.ihug.co.nz ([203.173.146.91] helo=[192.168.1.8]) by lycra.luckie.org.nz with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.51 (FreeBSD)) id 1Dir26-000GbO-6y for freebsd-current@freebsd.org; Thu, 16 Jun 2005 21:51:34 +1200 Message-ID: <42B14BA3.5050700@luckie.org.nz> Date: Thu, 16 Jun 2005 21:51:31 +1200 From: Matthew Luckie User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050530 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: BPF writes on DLT_NULL devices 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, 16 Jun 2005 09:51:39 -0000 Hi -current I'm writing to see if I can find someone to review and commit a patch I submitted to PR 82157 as suggested by re@ http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/82157 The patch attempts to tidy up the mess that is BPF write on DLT_NULL devices. Some of these devices are handy to write to, e.g. tun, gif, and gre. There are a number of limitations and flaws in the -current code; namely * not all DLT_NULL devices support bpf write, including gif and gre * write() will fail if trying to send a packet larger than the IP MTU less 4 bytes, due to bpf_movein not taking into account the psuedo header * if_loop.c checks for bpf write in if_simloop; however the only device passing a packet via BPF to that function is looutput, yet looutput will return EAFNOSUPPORT because AF_UNSPEC is not checked in that function. Full details, including test code and a patch is available in the PR Any takers? Matthew From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 09:51:47 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 7B4A116A42C for ; Thu, 16 Jun 2005 09:51:47 +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 596E843D53 for ; Thu, 16 Jun 2005 09:51:47 +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 765BA19F52 for ; Thu, 16 Jun 2005 02:53:16 -0700 (PDT) From: "Darren Pilgrim" To: Date: Thu, 16 Jun 2005 02:51:44 -0700 Message-ID: <000001c57259$01a259c0$0b2a15ac@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 Importance: Normal Cc: Subject: Is anyone working on /etc/rc.d/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: Thu, 16 Jun 2005 09:51:47 -0000 Is anyone working on the proposed /etc/rc.d/wpa_supplicant script (as mentioned in /etc/network.subr? If not, I'll get started on one. Also if not, what are some guidelines for what the script should do? Is just terminating wpa_supplicant sufficient, or should the script stop dhclient, de-configure and down the interface as well? From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 09:59:11 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 9560516A41C; Thu, 16 Jun 2005 09:59:11 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4C68A43D49; Thu, 16 Jun 2005 09:59:11 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=h311r4z3r) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1Dir96-0007df-HJ; Thu, 16 Jun 2005 11:58:50 +0200 Date: Thu, 16 Jun 2005 11:59:06 +0200 From: Marcin Jessa To: ray@redshift.com Message-Id: <20050616115906.2bc4bc26.lists@yazzy.org> In-Reply-To: <3.0.1.32.20050616023527.00abb700@pop.redshift.com> References: <20050615114556.6df96e8c.lists@yazzy.org> <3.0.1.32.20050616023527.00abb700@pop.redshift.com> Organization: YazzY.org X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: Looking for networking solution. 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, 16 Jun 2005 09:59:11 -0000 On Thu, 16 Jun 2005 02:35:27 -0700 ray@redshift.com wrote: > Marcin, > > What is it you are trying to accomplish and/or solve here? Switching between > UDP and TCP isn't going to have much impact on your problem if it is a function > of a lower network layer. > > In a case where you have a questionable connection, TCP is really what you > want, because UDP has a habit of saying "oh, can't get this packet to ya, sorry, > see ya later, drop packet". In other words, UDP is more a hope for the best > sort of situation, whereas TCP has built in retranmission, error checking, etc. > > Again, I'm not sure what exactly you are trying to accomplish with this idea? I want to just dump all the packets between two satelite links without checking for ack back and forth which creates latency and long ping times. For that I want both the peers between satelite links to take care of that and be able to deal with routing the traffic flow out again. I am not sure what solution would be appropriate for that problem and I am very open for suggestions. What I want is a solution which does not requires 3.rd party software/hardware (I am aware of the existing ones). I want it to be able to run on FreeBSD. > > > At 11:45 AM 6/15/2005 +0200, Marcin Jessa wrote: > | Hi guys. > | > | I am looking for solution I could implement on a link with a huge latency when > ping replies can go up to a few hundred miliseconds, e.g sateliete links. > | What I was thinking about is some kind of virtual interface which could > translate tcp to udp in one of the pears of the link and push the data it > received from a 'normal' interface through the virtual interface without > bothering about ack-timing. > | The receiving end would have a similar interface which would translate the udp > data stream to tcp and then route it out to the internet. > | (normal network)tcp<-->virtual udp interface<-------->virtual udp > interface<-->tcp(normal network) > | > | Is there something avaliable on FreeBSD that can be used for that purpose? > | Maybe someone is working on such a thing in CURRENT ? > | Any thoughts about that? Any sugestions for a solution? > | > | > | Regards, > | Marcin Jessa. > | > | _______________________________________________ > | freebsd-net@freebsd.org mailing list > | http://lists.freebsd.org/mailman/listinfo/freebsd-net > | To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > | > | > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 10:01: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 7946616A41C for ; Thu, 16 Jun 2005 10:01:33 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail16.syd.optusnet.com.au (mail16.syd.optusnet.com.au [211.29.132.197]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD81443D53 for ; Thu, 16 Jun 2005 10:01:30 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-8-51.belrs4.nsw.optusnet.com.au [220.239.8.51]) by mail16.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j5GA1HHV020525 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 16 Jun 2005 20:01:17 +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 j5GA1HRx057176; Thu, 16 Jun 2005 20:01: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 j5GA1HbI057175; Thu, 16 Jun 2005 20:01:17 +1000 (EST) (envelope-from pjeremy) Date: Thu, 16 Jun 2005 20:01:17 +1000 From: Peter Jeremy To: Chuck Swiger Message-ID: <20050616100117.GG50157@cirb503493.alcatel.com.au> References: <20050615054209.L29741@beagle.kn.op.dlr.de> <20050615160741.GA55062@dragon.NUXI.org> <88862BDF-ED45-42CE-9B24-DEEED2E66C2C@mac.com> <20050615.212337.108191340.imp@bsdimp.com> <42B10804.2010308@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42B10804.2010308@mac.com> User-Agent: Mutt/1.4.2i Cc: freebsd-current@freebsd.org, "M. Warner Losh" Subject: Re: groff alternative? 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, 16 Jun 2005 10:01:33 -0000 On Thu, 2005-Jun-16 01:03:00 -0400, Chuck Swiger wrote: >Perhaps there won't be a rush of code adoption from OpenSolaris into >FreeBSD, but it would be a surprise and a pity if there was nothing to be >learned. I'd imagine that the Solaris NFS code would be worth looking at, >for instance. Agreed. But we want to be ensure that any improvements that are made to FreeBSD don't impact the code's existing license: It's one thing to swap a GPL groff for a CDDL troff but winding up with Sun claiming that FreeBSD's NFS is a derivative of the Solaris NFS would be a serious problem for the FreeBSD Project. >Lots of license flavors are handled OK via src/contrib and throughout the >entire ports collection now. It's not as if CDDL-licensed code is going to >sneak up and infect existing BSD-licensed code; the two licenses are >miscible. The non-BSD-licensed code is deliberately kept in src/contrib so that it can be easily isolated for vendors who want to restrict themselves to a BSD-licensed system. >M. Warner Losh wrote: >>Anyway, since we don't ship groff/roff/etc with the systems we create, >>this specific program doesn't matter much... > >4-sec% /usr/bin/nroff --version >GNU nroff (groff) version 1.19 ... >This seems to be from src/contrib/groff? I believe Warner was referring to the embedded systems he builds as a day-job rather than the FreeBSD Project. IMHO, the fewer different licenses used by the FreeBSD base system the better. If FreeBSD needs to grow a CDDL (for part of the base system) the Solaris troff needs to offer significant benefits. -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 10:13: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 8105316A41C; Thu, 16 Jun 2005 10:13:35 +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 29D7B43D55; Thu, 16 Jun 2005 10:13:35 +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 C763CEB1479; Thu, 16 Jun 2005 18:13:31 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 34D0813112B; Thu, 16 Jun 2005 18:13:27 +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 44123-02; Thu, 16 Jun 2005 18:13:19 +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 23F95130D46; Thu, 16 Jun 2005 18:13:18 +0800 (CST) From: Xin LI To: Jiawei Ye In-Reply-To: References: <1118912651.860.17.camel@spirit> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-1T1iiRfmL+mhLJgRSani" Organization: The FreeBSD Simplified Chinese Project Date: Thu, 16 Jun 2005 18:13:11 +0800 Message-Id: <1118916792.860.26.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at frontfree.net Cc: freebsd-current@freebsd.org Subject: Re: Recent VFS locking vs kqueue 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: Thu, 16 Jun 2005 10:13:35 -0000 --=-1T1iiRfmL+mhLJgRSani Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Jiawei, =E5=9C=A8 2005-06-16=E5=9B=9B=E7=9A=84 17:46 +0800=EF=BC=8CJiawei Ye=E5=86= =99=E9=81=93=EF=BC=9A > On 6/16/05, Xin LI wrote: [snip] > Perhaps you could try compling Apache2 with KQUEUE and THREADS > support, then try exercise the httpd server with 'webbench -c 1000'. I > got several panics (alas, not dump available) during the last week > with such setup. After turning off KQUEUE and THREADS support in > Apache2, things calmed down. Thanks for the hints. Will make an Apache 2.0.54 with worker MPM, KQUEUE and THREADS+THREADS_MODULES and try. I'm not sure whether we are discussing the same problem, though, but I'd be happy if I can hit some bugs and maybe to fix them :-) Cheers, --=20 Xin LI http://www.delphij.net/ --=-1T1iiRfmL+mhLJgRSani 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) iD8DBQBCsVC3/cVsHxFZiIoRAmwnAJ4j0rq+mOsyT8xvX/2w0LoIcp3pNgCfaxZU JR/OkBmG7wuO2ffHjCPC5Z0= =0BGv -----END PGP SIGNATURE----- --=-1T1iiRfmL+mhLJgRSani-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 10:31: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 A629C16A41C for ; Thu, 16 Jun 2005 10:31:08 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from mrout3.yahoo.com (mrout3.yahoo.com [216.145.54.173]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8F32A43D53 for ; Thu, 16 Jun 2005 10:31:06 +0000 (GMT) (envelope-from gnn@neville-neil.com) Received: from minion.local.neville-neil.com (proxy7.corp.yahoo.com [216.145.48.98]) by mrout3.yahoo.com (8.13.4/8.13.4/y.out) with ESMTP id j5GASRFJ087153; Thu, 16 Jun 2005 03:28:28 -0700 (PDT) Date: Thu, 16 Jun 2005 19:28:28 +0900 Message-ID: From: "George V. Neville-Neil" To: Sam Leffler In-Reply-To: <42B1146C.6070508@errno.com> References: <20050614205537.D62878@gabby.gsicomp.on.ca> <1118806968.1003.9.camel@localhost> <20050615061009.GA11914@odin.ac.hmc.edu> <20050615.003020.99022728.imp@bsdimp.com> <42B1146C.6070508@errno.com> User-Agent: Wanderlust/2.12.2 (99 Luftballons) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.2 (powerpc-apple-darwin) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: vova@fbsd.ru, freebsd-current@freebsd.org, "M. Warner Losh" , matt@gsicomp.on.ca Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 10:31:08 -0000 At Wed, 15 Jun 2005 22:55:56 -0700, sam wrote: > I've noticed one issue. If you mark an interface down then dhclient > exits but any assigned ip address is not removed. This is a change from > the previous dhclient and something I thought I'd fixed (but clearly > not). OTOH brooks pointed out that leaving the ip address around means > tcp sessions don't immediately die so if you reconnect and reacquire the > same lease your sessions can be revived if they were idle. I too see this in my test lab. I'm not sure if this effects the scripts, but other than that it does not seem like a bad change. According to the protocol the interface only needs to have its IP removed if the client is active and if it cannot renew the lease and bringing the interface down effectively removes the IP address from the network. Later, George From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 10:33:44 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 35A1C16A41C for ; Thu, 16 Jun 2005 10:33:44 +0000 (GMT) (envelope-from emil@cs.rmit.edu.au) Received: from its-mu-mail4.its.rmit.edu.au (its-mu-mail4.its.rmit.edu.au [131.170.2.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id BBD4343D1D for ; Thu, 16 Jun 2005 10:33:43 +0000 (GMT) (envelope-from emil@cs.rmit.edu.au) Received: from wombat.cs.rmit.edu.au (wombat.cs.rmit.edu.au [131.170.24.41]) by its-mu-mail4.its.rmit.edu.au (8.13.1/8.13.1/mail4) with ESMTP id j5GAXZ30009604 for ; Thu, 16 Jun 2005 20:33:41 +1000 (EST) Received: from goanna.cs.rmit.edu.au (goanna.cs.rmit.edu.au [131.170.24.40]) by wombat.cs.rmit.edu.au (8.12.10/8.12.10/cshub) with ESMTP id j5GAVjtQ019863 for ; Thu, 16 Jun 2005 20:31:45 +1000 (EST) Received: (from emil@localhost) by goanna.cs.rmit.edu.au (8.11.3/8.9.3/csnode) id j5GAVii13187 for current@freebsd.org; Thu, 16 Jun 2005 20:31:44 +1000 (EST) Date: Thu, 16 Jun 2005 20:31:44 +1000 From: Emil Mikulic To: current@freebsd.org Message-ID: <20050616103144.GA9596@cs.rmit.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Written-On: goanna.cs.rmit.edu.au (SunOS 5.9 sun4u) X-PGP-Fingerprint: D2B4 7C14 0C41 9AE5 8D2B 16B0 D3D6 F910 8E4C 5D35 User-Agent: Mutt/1.5.9i X-Scanned-By: MIMEDefang 2.44 Cc: Subject: gdb firefox with libthr -> fatal trap 9 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, 16 Jun 2005 10:33:44 -0000 I tried to run firefox from gdb and it caused a panic. (The second time I tried it, I started X then switched to a text VT to run "gdb firefox-bin" so that the panic wouldn't cause an instant reboot) I have libmap.conf set up so that firefox-bin uses libthr. If I use libpthread instead, there's no panic, firefox runs in the debugger. Transcript of the panic follows: kernel trap 9 with interrupts disabled Fatal trap 9: general protection fault while in kernel mode instruction pointer = 0x20:0xc061558b stack pointer = 0x28:0xc7557cf0 frame pointer = 0x28:0xc7557cf0 code segment = base 0x0, limit 0xfffff, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = resume, IOPL = 0 current process = 666 (firefox-bin) [thread pid 666 tid 100082] Stopped at fpurstor+0xf: db> where Tracing pid 666 tid 100082 td 0xc13897d0 fpurstor(c7557dd0) at fpurstor+0xf npxdna(0,0,0,3,c1388400) at npxdna+0xe5 trap(3b,3b,3b,8076c80,0) at trap+0x297 calltrap() at calltrap+0x5 --- trap 0x16, eip = 0x2885d02b, esp = 0xbfbfe520, ebp = 0xbfbfe538 --- db> call doadump Dumping 97 MB Transcribed manually because doadump didn't. =( It just stopped, although hitting keys caused it to print "[CTRL-C to abort]" This is on 6-CURRENT from earlier today. I'm not suggesting anything has been broken recently since I've never tried to run firefox-bin from gdb before. --Emil (mildly amused by the process ID) From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 11: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 A696016A41C for ; Thu, 16 Jun 2005 11:15: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 6072943D1F for ; Thu, 16 Jun 2005 11:15: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 j5GBFObh094345; Thu, 16 Jun 2005 06:15:24 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42B15F2E.9050408@centtech.com> Date: Thu, 16 Jun 2005 06:14:54 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050603 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "M. Warner Losh" References: <20050616070445.GD2239@obiwan.tataz.chchile.org> <20050616.012302.48201645.imp@bsdimp.com> <20050616075743.GE2239@obiwan.tataz.chchile.org> <20050616.020442.31252848.imp@bsdimp.com> In-Reply-To: <20050616.020442.31252848.imp@bsdimp.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org, jeremie@le-hen.org Subject: Re: incorrect ping(8) interval with powerd(8) 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, 16 Jun 2005 11:15:33 -0000 M. Warner Losh wrote: > In message: <20050616075743.GE2239@obiwan.tataz.chchile.org> > Jeremie Le Hen writes: > : > : May you delve into this a little bit more please ? The ping(8) manual > : > : page states that the -i flags makes ping(8) to wait a given couple of > : > : seconds. If I use the flags "-i 1", I expect ECHO Requests to be sent > : > : with one second between each, whatever the AC line status is. > : > : (Note that I didn't explicitely specified "-i 1" in the above example, > : > : but this doesn't change the behaviour.) > : > > : > Well, the rount trip times went way up (3x longer). That's normal for > : > a 200MHz CPU... My 333MHz EISA machine can't do much better than > : > that. > : > > : > But the 2.252s run time is a little longish. Do you see this > : > consistantly? If you ran it a second time would you get identical > : > results. I've seen ARP take a while... What else do you have running > : > on the system? Maybe a daemon that takes almost no time at 1.7GHz > : > takes a lot longer at 200Mhz and that's starving the ping process... > : > Or some driver has gone insane... > : > : Yes, I ran this test multiple times, and I almost get always this same > : result although I got 2.208s sometimes, but I don't think this is > : significant. > : > : FYI, > : my powerd(8) is configured to tastes AC-line four times per seconds. > : I tried reducing it's freqency from 4 to 1, but it doesn't change > : anything. > : > : ARP is not the culprit, the MAC address is already in cache. > : > : My kernel is compiled with INVARIANTS, but I don't have WITNESS. My > : network interface uses the bge(4) driver. No firewall rule or complex > : network setup. > : > : Anyway this doesn't hurt much. Thanks for lightening me. > > Dang, I was hoping it was one of the easy explainations.... Maybe it > is the idle code not waking up fast enough when it has been asleep for > a bit. But that's pure speculation at this point... Another datapoint - running -CURRENT as of about June 7th, I see this too: $ time ping -i 1 -c 5 localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.041 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.033 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.029 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.031 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.035 ms --- localhost ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.029/0.034/0.041/0.004 ms real 0m9.728s user 0m0.000s sys 0m0.003s On a 5-STABLE machine: $ time ping -i 1 -c 5 localhost PING localhost (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.049 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.032 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.024 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.021 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.032 ms --- localhost ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.021/0.032/0.049/0.010 ms real 0m4.064s user 0m0.000s sys 0m0.005s I have powerd running, but it makes no difference whether I have it running or not, nor does it make any difference if I'm on ac or battery. This worked fine a couple weeks back for me - the only thing I recall changing is adding apic to my kernel. 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 Jun 16 11:32: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 6502E16A41C; Thu, 16 Jun 2005 11:32:41 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE60843D48; Thu, 16 Jun 2005 11:32:40 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=h311r4z3r) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1Disba-0000oD-NZ; Thu, 16 Jun 2005 13:32:20 +0200 Date: Thu, 16 Jun 2005 13:32:36 +0200 From: Marcin Jessa To: FreeBSD-mobile , FreeBSD-Current Message-Id: <20050616133236.4a83eb19.lists@yazzy.org> Organization: YazzY.org X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) Cc: damien.bergamini@free.fr Subject: Intel firmware 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, 16 Jun 2005 11:32:41 -0000 Hi guys. Trying to compile firmware for iwi driver i get following errors: [root@h311r4z3r:/home/yazzy/iwi-freebsd-1.3.4]# make ===> src (all) ===> src/usr.sbin (all) ===> src/usr.sbin/iwicontrol (all) Warning: Object directory not changed from original /home/yazzy/iwi-freebsd-1.3.4/src/usr.sbin/iwicontrol cc -O -pipe -march=pentium4 -c iwicontrol.c cc -O -pipe -march=pentium4 -o iwicontrol iwicontrol.o gzip -cn iwicontrol.8 > iwicontrol.8.gz groff -Tascii -mtty-char -man -t iwicontrol.8 | gzip -cn > iwicontrol.8.cat.gz ===> src/share (all) ===> src/share/man (all) ===> src/share/man/man4 (all) Warning: Object directory not changed from original /home/yazzy/iwi-freebsd-1.3.4/src/share/man/man4 gzip -cn iwi.4 > iwi.4.gz groff -Tascii -mtty-char -man -t iwi.4 | gzip -cn > iwi.4.cat.gz ===> src/sys (all) ===> src/sys/modules (all) ===> src/sys/modules/iwi (all) Warning: Object directory not changed from original /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi @ -> /usr/src/sys machine -> /usr/src/sys/i386/include awk -f @/tools/makeobjops.awk @/kern/device_if.m -h awk -f @/tools/makeobjops.awk @/kern/bus_if.m -h awk -f @/tools/makeobjops.awk @/dev/pci/pci_if.m -h cc -O -pipe -march=pentium4 -DIWI_DEBUG -DNBPFILTER=1 -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I- -I. -I@ -I@/contrib/altq -I@/../include -I/usr/include -finline-limit=8000 -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -c /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_attach': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:217: error: structure has no member named `ic_if' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:332: warning: passing arg 1 of `ieee80211_ifattach' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:336: warning: passing arg 1 of `ieee80211_media_init' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_detach': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:381: error: structure has no member named `ic_if' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:393: warning: passing arg 1 of `ieee80211_ifdetach' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_resume': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:630: error: structure has no member named `ic_if' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_newstate': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:731: error: structure has no member named `ic_softc' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_frame_intr': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:854: error: structure has no member named `ic_if' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:916: warning: passing arg 1 of `ieee80211_find_node' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:923: warning: passing arg 1 of `ieee80211_input' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:928: warning: passing arg 1 of `ieee80211_free_node' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:928: error: too many arguments to function `ieee80211_free_node' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_notification_intr': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:952: error: structure has no member named `ic_if' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:971: warning: passing arg 1 of `ieee80211_end_scan' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1005: warning: passing arg 1 of `ieee80211_begin_scan' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1005: error: too few arguments to function `ieee80211_begin_scan' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_tx_intr': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1071: error: structure has no member named `ic_if' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1088: warning: passing arg 1 of `ieee80211_free_node' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1088: error: too many arguments to function `ieee80211_free_node' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_intr': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1125: error: structure has no member named `ic_if' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1136: error: structure has no member named `ic_if' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_tx_start': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1289: error: `IEEE80211_F_WEPON' undeclared (first use in this function) /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1289: error: (Each undeclared identifier is reported only once /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1289: error: for each function it appears in.) /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1291: error: structure has no member named `ic_wep_txkey' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_start': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1349: warning: passing arg 1 of `ieee80211_encap' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1349: warning: passing arg 3 of `ieee80211_encap' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1360: warning: passing arg 1 of `ieee80211_free_node' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1360: error: too many arguments to function `ieee80211_free_node' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_watchdog': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1392: warning: passing arg 1 of `ieee80211_watchdog' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_ioctl': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1445: warning: passing arg 1 of `ieee80211_ioctl' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1461: warning: passing arg 1 of `ieee80211_ioctl' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1466: warning: passing arg 1 of `ieee80211_ioctl' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_config': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1826: error: structure has no member named `ic_if' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1911: error: `IEEE80211_F_WEPON' undeclared (first use in this function) /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1912: warning: assignment from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_auth_and_assoc': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:1974: error: structure has no member named `ic_if' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2029: error: structure has no member named `ic_wep_txkey' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2030: error: incompatible type for argument 1 of `bcopy' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_init': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2050: error: structure has no member named `ic_if' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2132: warning: passing arg 1 of `ieee80211_begin_scan' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2132: error: too few arguments to function `ieee80211_begin_scan' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c: In function `iwi_stop': /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2148: error: structure has no member named `ic_if' /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2170: warning: passing arg 1 of `ieee80211_free_node' from incompatible pointer type /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi/../../dev/iwi/if_iwi.c:2170: error: too many arguments to function `ieee80211_free_node' *** Error code 1 Stop in /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules/iwi. *** Error code 1 Stop in /home/yazzy/iwi-freebsd-1.3.4/src/sys/modules. *** Error code 1 Stop in /home/yazzy/iwi-freebsd-1.3.4/src/sys. *** Error code 1 Stop in /home/yazzy/iwi-freebsd-1.3.4/src. *** Error code 1 Stop in /home/yazzy/iwi-freebsd-1.3.4. From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 04:42: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 31F7416A41F for ; Thu, 16 Jun 2005 04:42:54 +0000 (GMT) (envelope-from bsd@dino.sk) Received: from bsd.dino.sk (bsd.dino.sk [213.215.72.60]) by mx1.FreeBSD.org (Postfix) with ESMTP id B486A43D4C for ; Thu, 16 Jun 2005 04:42:52 +0000 (GMT) (envelope-from bsd@dino.sk) Received: from home.dino.sk ([213.215.74.194]) (AUTH: LOGIN milan) by bsd.dino.sk with esmtp; Thu, 16 Jun 2005 06:44:28 +0200 id 000001CE.42B103AC.00008817 From: Milan Obuch To: freebsd-current@freebsd.org Date: Thu, 16 Jun 2005 06:42:40 +0200 User-Agent: KMail/1.8 References: <20050615061009.GA11914@odin.ac.hmc.edu> <200506151140.56908.current@dino.sk> <20050615.211929.103236830.imp@bsdimp.com> In-Reply-To: <20050615.211929.103236830.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506160642.41790.bsd@dino.sk> X-Mailman-Approved-At: Thu, 16 Jun 2005 11:35:58 +0000 Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 04:42:54 -0000 On Thursday 16 June 2005 05:19, M. Warner Losh wrote: > In message: <200506151140.56908.current@dino.sk> > > Milan Obuch writes: > : On Wednesday 15 June 2005 08:30, M. Warner Losh wrote: > : ... > : > : > ifconfig fxp0 1.2.3.4/24 > : > > : > will kill dhclient every time for me. > : > : Well, I would consider this a feature, not a bug, and a convenient one. > : It happens on me from time to time that I have DHCP configured on one > : interface, then after move to another place I issue 'ifconfig fxp0 ....' > : and some time after network suddenly stops working due to dhclient > : running and deleting my manually entered setting. > : Where there also 'ifconfig fxp0 DHCP' for consistency... > : I know this could be easily done with some scripting, but I could not > : resist :) > > The problem that I have with it is that if I then unplug and plug the > cable in (say press-ganging my laptop into service to test static IP > addresses) causes dhclient to run again. I'm not sure that's a bug, > but it is a behavior change from the old dhclient. It is doing what I > told it to do, but much more enthusiastically. I'm not sure what to > suggest to fix it, however... > I am not sure I got your point. I think unplugging and plugging network cable in should not cause any change whether dhclient runs or interface is statically configured, nor should it depend on whether interface is configured from boot script or manually. As an alternative, from user's perspective equal, would be kill dhclient on unplugging and starting it again on plugging cable, but this looks to me as unnecessary complication. I did not test this behaviour on my -current yet, though. Maybe I do not know all events coming into play here, either. Milan From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 00:35:35 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 1182F16A41C; Thu, 16 Jun 2005 00:35:35 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id F342A43D1F; Thu, 16 Jun 2005 00:35:33 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j5G0ZRmt052914 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2005 07:35:27 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id j5G0ZPZH022536; Thu, 16 Jun 2005 07:35:25 +0700 (ICT) Date: Thu, 16 Jun 2005 07:35:25 +0700 (ICT) Message-Id: <200506160035.j5G0ZPZH022536@banyan.cs.ait.ac.th> From: Olivier Nicole To: lists@yazzy.org In-reply-to: <58397.148.122.180.9.1118829978.squirrel@mail.yazzy.org> (lists@yazzy.org) References: <58397.148.122.180.9.1118829978.squirrel@mail.yazzy.org> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) X-Mailman-Approved-At: Thu, 16 Jun 2005 11:36:18 +0000 Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: Looking for networking solution. 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, 16 Jun 2005 00:35:35 -0000 > I am looking for solution I could implement on a link with a huge latency > when ping replies can go up to a few hundred miliseconds, e.g sateliete > links. > Etc. One way we have been thinking was to use some NAT on both end of the satellite connection and change the window size on the satellite link. That way you can push more data on the link before the first ack is due. I do not see how you can do only local ack, if a packet is lost on the "normal network" you have to have a way to inform the other end and do retransmission. If you can do only local retransmission, then you are talking about full satellite accelerator box :) Olivier From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 00:15: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 848E816A41C for ; Thu, 16 Jun 2005 00:15:36 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: from web51609.mail.yahoo.com (web51609.mail.yahoo.com [206.190.38.214]) by mx1.FreeBSD.org (Postfix) with SMTP id 2758243D4C for ; Thu, 16 Jun 2005 00:15:36 +0000 (GMT) (envelope-from pfgshield-freebsd@yahoo.com) Received: (qmail 66329 invoked by uid 60001); 16 Jun 2005 00:15:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=ui45fLe/aF2oCd4fhJ+VF5VYhS/HLe/H78EXaUKRYkJZK437GvOOHOOSIV1jskzUvBPYFXM5ZoMvW3wAd37EBKHTW8wr8GUY/7F7fLO+tmR2AgoXvUqG1eSMO3Iku8vcYxUlwQWjgUEJtt/4rH/jJTdnBo4FIj8Ckvz9HlwQttQ= ; Message-ID: <20050616001535.66327.qmail@web51609.mail.yahoo.com> Received: from [200.119.73.72] by web51609.mail.yahoo.com via HTTP; Thu, 16 Jun 2005 02:15:35 CEST Date: Thu, 16 Jun 2005 02:15:35 +0200 (CEST) From: To: freebsd-current@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Mailman-Approved-At: Thu, 16 Jun 2005 11:36:49 +0000 Cc: Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfgshield-freebsd@yahoo.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2005 00:15:36 -0000 Hmmm.. http://cvs.opensolaris.org/source/xref/usr/src/cmd/troff/ A quick glance showed this in addition to the CDDL: ... 33 /* 34 * University Copyright- Copyright (c) 1982, 1986, 1988 35 * The Regents of the University of California 36 * All Rights Reserved 37 * 38 * University Acknowledgment- Portions of this document are derived from 39 * software developed by the University of California, Berkeley, and its 40 * contributors. 41 */ ... cheers, Pedro. ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 09:35: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 0FF9616A41C; Thu, 16 Jun 2005 09:35:16 +0000 (GMT) (envelope-from ray@redshift.com) Received: from outgoing.redshift.com (outgoing.redshift.com [207.177.231.8]) by mx1.FreeBSD.org (Postfix) with ESMTP id E7AA443D1F; Thu, 16 Jun 2005 09:35:15 +0000 (GMT) (envelope-from ray@redshift.com) Received: from workstation (216-228-19-21.dsl.redshift.com [216.228.19.21]) by outgoing.redshift.com (Postfix) with SMTP id 492CE970A6; Thu, 16 Jun 2005 02:35:14 -0700 (PDT) Message-Id: <3.0.1.32.20050616023527.00abb700@pop.redshift.com> X-Mailer: na X-Sender: redshift.com Date: Thu, 16 Jun 2005 02:35:27 -0700 To: Marcin Jessa , FreeBSD-net , FreeBSD-Current From: ray@redshift.com In-Reply-To: <20050615114556.6df96e8c.lists@yazzy.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailman-Approved-At: Thu, 16 Jun 2005 11:37:08 +0000 Cc: Subject: Re: Looking for networking solution. 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, 16 Jun 2005 09:35:16 -0000 Marcin, What is it you are trying to accomplish and/or solve here? Switching between UDP and TCP isn't going to have much impact on your problem if it is a function of a lower network layer. In a case where you have a questionable connection, TCP is really what you want, because UDP has a habit of saying "oh, can't get this packet to ya, sorry, see ya later, drop packet". In other words, UDP is more a hope for the best sort of situation, whereas TCP has built in retranmission, error checking, etc. Again, I'm not sure what exactly you are trying to accomplish with this idea? Ray At 11:45 AM 6/15/2005 +0200, Marcin Jessa wrote: | Hi guys. | | I am looking for solution I could implement on a link with a huge latency when ping replies can go up to a few hundred miliseconds, e.g sateliete links. | What I was thinking about is some kind of virtual interface which could translate tcp to udp in one of the pears of the link and push the data it received from a 'normal' interface through the virtual interface without bothering about ack-timing. | The receiving end would have a similar interface which would translate the udp data stream to tcp and then route it out to the internet. | (normal network)tcp<-->virtual udp interface<-------->virtual udp interface<-->tcp(normal network) | | Is there something avaliable on FreeBSD that can be used for that purpose? | Maybe someone is working on such a thing in CURRENT ? | Any thoughts about that? Any sugestions for a solution? | | | Regards, | Marcin Jessa. | | _______________________________________________ | freebsd-net@freebsd.org mailing list | http://lists.freebsd.org/mailman/listinfo/freebsd-net | To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" | | From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 12:10: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 3510216A41C; Thu, 16 Jun 2005 12:10:07 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id E5D9A43D49; Thu, 16 Jun 2005 12:10:06 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 686E360FB; Thu, 16 Jun 2005 14:10:02 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 56BC460FA; Thu, 16 Jun 2005 14:10:02 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 4740933C52; Thu, 16 Jun 2005 14:10:02 +0200 (CEST) To: gnn@freebsd.org References: From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Thu, 16 Jun 2005 14:10:02 +0200 In-Reply-To: (gnn@freebsd.org's message of "Tue, 14 Jun 2005 22:29:26 +0900") Message-ID: <86aclq5wpx.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Learn: ham X-Spam-Score: -5.2/5.0 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tim.des.no Cc: freebsd-current@freebsd.org Subject: Re: Should I be able to run tinderbox as myself? 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, 16 Jun 2005 12:10:07 -0000 gnn@freebsd.org writes: > I'm trying to use the tinderbox script at home to do nightly builds. It's not intended for that kind of use. > I got a successful build but then could not install due to the touch: > not found error which is supposed to be due to clock skew issues. That happens because 'make installworld' can't find the object directory. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 12:28: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 2A26516A41C for ; Thu, 16 Jun 2005 12:28:52 +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 178E943D55 for ; Thu, 16 Jun 2005 12:28:52 +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 1DitUJ-0008zP-Mn; Thu, 16 Jun 2005 12:28:51 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DitUJ-0006me-0X; Thu, 16 Jun 2005 05:28:51 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17073.28802.502964.714076@roam.psg.com> Date: Thu, 16 Jun 2005 13:28:50 +0100 To: FreeBSD Current Subject: kbd goes away on multi 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, 16 Jun 2005 12:28:52 -0000 installing from june snapshot cd on a dell poweredge 2850 1ru rackem-stackem server install was fine boot single user and all is fine go multi and the keyboard does nothing anyone seen this? randy From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 12:31: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 CC68216A41C for ; Thu, 16 Jun 2005 12:31:18 +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 914B043D1D for ; Thu, 16 Jun 2005 12:31:17 +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 j5GCVH4O015834; Thu, 16 Jun 2005 07:31:17 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42B170F6.9080705@centtech.com> Date: Thu, 16 Jun 2005 07:30:46 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050603 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Randy Bush References: <17073.28802.502964.714076@roam.psg.com> In-Reply-To: <17073.28802.502964.714076@roam.psg.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.82/941/Wed Jun 15 13:13:38 2005 on mh1.centtech.com X-Virus-Status: Clean Cc: FreeBSD Current Subject: Re: kbd goes away on multi 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, 16 Jun 2005 12:31:18 -0000 Randy Bush wrote: > installing from june snapshot cd on a dell poweredge 2850 > 1ru rackem-stackem server > > install was fine > boot single user and all is fine > go multi and the keyboard does nothing > > anyone seen this? Are you using a USB keyboard? If so - are you plugged in to the front or back of the rack? 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 Jun 16 12:36: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 8CF0816A41C for ; Thu, 16 Jun 2005 12:36:52 +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 77B6043D1D for ; Thu, 16 Jun 2005 12:36:52 +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 1Ditc4-0009Bl-5Z; Thu, 16 Jun 2005 12:36:52 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1Ditc3-0006nW-Fi; Thu, 16 Jun 2005 05:36:51 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17073.29282.974622.37734@roam.psg.com> Date: Thu, 16 Jun 2005 13:36:50 +0100 To: Eric Anderson References: <17073.28802.502964.714076@roam.psg.com> <42B170F6.9080705@centtech.com> Cc: FreeBSD Current Subject: Re: kbd goes away on multi 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, 16 Jun 2005 12:36:52 -0000 >> installing from june snapshot cd on a dell poweredge 2850 >> 1ru rackem-stackem server >> >> install was fine >> boot single user and all is fine >> go multi and the keyboard does nothing >> >> anyone seen this? > > Are you using a USB keyboard? sorry, should have stated. ps/2 plugged in back randy From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 12:37: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 8878A16A41C for ; Thu, 16 Jun 2005 12:37:26 +0000 (GMT) (envelope-from fmayhar@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id 32EB543D5C for ; Thu, 16 Jun 2005 12:37:26 +0000 (GMT) (envelope-from fmayhar@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so303354nzo for ; Thu, 16 Jun 2005 05:37:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:reply-to:to:cc:in-reply-to:references:content-type:organization:date:message-id:mime-version:x-mailer:content-transfer-encoding:from; b=UnK0YXM+zJJJIxB42q3ssnPcoCVbpIXAyywoZx6mLz9y/r7PNzc8azBnY9o+Bu/GLD+E8bcFHFuA5KkDx9ozZezgIK8l2LuxgIbDQRLjVanjHKww+PsJoecopadch1TbpP1qQM00NPGwfi8zXB9FKUQ22Zn0m82avAQKH6mb+AQ= Received: by 10.36.103.11 with SMTP id a11mr451561nzc; Thu, 16 Jun 2005 05:37:25 -0700 (PDT) Received: from localhost.localdomain ([209.179.146.150]) by mx.gmail.com with ESMTP id 39sm928949nzk.2005.06.16.05.37.21; Thu, 16 Jun 2005 05:37:25 -0700 (PDT) To: Marcin Jessa In-Reply-To: <20050615114556.6df96e8c.lists@yazzy.org> References: <20050615114556.6df96e8c.lists@yazzy.org> Content-Type: text/plain Organization: Exit Consulting Date: Thu, 16 Jun 2005 05:37:18 -0700 Message-Id: <1118925438.91936.2.camel@realtime.exit.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit From: Frank Mayhar Cc: FreeBSD-net , FreeBSD-Current Subject: Re: Looking for networking solution. X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: frank@exit.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2005 12:37:26 -0000 On Wed, 2005-06-15 at 11:45 +0200, Marcin Jessa wrote: > I am looking for solution I could implement on a link with a huge latency when ping replies can go up to a few hundred miliseconds, e.g sateliete links. > What I was thinking about is some kind of virtual interface which could translate tcp to udp in one of the pears of the link and push the data it received from a 'normal' interface through the virtual interface without bothering about ack-timing. > The receiving end would have a similar interface which would translate the udp data stream to tcp and then route it out to the internet. > (normal network)tcp<-->virtual udp interface<-------->virtual udp interface<-->tcp(normal network) > > Is there something avaliable on FreeBSD that can be used for that purpose? > Maybe someone is working on such a thing in CURRENT ? > Any thoughts about that? Any sugestions for a solution? You want SCPS (the Space Communications Protocols Specification) software. Briefly, it fakes local TCP on either end while talking its own protocol over the high-latency link. I don't know if there is any open-source package available but there are certainly commercial solutions out there. -- Frank Mayhar frank@exit.com http://www.exit.com/ Exit Consulting http://www.gpsclock.com/ http://www.exit.com/blog/frank/ From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 12:44: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 CA26B16A41C; Thu, 16 Jun 2005 12:44:06 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from efnet-math.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4769D43D4C; Thu, 16 Jun 2005 12:44:06 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] ([63.170.138.118]) (authenticated bits=0) by efnet-math.org (8.13.1/8.13.1) with ESMTP id j5GChj3e017426 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Thu, 16 Jun 2005 08:43:48 -0400 In-Reply-To: <1118912651.860.17.camel@spirit> References: <1118912651.860.17.camel@spirit> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4A0C62C6-758B-4D54-9583-4B404EDD9643@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Thu, 16 Jun 2005 08:43:28 -0400 To: delphij@delphij.net X-Mailer: Apple Mail (2.730) Cc: jeff@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Recent VFS locking vs kqueue 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, 16 Jun 2005 12:44:06 -0000 Hi On Jun 16, 2005, at 5:04 AM, Xin LI wrote: > Hi, Jeff and -current@, > > With a fresh -CURRENT kernel (today's source) I got the following > messages from console and /var/log/messages on my laptop, with a > "cvs -R > up -PdA 2>/dev/null" running on one console (which results in disk/fs > activities) and "tail -F /var/log/messages" (which uses kqueue > events). > > The kernel is built with ULE scheduler, PREEMPTION+FULL_PREEMPTION > enabled, and all debugging options, like INVARIANTS and WITESS turned > on. > > BTW. I have found something that can lead to panic: Negative nice > count, which indicates that there are some races in our code, but it > seems that the bug is not easy to exercise. Will report more > information/patches once I got some findings. > > Thanks in advance! > > Jun 16 16:44:09 spirit kernel: Acquiring lockmgr lock "ufs" with the > following non-sleepable locks held: > Jun 16 16:44:09 spirit kernel: exclusive sleep mutex kqueue r = 0 > (0xc1b60a00) locked @ /usr/src/sys/kern/kern_event.c:1524 > Jun 16 16:44:09 spirit kernel: exclusive sleep mutex vnode pollinfo > r = > 0 (0xc2074000) locked @ /usr/src/sys/kern/kern_event.c:1512 This has been reported before by Jun Kuriyama.. Unfortunately, I'm a little busy this week, so I've not had time to fix it yet, but hopefully, I'll have something this weekend. In the meantime, you can patch -R this: http://people.freebsd.org/ ~ssouhlal/testing/kqueue-hooks-20050603.diff . Bye. -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 12:47:11 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 BCF7A16A41C; Thu, 16 Jun 2005 12:47:11 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 778B443D58; Thu, 16 Jun 2005 12:47:11 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from 217-13-2-82.dd.nextgentel.com ([217.13.2.82] helo=h311r4z3r) by mail.yazzy.org with esmtps (TLSv1:AES256-SHA:256) (YazzY.org) id 1Ditlh-0007ek-2T; Thu, 16 Jun 2005 14:46:49 +0200 Date: Thu, 16 Jun 2005 14:47:07 +0200 From: Marcin Jessa To: frank@exit.com Message-Id: <20050616144707.18bfa000.lists@yazzy.org> In-Reply-To: <1118925438.91936.2.camel@realtime.exit.com> References: <20050615114556.6df96e8c.lists@yazzy.org> <1118925438.91936.2.camel@realtime.exit.com> Organization: YazzY.org X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: -2.6 (--) Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: Looking for networking solution. 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, 16 Jun 2005 12:47:11 -0000 On Thu, 16 Jun 2005 05:37:18 -0700 Frank Mayhar wrote: > On Wed, 2005-06-15 at 11:45 +0200, Marcin Jessa wrote: > > I am looking for solution I could implement on a link with a huge latency when ping replies can go up to a few hundred miliseconds, e.g sateliete links. > > What I was thinking about is some kind of virtual interface which could translate tcp to udp in one of the pears of the link and push the data it received from a 'normal' interface through the virtual interface without bothering about ack-timing. > > The receiving end would have a similar interface which would translate the udp data stream to tcp and then route it out to the internet. > > (normal network)tcp<-->virtual udp interface<-------->virtual udp interface<-->tcp(normal network) > > > > Is there something avaliable on FreeBSD that can be used for that purpose? > > Maybe someone is working on such a thing in CURRENT ? > > Any thoughts about that? Any sugestions for a solution? > > You want SCPS (the Space Communications Protocols Specification) > software. Briefly, it fakes local TCP on either end while talking its > own protocol over the high-latency link. I don't know if there is any > open-source package available but there are certainly commercial > solutions out there. > -- Correct. That's why I asked about this problem here. I was in doubt something like that existed for FreeBSD. We are willing to pay someone to develop such a solution for FreeBSD. I'd love to get in touch with someone willing to pick up that challenge. From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 12:47: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 71C7D16A47D; Thu, 16 Jun 2005 12:47:26 +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 C872243D4C; Thu, 16 Jun 2005 12:47:25 +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.13.4/8.13.4) with ESMTP id j5GClFtb071820; Thu, 16 Jun 2005 22:17:16 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Thu, 16 Jun 2005 22:17:00 +0930 User-Agent: KMail/1.8 References: <20050616133236.4a83eb19.lists@yazzy.org> In-Reply-To: <20050616133236.4a83eb19.lists@yazzy.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3768465.xFCpGYUCbO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506162217.10514.doconnor@gsoft.com.au> X-Spam-Score: -2.4 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: damien.bergamini@free.fr, Marcin Jessa , FreeBSD-Current , FreeBSD-mobile Subject: Re: Intel firmware 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, 16 Jun 2005 12:47:26 -0000 --nextPart3768465.xFCpGYUCbO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 16 Jun 2005 21:02, Marcin Jessa wrote: > Trying to compile firmware for iwi driver i get following errors: That is the driver, not the firmware. > [root@h311r4z3r:/home/yazzy/iwi-freebsd-1.3.4]# make Current has changed network driver structures a bit (just recently), so thi= s=20 driver not compiling is not very suprising.. Also, the iwi driver is in -current - kldload if_iwi There is a port for the ipw firmware but not for the iwi that I can see so = I'm=20 not sure what the deal is there - maybe it doesn't need it uploaded like ip= w=20 does. =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 --nextPart3768465.xFCpGYUCbO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCsXTO5ZPcIHs/zowRApj/AJ0YBkBoMPOIQGIC6DDVxN19eijWUQCeMzDw 9LL4ExyFVKKss+lGShBUaYY= =2qw+ -----END PGP SIGNATURE----- --nextPart3768465.xFCpGYUCbO-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 12:47: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 71C7D16A47D; Thu, 16 Jun 2005 12:47:26 +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 C872243D4C; Thu, 16 Jun 2005 12:47:25 +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.13.4/8.13.4) with ESMTP id j5GClFtb071820; Thu, 16 Jun 2005 22:17:16 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Thu, 16 Jun 2005 22:17:00 +0930 User-Agent: KMail/1.8 References: <20050616133236.4a83eb19.lists@yazzy.org> In-Reply-To: <20050616133236.4a83eb19.lists@yazzy.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3768465.xFCpGYUCbO"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506162217.10514.doconnor@gsoft.com.au> X-Spam-Score: -2.4 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: damien.bergamini@free.fr, Marcin Jessa , FreeBSD-Current , FreeBSD-mobile Subject: Re: Intel firmware 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, 16 Jun 2005 12:47:26 -0000 --nextPart3768465.xFCpGYUCbO Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thu, 16 Jun 2005 21:02, Marcin Jessa wrote: > Trying to compile firmware for iwi driver i get following errors: That is the driver, not the firmware. > [root@h311r4z3r:/home/yazzy/iwi-freebsd-1.3.4]# make Current has changed network driver structures a bit (just recently), so thi= s=20 driver not compiling is not very suprising.. Also, the iwi driver is in -current - kldload if_iwi There is a port for the ipw firmware but not for the iwi that I can see so = I'm=20 not sure what the deal is there - maybe it doesn't need it uploaded like ip= w=20 does. =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 --nextPart3768465.xFCpGYUCbO Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCsXTO5ZPcIHs/zowRApj/AJ0YBkBoMPOIQGIC6DDVxN19eijWUQCeMzDw 9LL4ExyFVKKss+lGShBUaYY= =2qw+ -----END PGP SIGNATURE----- --nextPart3768465.xFCpGYUCbO-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 12:56: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 0557616A41C for ; Thu, 16 Jun 2005 12:56:49 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from mail.hamnpolare.net (manticore.shapeshifter.se [212.37.5.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 850C343D4C for ; Thu, 16 Jun 2005 12:56:46 +0000 (GMT) (envelope-from fli+freebsd-current@shapeshifter.se) Received: from localhost (localhost [127.0.0.1]) by mail.hamnpolare.net (Postfix) with ESMTP id B4E4B1A6F0 for ; Thu, 16 Jun 2005 14:56:41 +0200 (CEST) Received: from mail.hamnpolare.net ([127.0.0.1]) by localhost (manticore.shapeshifter.se [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07753-09 for ; Thu, 16 Jun 2005 14:56:40 +0200 (CEST) Received: from biocandy.shapeshifter.se (h99n2fls32o270.telia.com [217.210.25.99]) by mail.hamnpolare.net (Postfix) with ESMTP id 6EA871A6D5 for ; Thu, 16 Jun 2005 14:56:40 +0200 (CEST) Received: by biocandy.shapeshifter.se (Postfix, from userid 1001) id DC3834197; Thu, 16 Jun 2005 14:56:39 +0200 (CEST) Date: Thu, 16 Jun 2005 14:56:39 +0200 From: Fredrik Lindberg To: freebsd-current@freebsd.org Message-ID: <20050616125639.GA1419@shapeshifter.se> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-Virus-Scanned: at mail.hamnpolare.net Subject: Slight problem with ndisgen and ndiscvt 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, 16 Jun 2005 12:56:49 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi There is a slight problem with ndisgen and ndiscvt when the filename of the .sys-file starts with a number (such as 3C154G72.sys). The produced header file contains variable declarations which starts with a number, such as extern unsigned char 3C154G72_sys_drv_data_start[] which results in several "syntax error before numeric constant" during compilation. While this can be solved simply by renaming the .sys-file, that solution might not be obvious to ordinary users. Here is a small patch which adds a "ndis_" prefix to drv_data_start and related variables. This will allow filesnames which starts with a number. Maybe even more care should be taken to make sure there are no spaces or other "strange" characters in the name. Fredrik Lindberg --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ndisgen-numeric-sysfile.patch" diff -cr --exclude=CVS ndiscvt.old/ndiscvt.c ndiscvt/ndiscvt.c *** ndiscvt.old/ndiscvt.c Thu Jun 16 14:45:38 2005 --- ndiscvt/ndiscvt.c Mon Jun 13 19:07:26 2005 *************** *** 207,215 **** } snprintf(sysbuf, sizeof(sysbuf), ! "objcopy --redefine-sym _binary_%s_start=%s_drv_data_start " "--strip-symbol _binary_%s_size " ! "--redefine-sym _binary_%s_end=%s_drv_data_end %s.o %s.o\n", tname, sysfile, tname, tname, sysfile, outfile, outfile); printf("%s", sysbuf); system(sysbuf); --- 207,215 ---- } snprintf(sysbuf, sizeof(sysbuf), ! "objcopy --redefine-sym _binary_%s_start=ndis_%s_drv_data_start " "--strip-symbol _binary_%s_size " ! "--redefine-sym _binary_%s_end=ndis_%s_drv_data_end %s.o %s.o\n", tname, sysfile, tname, tname, sysfile, outfile, outfile); printf("%s", sysbuf); system(sysbuf); *************** *** 384,393 **** ptr++; } fprintf(outfp, ! "\nextern unsigned char %s_drv_data_start[];\n", sysfile); fprintf(outfp, "static unsigned char *drv_data = " ! "%s_drv_data_start;\n\n", sysfile); bincvt(sysfile, outfile, img, fsize); goto done; } --- 384,393 ---- ptr++; } fprintf(outfp, ! "\nextern unsigned char ndis_%s_drv_data_start[];\n", sysfile); fprintf(outfp, "static unsigned char *drv_data = " ! "ndis_%s_drv_data_start;\n\n", sysfile); bincvt(sysfile, outfile, img, fsize); goto done; } diff -cr --exclude=CVS ndiscvt.old/ndisgen.sh ndiscvt/ndisgen.sh *** ndiscvt.old/ndisgen.sh Thu Jun 16 14:45:38 2005 --- ndiscvt/ndisgen.sh Mon Jun 13 20:45:37 2005 *************** *** 393,399 **** touch bus_if.h touch device_if.h echo -n " Compiling stub... " ! if ! ${CC} -D_KERNEL -DDRV_DATA_START=${SYSBASE}_drv_data_start -DDRV_NAME=${SYSBASE} -DDRV_DATA_END=${SYSBASE}_drv_data_end -I. ${STUBFILE} -c -o windrv_stub.o; then echo "compilation failed. Exiting." echo "" exit --- 393,399 ---- touch bus_if.h touch device_if.h echo -n " Compiling stub... " ! if ! ${CC} -D_KERNEL -DDRV_DATA_START=ndis_${SYSBASE}_drv_data_start -DDRV_NAME=ndis_${SYSBASE} -DDRV_DATA_END=ndis_${SYSBASE}_drv_data_end -I. ${STUBFILE} -c -o windrv_stub.o; then echo "compilation failed. Exiting." echo "" exit --r5Pyd7+fXNt84Ff3-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 13:59: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 0748316A41F; Thu, 16 Jun 2005 13:59:48 +0000 (GMT) (envelope-from sepotvin@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 99BA243D53; Thu, 16 Jun 2005 13:59:47 +0000 (GMT) (envelope-from sepotvin@videotron.ca) Received: from [10.0.0.147] ([67.70.237.74]) by VL-MO-MR001.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0II600KMGK3A6L@VL-MO-MR001.ip.videotron.ca>; Thu, 16 Jun 2005 09:57:12 -0400 (EDT) Date: Thu, 16 Jun 2005 09:57:10 -0400 From: "Stephane E. Potvin" To: Robert Watson , freebsd-current@FreeBSD.org Message-id: <42B18536.3080200@videotron.ca> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_Q71htTUolz6xzV2gSfBqGg)" X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330) X-Enigmail-Version: 0.91.0.0 Cc: Subject: Reboot while booting with new per-CPU allocator 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, 16 Jun 2005 13:59:48 -0000 This is a multi-part message in MIME format. --Boundary_(ID_Q71htTUolz6xzV2gSfBqGg) Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Starting with the commit of the new per-CPU allocator, rwatson 2005-05-29 13:38:07 UTC FreeBSD src repository Modified files: sys/sys malloc.h sys/kern kern_malloc.c Log: Kernel malloc layers malloc_type allocation over one of two underlying allocators: a set of power-of-two UMA zones for small allocations, and the ... modifications to vmstat in order to restore "vmstat -m" on core dumps will follow shortly. Several improvements from: bde Statistics approach discussed with: ups Tested by: scottl, others Revision Changes Path 1.140 +159 -130 src/sys/kern/kern_malloc.c 1.79 +72 -16 src/sys/sys/malloc.h I get spontaneous reboots while the kernel is loading after the kernel finds the APICs while booting verbose: 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 #4: Wed Jun 15 14:12:26 EDT 2005 spotvin@homer.telcobridges.com:/usr/obj/usr/src/sys/HOMER Preloaded elf kernel "/boot/kernel.working/kernel" at 0xc08cf000. Preloaded elf module "/boot/kernel.working/vesa.ko" at 0xc08cf1b0. Preloaded elf module "/boot/kernel.working/cd9660.ko" at 0xc08cf264. Preloaded elf module "/boot/kernel.working/g_md.ko" at 0xc08cf318. Preloaded elf module "/boot/kernel.working/if_bge.ko" at 0xc08cf3cc. Preloaded elf module "/boot/kernel.working/miibus.ko" at 0xc08cf480. Preloaded elf module "/boot/kernel.working/snd_ich.ko" at 0xc08cf534. Preloaded elf module "/boot/kernel.working/sound.ko" at 0xc08cf5e8. Preloaded elf module "/boot/kernel.working/usb.ko" at 0xc08cf69c. Preloaded elf module "/boot/kernel.working/ugen.ko" at 0xc08cf74c. Preloaded elf module "/boot/kernel.working/ukbd.ko" at 0xc08cf800. Preloaded elf module "/boot/kernel.working/ums.ko" at 0xc08cf8b4. Preloaded elf module "/boot/kernel.working/umass.ko" at 0xc08cf964. Preloaded elf module "/boot/kernel.working/agp.ko" at 0xc08cfa18. Preloaded elf module "/boot/kernel.working/acpi_video.ko" at 0xc08cfac8. Preloaded elf module "/boot/kernel.working/acpi.ko" at 0xc08cfb80. Preloaded elf module "/boot/kernel.working/if_ndis.ko" at 0xc08cfc34. Preloaded elf module "/boot/kernel.working/pccard.ko" at 0xc08cfce8. Preloaded elf module "/boot/kernel.working/ndis.ko" at 0xc08cfd9c. Preloaded elf module "/boot/kernel.working/radeon.ko" at 0xc08cfe50. Preloaded elf module "/boot/kernel.working/drm.ko" at 0xc08cff04. Preloaded elf module "/boot/kernel.working/sysvshm.ko" at 0xc08cffb4. Preloaded elf module "/boot/kernel.working/sysvsem.ko" at 0xc08d0068. Preloaded elf module "/boot/kernel.working/sysvmsg.ko" at 0xc08d011c. Preloaded elf module "/boot/kernel.working/ucom.ko" at 0xc08d01d0. Preloaded elf module "/boot/kernel.working/uplcom.ko" at 0xc08d0284. Preloaded elf module "/boot/kernel.working/firewire.ko" at 0xc08d0338. Preloaded elf module "/boot/kernel.working/exca.ko" at 0xc08d03f0. Preloaded elf module "/boot/kernel.working/cbb.ko" at 0xc08d04a4. Preloaded elf module "/boot/kernel.working/cardbus.ko" at 0xc08d0554. Preloaded elf module "/boot/kernel.working/io.ko" at 0xc08d0608. Preloaded elf module "/boot/kernel.working/ichwd.ko" at 0xc08d06b8. Preloaded elf module "/boot/kernel.working/cpufreq.ko" at 0xc08d076c. Preloaded elf module "/boot/kernel.working/geom_bde.ko" at 0xc08d0820. Table 'FACP' at 0x3fff0400 Table 'APIC' at 0x3fff0c00 MADT: Found table at 0x3fff0c00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: disabled <<>> I'm attaching the verbose dmesg output from a successfull kernel boot. I understand that I've not given that much information so if anybody needs more information to help debug this problem I'll be glad to oblige if possible. Steph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCsYU2mdOXtTCX/nsRAv5GAJ9gADBob0qm/LzpVS3SvcjpfSNHuQCcDM+d SfRJwIDDXVeY6Za4e9P6u64= =uYbl -----END PGP SIGNATURE----- --Boundary_(ID_Q71htTUolz6xzV2gSfBqGg) Content-type: text/plain; name=dmesg.out; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Content-disposition: inline; filename=dmesg.out 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 #5: Wed Jun 15 14:50:21 EDT 2005 spotvin@homer.telcobridges.com:/usr/obj/usr/src/sys/HOMER Preloaded elf kernel "/boot/kernel.working/kernel" at 0xc08cf000. Preloaded elf module "/boot/kernel.working/vesa.ko" at 0xc08cf1b0. Preloaded elf module "/boot/kernel.working/cd9660.ko" at 0xc08cf264. Preloaded elf module "/boot/kernel.working/g_md.ko" at 0xc08cf318. Preloaded elf module "/boot/kernel.working/if_bge.ko" at 0xc08cf3cc. Preloaded elf module "/boot/kernel.working/miibus.ko" at 0xc08cf480. Preloaded elf module "/boot/kernel.working/snd_ich.ko" at 0xc08cf534. Preloaded elf module "/boot/kernel.working/sound.ko" at 0xc08cf5e8. Preloaded elf module "/boot/kernel.working/usb.ko" at 0xc08cf69c. Preloaded elf module "/boot/kernel.working/ugen.ko" at 0xc08cf74c. Preloaded elf module "/boot/kernel.working/ukbd.ko" at 0xc08cf800. Preloaded elf module "/boot/kernel.working/ums.ko" at 0xc08cf8b4. Preloaded elf module "/boot/kernel.working/umass.ko" at 0xc08cf964. Preloaded elf module "/boot/kernel.working/agp.ko" at 0xc08cfa18. Preloaded elf module "/boot/kernel.working/acpi_video.ko" at 0xc08cfac8. Preloaded elf module "/boot/kernel.working/acpi.ko" at 0xc08cfb80. Preloaded elf module "/boot/kernel.working/if_ndis.ko" at 0xc08cfc34. Preloaded elf module "/boot/kernel.working/pccard.ko" at 0xc08cfce8. Preloaded elf module "/boot/kernel.working/ndis.ko" at 0xc08cfd9c. Preloaded elf module "/boot/kernel.working/radeon.ko" at 0xc08cfe50. Preloaded elf module "/boot/kernel.working/drm.ko" at 0xc08cff04. Preloaded elf module "/boot/kernel.working/sysvshm.ko" at 0xc08cffb4. Preloaded elf module "/boot/kernel.working/sysvsem.ko" at 0xc08d0068. Preloaded elf module "/boot/kernel.working/sysvmsg.ko" at 0xc08d011c. Preloaded elf module "/boot/kernel.working/ucom.ko" at 0xc08d01d0. Preloaded elf module "/boot/kernel.working/uplcom.ko" at 0xc08d0284. Preloaded elf module "/boot/kernel.working/firewire.ko" at 0xc08d0338. Preloaded elf module "/boot/kernel.working/exca.ko" at 0xc08d03f0. Preloaded elf module "/boot/kernel.working/cbb.ko" at 0xc08d04a4. Preloaded elf module "/boot/kernel.working/cardbus.ko" at 0xc08d0554. Preloaded elf module "/boot/kernel.working/io.ko" at 0xc08d0608. Preloaded elf module "/boot/kernel.working/ichwd.ko" at 0xc08d06b8. Preloaded elf module "/boot/kernel.working/cpufreq.ko" at 0xc08d076c. Preloaded elf module "/boot/kernel.working/geom_bde.ko" at 0xc08d0820. Table 'FACP' at 0x3fff0400 Table 'APIC' at 0x3fff0c00 MADT: Found table at 0x3fff0c00 APIC: Using the MADT enumerator. MADT: Found CPU APIC ID 0 ACPI ID 0: enabled SMP: Added CPU 0 (AP) MADT: Found CPU APIC ID 1 ACPI ID 1: disabled ACPI APIC Table: Calibrating clock(s) ... i8254 clock: 1193232 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz quality 0 Calibrating TSC clock ... TSC clock: 3391518640 Hz CPU: Intel(R) Pentium(R) 4 CPU 3.40GHz (3391.52-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf25 Stepping = 5 Features=0xbfebfbff Features2=0x4400> Hyperthreading: 2 logical CPUs real memory = 1073389568 (1023 MB) Physical memory chunk(s): 0x0000000000001000 - 0x000000000009dfff, 643072 bytes (157 pages) 0x0000000000100000 - 0x00000000003fffff, 3145728 bytes (768 pages) 0x0000000000c28000 - 0x000000003ed72fff, 1041543168 bytes (254283 pages) avail memory = 1041428480 (993 MB) APIC: CPU 0 has ACPI ID 0 bios32: Found BIOS32 Service Directory header at 0xc00ffe80 bios32: Entry = 0xffe90 (c00ffe90) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf0000+0xcc7e pnpbios: Found PnP BIOS data at 0xc00fe2d0 pnpbios: Entry = f0000:e2f4 Rev = 1.0 pnpbios: Event flag at 4b4 Other BIOS signatures found: MADT: Found IO APIC ID 1, Interrupt 0 at 0xfec00000 ioapic0: Changing APIC ID to 1 ioapic0: Routing external 8259A's -> intpin 0 ioapic0: intpin 0 -> ExtINT (edge, high) ioapic0: intpin 1 -> ISA IRQ 1 (edge, high) ioapic0: intpin 2 -> ISA IRQ 2 (edge, high) ioapic0: intpin 3 -> ISA IRQ 3 (edge, high) ioapic0: intpin 4 -> ISA IRQ 4 (edge, high) ioapic0: intpin 5 -> ISA IRQ 5 (edge, high) ioapic0: intpin 6 -> ISA IRQ 6 (edge, high) ioapic0: intpin 7 -> ISA IRQ 7 (edge, high) ioapic0: intpin 8 -> ISA IRQ 8 (edge, high) ioapic0: intpin 9 -> ISA IRQ 9 (edge, high) ioapic0: intpin 10 -> ISA IRQ 10 (edge, high) ioapic0: intpin 11 -> ISA IRQ 11 (edge, high) ioapic0: intpin 12 -> ISA IRQ 12 (edge, high) ioapic0: intpin 13 -> ISA IRQ 13 (edge, high) ioapic0: intpin 14 -> ISA IRQ 14 (edge, high) ioapic0: intpin 15 -> ISA IRQ 15 (edge, high) ioapic0: intpin 16 -> PCI IRQ 16 (level, low) ioapic0: intpin 17 -> PCI IRQ 17 (level, low) ioapic0: intpin 18 -> PCI IRQ 18 (level, low) ioapic0: intpin 19 -> PCI IRQ 19 (level, low) ioapic0: intpin 20 -> PCI IRQ 20 (level, low) ioapic0: intpin 21 -> PCI IRQ 21 (level, low) ioapic0: intpin 22 -> PCI IRQ 22 (level, low) ioapic0: intpin 23 -> PCI IRQ 23 (level, low) MADT: Interrupt override: source 0, irq 2 ioapic0: Routing IRQ 0 -> intpin 2 ioapic0: intpin 2 trigger: edge ioapic0: intpin 2 polarity: high MADT: Interrupt override: source 9, irq 9 ioapic0: intpin 9 trigger: level ioapic0: intpin 9 polarity: high lapic0: Routing NMI -> LINT1 lapic0: LINT1 trigger: edge lapic0: LINT1 polarity: high MADT: Ignoring local NMI routed to ACPI CPU 1 ioapic0 irqs 0-23 on motherboard cpu0 BSP: ID: 0x00000000 VER: 0x00050014 LDR: 0x01000000 DFR: 0x0fffffff lint0: 0x00010700 lint1: 0x00000400 TPR: 0x00000000 SVR: 0x000001ff timer: 0x000100ef therm: 0x00010000 err: 0x00010000 pcm: 0x00010000 wlan: <802.11 Link Layer> VESA: information block 56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 00 01 ff 07 00 01 1c 01 00 01 32 01 00 01 37 01 00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 VESA: 60 mode(s) found VESA: v2.0, 131008k memory, flags:0x1, mode table:0xc07036c2 (1000022) VESA: ATI MOBILITY RADEON 9700 VESA: ATI Technologies Inc. P11 01.00 null: random: mem: Pentium Pro MTRR support enabled io:
ichwd module loaded acpi0: on motherboard acpi0: [MPSAFE] pci_open(1): mode 1 addr port (0x0cf8) is 0x80010014 pci_open(1a): mode1res=0x80000000 (0x80000000) pci_cfgcheck: device 0 [class=060000] [hdr=00] is there (id=25708086) pcibios: BIOS version 2.10 Found $PIR table, 9 entries at 0xc00fc890 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded 0 29 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 29 D 0x6b 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 B 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 C 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 0 30 D 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 0 31 A 0x62 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 1 0 A 0x60 3 4 5 6 7 9 10 11 12 14 15 embedded 2 0 A 0x62 3 4 5 6 7 9 10 11 12 14 15 embedded 2 1 A 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 2 1 B 0x63 none embedded 2 3 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 2 3 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 8 0 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 8 0 B 0x63 3 4 5 6 7 9 10 11 12 14 15 embedded 8 1 A 0x61 3 4 5 6 7 9 10 11 12 14 15 embedded 8 1 B 0x63 3 4 5 6 7 9 10 11 12 14 15 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 acpi_bus_number: root bus has no _BBN, assuming 0 AcpiOsDerivePciId: bus 0 dev 31 func 0 pci_link0: irq 11 on acpi0 pci_link0: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 9 10 11 pci_link0: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 9 10 11 pci_link0: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 9 10 11 pci_link1: irq 11 on acpi0 pci_link1: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 5 7 pci_link1: Links after initial validation: Index IRQ Rtd Ref IRQs 0 255 N 0 5 7 pci_link1: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 5 7 pci_link2: irq 11 on acpi0 pci_link2: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 9 10 11 pci_link2: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 9 10 11 pci_link2: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 9 10 11 pci_link3: irq 11 on acpi0 pci_link3: Links after initial probe: Index IRQ Rtd Ref IRQs 0 11 N 0 5 7 9 10 11 pci_link3: Links after initial validation: Index IRQ Rtd Ref IRQs 0 11 N 0 5 7 9 10 11 pci_link3: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 5 7 9 10 11 pci_link4: 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 11 on acpi0 pci_link5: 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_link5: 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_link5: Links after disable: Index IRQ Rtd Ref IRQs 0 255 N 0 3 4 5 6 7 9 10 11 12 14 15 ACPI timer: 1/1 1/1 1/0 1/1 1/1 1/1 1/0 1/0 1/0 1/1 -> 10 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 cpu0: on acpi0 p4tcc0: on cpu0 acpi_acad0: on acpi0 acpi_cmbat0: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pci0: physical bus=0 found-> vendor=0x8086, dev=0x2570, 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 e8000000, size 27, enabled found-> vendor=0x8086, dev=0x2571, 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=0x0c (3000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24d2, revid=0x02 bus=0, slot=29, func=0 class=0c-03-00, hdrtype=0x00, mfdev=1 cmdreg=0x0005, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 map[20]: type 4, range 32, base 0000bf80, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x24d4, revid=0x02 bus=0, slot=29, func=1 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=b, irq=11 map[20]: type 4, range 32, base 0000bf60, size 5, enabled pcib0: matched entry for 0.29.INTB pcib0: slot 29 INTB hardwired to IRQ 19 found-> vendor=0x8086, dev=0x24d7, revid=0x02 bus=0, slot=29, 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=c, irq=11 map[20]: type 4, range 32, base 0000bf40, size 5, enabled pcib0: matched entry for 0.29.INTC pcib0: slot 29 INTC hardwired to IRQ 18 found-> vendor=0x8086, dev=0x24de, revid=0x02 bus=0, slot=29, func=3 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=a, irq=11 map[20]: type 4, range 32, base 0000bf20, size 5, enabled pcib0: matched entry for 0.29.INTA pcib0: slot 29 INTA hardwired to IRQ 16 found-> vendor=0x8086, dev=0x24dd, revid=0x02 bus=0, slot=29, func=7 class=0c-03-20, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=d, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 1, range 32, base f8fffc00, size 10, enabled pcib0: matched entry for 0.29.INTD pcib0: slot 29 INTD hardwired to IRQ 23 found-> vendor=0x8086, dev=0x244e, revid=0xc2 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=0x04 (1000 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24d0, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x010f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found-> vendor=0x8086, dev=0x24db, revid=0x02 bus=0, slot=31, func=1 class=01-01-8a, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0288, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=255 map[20]: type 4, range 32, base 0000bfa0, size 4, enabled map[24]: type 1, range 32, base 00000000, size 10, memory disabled found-> vendor=0x8086, dev=0x24d5, revid=0x02 bus=0, slot=31, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 cmdreg=0x0007, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000d800, size 8, enabled map[14]: type 4, range 32, base 0000dc40, size 6, enabled map[18]: type 1, range 32, base f8fff800, size 9, enabled map[1c]: type 1, range 32, base f8fff400, size 8, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 found-> vendor=0x8086, dev=0x24d6, revid=0x02 bus=0, slot=31, func=6 class=07-03-00, hdrtype=0x00, mfdev=0 cmdreg=0x0005, statreg=0x0290, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=b, irq=11 powerspec 2 supports D0 D3 current D0 map[10]: type 4, range 32, base 0000d400, size 8, enabled map[14]: type 4, range 32, base 0000d080, size 7, enabled pcib0: matched entry for 0.31.INTB pcib0: slot 31 INTB hardwired to IRQ 17 agp0: mem 0xe8000000-0xefffffff at device 0.0 on pci0 agp0: Reserved 0x8000000 bytes for rid 0x10 type 3 at 0xe8000000 agp0: allocating GATT for aperture of size 128M pcib1: at device 1.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode 0xc000-0xcfff pcib1: memory decode 0xfc000000-0xfdffffff pcib1: prefetched decode 0xf0000000-0xf7ffffff pci1: on pcib1 pci1: physical bus=1 found-> vendor=0x1002, dev=0x4e50, revid=0x00 bus=1, slot=0, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0127, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x08 (2000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 3, range 32, base f0000000, size 27, enabled pcib1: (null) requested memory range 0xf0000000-0xf7ffffff: good map[14]: type 4, range 32, base 0000c000, size 8, enabled pcib1: (null) requested I/O range 0xc000-0xc0ff: in range map[18]: type 1, range 32, base fcff0000, size 16, enabled pcib1: (null) requested memory range 0xfcff0000-0xfcffffff: good pcib1: matched entry for 1.0.INTA pcib1: slot 0 INTA hardwired to IRQ 16 acpi_video0: port 0xc000-0xc0ff mem 0xf0000000-0xf7ffffff,0xfcff0000-0xfcffffff irq 16 at device 0.0 on pci1 found TV(200), detectable by BIOS, head #0 found CRT monitor(100), detectable by BIOS, head #0 found unknown output(120), detectable by BIOS, head #0 found LCD panel(110), detectable by BIOS, head #0 found unknown output(210), detectable by BIOS, head #0 uhci0: port 0xbf80-0xbf9f irq 16 at device 29.0 on pci0 uhci0: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbf80 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 uhci1: port 0xbf60-0xbf7f irq 19 at device 29.1 on pci0 uhci1: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbf60 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 uhci2: port 0xbf40-0xbf5f irq 18 at device 29.2 on pci0 uhci2: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbf40 uhci2: [GIANT-LOCKED] usb2: on uhci2 usb2: USB revision 1.0 uhub2: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub2: 2 ports with 2 removable, self powered uhci3: port 0xbf20-0xbf3f irq 16 at device 29.3 on pci0 uhci3: Reserved 0x20 bytes for rid 0x20 type 4 at 0xbf20 uhci3: [GIANT-LOCKED] usb3: on uhci3 usb3: USB revision 1.0 uhub3: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub3: 2 ports with 2 removable, self powered ehci0: mem 0xf8fffc00-0xf8ffffff irq 23 at device 29.7 on pci0 ehci0: Reserved 0x400 bytes for rid 0x10 type 3 at 0xf8fffc00 ehci0: [GIANT-LOCKED] usb4: EHCI version 1.0 usb4: companion controllers, 2 ports each: usb0 usb1 usb2 usb3 usb4: on ehci0 usb4: USB revision 2.0 uhub4: Intel EHCI root hub, class 9/0, rev 2.00/1.00, addr 1 uhub4: 8 ports with 8 removable, self powered pcib2: at device 30.0 on pci0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode 0xe000-0xefff pcib2: memory decode 0xfa000000-0xfbffffff pcib2: prefetched decode 0xfff00000-0xfffff pcib2: Subtractively decoded bridge. pci2: on pcib2 pci2: physical bus=2 found-> vendor=0x14e4, dev=0x165d, revid=0x01 bus=2, slot=0, func=0 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0116, statreg=0x02b0, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D3 current D0 MSI supports 8 messages, 64 bit map[10]: type 1, range 64, base faff0000, size 16, enabled pcib2: (null) requested memory range 0xfaff0000-0xfaffffff: good pcib2: matched entry for 2.0.INTA pcib2: slot 0 INTA hardwired to IRQ 18 found-> vendor=0x104c, dev=0xac44, revid=0x02 bus=2, slot=1, func=0 class=06-07-00, hdrtype=0x02, mfdev=1 cmdreg=0x0000, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x07 (1750 ns) intpin=a, irq=255 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base 00000000, size 12, memory disabled found-> vendor=0x104c, dev=0x8029, revid=0x00 bus=2, slot=1, func=1 class=0c-00-10, hdrtype=0x00, mfdev=1 cmdreg=0x0116, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0x20 (960 ns), mingnt=0x02 (500 ns), maxlat=0x04 (1000 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base fafef800, size 11, enabled pcib2: (null) requested memory range 0xfafef800-0xfafeffff: good map[14]: type 1, range 32, base fafe8000, size 14, enabled pcib2: (null) requested memory range 0xfafe8000-0xfafebfff: good pcib2: matched entry for 2.1.INTA pcib2: slot 1 INTA hardwired to IRQ 19 found-> vendor=0x14e4, dev=0x4324, revid=0x02 bus=2, slot=3, func=0 class=02-80-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x0010, cachelnsz=0 (dwords) lattimer=0x20 (960 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) intpin=a, irq=11 powerspec 2 supports D0 D1 D2 D3 current D0 map[10]: type 1, range 32, base fafec000, size 13, enabled pcib2: (null) requested memory range 0xfafec000-0xfafedfff: good pcib2: matched entry for 2.3.INTA pcib2: slot 3 INTA hardwired to IRQ 17 bge0: mem 0xfaff0000-0xfaffffff irq 18 at device 0.0 on pci2 bge0: Reserved 0x10000 bytes for rid 0x10 type 3 at 0xfaff0000 miibus0: on bge0 brgphy0: on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseTX, 1000baseTX-FDX, auto bge0: bpf attached bge0: Ethernet address: 00:0f:1f:0c:0e:60 bge0: [MPSAFE] cbb0: at device 1.0 on pci2 pcib2: cbb0 requested memory range 0xfa000000-0xfbffffff: good cbb0: Lazy allocation of 0x1000 bytes rid 0x10 type 3 at 0xfa000000 cardbus0: on cbb0 pccard0: <16-bit PCCard bus> on cbb0 pcib2: matched entry for 2.1.INTA pcib2: slot 1 INTA hardwired to IRQ 19 cbb0: [MPSAFE] cbb0: PCI Configuration space: 0x00: 0xac44104c 0x02100007 0x06070002 0x00822008 0x10: 0xfa000000 0x020000a0 0x20040302 0xfffff000 0x20: 0x00000000 0xfffff000 0x00000000 0xfffffffc 0x30: 0x00000000 0xfffffffc 0x00000000 0x07400113 0x40: 0x017c1028 0x00000001 0x00000000 0x00000000 0x50: 0x00000000 0x00000000 0x00000000 0x00000000 0x60: 0x00000000 0x00000000 0x00000000 0x00000000 0x70: 0x00000000 0x00000000 0x00000000 0x00000000 0x80: 0x28405061 0x00000000 0x001f0000 0x012c1202 0x90: 0x606482c0 0x00000000 0x00000000 0x00000000 0xa0: 0xfe120001 0x00c00000 0x00000000 0x00000000 0xb0: 0x00000000 0x00000000 0x00000000 0x00000000 0xc0: 0x00000000 0x00000000 0x00000000 0x00000000 0xd0: 0x00000000 0x00000000 0x00000000 0x00000000 0xe0: 0x00000000 0x00000000 0x00000000 0x00000000 0xf0: 0x00000000 0x00000000 0x00000000 0x00000000 fwohci0: vendor=104c, dev=8029 fwohci0: vendor=104c, dev=8029 fwohci0: <1394 Open Host Controller Interface> mem 0xfafef800-0xfafeffff,0xfafe8000-0xfafebfff irq 19 at device 1.1 on pci2 fwohci0: Reserved 0x800 bytes for rid 0x10 type 3 at 0xfafef800 fwohci0: [MPSAFE] fwohci0: OHCI version 1.10 (ROM=0) fwohci0: No. of Isochronous channels is 4. fwohci0: EUI64 48:4f:c0:00:30:c5:d4:81 fwohci0: Phy 1394a available S400, 2 ports. fwohci0: Link S400, max_rec 2048 bytes. firewire0: on fwohci0 fwohci0: Initiate bus reset fwohci0: node_id=0xc800ffc0, gen=1, CYCLEMASTER mode firewire0: 1 nodes, maxhop <= 0, cable IRM = 0 (me) firewire0: bus manager 0 (me) pci2: at device 3.0 (no driver attached) pci2:3:0: Transition from D0 to D3 isab0: at device 31.0 on pci0 isa0: on isab0 atapci0: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xbfa0-0xbfaf at device 31.1 on pci0 atapci0: Reserved 0x10 bytes for rid 0x20 type 4 at 0xbfa0 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=0x04 lsb=0x00 msb=0x00 ata1: reset tp2 stat0=00 stat1=00 devices=0x4 ata1: [MPSAFE] pcm0: port 0xd800-0xd8ff,0xdc40-0xdc7f mem 0xf8fff800-0xf8fff9ff,0xf8fff400-0xf8fff4ff irq 17 at device 31.5 on pci0 pcm0: Reserved 0x200 bytes for rid 0x18 type 3 at 0xf8fff800 pcm0: Reserved 0x100 bytes for rid 0x1c type 3 at 0xf8fff400 pcm0: [GIANT-LOCKED] pcm0: pcm0: Codec features headphone, 20 bit DAC, 20 bit ADC, 5 bit master volume, SigmaTel 3D Enhancement pcm0: Primary codec extended features variable rate PCM, reserved 1, AMAP, reserved 4 pcm0: sndbuf_setmap 3e964000, 4000; 0xed156000 -> 3e964000 pcm0: sndbuf_setmap 3e94f000, 4000; 0xed15a000 -> 3e94f000 pci0: at device 31.6 (no driver attached) pci0:31:6: Transition from D0 to D3 acpi_tz0: on acpi0 psmcpnp0: irq 12 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 atkbd: the current kbd controller command byte 0065 atkbd: keyboard ID 0x41ab (2) kbd0 at atkbd0 kbd0: atkbd0, AT 101/102 (2), config:0x0, flags:0x3d0000 atkbd0: [GIANT-LOCKED] psm0: current command byte:0065 psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model GlidePoint, device ID 0-00, 2 buttons psm0: config:00000000, flags:00000008, packet size:3 psm0: syncmask:c0, syncbits:00 sio0: irq maps: 0xc801 0xc811 0xc801 0xc801 sio0 port 0x3f8-0x3ff,0x270-0x277 irq 4 drq 3 flags 0x10 on acpi0 sio0: type 16550A npx0: [FAST] npx0: on motherboard npx0: INT 16 interface ata: ata0 already exists; skipping it ata: ata1 already exists; skipping it atkbdc: atkbdc0 already exists; skipping it sio: sio0 already exists; skipping it vga: vga0 already exists; skipping it pnp_identify: Trying Read_Port at 203 pnp_identify: Trying Read_Port at 243 pnp_identify: Trying Read_Port at 283 pnp_identify: Trying Read_Port at 2c3 pnp_identify: Trying Read_Port at 303 pnp_identify: Trying Read_Port at 343 pnp_identify: Trying Read_Port at 383 pnp_identify: Trying Read_Port at 3c3 PNP Identify complete sc: sc0 already exists; skipping it isa_probe_children: disabling PnP devices isa_probe_children: probing non-PnP devices pmtimer0 on isa0 orm0: at iomem 0xc0000-0xcffff on isa0 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) fdc0 failed to probe at port 0x3f0 irq 6 drq 2 on isa0 fe0: not probed (disabled) ie0: not probed (disabled) lnc0: not probed (disabled) ppc0 failed to probe at irq 7 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> sc0: fb0, kbd0, terminal emulator: sc (syscons terminal) sio1: not probed (disabled) sio2: not probed (disabled) sio3: not probed (disabled) sn0: not probed (disabled) vt0: not probed (disabled) isa_probe_children: probing PnP devices ums0: Microsoft Microsoft 3-Button Mouse with IntelliEye(TM), rev 1.10/3.00, addr 2, iclass 3/1 ums0: 3 buttons and Z dir. ucom0: Prolific Technology Inc. USB-Serial Controller, rev 1.10/3.00, addr 2 Device configuration finished. lapic: Divisor 2, Frequency 99750208 hz Timecounter "TSC" frequency 3391518640 Hz quality 800 Timecounters tick every 1.000 msec lo0: bpf attached acpi_acad0: acline initialization start acpi_acad0: On Line acpi_acad0: acline initialization done, tried 1 times acpi_cmbat0: battery initialization start ata0-master: pio=PIO4 wdma=WDMA2 udma=UDMA100 cable=80 wire atapicam: atapicam0 already exists; skipping it ad0: setting PIO4 on Intel ICH5 chip ad0: setting UDMA100 on Intel ICH5 chip acpi_cmbat0: battery initialization done, tried 1 times ad0: 57231MB at ata0-master UDMA100 ad0: 117210240 sectors [116280C/16H/63S] 16 sectors/interrupt 1 depth queue GEOM: new disk ad0 ata1-master: pio=PIO4 wdma=WDMA2 udma=UDMA33 cable=40 wire acd0: setting PIO4 on Intel ICH5 chip acd0: setting UDMA33 on Intel ICH5 chip acd0: DVDR drive at ata1 as master acd0: read 4134KB/s (4134KB/s) write 2755KB/s (2755KB/s), 2048KB buffer, UDMA33 acd0: Reads: CDR, CDRW, CDDA stream, DVDROM, DVDR, packet acd0: Writes: CDR, CDRW, DVDR, test write, burnproof acd0: Audio: play, 256 volume levels acd0: Mechanism: ejectable tray, unlocked acd0: Medium: CD-ROM 120mm data disc pcm0: measured ac97 link rate at 47995 Hz, will use 48000 Hz pass0 at ata1 bus 0 target 0 lun 0 pass0: <_NEC DVD_RW ND-5500A 1.51> Removable CD-ROM SCSI-0 device pass0: Serial Number [ pass0: 33.000MB/s transfers ioapic0: routing intpin 1 (ISA IRQ 1) to cluster 0 ioapic0: routing intpin 4 (ISA IRQ 4) to cluster 0 ioapic0: routing intpin 9 (ISA IRQ 9) to cluster 0 ioapic0: routing intpin 12 (ISA IRQ 12) to cluster 0 ioapic0: routing intpin 13 (ISA IRQ 13) to cluster 0 ioapic0: routing intpin 14 (ISA IRQ 14) to cluster 0 ioapic0: routing intpin 15 (ISA IRQ 15) to cluster 0 ioapic0: routing intpin 16 (PCI IRQ 16) to cluster 0 ioapic0: routing intpin 17 (PCI IRQ 17) to cluster 0 ioapic0: routing intpin 18 (PCI IRQ 18) to cluster 0 ioapic0: routing intpin 19 (PCI IRQ 19) to cluster 0 ioapic0: routing intpin 23 (PCI IRQ 23) to cluster 0 cd0 at ata1 bus 0 target 0 lun 0 cd0: <_NEC DVD_RW ND-5500A 1.51> Removable CD-ROM SCSI-0 device cd0: Serial Number [ cd0: 33.000MB/s transfers cd0: cd present [281772 x 2048 byte records] GEOM: new disk cd0 Trying to mount root from ufs:/dev/ad0s2a start_init: trying /sbin/init procfs registered Linux ELF exec handler installed linprocfs registered nfslock: pseudo-device --Boundary_(ID_Q71htTUolz6xzV2gSfBqGg)-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 14:16: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 01D5C16A41C for ; Thu, 16 Jun 2005 14:16:12 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id CD56343D60 for ; Thu, 16 Jun 2005 14:16:11 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 22BD446B7F; Thu, 16 Jun 2005 10:16:11 -0400 (EDT) Date: Thu, 16 Jun 2005 15:18:23 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Stephane E. Potvin" In-Reply-To: <42B18536.3080200@videotron.ca> Message-ID: <20050616151502.X27625@fledge.watson.org> References: <42B18536.3080200@videotron.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: Reboot while booting with new per-CPU allocator 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, 16 Jun 2005 14:16:12 -0000 On Thu, 16 Jun 2005, Stephane E. Potvin wrote: > Kernel malloc layers malloc_type allocation over one of two underlying > allocators: a set of power-of-two UMA zones for small allocations, and the > ... > modifications to vmstat in order to restore "vmstat -m" on core dumps will > follow shortly. > > I get spontaneous reboots while the kernel is loading after the kernel > finds the APICs while booting verbose: It sounds like you've one a binary search to track this down and it's definitely that commit that did it? I.e., if you specifically back out the associated changes to kern_malloc.c and malloc.h locally with a curret kernel, all is well? Have you tried running with kern_malloc.c:1.141 (Jun 10) from Joseph Koshy, which corrects a bug in the deregistering of malloc types? It looks like you're running with a serial console, but if not, could you do so and make sure there are no last second printfs that get eaten by the reboot clearing the video console? Thanks, Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 14:40: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 DEC3D16A41C for ; Thu, 16 Jun 2005 14:40:03 +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 931E543D4C for ; Thu, 16 Jun 2005 14:40:03 +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 j5GEdqge022254; Thu, 16 Jun 2005 10:39:52 -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 j5GEdlKX022251; Thu, 16 Jun 2005 10:39:52 -0400 (EDT) (envelope-from andy@siliconlandmark.com) X-Authentication-Warning: lexi.siliconlandmark.com: andy owned process doing -bs Date: Thu, 16 Jun 2005 10:39:47 -0400 (EDT) From: Andre Guibert de Bruet To: Eric Anderson In-Reply-To: <42B15F2E.9050408@centtech.com> Message-ID: <20050616103629.T42933@lexi.siliconlandmark.com> References: <20050616070445.GD2239@obiwan.tataz.chchile.org> <20050616.012302.48201645.imp@bsdimp.com> <20050616075743.GE2239@obiwan.tataz.chchile.org> <20050616.020442.31252848.imp@bsdimp.com> <42B15F2E.9050408@centtech.com> 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.535, 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: incorrect ping(8) interval with powerd(8) 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, 16 Jun 2005 14:40:04 -0000 On Thu, 16 Jun 2005, Eric Anderson wrote: > M. Warner Losh wrote: >> In message: <20050616075743.GE2239@obiwan.tataz.chchile.org> >> Jeremie Le Hen writes: >> : > : May you delve into this a little bit more please ? The ping(8) >> manual >> : > : page states that the -i flags makes ping(8) to wait a given couple of >> : > : seconds. If I use the flags "-i 1", I expect ECHO Requests to be >> sent >> : > : with one second between each, whatever the AC line status is. >> : > : (Note that I didn't explicitely specified "-i 1" in the above >> example, >> : > : but this doesn't change the behaviour.) >> : > : > Well, the rount trip times went way up (3x longer). That's normal >> for >> : > a 200MHz CPU... My 333MHz EISA machine can't do much better than >> : > that. >> : > : > But the 2.252s run time is a little longish. Do you see this >> : > consistantly? If you ran it a second time would you get identical >> : > results. I've seen ARP take a while... What else do you have running >> : > on the system? Maybe a daemon that takes almost no time at 1.7GHz >> : > takes a lot longer at 200Mhz and that's starving the ping process... >> : > Or some driver has gone insane... >> : : Yes, I ran this test multiple times, and I almost get always this same >> : result although I got 2.208s sometimes, but I don't think this is >> : significant. >> : : FYI, >> : my powerd(8) is configured to tastes AC-line four times per seconds. >> : I tried reducing it's freqency from 4 to 1, but it doesn't change >> : anything. >> : : ARP is not the culprit, the MAC address is already in cache. >> : : My kernel is compiled with INVARIANTS, but I don't have WITNESS. My >> : network interface uses the bge(4) driver. No firewall rule or complex >> : network setup. >> : : Anyway this doesn't hurt much. Thanks for lightening me. >> >> Dang, I was hoping it was one of the easy explainations.... Maybe it >> is the idle code not waking up fast enough when it has been asleep for >> a bit. But that's pure speculation at this point... > > Another datapoint - running -CURRENT as of about June 7th, I see this too: > > $ time ping -i 1 -c 5 localhost > PING localhost (127.0.0.1): 56 data bytes > 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.041 ms > 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.033 ms > 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.029 ms > 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.031 ms > 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.035 ms > > --- localhost ping statistics --- > 5 packets transmitted, 5 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.029/0.034/0.041/0.004 ms > > real 0m9.728s > user 0m0.000s > sys 0m0.003s > > On a 5-STABLE machine: > $ time ping -i 1 -c 5 localhost > PING localhost (127.0.0.1): 56 data bytes > 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.049 ms > 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.032 ms > 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.024 ms > 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.021 ms > 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.032 ms > > --- localhost ping statistics --- > 5 packets transmitted, 5 packets received, 0% packet loss > round-trip min/avg/max/stddev = 0.021/0.032/0.049/0.010 ms > > real 0m4.064s > user 0m0.000s > sys 0m0.005s > > > I have powerd running, but it makes no difference whether I have it running > or not, nor does it make any difference if I'm on ac or battery. > > This worked fine a couple weeks back for me - the only thing I recall > changing is adding apic to my kernel. Just out of curiosity, does removing debugging options from your kernel config change anything? 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 Thu Jun 16 14:56: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 B29EA16A41C; Thu, 16 Jun 2005 14:56:20 +0000 (GMT) (envelope-from sepotvin@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8921643D48; Thu, 16 Jun 2005 14:56:20 +0000 (GMT) (envelope-from sepotvin@videotron.ca) Received: from [10.0.0.147] ([67.70.237.74]) by VL-MO-MR001.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0II600K9UMS242@VL-MO-MR001.ip.videotron.ca>; Thu, 16 Jun 2005 10:55:15 -0400 (EDT) Date: Thu, 16 Jun 2005 10:55:14 -0400 From: "Stephane E. Potvin" In-reply-to: <20050616151502.X27625@fledge.watson.org> To: Robert Watson Message-id: <42B192D2.7000505@videotron.ca> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330) X-Enigmail-Version: 0.91.0.0 References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> Cc: freebsd-current@FreeBSD.org Subject: Re: Reboot while booting with new per-CPU allocator 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, 16 Jun 2005 14:56:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Watson wrote: > > On Thu, 16 Jun 2005, Stephane E. Potvin wrote: > >> Kernel malloc layers malloc_type allocation over one of two underlying >> allocators: a set of power-of-two UMA zones for small allocations, >> and the >> ... >> modifications to vmstat in order to restore "vmstat -m" on core dumps >> will >> follow shortly. >> >> I get spontaneous reboots while the kernel is loading after the kernel >> finds the APICs while booting verbose: > > > It sounds like you've one a binary search to track this down and it's > definitely that commit that did it? I.e., if you specifically back out > the associated changes to kern_malloc.c and malloc.h locally with a > curret kernel, all is well? > > Have you tried running with kern_malloc.c:1.141 (Jun 10) from Joseph > Koshy, which corrects a bug in the deregistering of malloc types? > > It looks like you're running with a serial console, but if not, could > you do so and make sure there are no last second printfs that get eaten > by the reboot clearing the video console? > I did a binary search to find the offending commit. Reverting the changes to kern_malloc.c and malloc.h locally did fix the problem. That's what I'm currently using to type this message. I also had to revert the changes to vmstat to make the world compile. Using head sources from yesterday (Jun 15) exhibit the same problem unfortunately. The computer that has this problem is a Dell XPS laptop which, being quite recent, doesn't have any serial port. The boot output I gave is a mix of interpolating the beginning from a working image (with only the kern_malloc.c and malloc.h differing) and getting the last part with a digital camera. I guessed it wouldn't cause a problem as the kern_malloc.c diff didn't seems to print anything during the boot. There might be some last second printfs going to the console before the reboot but in that case they are much too fast to be seen even to the naked eyes. Steph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCsZLSmdOXtTCX/nsRAtG8AKDc858m6/64Iv4aKs90mZysXulc+ACfQuQo Tp0ZxB6AECs15V8Fz87lR5c= =pLjb -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 16:28:13 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 C76AC16A41C; Thu, 16 Jun 2005 16:28:13 +0000 (GMT) (envelope-from rb@gid.co.uk) Received: from gidgate.gid.co.uk (gid.co.uk [194.32.164.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0910243D49; Thu, 16 Jun 2005 16:28:12 +0000 (GMT) (envelope-from rb@gid.co.uk) Received: (from rb@localhost) by gidgate.gid.co.uk (8.11.7/8.11.6) id j5GGRQ364234; Thu, 16 Jun 2005 17:27:26 +0100 (BST) (envelope-from rb) Message-Id: <6.2.0.14.2.20050616172335.044bef40@gid.co.uk> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Thu, 16 Jun 2005 17:27:20 +0100 To: Marcin Jessa , frank@exit.com From: Bob Bishop In-Reply-To: <20050616144707.18bfa000.lists@yazzy.org> References: <20050615114556.6df96e8c.lists@yazzy.org> <1118925438.91936.2.camel@realtime.exit.com> <20050616144707.18bfa000.lists@yazzy.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: Looking for networking solution. 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, 16 Jun 2005 16:28:13 -0000 Hi, At 13:47 16/06/2005, Marcin Jessa wrote: >On Thu, 16 Jun 2005 05:37:18 -0700 >Frank Mayhar wrote: > > > > > You want SCPS (the Space Communications Protocols Specification) > > software. Briefly, it fakes local TCP on either end while talking its > > own protocol over the high-latency link. I don't know if there is any > > open-source package available but there are certainly commercial > > solutions out there. > > -- > >Correct. That's why I asked about this problem here. >I was in doubt something like that existed for FreeBSD. >We are willing to pay someone to develop such a solution for FreeBSD. >I'd love to get in touch with someone willing to pick up that challenge. If you haven't done so, you might want to look at http://www.scps.org/scps/Reference_S_W/reference_s_w.html and see whether the reference implementation would be available for porting to FreeBSD. -- Bob Bishop +44 (0)118 940 1243 rb@gid.co.uk fax +44 (0)118 940 1295 From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 16:50: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 2477D16A41C for ; Thu, 16 Jun 2005 16:50:03 +0000 (GMT) (envelope-from hiten.pandya@gmail.com) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.202]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF07C43D48 for ; Thu, 16 Jun 2005 16:50:02 +0000 (GMT) (envelope-from hiten.pandya@gmail.com) Received: by wproxy.gmail.com with SMTP id 68so588430wri for ; Thu, 16 Jun 2005 09:50:02 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:reply-to:from:to:subject:date:organization:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:x-mimeole:message-id; b=pOpJopTrqeG/9P5fysAmfOKIg4pfv/mTUp+Wbgka0F+b7udZMsX/k0aBZfSDK6aYLVOm2xx6jPYS2UbSFkX+1SNPRXcxVnKMqA1OBgwZ5bg1TuxusyGXeEyk1xDRcjzLEzMTvG+K3TIkIa4s7EpXorZiQLGIWboGmTaQVRfZYmA= Received: by 10.54.143.4 with SMTP id q4mr736588wrd; Thu, 16 Jun 2005 09:50:02 -0700 (PDT) Received: from hitenp ([82.18.88.18]) by mx.gmail.com with ESMTP id d75sm1055007wra.2005.06.16.09.50.00; Thu, 16 Jun 2005 09:50:02 -0700 (PDT) From: "Hiten Pandya" To: Date: Thu, 16 Jun 2005 17:49:44 +0100 Organization: FreeBSD MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Thread-Index: AcVyk2WImyLxri4vRpu+YpVFVBwKqw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Message-ID: <42b1adba.776977e2.0b2a.ffffa239@mx.gmail.com> Subject: 3com 357c issues X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: hiten.pandya@gmail.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2005 16:50:03 -0000 Since I upgraded the machine to -HEAD from 5.3, two of my 3com cardbus network cards have stopped working. I am receiving watchdog timeouts for my 3com 3c575C card; dmesg is showing the following before the xl0 lines: cardbus0: Resource not specified in CIS: id=14, size=80 cardbus0: Resource not specified in CIS: id=18, size=80 One of my other cardbus card, 3Com 3c575TX is also having issue; when booting up the dmesg shows: xl0: <3com 3c575TX Fast Etherlink XL...> xl0: couldn't map ports/memory Give me a shout if more debug output is required for this problem. Cheers, Hiten Pandya hmp at freebsd.org From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 16:51: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 054D816A421 for ; Thu, 16 Jun 2005 16:51:03 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4E2543D48 for ; Thu, 16 Jun 2005 16:51:02 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5GGloCX024254; Thu, 16 Jun 2005 09:47:50 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5GGlm1a024251; Thu, 16 Jun 2005 09:47:48 -0700 Date: Thu, 16 Jun 2005 09:47:47 -0700 From: Brooks Davis To: Darren Pilgrim Message-ID: <20050616164747.GB21733@odin.ac.hmc.edu> References: <20050615061009.GA11914@odin.ac.hmc.edu> <001501c5720b$aceb84d0$0b2a15ac@SMILEY> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="dc+cDN39EJAMEtIO" Content-Disposition: inline In-Reply-To: <001501c5720b$aceb84d0$0b2a15ac@SMILEY> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: 'Vladimir Grebenschikov' , freebsd-current@freebsd.org, 'Matthew Emmerton' Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 16:51:03 -0000 --dc+cDN39EJAMEtIO Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jun 15, 2005 at 05:38:10PM -0700, Darren Pilgrim wrote: > From: Brooks Davis > > There are two issues here. First, if we're going to keep > > network_interfaces around, /etc/rc.d/dhclient should honor > > it and not start dhclient on interfaces not in either > > network_interfaces or removable interfaces. >=20 > I think network_interfaces should be gotten rid of entirely for two > reasons: >=20 > 1: It creates a synchronization issue between it and the ifconfig_* > lines and duplicates functionality. IIRC, rc.conf being out of sync in > this way has tripped up users in the past. >=20 > 2: There are real configurations in which some interfaces are not > available when netif is run at boot. One example is the many newer > mini-PCI wireless NICs that require a firmware upload. Devd is the > accepted tool for performing such tasks, but rcordering puts devd after > NETWORKING. The actions taken by devd must therefore include steps > taken by netif. Calling the rc.d scripts directly from devd avoids > local scripts that duplicate rc.d functionality. A similar situation > occurs for removable interfaces. I'm seriously considering removing the following variables: network_interfaces removable_interfaces pccard_ether If I do that I'll probably add a pair of new start/stop targets to /etc/rc.d/netif to replicate the remaining functions of pccard_ether and nuke /etc/pccard_ether. I won't get to this until the week of the 27th because I'm going to be gone all next week. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --dc+cDN39EJAMEtIO Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCsa0zXY6L6fI4GtQRAqE3AKCsivo3IK6MAGZgRta0goafulvbvQCgjAIo tB8nV2p0wAKQvn80C/XG0Jk= =wwkZ -----END PGP SIGNATURE----- --dc+cDN39EJAMEtIO-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 17:13: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 BCE2F16A41C; Thu, 16 Jun 2005 17:13:34 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51B4543D55; Thu, 16 Jun 2005 17:13:34 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[216.133.140.1]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Thu, 16 Jun 2005 13:26:58 -0400 From: John Baldwin To: brooks@FreeBSD.org Date: Thu, 16 Jun 2005 13:12:51 -0400 User-Agent: KMail/1.8 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506161312.51857.jhb@FreeBSD.org> Cc: current@FreeBSD.org Subject: New dhclient broke multiple domains in domain-name 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, 16 Jun 2005 17:13:34 -0000 [ Apologies if this has already been brought up, I'm still 1800 messages behind on current@. ] A feature of both the old and new dhclient(8) is that it would take whatever was in the domain-name option returned by the DHCP server and stick it in the 'search' line in /etc/resolv.conf. Thus, if you wanted to have DNS search multiple domains, you could just pass a space separated list of domains to search in domain-name and it would just work. I've made use of this "feature" in several different environments in the past including my current test lab. It's even used in the example dhclient.conf in dhclient.conf(5): interface "ep0" { send host-name "andare.fugue.com"; send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; send dhcp-lease-time 3600; supersede domain-name "fugue.com rc.vix.com home.vix.com"; prepend domain-name-servers 127.0.0.1; ... } The new dhclient is barfing on my domain-name setting now because it doesn't look like a domain name: Setting hostname: deimos.baldwin.cx. fxp0: link state changed to UP DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 8 DHCPOFFER from 192.168.0.1 Bogus Host Name option 15: baldwin.cx freebsd.org atl.weather.com (baldwin.cx freebsd.org atl.weather.com) Invalid lease option - ignoring offer packet_to_lease failed. DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 10 DHCPOFFER from 192.168.0.1 Bogus Host Name option 15: baldwin.cx freebsd.org atl.weather.com (baldwin.cx freebsd.org atl.weather.com) Invalid lease option - ignoring offer packet_to_lease failed. ... I'd very much like the old behavior restored if possible, or an alternative way to achieve the same result (multiple domains in the 'search' part of /etc/resolv.conf). Note that the old domain-name trick has worked all the way back to at least 4.1 and maybe even back in the 3.x days IIRC. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 17:17: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 7DAC516A41F for ; Thu, 16 Jun 2005 17:17:12 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 51B7B43D4C for ; Thu, 16 Jun 2005 17:17:12 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id ED3CC46BB2; Thu, 16 Jun 2005 13:17:11 -0400 (EDT) Date: Thu, 16 Jun 2005 18:19:24 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Stephane E. Potvin" In-Reply-To: <42B192D2.7000505@videotron.ca> Message-ID: <20050616181820.E27625@fledge.watson.org> References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-current@FreeBSD.org Subject: Re: Reboot while booting with new per-CPU allocator 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, 16 Jun 2005 17:17:12 -0000 On Thu, 16 Jun 2005, Stephane E. Potvin wrote: >> Have you tried running with kern_malloc.c:1.141 (Jun 10) from Joseph >> Koshy, which corrects a bug in the deregistering of malloc types? >> >> It looks like you're running with a serial console, but if not, could >> you do so and make sure there are no last second printfs that get eaten >> by the reboot clearing the video console? >> > > I did a binary search to find the offending commit. Reverting the changes > to kern_malloc.c and malloc.h locally did fix the problem. That's what I'm > currently using to type this message. I also had to revert the changes to > vmstat to make the world compile. > > Using head sources from yesterday (Jun 15) exhibit the same problem > unfortunately. Hmm.. It looks like Alan Cox just committed the attached patch to uma_int.h to modify UMA_BOOT_PAGES following a report of a panic at a similar point in the boot process. Could you try updating to the latest uma_int.h or trying the patch below to see if it makes a difference? Robert N M Watson Index: uma_int.h =================================================================== RCS file: /home/ncvs/src/sys/vm/uma_int.h,v retrieving revision 1.30 retrieving revision 1.31 diff -u -r1.30 -r1.31 --- uma_int.h 29 Apr 2005 18:56:36 -0000 1.30 +++ uma_int.h 16 Jun 2005 17:06:34 -0000 1.31 @@ -119,7 +119,7 @@ #define UMA_SLAB_MASK (PAGE_SIZE - 1) /* Mask to get back to the page */ #define UMA_SLAB_SHIFT PAGE_SHIFT /* Number of bits PAGE_MASK */ -#define UMA_BOOT_PAGES 40 /* Pages allocated for startup */ +#define UMA_BOOT_PAGES 48 /* Pages allocated for startup */ /* Max waste before going to off page slab management */ #define UMA_MAX_WASTE (UMA_SLAB_SIZE / 10) From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 17: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 52EC416A426; Thu, 16 Jun 2005 17:31:59 +0000 (GMT) (envelope-from sepotvin@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1127043D1D; Thu, 16 Jun 2005 17:31:58 +0000 (GMT) (envelope-from sepotvin@videotron.ca) Received: from [10.0.0.147] ([67.70.237.74]) by VL-MO-MR011.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0II600A3XU108Z@VL-MO-MR011.ip.videotron.ca>; Thu, 16 Jun 2005 13:31:49 -0400 (EDT) Date: Thu, 16 Jun 2005 13:31:48 -0400 From: "Stephane E. Potvin" In-reply-to: <20050616181820.E27625@fledge.watson.org> To: Robert Watson Message-id: <42B1B784.8010405@videotron.ca> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330) X-Enigmail-Version: 0.91.0.0 References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> <20050616181820.E27625@fledge.watson.org> Cc: freebsd-current@FreeBSD.org Subject: Re: Reboot while booting with new per-CPU allocator 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, 16 Jun 2005 17:31:59 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Watson wrote: > > On Thu, 16 Jun 2005, Stephane E. Potvin wrote: > >>> Have you tried running with kern_malloc.c:1.141 (Jun 10) from Joseph >>> Koshy, which corrects a bug in the deregistering of malloc types? >>> >>> It looks like you're running with a serial console, but if not, could >>> you do so and make sure there are no last second printfs that get eaten >>> by the reboot clearing the video console? >>> >> >> I did a binary search to find the offending commit. Reverting the changes >> to kern_malloc.c and malloc.h locally did fix the problem. That's what >> I'm >> currently using to type this message. I also had to revert the changes to >> vmstat to make the world compile. >> >> Using head sources from yesterday (Jun 15) exhibit the same problem >> unfortunately. > > > Hmm.. It looks like Alan Cox just committed the attached patch to > uma_int.h to modify UMA_BOOT_PAGES following a report of a panic at a > similar point in the boot process. Could you try updating to the latest > uma_int.h or trying the patch below to see if it makes a difference? > Great :) It did the trick. The laptop is happily booting with the new allocator now. Thanks a lot to you and Alan Cox. Steph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCsbeEmdOXtTCX/nsRArNJAKCe+RAG18UaFtnATsy1fwL/uR7SVACeO6nx crxjNWLw2F+TzbDDFncW15c= =rHIp -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 17:38: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 C5FC216A41C for ; Thu, 16 Jun 2005 17:38:08 +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 B10B943D48 for ; Thu, 16 Jun 2005 17:38:08 +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 1DiyJc-000Glz-AP for freebsd-current@freebsd.org; Thu, 16 Jun 2005 17:38:08 +0000 Received: from [127.0.0.1] (helo=roam.psg.com.psg.com) by roam.psg.com with esmtp (Exim 4.51 (FreeBSD)) id 1DiyJb-0007ID-Ef for freebsd-current@freebsd.org; Thu, 16 Jun 2005 10:38:07 -0700 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17073.47359.49105.538751@roam.psg.com> Date: Thu, 16 Jun 2005 18:38:07 +0100 To: FreeBSD Current References: <17073.28802.502964.714076@roam.psg.com> Subject: Re: kbd goes away on multi 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, 16 Jun 2005 17:38:08 -0000 > installing from june snapshot cd on a dell poweredge 2850 > 1ru rackem-stackem server > install was fine > boot single user and all is fine > go multi and the keyboard does nothing cvsupped and rebuilt kernel and world. problem no longer reproduces. this is not necessarily a bad thing :-). randy From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 17:42: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 A066516A41C; Thu, 16 Jun 2005 17:42:05 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7380643D55; Thu, 16 Jun 2005 17:42:05 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 1D8EE46B45; Thu, 16 Jun 2005 13:42:05 -0400 (EDT) Date: Thu, 16 Jun 2005 18:44:18 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Stephane E. Potvin" In-Reply-To: <42B1B784.8010405@videotron.ca> Message-ID: <20050616184127.L27625@fledge.watson.org> References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> <20050616181820.E27625@fledge.watson.org> <42B1B784.8010405@videotron.ca> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: alc@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Reboot while booting with new per-CPU allocator 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, 16 Jun 2005 17:42:05 -0000 On Thu, 16 Jun 2005, Stephane E. Potvin wrote: >>> I did a binary search to find the offending commit. Reverting the changes >>> to kern_malloc.c and malloc.h locally did fix the problem. That's what >>> I'm >>> currently using to type this message. I also had to revert the changes to >>> vmstat to make the world compile. >>> >>> Using head sources from yesterday (Jun 15) exhibit the same problem >>> unfortunately. >> >> Hmm.. It looks like Alan Cox just committed the attached patch to >> uma_int.h to modify UMA_BOOT_PAGES following a report of a panic at a >> similar point in the boot process. Could you try updating to the latest >> uma_int.h or trying the patch below to see if it makes a difference? >> > > Great :) It did the trick. The laptop is happily booting with the new > allocator now. Thanks a lot to you and Alan Cox. Looks like what basically happened is this these kern_malloc.c changes increase the memory burden on UMA as statistics structures for malloc types now get allocated from UMA. It looks like, from your dmesg, you have a fair number of modules loaded, so the storage for the statistics comes out of the early UMA page pool, whereas before it came out of BSS. We'll see if further tuning is required or not with large numbers of modules. The thing that surprised me, though, is the unclean failure mode. The other report saw a clean panic which presumably made debugging it much easier... Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 18:20:58 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 7920616A41C for ; Thu, 16 Jun 2005 18:20:58 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 455E943D1F for ; Thu, 16 Jun 2005 18:20:58 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5GIKuc8002205; Thu, 16 Jun 2005 11:20:56 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5GIKuld002204; Thu, 16 Jun 2005 11:20:56 -0700 Date: Thu, 16 Jun 2005 11:20:56 -0700 From: Brooks Davis To: Darren Pilgrim Message-ID: <20050616182056.GF21733@odin.ac.hmc.edu> References: <000001c57259$01a259c0$0b2a15ac@SMILEY> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c57259$01a259c0$0b2a15ac@SMILEY> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@freebsd.org Subject: Re: Is anyone working on /etc/rc.d/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: Thu, 16 Jun 2005 18:20:58 -0000 On Thu, Jun 16, 2005 at 02:51:44AM -0700, Darren Pilgrim wrote: > Is anyone working on the proposed /etc/rc.d/wpa_supplicant script (as > mentioned in /etc/network.subr? If not, I'll get started on one. I'm planning to work on it, but if I don't do it my tomarrow it will have to wait for the week of the 27th as I will be without electronic devices next Sunday-Friday. > Also if not, what are some guidelines for what the script should do? Is > just terminating wpa_supplicant sufficient, or should the script stop > dhclient, de-configure and down the interface as well? The script should have no knowledge of dhclient and should act like the dhclient script for the most part. One could argue though that it actually has to be more complicated than the dhclient script because in some really weird configurations you might not have /usr mounted when netif is run and as a result you need to support starting supplicants after mountcritremote. In normal configurations, the script should see the already started wpa_supplicants and not do anything when it is run. I can't actually think of a good reason to have a machine with a remote /usr be a wireless station, but I'm sure some crazy person will come up with one. :) -- Brooks From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 18:39:32 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 2DA9816A41C; Thu, 16 Jun 2005 18:39:32 +0000 (GMT) (envelope-from hans@lambermont.dyndns.org) Received: from lambermont.dyndns.org (lambermont.dyndns.org [82.93.47.245]) by mx1.FreeBSD.org (Postfix) with ESMTP id C6D8343D1F; Thu, 16 Jun 2005 18:39:31 +0000 (GMT) (envelope-from hans@lambermont.dyndns.org) Received: by lambermont.dyndns.org (Postfix, from userid 1001) id DA6BD95B17; Thu, 16 Jun 2005 20:39:30 +0200 (CEST) Date: Thu, 16 Jun 2005 20:39:30 +0200 To: Marcin Jessa Message-ID: <20050616183930.GB24214@leia.lambermont.dyndns.org> References: <20050615114556.6df96e8c.lists@yazzy.org> <1118925438.91936.2.camel@realtime.exit.com> <20050616144707.18bfa000.lists@yazzy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050616144707.18bfa000.lists@yazzy.org> User-Agent: Mutt/1.4.2.1i From: hans@lambermont.dyndns.org (Hans Lambermont) Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: Looking for networking solution. 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, 16 Jun 2005 18:39:32 -0000 Marcin Jessa wrote: > Frank Mayhar wrote: ... >> You want SCPS (the Space Communications Protocols Specification) >> software. Briefly, it fakes local TCP on either end while talking >> its own protocol over the high-latency link. I don't know if there >> is any open-source package available but there are certainly >> commercial solutions out there. > > Correct. That's why I asked about this problem here. I was in doubt > something like that existed for FreeBSD. Yesterday I posted a mail about Tellitec. What I forgot to mention is that it runs on FreeBSD too. I'm sure Tellitec has a native FreeBSD binary, but the Linux binary I use at work also runs fine on FreeBSD. However, it is closed source, so : > We are willing to pay someone to develop such a solution for FreeBSD. > I'd love to get in touch with someone willing to pick up that challenge. I'm not sure it is what you're looking for. -- Hans Lambermont Disclaimer: I have a business relation to Tellitec. -- http://hans.dse.nl/ () ASCII-ribbon campaign against vCards, /\ HTML-mail and proprietary formats. From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 18:50:22 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 AFEEF16A41C; Thu, 16 Jun 2005 18:50:22 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8E4AF43D1D; Thu, 16 Jun 2005 18:50:22 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5GIoMDq005099; Thu, 16 Jun 2005 11:50:22 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5GIoM6k005098; Thu, 16 Jun 2005 11:50:22 -0700 Date: Thu, 16 Jun 2005 11:50:22 -0700 From: Brooks Davis To: John Baldwin Message-ID: <20050616185022.GJ21733@odin.ac.hmc.edu> References: <200506161312.51857.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506161312.51857.jhb@FreeBSD.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@FreeBSD.org Subject: Re: New dhclient broke multiple domains in domain-name 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, 16 Jun 2005 18:50:22 -0000 On Thu, Jun 16, 2005 at 01:12:51PM -0400, John Baldwin wrote: > [ Apologies if this has already been brought up, I'm still 1800 messages > behind on current@. ] > > A feature of both the old and new dhclient(8) is that it would take whatever > was in the domain-name option returned by the DHCP server and stick it in the > 'search' line in /etc/resolv.conf. Thus, if you wanted to have DNS search > multiple domains, you could just pass a space separated list of domains to > search in domain-name and it would just work. I've made use of this > "feature" in several different environments in the past including my current > test lab. It's even used in the example dhclient.conf in dhclient.conf(5): > > interface "ep0" { > send host-name "andare.fugue.com"; > send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; > send dhcp-lease-time 3600; > supersede domain-name "fugue.com rc.vix.com home.vix.com"; > prepend domain-name-servers 127.0.0.1; > ... > } > > The new dhclient is barfing on my domain-name setting now because it doesn't > look like a domain name: > > Setting hostname: deimos.baldwin.cx. > fxp0: link state changed to UP > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 8 > DHCPOFFER from 192.168.0.1 > Bogus Host Name option 15: baldwin.cx freebsd.org atl.weather.com (baldwin.cx > freebsd.org atl.weather.com) > Invalid lease option - ignoring offer > packet_to_lease failed. > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 10 > DHCPOFFER from 192.168.0.1 > Bogus Host Name option 15: baldwin.cx freebsd.org atl.weather.com (baldwin.cx > freebsd.org atl.weather.com) > Invalid lease option - ignoring offer > packet_to_lease failed. > ... > > I'd very much like the old behavior restored if possible, or an alternative > way to achieve the same result (multiple domains in the 'search' part > of /etc/resolv.conf). Note that the old domain-name trick has worked all the > way back to at least 4.1 and maybe even back in the 3.x days IIRC. I know about the issue and plan to fix it before release, but will not get to it for another week. This is a really annoying feature because it's widely supported, but clearly invalid based on reading the DHCP spec. It's a bug that isc-dhcpd sends domain-name with spaces in it since it violates the strict send, lenient accept rule. -- Brooks From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 19:12: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 D94A716A41C for ; Thu, 16 Jun 2005 19:12:02 +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 C57ED43D58 for ; Thu, 16 Jun 2005 19:12:02 +0000 (GMT) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id 890F872DDB; Thu, 16 Jun 2005 12:12:02 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id 83DD672DD4; Thu, 16 Jun 2005 12:12:02 -0700 (PDT) Date: Thu, 16 Jun 2005 12:12:02 -0700 (PDT) From: Doug White To: Ed Maste In-Reply-To: <20050615141447.GD95217@sandvine.com> Message-ID: <20050616121054.K48551@carver.gumbysoft.com> References: <20050613192308.GA87640@sandvine.com> <20050614082039.GA2038@dragon.NUXI.org> <20050614224704.Y75797@mp2.macomnet.net> <20050614190854.GA12928@dragon.NUXI.org> <20050614235132.L76669@mp2.macomnet.net> <20050615023600.GA20721@dragon.NUXI.org> <20050615141447.GD95217@sandvine.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-current@freebsd.org Subject: Re: savecore(8) increments /var/crash/bounds on each boot 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, 16 Jun 2005 19:12:03 -0000 On Wed, 15 Jun 2005, Ed Maste wrote: > On Tue, Jun 14, 2005 at 07:36:00PM -0700, David O'Brien wrote: > > > Do you understand the fix? How does lying in printheader() fix anything? > > Moving the call to getbounds() back to the original location is the "fix" > > but then it negates -vv. We shouldn't lie in printheader(). > > Fair enough, on dwhite's suggestion here's another try that splits the > increment-and-write out from getbounds() so that the bounds value can > be shown with -vv. Looks good to me, although I won't pass any verdict on style(9)isms. :) -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 19:14: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 121E716A41C for ; Thu, 16 Jun 2005 19:14:01 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: from imladris.teardrop.org (imladris.teardrop.org [66.92.66.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0748843D48 for ; Thu, 16 Jun 2005 19:13:59 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: by imladris.teardrop.org (Postfix, from userid 100) id E02F5BF6C4; Thu, 16 Jun 2005 15:14:50 -0400 (EDT) Date: Thu, 16 Jun 2005 15:14:50 -0400 From: James Snow To: freebsd-current@freebsd.org Message-ID: <20050616191450.GA98695@teardrop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: WPA Supplicant doesn't see my SSIDs? 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, 16 Jun 2005 19:14:01 -0000 Now that we've got WPA support I decided to give it a whirl with one of the WPA-enabled wireless networks I spend time near. I've successfully brought up a Windows machine on this network, but FreeBSD eludes me. It seems like the ath driver or wpa_supplicant are not seeing the SSID for some reason. /etc/wpa_supplicant.conf: ctrl_interface=/var/run/wpa_supplicant ctrl_interface_group=0 eapol_version=1 ap_scan=1 network={ ssid="external" scan_ssid=1 psk="MyPreSharedKey" } Output from wpa_supplicant -ddKt -i ath0 -c /etc/wpa_supplicant.conf -Dbsd: Jun 16 15:02:16.600289: Initializing interface 'ath0' conf '/etc/wpa_supplicant.conf' driver 'default' Jun 16 15:02:16.600422: Configuration file '/etc/wpa_supplicant.conf' -> '/etc/wpa_supplicant.conf' Jun 16 15:02:16.600440: Reading configuration file '/etc/wpa_supplicant.conf' Jun 16 15:02:16.600483: ctrl_interface='/var/run/wpa_supplicant' Jun 16 15:02:16.600950: ctrl_interface_group=0 Jun 16 15:02:16.600973: eapol_version=1 Jun 16 15:02:16.600984: ap_scan=1 Jun 16 15:02:16.600992: Line: 6 - start of a new network block Jun 16 15:02:16.601005: ssid - hexdump_ascii(len=8): 65 78 74 65 72 6e 61 6c external Jun 16 15:02:16.601026: scan_ssid=1 (0x1) ... ... Jun 16 15:02:16.677502: Priority group 0 Jun 16 15:02:16.677512: id=0 ssid='external' Jun 16 15:02:16.677523: Initializing interface (2) 'ath0' Jun 16 15:02:16.677847: Own MAC address: 00:0e:9b:6e:60:fc Jun 16 15:02:16.677862: wpa_driver_bsd_set_wpa: enabled=1 Jun 16 15:02:16.677875: wpa_driver_bsd_del_key: keyidx=0 Jun 16 15:02:16.677888: wpa_driver_bsd_del_key: keyidx=1 Jun 16 15:02:16.677899: wpa_driver_bsd_del_key: keyidx=2 Jun 16 15:02:16.677910: wpa_driver_bsd_del_key: keyidx=3 Jun 16 15:02:16.677921: wpa_driver_bsd_set_countermeasures: enabled=0 Jun 16 15:02:16.677931: wpa_driver_bsd_set_drop_unencrypted: enabled=1 Jun 16 15:02:16.677947: Setting scan request: 0 sec 100000 usec Jun 16 15:02:16.778153: Starting AP scan (specific SSID) Jun 16 15:02:16.778167: Scan SSID - hexdump_ascii(len=8): 65 78 74 65 72 6e 61 6c external Jun 16 15:02:24.734030: Received 0 bytes of scan results (4 BSSes) Jun 16 15:02:24.734051: Scan results: 4 Jun 16 15:02:24.734065: Selecting BSS from priority group 0 Jun 16 15:02:24.734075: 0: 00:0e:83:af:77:f5 ssid='' wpa_ie_len=26 rsn_ie_len=0 Jun 16 15:02:24.734087: skip - SSID mismatch Jun 16 15:02:24.734096: 1: 00:0e:38:51:ca:6c ssid='' wpa_ie_len=26 rsn_ie_len=0 Jun 16 15:02:24.734108: skip - SSID mismatch Jun 16 15:02:24.734116: 2: 00:0f:66:18:20:00 ssid='SDC-WAP-001' wpa_ie_len=0 rsn_ie_len=0 Jun 16 15:02:24.734129: skip - no WPA/RSN IE Jun 16 15:02:24.734137: 3: 00:07:eb:30:c6:de ssid='' wpa_ie_len=0 rsn_ie_len=0 Jun 16 15:02:24.734149: skip - no WPA/RSN IE Jun 16 15:02:24.734157: No suitable AP found. Jun 16 15:02:24.734168: Setting scan request: 5 sec 0 usec ^CJun 16 15:02:26.482136: Signal 2 received - terminating Jun 16 15:02:26.482153: No keys have been configured - skip key clearing Jun 16 15:02:26.482163: wpa_driver_bsd_set_wpa: enabled=0 Jun 16 15:02:26.482180: wpa_driver_bsd_set_drop_unencrypted: enabled=0 Jun 16 15:02:26.482191: wpa_driver_bsd_set_countermeasures: enabled=0 Jun 16 15:02:26.482202: No keys have been configured - skip key clearing Jun 16 15:02:26.485314: wpa_driver_bsd_set_wpa: enabled=0 I know from my Windows machine that the MAC addresses for my APs are IDs 0 and 1 in the above output. 2 and 3 are some other networks that also happen to be in the area. The odd thing is the empty SSID string which leads to an SSID mismatch. I tried setting my SSID string to an empty string ("") but still got a mismatch. Even if I had the PSK wrong or some other encryption setting wrong, I should still see the SSID, shouldn't I? Any suggestions? -Snow From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 19:46: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 5BC4616A41C; Thu, 16 Jun 2005 19:46:48 +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 136F643D1F; Thu, 16 Jun 2005 19:46:47 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j5GJkkms016051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2005 12:46:47 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42B1D823.5030108@errno.com> Date: Thu, 16 Jun 2005 12:50:59 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: John Baldwin References: <200506161312.51857.jhb@FreeBSD.org> In-Reply-To: <200506161312.51857.jhb@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: brooks@freebsd.org, current@freebsd.org Subject: Re: New dhclient broke multiple domains in domain-name 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, 16 Jun 2005 19:46:48 -0000 John Baldwin wrote: > [ Apologies if this has already been brought up, I'm still 1800 messages > behind on current@. ] > > A feature of both the old and new dhclient(8) is that it would take whatever > was in the domain-name option returned by the DHCP server and stick it in the > 'search' line in /etc/resolv.conf. Thus, if you wanted to have DNS search > multiple domains, you could just pass a space separated list of domains to > search in domain-name and it would just work. I've made use of this > "feature" in several different environments in the past including my current > test lab. It's even used in the example dhclient.conf in dhclient.conf(5): > > interface "ep0" { > send host-name "andare.fugue.com"; > send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; > send dhcp-lease-time 3600; > supersede domain-name "fugue.com rc.vix.com home.vix.com"; > prepend domain-name-servers 127.0.0.1; > ... > } > > The new dhclient is barfing on my domain-name setting now because it doesn't > look like a domain name: > > Setting hostname: deimos.baldwin.cx. > fxp0: link state changed to UP > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 8 > DHCPOFFER from 192.168.0.1 > Bogus Host Name option 15: baldwin.cx freebsd.org atl.weather.com (baldwin.cx > freebsd.org atl.weather.com) > Invalid lease option - ignoring offer > packet_to_lease failed. > DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 10 > DHCPOFFER from 192.168.0.1 > Bogus Host Name option 15: baldwin.cx freebsd.org atl.weather.com (baldwin.cx > freebsd.org atl.weather.com) > Invalid lease option - ignoring offer > packet_to_lease failed. > ... > > I'd very much like the old behavior restored if possible, or an alternative > way to achieve the same result (multiple domains in the 'search' part > of /etc/resolv.conf). Note that the old domain-name trick has worked all the > way back to at least 4.1 and maybe even back in the 3.x days IIRC. > Known issue being worked on. You're actually violating the spec but I know that's less important than having a way to do what you want. Sam From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 19:54: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 0426E16A41C for ; Thu, 16 Jun 2005 19:54:06 +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 B487143D60 for ; Thu, 16 Jun 2005 19:54:05 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j5GJs4ms016101 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2005 12:54:05 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42B1D9D9.7040604@errno.com> Date: Thu, 16 Jun 2005 12:58:17 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Snow References: <20050616191450.GA98695@teardrop.org> In-Reply-To: <20050616191450.GA98695@teardrop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WPA Supplicant doesn't see my SSIDs? 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, 16 Jun 2005 19:54:06 -0000 James Snow wrote: > Now that we've got WPA support I decided to give it a whirl with one of > the WPA-enabled wireless networks I spend time near. I've successfully > brought up a Windows machine on this network, but FreeBSD eludes me. It > seems like the ath driver or wpa_supplicant are not seeing the SSID for > some reason. > > /etc/wpa_supplicant.conf: > > ctrl_interface=/var/run/wpa_supplicant > ctrl_interface_group=0 > eapol_version=1 > ap_scan=1 > > network={ > ssid="external" > scan_ssid=1 > psk="MyPreSharedKey" > } > > Output from wpa_supplicant -ddKt -i ath0 -c /etc/wpa_supplicant.conf -Dbsd: > > Jun 16 15:02:16.600289: Initializing interface 'ath0' conf > '/etc/wpa_supplicant.conf' driver 'default' > Jun 16 15:02:16.600422: Configuration file '/etc/wpa_supplicant.conf' -> > '/etc/wpa_supplicant.conf' > Jun 16 15:02:16.600440: Reading configuration file > '/etc/wpa_supplicant.conf' > Jun 16 15:02:16.600483: ctrl_interface='/var/run/wpa_supplicant' > Jun 16 15:02:16.600950: ctrl_interface_group=0 > Jun 16 15:02:16.600973: eapol_version=1 > Jun 16 15:02:16.600984: ap_scan=1 > Jun 16 15:02:16.600992: Line: 6 - start of a new network block > Jun 16 15:02:16.601005: ssid - hexdump_ascii(len=8): > 65 78 74 65 72 6e 61 6c external > Jun 16 15:02:16.601026: scan_ssid=1 (0x1) > > ... ... > > Jun 16 15:02:16.677502: Priority group 0 > Jun 16 15:02:16.677512: id=0 ssid='external' > Jun 16 15:02:16.677523: Initializing interface (2) 'ath0' > Jun 16 15:02:16.677847: Own MAC address: 00:0e:9b:6e:60:fc > Jun 16 15:02:16.677862: wpa_driver_bsd_set_wpa: enabled=1 > Jun 16 15:02:16.677875: wpa_driver_bsd_del_key: keyidx=0 > Jun 16 15:02:16.677888: wpa_driver_bsd_del_key: keyidx=1 > Jun 16 15:02:16.677899: wpa_driver_bsd_del_key: keyidx=2 > Jun 16 15:02:16.677910: wpa_driver_bsd_del_key: keyidx=3 > Jun 16 15:02:16.677921: wpa_driver_bsd_set_countermeasures: enabled=0 > Jun 16 15:02:16.677931: wpa_driver_bsd_set_drop_unencrypted: enabled=1 > Jun 16 15:02:16.677947: Setting scan request: 0 sec 100000 usec > Jun 16 15:02:16.778153: Starting AP scan (specific SSID) > Jun 16 15:02:16.778167: Scan SSID - hexdump_ascii(len=8): > 65 78 74 65 72 6e 61 6c external > Jun 16 15:02:24.734030: Received 0 bytes of scan results (4 BSSes) > Jun 16 15:02:24.734051: Scan results: 4 > Jun 16 15:02:24.734065: Selecting BSS from priority group 0 > Jun 16 15:02:24.734075: 0: 00:0e:83:af:77:f5 ssid='' wpa_ie_len=26 rsn_ie_len=0 > Jun 16 15:02:24.734087: skip - SSID mismatch > Jun 16 15:02:24.734096: 1: 00:0e:38:51:ca:6c ssid='' wpa_ie_len=26 rsn_ie_len=0 > Jun 16 15:02:24.734108: skip - SSID mismatch > Jun 16 15:02:24.734116: 2: 00:0f:66:18:20:00 ssid='SDC-WAP-001' wpa_ie_len=0 > rsn_ie_len=0 > Jun 16 15:02:24.734129: skip - no WPA/RSN IE > Jun 16 15:02:24.734137: 3: 00:07:eb:30:c6:de ssid='' wpa_ie_len=0 rsn_ie_len=0 > Jun 16 15:02:24.734149: skip - no WPA/RSN IE > Jun 16 15:02:24.734157: No suitable AP found. > Jun 16 15:02:24.734168: Setting scan request: 5 sec 0 usec > ^CJun 16 15:02:26.482136: Signal 2 received - terminating > Jun 16 15:02:26.482153: No keys have been configured - skip key clearing > Jun 16 15:02:26.482163: wpa_driver_bsd_set_wpa: enabled=0 > Jun 16 15:02:26.482180: wpa_driver_bsd_set_drop_unencrypted: enabled=0 > Jun 16 15:02:26.482191: wpa_driver_bsd_set_countermeasures: enabled=0 > Jun 16 15:02:26.482202: No keys have been configured - skip key clearing > Jun 16 15:02:26.485314: wpa_driver_bsd_set_wpa: enabled=0 > > I know from my Windows machine that the MAC addresses for my APs are IDs > 0 and 1 in the above output. 2 and 3 are some other networks that also > happen to be in the area. The odd thing is the empty SSID string which > leads to an SSID mismatch. I tried setting my SSID string to an empty > string ("") but still got a mismatch. > > Even if I had the PSK wrong or some other encryption setting wrong, I > should still see the SSID, shouldn't I? > > Any suggestions? What does ifconfig ath0 list scan show? Try not setting scan_ssid in the network block; not sure that it does anything useful. Also you terminate the scan after one try; when a channel is crowded sometimes the first scan may not find all ap's on it. You can also build the 80211debug program in src/tools/tools/ath and do 80211debug scan to get debug msgs from kernel sent to the console. Sam From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 20:11: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 436D216A41C for ; Thu, 16 Jun 2005 20:11:12 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9B1E43D4C for ; Thu, 16 Jun 2005 20:11:11 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5GKB9Hj014461; Thu, 16 Jun 2005 13:11:09 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5GKB9Hj014460; Thu, 16 Jun 2005 13:11:09 -0700 Date: Thu, 16 Jun 2005 13:11:09 -0700 From: Brooks Davis To: Sam Leffler Message-ID: <20050616201109.GA13900@odin.ac.hmc.edu> References: <20050616191450.GA98695@teardrop.org> <42B1D9D9.7040604@errno.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: <42B1D9D9.7040604@errno.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: freebsd-current@freebsd.org, James Snow Subject: Re: WPA Supplicant doesn't see my SSIDs? 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, 16 Jun 2005 20:11:12 -0000 --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 16, 2005 at 12:58:17PM -0700, Sam Leffler wrote: > James Snow wrote: > >Now that we've got WPA support I decided to give it a whirl with one of > >the WPA-enabled wireless networks I spend time near. I've successfully > >brought up a Windows machine on this network, but FreeBSD eludes me. It > >seems like the ath driver or wpa_supplicant are not seeing the SSID for > >some reason. > > > >/etc/wpa_supplicant.conf: > > > >ctrl_interface=3D/var/run/wpa_supplicant > >ctrl_interface_group=3D0 > >eapol_version=3D1 > >ap_scan=3D1 > > > >network=3D{ > > ssid=3D"external" > > scan_ssid=3D1 > > psk=3D"MyPreSharedKey" > >} > > > >Output from wpa_supplicant -ddKt -i ath0 -c /etc/wpa_supplicant.conf -Db= sd: > > > >Jun 16 15:02:16.600289: Initializing interface 'ath0' conf=20 > >'/etc/wpa_supplicant.conf' driver 'default' > >Jun 16 15:02:16.600422: Configuration file '/etc/wpa_supplicant.conf' -> > >'/etc/wpa_supplicant.conf' > >Jun 16 15:02:16.600440: Reading configuration file > >'/etc/wpa_supplicant.conf' > >Jun 16 15:02:16.600483: ctrl_interface=3D'/var/run/wpa_supplicant' > >Jun 16 15:02:16.600950: ctrl_interface_group=3D0 > >Jun 16 15:02:16.600973: eapol_version=3D1 > >Jun 16 15:02:16.600984: ap_scan=3D1 > >Jun 16 15:02:16.600992: Line: 6 - start of a new network block > >Jun 16 15:02:16.601005: ssid - hexdump_ascii(len=3D8): > > 65 78 74 65 72 6e 61 6c external = =20 > >Jun 16 15:02:16.601026: scan_ssid=3D1 (0x1) > > > >... ... > > > >Jun 16 15:02:16.677502: Priority group 0 > >Jun 16 15:02:16.677512: id=3D0 ssid=3D'external' > >Jun 16 15:02:16.677523: Initializing interface (2) 'ath0' > >Jun 16 15:02:16.677847: Own MAC address: 00:0e:9b:6e:60:fc > >Jun 16 15:02:16.677862: wpa_driver_bsd_set_wpa: enabled=3D1 > >Jun 16 15:02:16.677875: wpa_driver_bsd_del_key: keyidx=3D0 > >Jun 16 15:02:16.677888: wpa_driver_bsd_del_key: keyidx=3D1 > >Jun 16 15:02:16.677899: wpa_driver_bsd_del_key: keyidx=3D2 > >Jun 16 15:02:16.677910: wpa_driver_bsd_del_key: keyidx=3D3 > >Jun 16 15:02:16.677921: wpa_driver_bsd_set_countermeasures: enabled=3D0 > >Jun 16 15:02:16.677931: wpa_driver_bsd_set_drop_unencrypted: enabled=3D1 > >Jun 16 15:02:16.677947: Setting scan request: 0 sec 100000 usec > >Jun 16 15:02:16.778153: Starting AP scan (specific SSID) > >Jun 16 15:02:16.778167: Scan SSID - hexdump_ascii(len=3D8): > > 65 78 74 65 72 6e 61 6c external = =20 > >Jun 16 15:02:24.734030: Received 0 bytes of scan results (4 BSSes) > >Jun 16 15:02:24.734051: Scan results: 4 > >Jun 16 15:02:24.734065: Selecting BSS from priority group 0 > >Jun 16 15:02:24.734075: 0: 00:0e:83:af:77:f5 ssid=3D'' wpa_ie_len=3D26= =20 > >rsn_ie_len=3D0 > >Jun 16 15:02:24.734087: skip - SSID mismatch > >Jun 16 15:02:24.734096: 1: 00:0e:38:51:ca:6c ssid=3D'' wpa_ie_len=3D26= =20 > >rsn_ie_len=3D0 > >Jun 16 15:02:24.734108: skip - SSID mismatch > >Jun 16 15:02:24.734116: 2: 00:0f:66:18:20:00 ssid=3D'SDC-WAP-001'=20 > >wpa_ie_len=3D0 rsn_ie_len=3D0 > >Jun 16 15:02:24.734129: skip - no WPA/RSN IE=20 > >Jun 16 15:02:24.734137: 3: 00:07:eb:30:c6:de ssid=3D'' wpa_ie_len=3D0=20 > >rsn_ie_len=3D0 > >Jun 16 15:02:24.734149: skip - no WPA/RSN IE > >Jun 16 15:02:24.734157: No suitable AP found. > >Jun 16 15:02:24.734168: Setting scan request: 5 sec 0 usec > >^CJun 16 15:02:26.482136: Signal 2 received - terminating > >Jun 16 15:02:26.482153: No keys have been configured - skip key clearing > >Jun 16 15:02:26.482163: wpa_driver_bsd_set_wpa: enabled=3D0 > >Jun 16 15:02:26.482180: wpa_driver_bsd_set_drop_unencrypted: enabled=3D0 > >Jun 16 15:02:26.482191: wpa_driver_bsd_set_countermeasures: enabled=3D0 > >Jun 16 15:02:26.482202: No keys have been configured - skip key clearing > >Jun 16 15:02:26.485314: wpa_driver_bsd_set_wpa: enabled=3D0 > > > >I know from my Windows machine that the MAC addresses for my APs are IDs > >0 and 1 in the above output. 2 and 3 are some other networks that also > >happen to be in the area. The odd thing is the empty SSID string which > >leads to an SSID mismatch. I tried setting my SSID string to an empty > >string ("") but still got a mismatch. > > > >Even if I had the PSK wrong or some other encryption setting wrong, I > >should still see the SSID, shouldn't I? > > > >Any suggestions? >=20 > What does ifconfig ath0 list scan show? Try not setting scan_ssid in=20 > the network block; not sure that it does anything useful. Also you=20 > terminate the scan after one try; when a channel is crowded sometimes=20 > the first scan may not find all ap's on it. >=20 > You can also build the 80211debug program in src/tools/tools/ath and do= =20 > 80211debug scan to get debug msgs from kernel sent to the console. scan_ssid does work (or at least did a couple months ago), but it's only useful for annoying networks that disable broadcast SSID. It really cuts into association performance when it's on since you can't associate with anything else while it's scanning for the AP. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCsdzdXY6L6fI4GtQRAkHwAJ9+On7LJgcU37K4oekTYU7rfH1kXgCdEUyy i8LHg3wHm0xRQP6yrQEmPUU= =jhts -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 20:11: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 B1DC916A41C for ; Thu, 16 Jun 2005 20:11:48 +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 72B1143D49 for ; Thu, 16 Jun 2005 20:11:48 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.94] ([66.127.85.94]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j5GKBlms016281 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2005 13:11:48 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42B1DD17.3000601@errno.com> Date: Thu, 16 Jun 2005 13:12:07 -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: James Snow References: <20050616191450.GA98695@teardrop.org> <42B1D9D9.7040604@errno.com> <20050616200450.GB98695@teardrop.org> In-Reply-To: <20050616200450.GB98695@teardrop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WPA Supplicant doesn't see my SSIDs? 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, 16 Jun 2005 20:11:48 -0000 James Snow wrote: > On Thu, Jun 16, 2005 at 12:58:17PM -0700, Sam Leffler wrote: > >>What does ifconfig ath0 list scan show? > > > SSID BSSID CHAN RATE S:N INT CAPS > 0... 00:0e:83:af:77:f5 40 54M 27:0 100 EP WPA WME > 0... 00:0e:38:51:ca:6c 52 54M 28:0 100 EP WPA WME > 0x000000000... 00:07:eb:30:c6:de 1 11M 27:0 100 EPS > SDC-WAP-001 00:0f:66:18:20:00 6 11M 7:0 100 E > > My Windows box confirms that 00:0e:83:af:77:f5 is on channel 40, so > there's definitely some communication taking place. Are these ap's hiding their ssid? Logs from the kernel with scan debug enabled would be useful. I thought the probe request frames were sent with a directed ssid in them but the current scanning code is kinda stupid in this area. I've totally rewritten it but that won't go in 6.0. Sam From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 20:16: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 5ED0F16A420; Thu, 16 Jun 2005 20:16:48 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB4A643D55; Thu, 16 Jun 2005 20:16:47 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5GKGk8P015324; Thu, 16 Jun 2005 13:16:46 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5GKGk6e015323; Thu, 16 Jun 2005 13:16:46 -0700 Date: Thu, 16 Jun 2005 13:16:46 -0700 From: Brooks Davis To: Sam Leffler Message-ID: <20050616201646.GC13900@odin.ac.hmc.edu> References: <200506161312.51857.jhb@FreeBSD.org> <42B1D823.5030108@errno.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="7gGkHNMELEOhSGF6" Content-Disposition: inline In-Reply-To: <42B1D823.5030108@errno.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@freebsd.org Subject: Re: New dhclient broke multiple domains in domain-name 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, 16 Jun 2005 20:16:48 -0000 --7gGkHNMELEOhSGF6 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 16, 2005 at 12:50:59PM -0700, Sam Leffler wrote: > John Baldwin wrote: > >[ Apologies if this has already been brought up, I'm still 1800 messages= =20 > >behind on current@. ] > > > >A feature of both the old and new dhclient(8) is that it would take=20 > >whatever was in the domain-name option returned by the DHCP server and= =20 > >stick it in the 'search' line in /etc/resolv.conf. Thus, if you wanted = to=20 > >have DNS search multiple domains, you could just pass a space separated= =20 > >list of domains to search in domain-name and it would just work. I've= =20 > >made use of this "feature" in several different environments in the past= =20 > >including my current test lab. It's even used in the example=20 > >dhclient.conf in dhclient.conf(5): > > > > interface "ep0" { > > send host-name "andare.fugue.com"; > > send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; > > send dhcp-lease-time 3600; > > supersede domain-name "fugue.com rc.vix.com home.vix.com"; > > prepend domain-name-servers 127.0.0.1; > > ... > > } > > > >The new dhclient is barfing on my domain-name setting now because it=20 > >doesn't look like a domain name: > > > >Setting hostname: deimos.baldwin.cx. > >fxp0: link state changed to UP > >DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 8 > >DHCPOFFER from 192.168.0.1 > >Bogus Host Name option 15: baldwin.cx freebsd.org atl.weather.com=20 > >(baldwin.cx freebsd.org atl.weather.com) > >Invalid lease option - ignoring offer > >packet_to_lease failed. > >DHCPDISCOVER on fxp0 to 255.255.255.255 port 67 interval 10 > >DHCPOFFER from 192.168.0.1 > >Bogus Host Name option 15: baldwin.cx freebsd.org atl.weather.com=20 > >(baldwin.cx freebsd.org atl.weather.com) > >Invalid lease option - ignoring offer > >packet_to_lease failed. > >... > > > >I'd very much like the old behavior restored if possible, or an=20 > >alternative way to achieve the same result (multiple domains in the=20 > >'search' part of /etc/resolv.conf). Note that the old domain-name trick= =20 > >has worked all the way back to at least 4.1 and maybe even back in the 3= .x=20 > >days IIRC. > > >=20 > Known issue being worked on. You're actually violating the spec but I=20 > know that's less important than having a way to do what you want. The RFC is shockingly lacking in this area. It's rather odd that they send a value for domain, but not for search (in resolv.conf). It's not suprising that people ended up abusing this to set search. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --7gGkHNMELEOhSGF6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCsd4tXY6L6fI4GtQRAvi7AJ9lSMkGQxr+wXWBH9o9oVz9GCBo9gCeKdoT +3qKsLMBXWT/a1HL/veoBDU= =V5Qa -----END PGP SIGNATURE----- --7gGkHNMELEOhSGF6-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 20:26: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 5275416A41C for ; Thu, 16 Jun 2005 20:26:30 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0EC5343D1F for ; Thu, 16 Jun 2005 20:26:29 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5GKP78K044502; Thu, 16 Jun 2005 14:25:07 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 16 Jun 2005 14:25:07 -0600 (MDT) Message-Id: <20050616.142507.85367515.imp@bsdimp.com> To: brooks@one-eyed-alien.net From: Warner Losh In-Reply-To: <20050616164747.GB21733@odin.ac.hmc.edu> References: <20050615061009.GA11914@odin.ac.hmc.edu> <001501c5720b$aceb84d0$0b2a15ac@SMILEY> <20050616164747.GB21733@odin.ac.hmc.edu> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: vova@fbsd.ru, dmp@bitfreak.org, matt@gsicomp.on.ca, freebsd-current@freebsd.org Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 20:26:30 -0000 From: Brooks Davis Subject: Re: HEADSUP: OpenBSD dhclient incoming Date: Thu, 16 Jun 2005 09:47:47 -0700 > On Wed, Jun 15, 2005 at 05:38:10PM -0700, Darren Pilgrim wrote: > > From: Brooks Davis > > > There are two issues here. First, if we're going to keep > > > network_interfaces around, /etc/rc.d/dhclient should honor > > > it and not start dhclient on interfaces not in either > > > network_interfaces or removable interfaces. > > > > I think network_interfaces should be gotten rid of entirely for two > > reasons: > > > > 1: It creates a synchronization issue between it and the ifconfig_* > > lines and duplicates functionality. IIRC, rc.conf being out of sync in > > this way has tripped up users in the past. > > > > 2: There are real configurations in which some interfaces are not > > available when netif is run at boot. One example is the many newer > > mini-PCI wireless NICs that require a firmware upload. Devd is the > > accepted tool for performing such tasks, but rcordering puts devd after > > NETWORKING. The actions taken by devd must therefore include steps > > taken by netif. Calling the rc.d scripts directly from devd avoids > > local scripts that duplicate rc.d functionality. A similar situation > > occurs for removable interfaces. > > I'm seriously considering removing the following variables: > > network_interfaces > removable_interfaces > pccard_ether pccard_ifconfig you mean? > If I do that I'll probably add a pair of new start/stop targets to > /etc/rc.d/netif to replicate the remaining functions of pccard_ether > and nuke /etc/pccard_ether. I invented pccard_ifconfig to be done whenever a new device appeared on the system. I test about 20 different drivers these days, and having that many different ifconfig_foo= lines was burdonsome. I'd love to see the fallback functionality that this provided retained somehow. Warner From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 20:32: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 BEC4016A41C for ; Thu, 16 Jun 2005 20:32:08 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 89ADB43D49 for ; Thu, 16 Jun 2005 20:32:08 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5GKUiQ1044572; Thu, 16 Jun 2005 14:30:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 16 Jun 2005 14:30:44 -0600 (MDT) Message-Id: <20050616.143044.39199713.imp@bsdimp.com> To: hiten.pandya@gmail.com From: Warner Losh In-Reply-To: <42b1adba.776977e2.0b2a.ffffa239@mx.gmail.com> References: <42b1adba.776977e2.0b2a.ffffa239@mx.gmail.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: 3com 357c issues 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, 16 Jun 2005 20:32:08 -0000 > Since I upgraded the machine to -HEAD from 5.3, two of my 3com cardbus > network cards have stopped working. > > I am receiving watchdog timeouts for my 3com 3c575C card; dmesg is showing > the following before the xl0 lines: > > cardbus0: Resource not specified in CIS: id=14, size=80 > cardbus0: Resource not specified in CIS: id=18, size=80 > > One of my other cardbus card, 3Com 3c575TX is also having issue; when > booting up the dmesg shows: > > xl0: <3com 3c575TX Fast Etherlink XL...> > xl0: couldn't map ports/memory > > > Give me a shout if more debug output is required for this problem. Please provide the standard things I always ask for: set the following in /boot/loader.confg: hw.pccard.debug=1 hw.cardbus.debug=1 hw.cardbus.cis_debug=1 hw.cbb.debug=1 and boot -v and send me the resulting dmesg. These cards work for me as of just before the inet changes. Warner From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 20:39: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 887B916A41C for ; Thu, 16 Jun 2005 20:39:53 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: from imladris.teardrop.org (imladris.teardrop.org [66.92.66.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 532F543D48 for ; Thu, 16 Jun 2005 20:39:53 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: by imladris.teardrop.org (Postfix, from userid 100) id A0E40BF6FB; Thu, 16 Jun 2005 16:40:44 -0400 (EDT) Date: Thu, 16 Jun 2005 16:40:44 -0400 From: James Snow To: Sam Leffler Message-ID: <20050616204044.GC98695@teardrop.org> References: <20050616191450.GA98695@teardrop.org> <42B1D9D9.7040604@errno.com> <20050616200450.GB98695@teardrop.org> <42B1DD17.3000601@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42B1DD17.3000601@errno.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: WPA Supplicant doesn't see my SSIDs? 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, 16 Jun 2005 20:39:53 -0000 On Thu, Jun 16, 2005 at 01:12:07PM -0700, Sam Leffler wrote: > > Are these ap's hiding their ssid? Seems so. Apparently they recently upgraded IOS on these APs and it did all kinds of strange things to them. They checked off the bizzarely named box that enabled SSID broadcasts and now I see the SSID: x40# ifconfig ath0 list scan SSID BSSID CHAN RATE S:N INT CAPS 0x000000000... 00:07:eb:30:c6:de 1 11M 30:0 100 EPS SDC-WAP-001 00:0f:66:18:20:00 6 11M 5:0 100 E external 00:0e:83:af:77:f5 40 54M 28:0 100 EP WPA WME 0... 00:0e:38:51:ca:6c 52 54M 30:0 100 EP WPA WME Then four EAPOL keys are exchanged and: Jun 16 16:33:54.345757: WPA: Installing PTK to the driver. Jun 16 16:33:54.345767: WPA: RSC - hexdump(len=6): 00 00 00 00 00 00 Jun 16 16:33:54.345804: wpa_driver_bsd_set_key: alg=TKIP key_idx=0 set_tx=1 seq_len=6 key_len=32 ioctl[SIOCS80211, op 19, len 60]: Device not configured Jun 16 16:33:54.345862: WPA: Failed to set PTK to the driver. Jun 16 16:33:54.647313: Setting scan request: 0 sec 100000 usec Jun 16 16:33:54.647344: Added BSSID 00:0e:83:af:77:f5 into blacklist Jun 16 16:33:54.647358: Disconnect event - remove keys My ath card at boot: ath0: mem 0xd0200000-0xd020ffff irq 11 at device 2.0 on pci2 ath0: Ethernet address: 00:0e:9b:6e:60:fc ath0: mac 5.9 phy 4.3 radio 3.6 It's the onboard wireless in a ThinkPad X40, 2371H9U. -Snow From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 20:50:39 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 C393016A41C for ; Thu, 16 Jun 2005 20:50:39 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9B27243D48 for ; Thu, 16 Jun 2005 20:50:39 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5GKoYST019393; Thu, 16 Jun 2005 13:50:34 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5GKoXtg019392; Thu, 16 Jun 2005 13:50:33 -0700 Date: Thu, 16 Jun 2005 13:50:33 -0700 From: Brooks Davis To: Warner Losh Message-ID: <20050616205033.GF13900@odin.ac.hmc.edu> References: <20050615061009.GA11914@odin.ac.hmc.edu> <001501c5720b$aceb84d0$0b2a15ac@SMILEY> <20050616164747.GB21733@odin.ac.hmc.edu> <20050616.142507.85367515.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NGIwU0kFl1Z1A3An" Content-Disposition: inline In-Reply-To: <20050616.142507.85367515.imp@bsdimp.com> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: vova@fbsd.ru, dmp@bitfreak.org, matt@gsicomp.on.ca, freebsd-current@freebsd.org Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 20:50:40 -0000 --NGIwU0kFl1Z1A3An Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 16, 2005 at 02:25:07PM -0600, Warner Losh wrote: > From: Brooks Davis > Subject: Re: HEADSUP: OpenBSD dhclient incoming > Date: Thu, 16 Jun 2005 09:47:47 -0700 >=20 > > On Wed, Jun 15, 2005 at 05:38:10PM -0700, Darren Pilgrim wrote: > > > From: Brooks Davis > > > > There are two issues here. First, if we're going to keep > > > > network_interfaces around, /etc/rc.d/dhclient should honor > > > > it and not start dhclient on interfaces not in either > > > > network_interfaces or removable interfaces. > > >=20 > > > I think network_interfaces should be gotten rid of entirely for two > > > reasons: > > >=20 > > > 1: It creates a synchronization issue between it and the ifconfig_* > > > lines and duplicates functionality. IIRC, rc.conf being out of sync = in > > > this way has tripped up users in the past. > > >=20 > > > 2: There are real configurations in which some interfaces are not > > > available when netif is run at boot. One example is the many newer > > > mini-PCI wireless NICs that require a firmware upload. Devd is the > > > accepted tool for performing such tasks, but rcordering puts devd aft= er > > > NETWORKING. The actions taken by devd must therefore include steps > > > taken by netif. Calling the rc.d scripts directly from devd avoids > > > local scripts that duplicate rc.d functionality. A similar situation > > > occurs for removable interfaces. > >=20 > > I'm seriously considering removing the following variables: > >=20 > > network_interfaces > > removable_interfaces > > pccard_ether >=20 > pccard_ifconfig you mean? >=20 > > If I do that I'll probably add a pair of new start/stop targets to > > /etc/rc.d/netif to replicate the remaining functions of pccard_ether > > and nuke /etc/pccard_ether. >=20 > I invented pccard_ifconfig to be done whenever a new device appeared > on the system. I test about 20 different drivers these days, and > having that many different ifconfig_foo=3D lines was burdonsome. I'd > love to see the fallback functionality that this provided retained > somehow. Agreed. There's actually some demand for a default for wired interfaces as well. If nothing else I know the EmuLab people would like one so they didn't have to use their own scripts to configure all the interfaces. I've thought about it a bit. I'm leaning towards a default_ifconfig variable plus a new magic ifconfig_ option NONE to cause the default option not to be used. One other issue here is that I'm not sure what happens if you try to run dhcp on a hardware point-to-point link. At least with ppp(4) it just fails and exits. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --NGIwU0kFl1Z1A3An Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCseYZXY6L6fI4GtQRAlM/AKCimvIJ6gRkel4+gKwhqF9kYr9NcwCfUURS KQ6yLOu+swYIXcXpFeKvHDE= =SKoH -----END PGP SIGNATURE----- --NGIwU0kFl1Z1A3An-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 20:53: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 AC0B316A41C for ; Thu, 16 Jun 2005 20:53:31 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8841E43D48 for ; Thu, 16 Jun 2005 20:53:31 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5GKrTSJ019794; Thu, 16 Jun 2005 13:53:29 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5GKrTjC019793; Thu, 16 Jun 2005 13:53:29 -0700 Date: Thu, 16 Jun 2005 13:53:29 -0700 From: Brooks Davis To: Garrett Wollman Message-ID: <20050616205329.GG13900@odin.ac.hmc.edu> References: <200506161312.51857.jhb@FreeBSD.org> <42B1D823.5030108@errno.com> <20050616201646.GC13900@odin.ac.hmc.edu> <17073.58552.862249.81604@khavrinen.csail.mit.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="NPukt5Otb9an/u20" Content-Disposition: inline In-Reply-To: <17073.58552.862249.81604@khavrinen.csail.mit.edu> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@FreeBSD.ORG Subject: Re: New dhclient broke multiple domains in domain-name 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, 16 Jun 2005 20:53:31 -0000 --NPukt5Otb9an/u20 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 16, 2005 at 04:44:40PM -0400, Garrett Wollman wrote: > < said: >=20 > > The RFC is shockingly lacking in this area. It's rather odd that they > > send a value for domain, but not for search (in resolv.conf). It's not > > suprising that people ended up abusing this to set search. >=20 > There is a standard (unless it didn't make it out of I-D) for doing > this. The shocking thing is that isc-dhcp(d) has never supported it. > I used to have something like this in my dhcpd.conf: >=20 > #option domain-search-order code 119 =3D string; > # > # This was generated using the following command: > # perl -e 'print "\3lcs\3mit\3edu\0\2ai\xc0\4\xc0\4\2w3\3org\0"' | = hd > # ...and represents the search-list lcs.mit.edu, ai.mit.edu, mit.edu, w3.= org > # in DNS compressed encoding. > # > #option domain-search-order 03:6c:63:73:03:6d:69:74:03:65:64:75:00:02:61:= 69:c0:0 > 4:c0:04:02:77:33:03:6f:72:67:00; >=20 > AFAIK not even Microsoft clients bother to implement this. It doesn't look like this made it out of the working group, at least I can't find anything like it in RFC2132. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --NPukt5Otb9an/u20 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCsebIXY6L6fI4GtQRArDzAJ4vWtn6FFNTuS6vyHzeECCUQO6zVgCgrcuu KDNjng1NxHtEkt8f7rbaNJ0= =438h -----END PGP SIGNATURE----- --NPukt5Otb9an/u20-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 21:00: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 5DF2316A41C for ; Thu, 16 Jun 2005 21:00:48 +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 3032E43D49 for ; Thu, 16 Jun 2005 21:00:48 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j5GL0kms016568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2005 14:00:47 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42B1E97B.5070408@errno.com> Date: Thu, 16 Jun 2005 14:04:59 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Snow References: <20050616191450.GA98695@teardrop.org> <42B1D9D9.7040604@errno.com> <20050616200450.GB98695@teardrop.org> <42B1DD17.3000601@errno.com> <20050616204044.GC98695@teardrop.org> In-Reply-To: <20050616204044.GC98695@teardrop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WPA Supplicant doesn't see my SSIDs? 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, 16 Jun 2005 21:00:48 -0000 James Snow wrote: > On Thu, Jun 16, 2005 at 01:12:07PM -0700, Sam Leffler wrote: > >>Are these ap's hiding their ssid? > > > Seems so. Apparently they recently upgraded IOS on these APs and it did > all kinds of strange things to them. They checked off the bizzarely > named box that enabled SSID broadcasts and now I see the SSID: > > x40# ifconfig ath0 list scan > SSID BSSID CHAN RATE S:N INT CAPS > 0x000000000... 00:07:eb:30:c6:de 1 11M 30:0 100 EPS > SDC-WAP-001 00:0f:66:18:20:00 6 11M 5:0 100 E > external 00:0e:83:af:77:f5 40 54M 28:0 100 EP WPA WME > 0... 00:0e:38:51:ca:6c 52 54M 30:0 100 EP WPA WME > > Then four EAPOL keys are exchanged and: > > Jun 16 16:33:54.345757: WPA: Installing PTK to the driver. > Jun 16 16:33:54.345767: WPA: RSC - hexdump(len=6): 00 00 00 00 00 00 > Jun 16 16:33:54.345804: wpa_driver_bsd_set_key: alg=TKIP key_idx=0 > set_tx=1 seq_len=6 key_len=32 > ioctl[SIOCS80211, op 19, len 60]: Device not configured > Jun 16 16:33:54.345862: WPA: Failed to set PTK to the driver. > Jun 16 16:33:54.647313: Setting scan request: 0 sec 100000 usec > Jun 16 16:33:54.647344: Added BSSID 00:0e:83:af:77:f5 into blacklist > Jun 16 16:33:54.647358: Disconnect event - remove keys > > My ath card at boot: > > ath0: mem 0xd0200000-0xd020ffff irq 11 at device 2.0 on > pci2 > ath0: Ethernet address: 00:0e:9b:6e:60:fc > ath0: mac 5.9 phy 4.3 radio 3.6 > > It's the onboard wireless in a ThinkPad X40, 2371H9U. dmesg will show you don't have wlan_tkip loaded. If you can disable the ssid again and collect a kernel debug log for me I'll try to fix the hidden ssid problem. Please send that privately. Sam From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 21:03: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 8BC4916A41C for ; Thu, 16 Jun 2005 21:03:56 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: from imladris.teardrop.org (imladris.teardrop.org [66.92.66.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5A97843D1F for ; Thu, 16 Jun 2005 21:03:56 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: by imladris.teardrop.org (Postfix, from userid 100) id 013C4BF6AB; Thu, 16 Jun 2005 17:04:47 -0400 (EDT) Date: Thu, 16 Jun 2005 17:04:47 -0400 From: James Snow To: Sam Leffler Message-ID: <20050616210447.GD98695@teardrop.org> References: <20050616191450.GA98695@teardrop.org> <42B1D9D9.7040604@errno.com> <20050616200450.GB98695@teardrop.org> <42B1DD17.3000601@errno.com> <20050616204044.GC98695@teardrop.org> <42B1E97B.5070408@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42B1E97B.5070408@errno.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, James Snow Subject: Re: WPA Supplicant doesn't see my SSIDs? 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, 16 Jun 2005 21:03:56 -0000 On Thu, Jun 16, 2005 at 02:04:59PM -0700, Sam Leffler wrote: > > dmesg will show you don't have wlan_tkip loaded. ieee80211_load_module: load the wlan_tkip module by hand for now. Indeed. Sorry for missing the obvious. > If you can disable the ssid again and collect a kernel debug log for me > I'll try to fix the hidden ssid problem. Please send that privately. Will do. Once again, thank you for your help over the past week. -Snow From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 21:04:05 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 7AABB16A41C for ; Thu, 16 Jun 2005 21:04:05 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (adsl-63-193-123-122.dsl.snfc21.pacbell.net [63.193.123.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 50D3D43D1F for ; Thu, 16 Jun 2005 21:04:05 +0000 (GMT) (envelope-from david@catwhisker.org) Received: from bunrab.catwhisker.org (localhost [127.0.0.1]) by bunrab.catwhisker.org (8.13.3/8.13.3) with ESMTP id j5GL44Jx035283 for ; Thu, 16 Jun 2005 14:04:04 -0700 (PDT) (envelope-from david@bunrab.catwhisker.org) Received: (from david@localhost) by bunrab.catwhisker.org (8.13.3/8.13.1/Submit) id j5GL44HU035282 for current@freebsd.org; Thu, 16 Jun 2005 14:04:04 -0700 (PDT) (envelope-from david) Date: Thu, 16 Jun 2005 14:04:04 -0700 From: David Wolfskill To: current@freebsd.org Message-ID: <20050616210404.GM33118@bunrab.catwhisker.org> Mail-Followup-To: David Wolfskill , current@freebsd.org References: <20050615061009.GA11914@odin.ac.hmc.edu> <001501c5720b$aceb84d0$0b2a15ac@SMILEY> <20050616164747.GB21733@odin.ac.hmc.edu> <20050616.142507.85367515.imp@bsdimp.com> <20050616205033.GF13900@odin.ac.hmc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050616205033.GF13900@odin.ac.hmc.edu> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 21:04:05 -0000 On Thu, Jun 16, 2005 at 01:50:33PM -0700, Brooks Davis wrote: > ... > Agreed. There's actually some demand for a default for wired interfaces > as well. If nothing else I know the EmuLab people would like one > so they didn't have to use their own scripts to configure all the > interfaces. I've thought about it a bit. I'm leaning towards a > default_ifconfig variable plus a new magic ifconfig_ option NONE to > cause the default option not to be used. >From the perspective that NIC-specific variables are of the form "ifconfig_${NIC}" (e.g., ifconfig_lo0; ifconfig_ed0; ifconfig_xl0), might it make at least as much sense to call it "ifconfig_default" (or something similar)? Peace, david -- David H. Wolfskill david@catwhisker.org Any given sequence of letters is a misspelling of a great many English words. See http://www.catwhisker.org/~david/publickey.gpg for public key. From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 22:02: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 B082D16A41C for ; Thu, 16 Jun 2005 22:02:35 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: from imladris.teardrop.org (imladris.teardrop.org [66.92.66.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7DD7743D53 for ; Thu, 16 Jun 2005 22:02:35 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: by imladris.teardrop.org (Postfix, from userid 100) id 182BABF6AB; Thu, 16 Jun 2005 18:03:27 -0400 (EDT) Date: Thu, 16 Jun 2005 18:03:27 -0400 From: James Snow To: Sam Leffler , freebsd-current@freebsd.org Message-ID: <20050616220327.GE98695@teardrop.org> References: <20050616191450.GA98695@teardrop.org> <42B1D9D9.7040604@errno.com> <20050616200450.GB98695@teardrop.org> <42B1DD17.3000601@errno.com> <20050616204044.GC98695@teardrop.org> <42B1E97B.5070408@errno.com> <20050616210447.GD98695@teardrop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050616210447.GD98695@teardrop.org> User-Agent: Mutt/1.4.2.1i Cc: Subject: Re: WPA Supplicant doesn't see my SSIDs? 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, 16 Jun 2005 22:02:35 -0000 Amusing update: I got wpa_supplicant to put ath0 into an associated state, but the moment I send any traffic out over ath0 - e.g., a DHCP request - I'm promptly disassociated. wpa_supplicant will try to reconnect, dhclient will keep sending out requests, and after a few iterations of this process the Cisco Aironets shut off all their wireless networks, disconnecting all their clients. :) They're Aironet 1200s running c1200-k9w7-tar.123-4.JA if anyone is curious. Given the instability on that side I wouldn't place too much credence in any WPA problem reports coming from me for the time being. -Snow From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 22:06: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 3FD6316A420 for ; Thu, 16 Jun 2005 22:06:06 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 171B643D48 for ; Thu, 16 Jun 2005 22:06:06 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5GM5GLd029091; Thu, 16 Jun 2005 15:05:16 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5GM5FUn029090; Thu, 16 Jun 2005 15:05:15 -0700 Date: Thu, 16 Jun 2005 15:05:15 -0700 From: Brooks Davis To: David Wolfskill , current@freebsd.org Message-ID: <20050616220515.GC20431@odin.ac.hmc.edu> References: <20050615061009.GA11914@odin.ac.hmc.edu> <001501c5720b$aceb84d0$0b2a15ac@SMILEY> <20050616164747.GB21733@odin.ac.hmc.edu> <20050616.142507.85367515.imp@bsdimp.com> <20050616205033.GF13900@odin.ac.hmc.edu> <20050616210404.GM33118@bunrab.catwhisker.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qtZFehHsKgwS5rPz" Content-Disposition: inline In-Reply-To: <20050616210404.GM33118@bunrab.catwhisker.org> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 22:06:06 -0000 --qtZFehHsKgwS5rPz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 16, 2005 at 02:04:04PM -0700, David Wolfskill wrote: > On Thu, Jun 16, 2005 at 01:50:33PM -0700, Brooks Davis wrote: > > ... > =20 > > Agreed. There's actually some demand for a default for wired interfaces > > as well. If nothing else I know the EmuLab people would like one > > so they didn't have to use their own scripts to configure all the > > interfaces. I've thought about it a bit. I'm leaning towards a > > default_ifconfig variable plus a new magic ifconfig_ option NONE to > > cause the default option not to be used. >=20 > >From the perspective that NIC-specific variables are of the form > "ifconfig_${NIC}" (e.g., ifconfig_lo0; ifconfig_ed0; ifconfig_xl0), > might it make at least as much sense to call it "ifconfig_default" (or > something similar)? I'm divided on that one. The problem is that users may want to name an interface "default" and this would break that. I like the symetry and the sort order of ifconfig_default, but I'm concerned about exceptions to the namespace as well. I'm somewhat tempted by ifconfig_DEFAULT. -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --qtZFehHsKgwS5rPz Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCsfeaXY6L6fI4GtQRArExAJ9TRVJg/rfysRTlH1VPACiiRkd9mgCggDHg GksEJYB1ByxC7T9WmNPBaWo= =twXL -----END PGP SIGNATURE----- --qtZFehHsKgwS5rPz-- From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 22:24: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 1EA9316A41C for ; Thu, 16 Jun 2005 22:24:23 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9C3B043D1F for ; Thu, 16 Jun 2005 22:24:22 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j5GMOLm3087291 for ; Fri, 17 Jun 2005 00:24:21 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j5GMOLrP087290 for freebsd-current@freebsd.org; Thu, 16 Jun 2005 18:24:21 -0400 (EDT) (envelope-from cracauer) Date: Thu, 16 Jun 2005 18:24:21 -0400 From: Martin Cracauer To: freebsd-current@freebsd.org Message-ID: <20050616182421.A87199@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: 6.0-current panic: loading radeon module 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, 16 Jun 2005 22:24:23 -0000 Loading the radeon module segfaults the kernel, 6.0-current of yesterday. I have a Thinkpad with Radeon mobility 7500. 5-stable works on the same hardware. ddb trace shows: bus_generic_activate_resource+0x64 bus_generic_activate_resource+0x64 bus_generic_activate_resource+0x64 pci_alloc_resource+0x226 pci_alloc_resource+0x7x drm_get_resource_len+0x2f radeon_preinit+0xa2 drm_attach+0x2d Not sure what is involved to use gdb at this time. Can I do serial gdb with a 6.0-current AMD64 machine running the display? Can I use a 5.x box? It is 100% reproducable so I can gather more info as needed. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 22:31: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 4AE1116A41F for ; Thu, 16 Jun 2005 22:31:30 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: from rproxy.gmail.com (rproxy.gmail.com [64.233.170.193]) by mx1.FreeBSD.org (Postfix) with ESMTP id EBF1B43D58 for ; Thu, 16 Jun 2005 22:31:29 +0000 (GMT) (envelope-from pawel.worach@gmail.com) Received: by rproxy.gmail.com with SMTP id r35so504902rna for ; Thu, 16 Jun 2005 15:31:29 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding; b=FJ77nQYHKjGf2iZjIV4tFxrNxaMjPR7WlWogqQcQkuiQppByoqzIrR+O3Mtze0eltxsDwyMwb8u7eOUJ/J7NL3S7gQyLbkcnqjPad7MtbNyHYadcfzqW7ndGqhQTP5lx6vCsxORF6+LmFMQ/X0KMltvnZcyafcWnFpKp+0u8suQ= Received: by 10.38.9.9 with SMTP id 9mr592604rni; Thu, 16 Jun 2005 15:31:29 -0700 (PDT) Received: from ?192.168.1.200? ([213.64.231.30]) by mx.gmail.com with ESMTP id 58sm151786rnc.2005.06.16.15.31.28; Thu, 16 Jun 2005 15:31:29 -0700 (PDT) Message-ID: <42B1FDBD.1000304@gmail.com> Date: Fri, 17 Jun 2005 00:31:25 +0200 From: Pawel Worach User-Agent: Mozilla Thunderbird 1.0+ (X11/20050611) MIME-Version: 1.0 To: Brooks Davis References: <200506161312.51857.jhb@FreeBSD.org> <42B1D823.5030108@errno.com> <20050616201646.GC13900@odin.ac.hmc.edu> <17073.58552.862249.81604@khavrinen.csail.mit.edu> <20050616205329.GG13900@odin.ac.hmc.edu> In-Reply-To: <20050616205329.GG13900@odin.ac.hmc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Wollman , current@FreeBSD.ORG Subject: Re: New dhclient broke multiple domains in domain-name 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, 16 Jun 2005 22:31:30 -0000 Brooks Davis wrote: > > It doesn't look like this made it out of the working group, at least I > can't find anything like it in RFC2132. > > -- Brooks > We have "RFC 3397 - Dynamic Host Configuration Protocol (DHCP) Domain Search Option" for this purpose, no idea of any clients use it. Regards, -- Pawel From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 23:32: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 5807616A41C for ; Thu, 16 Jun 2005 23:32:26 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from bache.ece.cmu.edu (BACHE.ECE.CMU.EDU [128.2.129.23]) by mx1.FreeBSD.org (Postfix) with ESMTP id 287DB43D5D for ; Thu, 16 Jun 2005 23:32:26 +0000 (GMT) (envelope-from allbery@ece.cmu.edu) Received: from localhost.localdomain (dsl093-061-215.pit1.dsl.speakeasy.net [66.93.61.215]) by bache.ece.cmu.edu (Postfix) with ESMTP id F361F7C for ; Thu, 16 Jun 2005 19:32:24 -0400 (EDT) From: "Brandon S. Allbery KF8NH" To: freebsd-current@freebsd.org In-Reply-To: <20050616220515.GC20431@odin.ac.hmc.edu> References: <20050615061009.GA11914@odin.ac.hmc.edu> <001501c5720b$aceb84d0$0b2a15ac@SMILEY> <20050616164747.GB21733@odin.ac.hmc.edu> <20050616.142507.85367515.imp@bsdimp.com> <20050616205033.GF13900@odin.ac.hmc.edu> <20050616210404.GM33118@bunrab.catwhisker.org> <20050616220515.GC20431@odin.ac.hmc.edu> Content-Type: text/plain Date: Thu, 16 Jun 2005 19:32:57 -0400 Message-Id: <1118964777.21992.0.camel@rushlight.kf8nh.com> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 16 Jun 2005 23:32:26 -0000 On Thu, 2005-06-16 at 15:05 -0700, Brooks Davis wrote: > On Thu, Jun 16, 2005 at 02:04:04PM -0700, David Wolfskill wrote: > > >From the perspective that NIC-specific variables are of the form > > "ifconfig_${NIC}" (e.g., ifconfig_lo0; ifconfig_ed0; ifconfig_xl0), > > might it make at least as much sense to call it "ifconfig_default" (or > > something similar)? > > I'm divided on that one. The problem is that users may want to name an > interface "default" and this would break that. I like the symetry and > the sort order of ifconfig_default, but I'm concerned about exceptions > to the namespace as well. I'm somewhat tempted by ifconfig_DEFAULT. ifconfig_="...defaults..." -- brandon s. allbery [linux,solaris,freebsd,perl] allbery@kf8nh.com system administrator [WAY too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon univ. KF8NH From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 00:17: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 A66FE16A41C for ; Fri, 17 Jun 2005 00:17:26 +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 7B64043D48 for ; Fri, 17 Jun 2005 00:17:26 +0000 (GMT) (envelope-from sam@errno.com) Received: from [66.127.85.91] ([66.127.85.91]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.6) with ESMTP id j5H0HPms017588 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Jun 2005 17:17:25 -0700 (PDT) (envelope-from sam@errno.com) Message-ID: <42B21790.4060301@errno.com> Date: Thu, 16 Jun 2005 17:21:36 -0700 From: Sam Leffler User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050327) X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Snow References: <20050616191450.GA98695@teardrop.org> <42B1D9D9.7040604@errno.com> <20050616200450.GB98695@teardrop.org> <42B1DD17.3000601@errno.com> <20050616204044.GC98695@teardrop.org> <42B1E97B.5070408@errno.com> <20050616210447.GD98695@teardrop.org> <20050616220327.GE98695@teardrop.org> In-Reply-To: <20050616220327.GE98695@teardrop.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: WPA Supplicant doesn't see my SSIDs? 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, 17 Jun 2005 00:17:26 -0000 James Snow wrote: > Amusing update: > > I got wpa_supplicant to put ath0 into an associated state, but the > moment I send any traffic out over ath0 - e.g., a DHCP request - I'm > promptly disassociated. wpa_supplicant will try to reconnect, dhclient > will keep sending out requests, and after a few iterations of this > process the Cisco Aironets shut off all their wireless networks, > disconnecting all their clients. > > :) > > They're Aironet 1200s running c1200-k9w7-tar.123-4.JA if anyone is > curious. > > Given the instability on that side I wouldn't place too much credence in > any WPA problem reports coming from me for the time being. Sounds like you're using TKIP and the ap detects MIC errors in the frames you are sending. When this happens it is required to enable countermeasures that include dropping traffic for a period of time. Check if your station negotiated WME; there have been problems with using h/w TKIP together with WME that require doing the MIC calculations in s/w. The crypto support in current doesn't have all these changes. If there's no WME negotiated then I'm not sure what to say; TKIP works fine in both h/w and s/w use in all my testing but I brought in a number of fixes (some WPA-related) shortly before the freeze. Sam From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 02:14:11 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 98C9B16A41C for ; Fri, 17 Jun 2005 02:14:11 +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 5FEA943D1F for ; Fri, 17 Jun 2005 02:14:11 +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 8528619F3B; Thu, 16 Jun 2005 19:15:41 -0700 (PDT) From: "Darren Pilgrim" To: "'Brooks Davis'" Date: Thu, 16 Jun 2005 19:14:09 -0700 Message-ID: <001801c572e2$3faaa310$0b2a15ac@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: <20050616182056.GF21733@odin.ac.hmc.edu> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527 Importance: Normal Cc: current@freebsd.org Subject: RE: Is anyone working on /etc/rc.d/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: Fri, 17 Jun 2005 02:14:11 -0000 From: Brooks Davis [mailto:brooks@one-eyed-alien.net]=20 > On Thu, Jun 16, 2005 at 02:51:44AM -0700, Darren Pilgrim wrote: > > Is anyone working on the proposed /etc/rc.d/wpa_supplicant script > > (as mentioned in /etc/network.subr? If not, I'll get started on > > one. >=20 > I'm planning to work on it, but if I don't do it my tomarrow it will > have to wait for the week of the 27th as I will be without electronic > devices next Sunday-Friday. Was that a yes or a no? :) > One could argue though that it actually has to be more complicated > than the dhclient script because in some really weird configurations > you might not have /usr mounted when netif is run and as a result > you need to support starting supplicants after mountcritremote. In > normal configurations, the script should see the already started > wpa_supplicants and not do anything when it is run. >=20 > I can't actually think of a good reason to have a machine with a > remote /usr be a wireless station, but I'm sure some crazy person > will come up with one. :) If you need wpa_supplicant and /usr is a remote filesystem, the network over which /usr is being mounted probably requires WPA, so it would be somewhat pointless. There could be some exotic configurations in which /usr is mounted over a non-WPA-required interface and WPA is needed for another interface. But I think that's stepping into the YBWI realm of system configuration. If this is a real concern, then I think the only real solution is to modify the wpa_supplicant Makefile(s) so it installs in /sbin and its library dependencies install in /lib. From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 02:44: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 2905D16A41C; Fri, 17 Jun 2005 02:44:26 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA8DF43D48; Fri, 17 Jun 2005 02:44:25 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5H2fUXH047358; Thu, 16 Jun 2005 20:41:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 16 Jun 2005 20:42:42 -0600 (MDT) Message-Id: <20050616.204242.116963478.imp@bsdimp.com> To: doconnor@gsoft.com.au From: "M. Warner Losh" In-Reply-To: <200506162217.10514.doconnor@gsoft.com.au> References: <20050616133236.4a83eb19.lists@yazzy.org> <200506162217.10514.doconnor@gsoft.com.au> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: damien.bergamini@free.fr, freebsd-current@freebsd.org, lists@yazzy.org, freebsd-mobile@freebsd.org, current@freebsd.org Subject: Re: Intel firmware 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, 17 Jun 2005 02:44:26 -0000 In message: <200506162217.10514.doconnor@gsoft.com.au> "Daniel O'Connor" writes: : There is a port for the ipw firmware but not for the iwi that I can see so I'm : not sure what the deal is there - maybe it doesn't need it uploaded like ipw : does. I believe that you still need to get it directly from the iwi web site. Please see the iwi man page for what I discovered when I used my iwi device. Warner From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 02:44: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 2905D16A41C; Fri, 17 Jun 2005 02:44:26 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA8DF43D48; Fri, 17 Jun 2005 02:44:25 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5H2fUXH047358; Thu, 16 Jun 2005 20:41:34 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 16 Jun 2005 20:42:42 -0600 (MDT) Message-Id: <20050616.204242.116963478.imp@bsdimp.com> To: doconnor@gsoft.com.au From: "M. Warner Losh" In-Reply-To: <200506162217.10514.doconnor@gsoft.com.au> References: <20050616133236.4a83eb19.lists@yazzy.org> <200506162217.10514.doconnor@gsoft.com.au> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: damien.bergamini@free.fr, freebsd-current@freebsd.org, lists@yazzy.org, freebsd-mobile@freebsd.org, current@freebsd.org Subject: Re: Intel firmware 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, 17 Jun 2005 02:44:26 -0000 In message: <200506162217.10514.doconnor@gsoft.com.au> "Daniel O'Connor" writes: : There is a port for the ipw firmware but not for the iwi that I can see so I'm : not sure what the deal is there - maybe it doesn't need it uploaded like ipw : does. I believe that you still need to get it directly from the iwi web site. Please see the iwi man page for what I discovered when I used my iwi device. Warner From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 03:05: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 A9F1B16A41F for ; Fri, 17 Jun 2005 03:05:17 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 74F8F43D5C for ; Fri, 17 Jun 2005 03:05:17 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5H34HXX047619; Thu, 16 Jun 2005 21:04:18 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Thu, 16 Jun 2005 21:05:29 -0600 (MDT) Message-Id: <20050616.210529.20240024.imp@bsdimp.com> To: cracauer@cons.org From: "M. Warner Losh" In-Reply-To: <20050616182421.A87199@cons.org> References: <20050616182421.A87199@cons.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 03:05:17 -0000 In message: <20050616182421.A87199@cons.org> Martin Cracauer writes: : Loading the radeon module segfaults the kernel, 6.0-current of : yesterday. : : I have a Thinkpad with Radeon mobility 7500. 5-stable works on the : same hardware. : : ddb trace shows: : : bus_generic_activate_resource+0x64 : bus_generic_activate_resource+0x64 : bus_generic_activate_resource+0x64 : pci_alloc_resource+0x226 : pci_alloc_resource+0x7x : drm_get_resource_len+0x2f : radeon_preinit+0xa2 : drm_attach+0x2d : : Not sure what is involved to use gdb at this time. Can I do serial : gdb with a 6.0-current AMD64 machine running the display? Can I use a : 5.x box? : : It is 100% reproducable so I can gather more info as needed. Is this a module you compiled, or a module that's vendor supplied? Warner From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 03:08:03 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 C856916A41C; Fri, 17 Jun 2005 03:08:03 +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 2060343D5D; Fri, 17 Jun 2005 03:08:02 +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.13.4/8.13.4) with ESMTP id j5H37lME096781; Fri, 17 Jun 2005 12:37:48 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "M. Warner Losh" Date: Fri, 17 Jun 2005 12:37:36 +0930 User-Agent: KMail/1.8 References: <20050616133236.4a83eb19.lists@yazzy.org> <200506162217.10514.doconnor@gsoft.com.au> <20050616.204242.116963478.imp@bsdimp.com> In-Reply-To: <20050616.204242.116963478.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1323707.oakgtutYxn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506171237.44654.doconnor@gsoft.com.au> X-Spam-Score: -2.4 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: damien.bergamini@free.fr, freebsd-current@freebsd.org, lists@yazzy.org, freebsd-mobile@freebsd.org, current@freebsd.org Subject: Re: Intel firmware 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, 17 Jun 2005 03:08:04 -0000 --nextPart1323707.oakgtutYxn Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 17 Jun 2005 12:12, M. Warner Losh wrote: > In message: <200506162217.10514.doconnor@gsoft.com.au> > > "Daniel O'Connor" writes: > : There is a port for the ipw firmware but not for the iwi that I can see > : so I'm not sure what the deal is there - maybe it doesn't need it > : uploaded like ipw does. > > I believe that you still need to get it directly from the iwi web > site. Please see the iwi man page for what I discovered when I used > my iwi device. The man page has.. SEE ALSO an(4), ath(4), ipw(4), pci(4), wi(4), wlan(4), ifconfig(8), iwicontrol(8,) wicontrol(8) The IWI Web Page, http://damien.bergamini.free.fr/ipw/ There is no iwicontrol(8) page, and the URL goes to Damien's page. If you g= o=20 through to the Download area you can get the iwi firmware and iwicontrol=20 source but it seems like an oversight that a) iwicontrol isn't in base, and= =20 b) the iwi firmware isn't available as a port, since both of these for ipw= =20 are available. =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 --nextPart1323707.oakgtutYxn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCsj6A5ZPcIHs/zowRAuhcAJ9sgXbsd+0XiqsgO3YGEs1VKx2CBgCgm9+9 YZCzvTFx30NsKic6nI+veCU= =GpI1 -----END PGP SIGNATURE----- --nextPart1323707.oakgtutYxn-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 03:08: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 C856916A41C; Fri, 17 Jun 2005 03:08:03 +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 2060343D5D; Fri, 17 Jun 2005 03:08:02 +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.13.4/8.13.4) with ESMTP id j5H37lME096781; Fri, 17 Jun 2005 12:37:48 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: "M. Warner Losh" Date: Fri, 17 Jun 2005 12:37:36 +0930 User-Agent: KMail/1.8 References: <20050616133236.4a83eb19.lists@yazzy.org> <200506162217.10514.doconnor@gsoft.com.au> <20050616.204242.116963478.imp@bsdimp.com> In-Reply-To: <20050616.204242.116963478.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1323707.oakgtutYxn"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506171237.44654.doconnor@gsoft.com.au> X-Spam-Score: -2.4 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: damien.bergamini@free.fr, freebsd-current@freebsd.org, lists@yazzy.org, freebsd-mobile@freebsd.org, current@freebsd.org Subject: Re: Intel firmware 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, 17 Jun 2005 03:08:04 -0000 --nextPart1323707.oakgtutYxn Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Fri, 17 Jun 2005 12:12, M. Warner Losh wrote: > In message: <200506162217.10514.doconnor@gsoft.com.au> > > "Daniel O'Connor" writes: > : There is a port for the ipw firmware but not for the iwi that I can see > : so I'm not sure what the deal is there - maybe it doesn't need it > : uploaded like ipw does. > > I believe that you still need to get it directly from the iwi web > site. Please see the iwi man page for what I discovered when I used > my iwi device. The man page has.. SEE ALSO an(4), ath(4), ipw(4), pci(4), wi(4), wlan(4), ifconfig(8), iwicontrol(8,) wicontrol(8) The IWI Web Page, http://damien.bergamini.free.fr/ipw/ There is no iwicontrol(8) page, and the URL goes to Damien's page. If you g= o=20 through to the Download area you can get the iwi firmware and iwicontrol=20 source but it seems like an oversight that a) iwicontrol isn't in base, and= =20 b) the iwi firmware isn't available as a port, since both of these for ipw= =20 are available. =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 --nextPart1323707.oakgtutYxn Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCsj6A5ZPcIHs/zowRAuhcAJ9sgXbsd+0XiqsgO3YGEs1VKx2CBgCgm9+9 YZCzvTFx30NsKic6nI+veCU= =GpI1 -----END PGP SIGNATURE----- --nextPart1323707.oakgtutYxn-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 03:45: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 3F93E16A41C for ; Fri, 17 Jun 2005 03:45:13 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [210.226.20.147]) by mx1.FreeBSD.org (Postfix) with ESMTP id B6CE543D49 for ; Fri, 17 Jun 2005 03:45:12 +0000 (GMT) (envelope-from kuriyama@imgsrc.co.jp) Received: from localhost (localhost [127.0.0.1]) by black.imgsrc.co.jp (Postfix) with ESMTP id 2E68850D01; Fri, 17 Jun 2005 12:45:11 +0900 (JST) Received: from black.imgsrc.co.jp (black.imgsrc.co.jp [IPv6:2001:218:422:2::9999]) by black.imgsrc.co.jp (Postfix) with ESMTP id 839CA50D04; Fri, 17 Jun 2005 12:45:09 +0900 (JST) Date: Fri, 17 Jun 2005 12:45:09 +0900 Message-ID: <7mll59myt6.wl%kuriyama@imgsrc.co.jp> From: Jun Kuriyama To: Doug White In-Reply-To: <20050614194742.U24745@carver.gumbysoft.com> References: <7mpsupni5r.wl%kuriyama@imgsrc.co.jp> <20050614194742.U24745@carver.gumbysoft.com> User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (=?ISO-8859-4?Q?Sanj=F2?=) APEL/10.6 Emacs/21.3 (i386--freebsd) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII X-Virus-Scanned: by amavisd 0.1 Cc: Current Subject: Re: How to help debugging of lock-up 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, 17 Jun 2005 03:45:13 -0000 At Tue, 14 Jun 2005 19:48:27 -0700 (PDT), Doug White wrote: > > I'm not sure which process I should suspect. Is there something I can > > provide to help debugging about this? > > The trace looks normal for something network- and disk-bound. Perhaps your > NIC's overloaded or hung? Where is the amanda backup going -- back to the > same system? Yes, it looks trace is normal. But even serial console, getty does not respond. Backup server is another box, dump is going through the network. And I got another lock-up with today's kernel (including jeff's r1.103 of vfs_cache.c). If noone sees this behavior, is there a possibility which my hardware is broken? (but old 2005-04-09 kernel works without problem) ----- KDB: enter: Break sequence on console [thread pid 11 tid 100006 ] Stopped at kdb_enter+0x2b: nop db> ps pid proc uid ppid pgrp flag stat wmesg wchan cmd 35659 c6569c00 103 35657 758 0004000 [SLPQ getblk 0xd7775df0][SLP] as 35657 c3939a00 103 35656 758 0004000 [SLPQ wait 0xc3939a00][SLP] c++ 35656 c8d33c00 103 35635 758 0004000 [SLPQ wait 0xc8d33c00][SLP] sh 35655 c3b3cc00 103 35654 758 0004000 [SLPQ biord 0xd766c638][SLP] cc1 35654 c393c200 103 35653 758 0004000 [SLPQ wait 0xc393c200][SLP] cc 35653 c8ebe600 103 35651 758 0004000 [SLPQ wait 0xc8ebe600][SLP] sh 35651 c3b3ca00 103 35650 758 0004000 [SLPQ wait 0xc3b3ca00][SLP] sh 35650 c656a800 103 35350 758 0004000 [SLPQ select 0xc075cb24][SLP] make 35648 c8ec0e00 0 35646 35648 0000110 [SLPQ kqread 0xc8fd1480][SLP] cron 35647 c8d30000 0 35644 35647 0000010 [SLPQ kqread 0xc8ffc880][SLP] cron 35646 c953fa00 0 588 588 0000000 [SLPQ ppwait 0xc953fa00][SLP] cron 35644 c656a400 0 588 588 0000000 [SLPQ ppwait 0xc656a400][SLP] cron 35635 c8ebee00 103 34347 758 0004000 [SLPQ select 0xc075cb24][SLP] make 35350 c93c1e00 103 35349 758 0004000 [SLPQ wait 0xc93c1e00][SLP] sh 35349 c93c1a00 103 35348 758 0004000 [SLPQ select 0xc075cb24][SLP] make 35348 c93bec00 103 33419 758 0004000 [SLPQ wait 0xc93bec00][SLP] sh 34347 c8d33800 103 34346 758 0004000 [SLPQ wait 0xc8d33800][SLP] sh 34346 c3b3c200 103 33426 758 0004000 [SLPQ select 0xc075cb24][SLP] make 33426 c6569000 103 33419 758 0004000 [SLPQ wait 0xc6569000][SLP] sh 33419 c38c3a00 103 18262 758 0004000 [SLPQ select 0xc075cb24][SLP] make 32618 c8ebe400 1021 702 32618 0004002 [SLPQ select 0xc075cb24][SLP] ssh 18262 c38c4a00 103 18255 758 0004000 [SLPQ wait 0xc38c4a00][SLP] sh 18255 c8ec0000 103 18254 758 0004000 [SLPQ select 0xc075cb24][SLP] make 18254 c8ec0a00 103 894 758 0004000 [SLPQ wait 0xc8ec0a00][SLP] sh 894 c656a200 103 892 758 0004000 [SLPQ select 0xc075cb24][SLP] make 892 c3939c00 103 811 758 0004000 [SLPQ wait 0xc3939c00][SLP] sh 811 c656a000 103 810 758 0004000 [SLPQ select 0xc075cb24][SLP] make 810 c6569e00 103 760 758 0004000 [SLPQ wait 0xc6569e00][SLP] lockf 760 c3939e00 103 759 758 0004000 [SLPQ wait 0xc3939e00][SLP] sh 759 c3b37800 103 758 758 0004000 [SLPQ wait 0xc3b37800][SLP] lockf 758 c3b37200 103 757 758 0004000 [SLPQ pause 0xc3b37234][SLP] csh 757 c393ce00 0 750 750 0004100 [SLPQ wait 0xc393ce00][SLP] su 750 c3ac2a00 0 747 750 0004000 [SLPQ wait 0xc3ac2a00][SLP] sh 747 c38c4c00 0 588 588 0000000 [SLPQ piperd 0xc3941480][SLP] cron 702 c3b37400 1021 701 702 0004002 [SLPQ pause 0xc3b37434][SLP] zsh 701 c3abe800 1021 699 699 0000100 [SLPQ select 0xc075cb24][SLP] sshd 699 c3b37a00 0 566 699 0004100 [SLPQ sbwait 0xc3b13334][SLP] sshd 698 c393c600 0 1 698 0004002 [SLPQ ttyin 0xc372d410][SLP] getty 697 c3b3c000 0 1 697 0004002 [SLPQ ttyin 0xc3744010][SLP] getty ... db> trace 35659 Tracing pid 35659 tid 100126 td 0xc359da80 sched_switch(c359da80,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(d7775df0,e6a72968,c050da15,d7775df0,0) at sleepq_switch+0xe0 sleepq_wait(d7775df0,0,0,c396329c,b5) at sleepq_wait+0x30 msleep(d7775df0,c070eb90,50,c06aeed5,0) at msleep+0x311 acquire(e6a729c0,120,60000,c359da80,0) at acquire+0x76 lockmgr(d7775df0,202122,c396329c,c359da80) at lockmgr+0x42a getblk(c3963220,a0cee0,0,4000,0) at getblk+0x12a breadn(c3963220,a0cee0,0,4000,0) at breadn+0x31 bread(c3963220,a0cee0,0,4000,0) at bread+0x20 ffs_update(c976c110,0,c976c110,c387dc00,1) at ffs_update+0x228 ufs_inactive(e6a72b10,c976c18c,c976c110,e6a72b28,c055b84a) at ufs_inactive+0x16c VOP_INACTIVE_APV(c06f7380,e6a72b10) at VOP_INACTIVE_APV+0x9b vinactive(c976c110,c359da80) at vinactive+0x8a vput(c976c110,c387dc00,c0704720,c976c110,3) at vput+0x160 vn_close(c976c110,3,c3a21480,c359da80,e6a72bd8) at vn_close+0x96 vn_closefile(c3938750,c359da80) at vn_closefile+0xca fdrop_locked(c3938750,c359da80,c34a0fac,0,c06a41df) at fdrop_locked+0x88 fdrop(c3938750,c359da80,6af,c0716380,0) at fdrop+0x24 closef(c3938750,c359da80,0,0,3) at closef+0x35f db> trace 35655 Tracing pid 35655 tid 100118 td 0xc3b38480 sched_switch(c3b38480,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(d766c638,ecf9eacc,c050da15,d766c638,0) at sleepq_switch+0xe0 sleepq_wait(d766c638,0,0,c06ae919,e52) at sleepq_wait+0x30 msleep(d766c638,c075d140,4c,c06af047,0) at msleep+0x311 bwait(d766c638,4c,c06af047) at bwait+0x47 bufwait(d766c638,1,0,0,ecf9ebb8) at bufwait+0x1a breadn(c82c4220,0,0,1000,0) at breadn+0x266 bread(c82c4220,0,0,1000,0) at bread+0x20 ffs_read(ecf9ec04,c39381f8,c82c4220,ecf9ec50,c0565a6a) at ffs_read+0x23f VOP_READ_APV(c06f7380,ecf9ec04) at VOP_READ_APV+0x9b vn_read(c39381f8,ecf9ec78,c3a21480,0,c3b38480) at vn_read+0x196 dofileread(c3b38480,c39381f8,3,845e000,a9e) at dofileread+0xad read(c3b38480,ecf9ed04,3,9,202) at read+0x3b syscall(3b,3b,3b,845e000,a9e) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (3, FreeBSD ELF32, read), eip = 0x82d05d3, esp = 0xbfbfe60c, ebp = 0xbfbfe638 --- db> trace 35648 Tracing pid 35648 tid 100167 td 0xc8d32300 sched_switch(c8d32300,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(c8fd1480,0,c8d32300,ed04bb68,c050d9d9) at sleepq_switch+0xe0 sleepq_timedwait_sig(c8fd1480,0,0,100,c06a45e3) at sleepq_timedwait_sig+0xd msleep(c8fd1480,c8fd1480,158,c06a46bf,1388) at msleep+0x2d5 kqueue_scan(c8fd1480,1,ed04bcc8,ed04bcc0,ed04bbf4) at kqueue_scan+0x221 kern_kevent(c8d32300,5,0,1,ed04bcc8) at kern_kevent+0x151 kevent(c8d32300,ed04bd04,6,10,292) at kevent+0x55 syscall(3b,3b,3b,805f000,bfbfe3b0) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (363, FreeBSD ELF32, kevent), eip = 0x280c9503, esp = 0xbfbfe31c, ebp = 0xbfbfe458 --- db> trace 35647 Tracing pid 35647 tid 100136 td 0xc3b38180 sched_switch(c3b38180,0,1) at sched_switch+0x177 mi_switch(1,0) at mi_switch+0x270 sleepq_switch(c8ffc880,0,c3b38180,ecf98b68,c050d9d9) at sleepq_switch+0xe0 sleepq_timedwait_sig(c8ffc880,0,0,100,c06a45e3) at sleepq_timedwait_sig+0xd msleep(c8ffc880,c8ffc880,158,c06a46bf,1389) at msleep+0x2d5 kqueue_scan(c8ffc880,1,ecf98cc8,ecf98cc0,ecf98bf4) at kqueue_scan+0x221 kern_kevent(c3b38180,5,0,1,ecf98cc8) at kern_kevent+0x151 kevent(c3b38180,ecf98d04,6,e,292) at kevent+0x55 syscall(3b,3b,3b,805f000,bfbfe3b0) at syscall+0x22f Xint0x80_syscall() at Xint0x80_syscall+0x1f --- syscall (363, FreeBSD ELF32, kevent), eip = 0x280c9503, esp = 0xbfbfe31c, ebp = 0xbfbfe458 --- -- Jun Kuriyama // IMG SRC, Inc. // FreeBSD Project From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 04:33: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 2D09B16A41C for ; Fri, 17 Jun 2005 04:33:24 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id E833043D49 for ; Fri, 17 Jun 2005 04:33:23 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5H4XMfB030430; Thu, 16 Jun 2005 21:33:22 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5H4XM0p030429; Thu, 16 Jun 2005 21:33:22 -0700 Date: Thu, 16 Jun 2005 21:33:22 -0700 From: Brooks Davis To: Darren Pilgrim Message-ID: <20050617043322.GB29871@odin.ac.hmc.edu> References: <20050616182056.GF21733@odin.ac.hmc.edu> <001801c572e2$3faaa310$0b2a15ac@SMILEY> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <001801c572e2$3faaa310$0b2a15ac@SMILEY> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: current@freebsd.org Subject: Re: Is anyone working on /etc/rc.d/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: Fri, 17 Jun 2005 04:33:24 -0000 On Thu, Jun 16, 2005 at 07:14:09PM -0700, Darren Pilgrim wrote: > From: Brooks Davis [mailto:brooks@one-eyed-alien.net] > > On Thu, Jun 16, 2005 at 02:51:44AM -0700, Darren Pilgrim wrote: > > > Is anyone working on the proposed /etc/rc.d/wpa_supplicant script > > > (as mentioned in /etc/network.subr? If not, I'll get started on > > > one. > > > > I'm planning to work on it, but if I don't do it my tomarrow it will > > have to wait for the week of the 27th as I will be without electronic > > devices next Sunday-Friday. > > Was that a yes or a no? :) Neither. I will commit something for 6.0 release. If you can't wait a week feel free to write something. I know roughly what I plan to write, but haven't done it yet. -- Brooks From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 06:34:07 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 664) id 365D816A41F; Fri, 17 Jun 2005 06:34:07 +0000 (GMT) Date: Fri, 17 Jun 2005 06:34:07 +0000 From: David O'Brien To: Eric Anderson Message-ID: <20050617063407.GA45182@hub.freebsd.org> References: <42AD8270.8060906@centtech.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42AD8270.8060906@centtech.com> User-Agent: Mutt/1.4.2.1i X-Operating-System: FreeBSD 4.11-STABLE 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 Cc: FreeBSD Current Subject: Re: _mtx_lock_sleep kernel crash.. 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: Fri, 17 Jun 2005 06:34:07 -0000 On Mon, Jun 13, 2005 at 07:56:16AM -0500, Eric Anderson wrote: > I'm getting this: > panic: _mtx_lock_sleep: recursed on non-recursive mutex system map @ > /usr/src/sys/vm/vm_kern.c:295 > > cpuid = 0 > KDB: enter: panic > [thread pid 0 tid 0 ] > Stopped at kdb_enter+0x2b: nop > > On bootup with my -current from a few days ago. Here's how I reproduce it: > With a GENERIC kernel, add any of these to your /boot/loader.conf: > vkbd_load="YES" > snd_pcm_load="YES" > snd_ich_load="YES" > > Removing 'smp' option from the kernel seems to fix it. I finally was able to get a traceback of my insta-reboots after marius' atkbd commit (2005-06-10 20:56:38 UTC) and it was exactly this same traceback. So it wasn't really 'smp' related, but a resource issue. alc increase of UMA_BOOT_PAGES fixes this panic. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 07:55: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 E4B2C16A41C for ; Fri, 17 Jun 2005 07:55:45 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9ABE743D1D for ; Fri, 17 Jun 2005 07:55:45 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 2651460FB; Fri, 17 Jun 2005 09:55:39 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 13BA360F3; Fri, 17 Jun 2005 09:55:39 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id ED7EC33C23; Fri, 17 Jun 2005 09:55:38 +0200 (CEST) To: Brooks Davis References: <20050615061009.GA11914@odin.ac.hmc.edu> <001501c5720b$aceb84d0$0b2a15ac@SMILEY> <20050616164747.GB21733@odin.ac.hmc.edu> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 17 Jun 2005 09:55:38 +0200 In-Reply-To: <20050616164747.GB21733@odin.ac.hmc.edu> (Brooks Davis's message of "Thu, 16 Jun 2005 09:47:47 -0700") Message-ID: <86y899ct8l.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Learn: ham X-Spam-Score: -5.2/5.0 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tim.des.no Cc: 'Vladimir Grebenschikov' , Darren Pilgrim , 'Matthew Emmerton' , freebsd-current@freebsd.org Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 17 Jun 2005 07:55:46 -0000 Brooks Davis writes: > I'm seriously considering removing the following variables: > > network_interfaces Don't. If network_interfaces is left unspecified, the scripts will use 'ifconfig -l' and everything is fine provided all the interfaces were already attached (i.e. the drivers were compiled into the kernel or listed in loader.conf). This is the common case. However, if the driver wasn't already loaded for some reason, network_interfaces + ifconfig_foo0 will take care of it. Without network_interfaces, we lose this functionality, for no benefit at all to anyone. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 08:35: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 F249E16A41C for ; Fri, 17 Jun 2005 08:35:09 +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 C3B8043D1F for ; Fri, 17 Jun 2005 08:35:09 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5H8Z9o6003362; Fri, 17 Jun 2005 01:35:09 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5H8Z8t6003361; Fri, 17 Jun 2005 01:35:08 -0700 (PDT) (envelope-from obrien) Date: Fri, 17 Jun 2005 01:35:08 -0700 From: "David O'Brien" To: Ed Maste Message-ID: <20050617083507.GA3061@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Ed Maste , freebsd-current@freebsd.org, Doug White References: <20050613192308.GA87640@sandvine.com> <20050614082039.GA2038@dragon.NUXI.org> <20050614224704.Y75797@mp2.macomnet.net> <20050614190854.GA12928@dragon.NUXI.org> <20050614235132.L76669@mp2.macomnet.net> <20050615023600.GA20721@dragon.NUXI.org> <20050615141447.GD95217@sandvine.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050615141447.GD95217@sandvine.com> 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 Subject: Re: savecore(8) increments /var/crash/bounds on each boot 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: Fri, 17 Jun 2005 08:35:10 -0000 On Wed, Jun 15, 2005 at 10:14:47AM -0400, Ed Maste wrote: > On Tue, Jun 14, 2005 at 07:36:00PM -0700, David O'Brien wrote: > > Do you understand the fix? How does lying in printheader() fix anything? > > Moving the call to getbounds() back to the original location is the "fix" > > but then it negates -vv. We shouldn't lie in printheader(). > > Fair enough, on dwhite's suggestion here's another try that splits the > increment-and-write out from getbounds() so that the bounds value can > be shown with -vv. ..snip.. > --- savecore.c.orig 2005-06-13 16:19:41.000000000 -0400 > +++ savecore.c 2005-06-15 09:41:52.000000000 -0400 ... > + writebounds(bounds+1); ^^^^^^^^ bounds + 1 I like the patch, after the style(9) fix. Might as well avoid a brucification. ;-) Who's going to commit this patch? -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 09:37: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 476FB16A41C; Fri, 17 Jun 2005 09:37:49 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout08.sul.t-online.com (mailout08.sul.t-online.com [194.25.134.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id EE8D343D55; Fri, 17 Jun 2005 09:37:46 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd18.aul.t-online.de by mailout08.sul.t-online.com with smtp id 1DjDIE-0001Fu-07; Fri, 17 Jun 2005 11:37:42 +0200 Received: from Andro-Beta.Leidinger.net (rxHPYEZdYe0d3Rl46jccDLYImHr2cTMSSu3qwwcCW1UuRw7+hlG9Q6@[84.165.234.13]) by fwd18.sul.t-online.de with esmtp id 1DjDI7-19116W0; Fri, 17 Jun 2005 11:37:35 +0200 Received: from localhost (localhost [127.0.0.1]) by Andro-Beta.Leidinger.net (8.13.3/8.13.3) with ESMTP id j5H9bTQY078251; Fri, 17 Jun 2005 11:37:29 +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 ; Fri, 17 Jun 2005 11:37:29 +0200 Message-ID: <20050617113729.i78gx3wiokw48g8k@netchild.homeip.net> X-Priority: 3 (Normal) Date: Fri, 17 Jun 2005 11:37:29 +0200 From: Alexander Leidinger To: Robert Watson References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> <20050616181820.E27625@fledge.watson.org> <42B1B784.8010405@videotron.ca> <20050616184127.L27625@fledge.watson.org> In-Reply-To: <20050616184127.L27625@fledge.watson.org> 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: rxHPYEZdYe0d3Rl46jccDLYImHr2cTMSSu3qwwcCW1UuRw7+hlG9Q6@t-dialin.net X-TOI-MSGID: a5ae6c12-754b-4e20-96de-370547d46b52 Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: Reboot while booting with new per-CPU allocator 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, 17 Jun 2005 09:37:49 -0000 Robert Watson wrote: > Looks like what basically happened is this these kern_malloc.c > changes increase the memory burden on UMA as statistics structures > for malloc types now get allocated from UMA. It looks like, from > your dmesg, you have a fair number of modules loaded, so the storage > for the statistics comes out of the early UMA page pool, whereas > before it came out of BSS. We'll see if further tuning is required or > not with large numbers of modules. I try to load as much as possible as modules. Can you quantify "large number of modules"? I could load some more modules for testing purposes at the weekend. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 "Why is it that we rejoice at a birth and grieve at a funeral? It is because we are not the person involved" -- Mark Twain From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 10:00: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 2E8B816A41C; Fri, 17 Jun 2005 10:00:25 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id F34E243D4C; Fri, 17 Jun 2005 10:00:24 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 0126546B3B; Fri, 17 Jun 2005 06:00:24 -0400 (EDT) Date: Fri, 17 Jun 2005 11:02:43 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Leidinger In-Reply-To: <20050617113729.i78gx3wiokw48g8k@netchild.homeip.net> Message-ID: <20050617110050.O56734@fledge.watson.org> References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> <20050616181820.E27625@fledge.watson.org> <42B1B784.8010405@videotron.ca> <20050616184127.L27625@fledge.watson.org> <20050617113729.i78gx3wiokw48g8k@netchild.homeip.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: Reboot while booting with new per-CPU allocator 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, 17 Jun 2005 10:00:25 -0000 On Fri, 17 Jun 2005, Alexander Leidinger wrote: > Robert Watson wrote: > >> Looks like what basically happened is this these kern_malloc.c changes >> increase the memory burden on UMA as statistics structures for malloc types >> now get allocated from UMA. It looks like, from your dmesg, you have a >> fair number of modules loaded, so the storage for the statistics comes out >> of the early UMA page pool, whereas before it came out of BSS. We'll see if >> further tuning is required or not with large numbers of modules. > > I try to load as much as possible as modules. Can you quantify "large > number of modules"? I could load some more modules for testing purposes > at the weekend. Well, it looked like 30 was enough to exceed the 40 page UMA threshold, but it's now been bumped to 48 in HEAD. However, what actually matters is malloc types, not modules, so I think two routes would be productive: to add a debugging printf to UMA to show how much of the boot page space is used at the time it transitions to non-boot pages, and to try creating a module that creates various numbers of malloc types. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 10:07: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 DED7A16A41C; Fri, 17 Jun 2005 10:07:35 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id B1A9543D1F; Fri, 17 Jun 2005 10:07:35 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id 6427A46BC7; Fri, 17 Jun 2005 06:07:35 -0400 (EDT) Date: Fri, 17 Jun 2005 11:09:54 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Stephane E. Potvin" In-Reply-To: <20050616184127.L27625@fledge.watson.org> Message-ID: <20050617110902.C56734@fledge.watson.org> References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> <20050616181820.E27625@fledge.watson.org> <42B1B784.8010405@videotron.ca> <20050616184127.L27625@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: alc@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Reboot while booting with new per-CPU allocator 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, 17 Jun 2005 10:07:36 -0000 On Thu, 16 Jun 2005, Robert Watson wrote: >> Great :) It did the trick. The laptop is happily booting with the new >> allocator now. Thanks a lot to you and Alan Cox. > > Looks like what basically happened is this these kern_malloc.c changes > increase the memory burden on UMA as statistics structures for malloc > types now get allocated from UMA. It looks like, from your dmesg, you > have a fair number of modules loaded, so the storage for the statistics > comes out of the early UMA page pool, whereas before it came out of BSS. > We'll see if further tuning is required or not with large numbers of > modules. The thing that surprised me, though, is the unclean failure > mode. The other report saw a clean panic which presumably made > debugging it much easier... Interestingly, there's been a bunch of reports of this in the past few days, and there weren't immediately after the malloc commit. I wonder if some other recent change has increased the amount of UMA memory allocated early in the boot, increasing the level of reports... Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 10:46: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 A5F8C16A41C; Fri, 17 Jun 2005 10:46:14 +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 8CFA643D4C; Fri, 17 Jun 2005 10:46:11 +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 6B289FDDE; Fri, 17 Jun 2005 14:46:09 +0400 (MSD) Received: from kirov.so-cdu.ru (localhost [127.0.0.1]) by rdu.kirov.ru (Postfix) with SMTP id 2F51415422; Fri, 17 Jun 2005 14:46:09 +0400 (MSD) Received: by rdu.kirov.ru (Postfix, from userid 1014) id 8F0DE15420; Fri, 17 Jun 2005 14:46:08 +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 674F51538B; Fri, 17 Jun 2005 14:46:08 +0400 (MSD) Message-ID: <42B2A9CF.3080603@yandex.ru> Date: Fri, 17 Jun 2005 14:45:35 +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 Mailing List , freebsd-current@freebsd.org Content-Type: multipart/mixed; boundary="------------040305060506050504080108" Cc: Subject: Re: kern/80642: [patch] IPFW small patch - new RULE OPTION 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, 17 Jun 2005 10:46:14 -0000 This is a multi-part message in MIME format. --------------040305060506050504080108 Content-Type: text/plain; charset=KOI8-R; format=flowed Content-Transfer-Encoding: 7bit Robert Watson wrote: > This patch breaks the ABI by inserting a new type into an implicitly > numbered enumeration, renumbering all entries later in the enum. > O_BOUND, if added, should be appended to the end, and/or we should > number the operations explicitly. Ok. I have corrected this. * ipfw_bound.diff - the patch with smallest changes, with only bound option. * ipfw_bound2.diff - bound and check-bound option. Examples: We can limit incoming traffic (internet is external interface): # ipfw add allow ip from any to 10.0.0.20 in recv internet bound 10MB # ipfw add deny ip from any to 10.0.0.0/24 in recv internet We can use traffic shaper after excess of a limit: # ipfw add allow ip from any to 10.0.0.20 in recv internet bound 10MB # ipfw add pipe 1 ip from any to 10.0.0.20 in recv internet # ipfw pipe 1 config bw 5Kbit/s queue 10Kbytes We can block any access after limit excess: # ipfw add 100 allow ip from 10.0.0.20 to any out xmit internet \ check-bound 200 # ipfw add 200 allow ip from any to 10.0.0.20 in recv internet bound \ 10MB # ipfw add 300 deny ip from any to any More details you can read on http://butcher.heavennet.ru/ -- WBR, Andrey V. Elsukov --------------040305060506050504080108 Content-Type: text/plain; name="ipfw_bound.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw_bound.diff" --- sbin/ipfw/ipfw2.c Tue Jun 7 18:11:17 2005 +++ sbin/ipfw/ipfw2.c Fri Jun 17 13:09:43 2005 @@ -277,6 +277,7 @@ TOK_SRCIP6, TOK_IPV4, + TOK_BOUND, }; struct _s_x dummynet_params[] = { @@ -403,6 +404,7 @@ { "dst-ip6", TOK_DSTIP6}, { "src-ipv6", TOK_SRCIP6}, { "src-ip6", TOK_SRCIP6}, + { "bound", TOK_BOUND}, { "//", TOK_COMMENT }, { "not", TOK_NOT }, /* pseudo option */ @@ -1858,6 +1860,10 @@ print_ext6hdr( (ipfw_insn *) cmd ); break; + case O_BOUND: + printf(" bound %u", ((ipfw_insn_u64 *)cmd)->bound); + break; + default: printf(" [opcode %d len %d]", cmd->opcode, cmd->len); @@ -2515,7 +2521,7 @@ " icmp6types LIST | ext6hdr LIST | flow-id N[,N] |\n" " mac ... | mac-type LIST | proto LIST | {recv|xmit|via} {IF|IPADDR} |\n" " setup | {tcpack|tcpseq|tcpwin} NN | tcpflags SPEC | tcpoptions SPEC |\n" -" tcpdatalen LIST | verrevpath | versrcreach | antispoof\n" +" tcpdatalen LIST | verrevpath | versrcreach | antispoof | bound VALUE\n" ); exit(0); } @@ -3683,6 +3689,7 @@ int i; int open_par = 0; /* open parenthesis ( */ + int have_bound = 0; /* proto is here because it is used to fetch ports */ u_char proto = IPPROTO_IP; /* default protocol */ @@ -4492,6 +4499,33 @@ fill_comment(cmd, ac, av); av += ac; ac = 0; + break; + + case TOK_BOUND: + NEED1("bound requires numeric value"); + if (have_bound) + errx(EX_USAGE, "only one of bound is allowed"); + if (open_par) + errx(EX_USAGE, "bound cannot be part " + "of an or block"); + if (cmd->len & F_NOT) + errx(EX_USAGE, + "\"not\" not allowed with bound option"); + { + char *end = NULL; + uint64_t bound = strtoull(*av, &end, 0); + if (bound) + switch (*end){ + case 'G': bound *= 1024; + case 'M': bound *= 1024; + case 'K': bound *= 1024; + }; + cmd->opcode = O_BOUND; + ((ipfw_insn_u64 *)cmd)->bound = bound; + cmd->len = F_INSN_SIZE(ipfw_insn_u64) & F_LEN_MASK; + have_bound = 1; + ac--; av++; + } break; default: --- sys/netinet/ip_fw.h Fri Jun 3 05:10:28 2005 +++ sys/netinet/ip_fw.h Fri Jun 17 11:30:30 2005 @@ -154,6 +154,7 @@ O_NGTEE, /* copy to ng_ipfw */ O_IP4, + O_BOUND, /* u64 = bound in bytes */ O_LAST_OPCODE /* not an opcode! */ }; @@ -228,6 +229,14 @@ ipfw_insn o; u_int32_t d[1]; /* one or more */ } ipfw_insn_u32; + +/* + * This is used to store 64-bit bound value. + */ +typedef struct _ipfw_insn_u64 { + ipfw_insn o; + u_int64_t bound; +} ipfw_insn_u64; /* * This is used to store IP addr-mask pairs. --- sys/netinet/ip_fw2.c Thu Jun 16 18:55:58 2005 +++ sys/netinet/ip_fw2.c Fri Jun 17 11:46:36 2005 @@ -2251,6 +2251,10 @@ * logic to deal with F_NOT and F_OR flags associated * with the opcode. */ + case O_BOUND: + match = (f->bcnt < ((ipfw_insn_u64 *)cmd)->bound); + break; + case O_NOP: match = 1; break; @@ -3387,6 +3391,11 @@ case O_PROB: case O_ICMPTYPE: if (cmdlen != F_INSN_SIZE(ipfw_insn_u32)) + goto bad_size; + break; + + case O_BOUND: + if (cmdlen != F_INSN_SIZE(ipfw_insn_u64)) goto bad_size; break; --------------040305060506050504080108 Content-Type: text/plain; name="ipfw_bound2.diff" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="ipfw_bound2.diff" --- sbin/ipfw/ipfw2.c Tue Jun 7 18:11:17 2005 +++ sbin/ipfw/ipfw2.c Fri Jun 17 13:40:54 2005 @@ -277,6 +277,8 @@ TOK_SRCIP6, TOK_IPV4, + TOK_BOUND, + TOK_CHECK_BOUND, }; struct _s_x dummynet_params[] = { @@ -403,6 +405,8 @@ { "dst-ip6", TOK_DSTIP6}, { "src-ipv6", TOK_SRCIP6}, { "src-ip6", TOK_SRCIP6}, + { "bound", TOK_BOUND}, + { "check-bound", TOK_CHECK_BOUND}, { "//", TOK_COMMENT }, { "not", TOK_NOT }, /* pseudo option */ @@ -1636,6 +1640,9 @@ flags |= HAVE_PROTO; break; + case O_BOUND: + break; + default: /*options ... */ if (!(cmd->len & (F_OR|F_NOT))) if (((cmd->opcode == O_IP6) && @@ -1858,6 +1865,10 @@ print_ext6hdr( (ipfw_insn *) cmd ); break; + case O_CHECK_BOUND: + printf(" check-bound %d", cmd->arg1); + break; + default: printf(" [opcode %d len %d]", cmd->opcode, cmd->len); @@ -1872,6 +1883,8 @@ } } show_prerequisites(&flags, HAVE_IP, 0); + if (rule->cmd->opcode == O_BOUND) + printf(" bound %u", ((ipfw_insn_u64 *)(rule->cmd))->bound); if (comment) printf(" // %s", comment); printf("\n"); @@ -2515,7 +2528,8 @@ " icmp6types LIST | ext6hdr LIST | flow-id N[,N] |\n" " mac ... | mac-type LIST | proto LIST | {recv|xmit|via} {IF|IPADDR} |\n" " setup | {tcpack|tcpseq|tcpwin} NN | tcpflags SPEC | tcpoptions SPEC |\n" -" tcpdatalen LIST | verrevpath | versrcreach | antispoof\n" +" tcpdatalen LIST | verrevpath | versrcreach | antispoof | bound VALUE |\n" +" check-bound NUM\n" ); exit(0); } @@ -3677,7 +3691,8 @@ * various flags used to record that we entered some fields. */ ipfw_insn *have_state = NULL; /* check-state or keep-state */ - ipfw_insn *have_log = NULL, *have_altq = NULL; + ipfw_insn *have_log = NULL, *have_altq = NULL, + *have_bound = NULL; size_t len; int i; @@ -4494,6 +4509,39 @@ ac = 0; break; + case TOK_BOUND: + NEED1("bound requires numeric value"); + if (have_bound) + errx(EX_USAGE, "only one of bound is allowed"); + if (open_par) + errx(EX_USAGE, "bound cannot be part " + "of an or block"); + if (cmd->len & F_NOT) + errx(EX_USAGE, + "\"not\" not allowed with bound option"); + { + char *end = NULL; + uint64_t bound = strtoull(*av, &end, 0); + if (bound) + switch (*end){ + case 'G': bound *= 1024; + case 'M': bound *= 1024; + case 'K': bound *= 1024; + }; + cmd->opcode = O_BOUND; + ((ipfw_insn_u64 *)cmd)->bound = bound; + cmd->len = F_INSN_SIZE(ipfw_insn_u64) & F_LEN_MASK; + have_bound = cmd; + ac--; av++; + } + break; + + case TOK_CHECK_BOUND: + NEED1("check-bound requires rule number"); + fill_cmd(cmd, O_CHECK_BOUND, 0, strtoul(*av, NULL, 0)); + ac--; av++; + break; + default: errx(EX_USAGE, "unrecognised option [%d] %s\n", i, s); } @@ -4506,6 +4554,8 @@ done: /* * Now copy stuff into the rule. + * If we have a bound option, the first instruction MUST BE + * a O_BOUND. * If we have a keep-state option, the first instruction * must be a PROBE_STATE (which is generated here). * If we have a LOG option, it was stored as the first command, @@ -4514,7 +4564,15 @@ dst = (ipfw_insn *)rule->cmd; /* - * First thing to write into the command stream is the match probability. + * First write into the command stream bound instruction + */ + if (have_bound) { + bcopy(have_bound, dst, F_LEN(have_bound) * sizeof(uint32_t)); + dst = next_cmd(dst); + } + + /* + * write the match probability */ if (match_prob != 1) { /* 1 means always match */ dst->opcode = O_PROB; @@ -4531,7 +4589,8 @@ dst = next_cmd(dst); } /* - * copy all commands but O_LOG, O_KEEP_STATE, O_LIMIT, O_ALTQ + * copy all commands but O_LOG, O_KEEP_STATE, O_LIMIT, O_ALTQ, + * O_BOUND */ for (src = (ipfw_insn *)cmdbuf; src != cmd; src += i) { i = F_LEN(src); @@ -4541,6 +4600,7 @@ case O_KEEP_STATE: case O_LIMIT: case O_ALTQ: + case O_BOUND: break; default: bcopy(src, dst, i * sizeof(uint32_t)); --- sys/netinet/ip_fw.h Fri Jun 3 05:10:28 2005 +++ sys/netinet/ip_fw.h Fri Jun 17 13:18:47 2005 @@ -154,6 +154,8 @@ O_NGTEE, /* copy to ng_ipfw */ O_IP4, + O_BOUND, /* u64 = bound in bytes */ + O_CHECK_BOUND, /* u16 = rule number */ O_LAST_OPCODE /* not an opcode! */ }; @@ -230,6 +232,14 @@ } ipfw_insn_u32; /* + * This is used to store 64-bit bound value. + */ +typedef struct _ipfw_insn_u64 { + ipfw_insn o; + u_int64_t bound; +} ipfw_insn_u64; + +/* * This is used to store IP addr-mask pairs. */ typedef struct _ipfw_insn_ip { @@ -351,11 +361,16 @@ * * When assembling instruction, remember the following: * + * + if a rule has a "bound" option, then the first instruction + * (at r->cmd) MUST BE an O_BOUND * + if a rule has a "keep-state" (or "limit") option, then the * first instruction (at r->cmd) MUST BE an O_PROBE_STATE * + if a rule has a "log" option, then the first action * (at ACTION_PTR(r)) MUST be O_LOG * + if a rule has an "altq" option, it comes after "log" + * + * NOTE: actually, O_PROB instruction may be first too. But O_BOUND + * MUST BE always first (at r->cmd). * * NOTE: we use a simple linked list of rules because we never need * to delete a rule without scanning the list. We do not use --- sys/netinet/ip_fw2.c Thu Jun 16 18:55:58 2005 +++ sys/netinet/ip_fw2.c Fri Jun 17 13:26:19 2005 @@ -2251,6 +2251,26 @@ * logic to deal with F_NOT and F_OR flags associated * with the opcode. */ + case O_BOUND: + match = (f->bcnt < ((ipfw_insn_u64 *)cmd)->bound); + break; + + case O_CHECK_BOUND: + { + struct ip_fw* rule; + for (rule = f->next; + rule && cmd->arg1 >= rule->rulenum; + rule = rule->next) + if (rule->rulenum == cmd->arg1 && + rule->cmd->opcode == O_BOUND ) + { + match = (rule->bcnt < + ((ipfw_insn_u64 *)(rule->cmd))->bound); + break; + } + } + break; + case O_NOP: match = 1; break; @@ -3373,6 +3393,7 @@ case O_EXT_HDR: case O_IP6: case O_IP4: + case O_CHECK_BOUND: if (cmdlen != F_INSN_SIZE(ipfw_insn)) goto bad_size; break; @@ -3388,6 +3409,16 @@ case O_ICMPTYPE: if (cmdlen != F_INSN_SIZE(ipfw_insn_u32)) goto bad_size; + break; + + case O_BOUND: + if (cmdlen != F_INSN_SIZE(ipfw_insn_u64)) + goto bad_size; + if (cmd != rule->cmd) { + printf("ipfw: bogus rule, opcode %d must be first\n", + cmd->opcode); + return EINVAL; + } break; case O_LIMIT: --------------040305060506050504080108-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 11:04: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 D4E6716A41C for ; Fri, 17 Jun 2005 11:04:24 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from aiolos.otenet.gr (aiolos.otenet.gr [195.170.0.93]) by mx1.FreeBSD.org (Postfix) with ESMTP id 38D7E43D49 for ; Fri, 17 Jun 2005 11:04:23 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from flame.daedalusnetworks.priv (aris.bedc.ondsl.gr [62.103.39.226]) by aiolos.otenet.gr (8.13.4/8.13.4/Debian-1) with SMTP id j5HB4IcJ017018; Fri, 17 Jun 2005 14:04:21 +0300 Received: from flame.daedalusnetworks.priv (localhost [127.0.0.1]) by flame.daedalusnetworks.priv (8.13.3+Sun/8.13.3) with ESMTP id j5HB4FHp000888; Fri, 17 Jun 2005 14:04:15 +0300 (EEST) Received: (from keramida@localhost) by flame.daedalusnetworks.priv (8.13.3+Sun/8.13.3/Submit) id j5HB49Tn000887; Fri, 17 Jun 2005 14:04:09 +0300 (EEST) Date: Fri, 17 Jun 2005 14:04:09 +0300 From: Giorgos Keramidas To: Scott Long Message-ID: <20050617110409.GA879@flame.pc> References: <1118845416.00316114.1118834401@10.7.7.3> <42B04080.9090504@icyb.net.ua> <42B04457.1070103@samsco.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42B04457.1070103@samsco.org> Cc: Emanuel Strobl , freebsd-current@freebsd.org, Andriy Gapon Subject: Re: PANIC: udf / lockmgr: locking against myself 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, 17 Jun 2005 11:04:24 -0000 On 2005-06-15 09:08, Scott Long wrote: > Andriy Gapon wrote: > >on 15.06.2005 14:19 Emanuel Strobl said the following: > >>Hello, > >> > >>I tried to read a backup DVD with UDF filesystem and I get the following > >>panick with yesterdays -current: > >> > >>mount_udf /dev/acd1 /mnt > >># cd /mnt > >># ls > >>Various Artists > >># cd Various > >>panic: lockmgr: locking against myself > > > > > >I can reproduce this panic on week old current under qemu emulation. > >Simple mount and ls do it. > > Probably fallout from the VFS work. I'll look at it =-( I can reliably reproduce this same panic on yesterday's current running on an Acer Ferrari 3400 by starting the build of procmail. I'm not sure if this is related to the file locking tests that procmail runs while the port is building, but it always triggers a panic. I didn't manage to get a backtrace, because the system instantly rebooted both times I tried to install procmail, but if necessary I'll try to get a dump. From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 11:32: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 1ECC016A41C; Fri, 17 Jun 2005 11:32: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 B9FA543D4C; Fri, 17 Jun 2005 11:32:18 +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 j5HBWHnC007226; Fri, 17 Jun 2005 06:32:17 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42B2B4C0.1030504@centtech.com> Date: Fri, 17 Jun 2005 06:32:16 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050603 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> <20050616181820.E27625@fledge.watson.org> <42B1B784.8010405@videotron.ca> <20050616184127.L27625@fledge.watson.org> <20050617110902.C56734@fledge.watson.org> In-Reply-To: <20050617110902.C56734@fledge.watson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: Reboot while booting with new per-CPU allocator 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, 17 Jun 2005 11:32:21 -0000 Robert Watson wrote: > > On Thu, 16 Jun 2005, Robert Watson wrote: > >>> Great :) It did the trick. The laptop is happily booting with the new >>> allocator now. Thanks a lot to you and Alan Cox. >> >> >> Looks like what basically happened is this these kern_malloc.c changes >> increase the memory burden on UMA as statistics structures for malloc >> types now get allocated from UMA. It looks like, from your dmesg, you >> have a fair number of modules loaded, so the storage for the >> statistics comes out of the early UMA page pool, whereas before it >> came out of BSS. We'll see if further tuning is required or not with >> large numbers of modules. The thing that surprised me, though, is the >> unclean failure mode. The other report saw a clean panic which >> presumably made debugging it much easier... > > > Interestingly, there's been a bunch of reports of this in the past few > days, and there weren't immediately after the malloc commit. I wonder > if some other recent change has increased the amount of UMA memory > allocated early in the boot, increasing the level of reports... alc 2005-06-16 17:06:34 UTC FreeBSD src repository Modified files: sys/vm uma_int.h Log: Increase UMA_BOOT_PAGES to prevent a crash during initialization. See http://docs.FreeBSD.org/cgi/mid.cgi?42AD8270.8060906 for a detailed description of the crash. Reported by: Eric Anderson Approved by: re (scottl) MFC after: 3 days Revision Changes Path 1.31 +1 -1 src/sys/vm/uma_int.h 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 Jun 17 11:38: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 479E016A41C; Fri, 17 Jun 2005 11:38:31 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [204.156.12.53]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1A53843D1D; Fri, 17 Jun 2005 11:38:31 +0000 (GMT) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by cyrus.watson.org (Postfix) with ESMTP id A6F6846B09; Fri, 17 Jun 2005 07:38:30 -0400 (EDT) Date: Fri, 17 Jun 2005 12:40:50 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Eric Anderson In-Reply-To: <42B2B4C0.1030504@centtech.com> Message-ID: <20050617123954.W56734@fledge.watson.org> References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> <20050616181820.E27625@fledge.watson.org> <42B1B784.8010405@videotron.ca> <20050616184127.L27625@fledge.watson.org> <20050617110902.C56734@fledge.watson.org> <42B2B4C0.1030504@centtech.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: alc@freebsd.org, freebsd-current@freebsd.org Subject: Re: Reboot while booting with new per-CPU allocator 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, 17 Jun 2005 11:38:31 -0000 On Fri, 17 Jun 2005, Eric Anderson wrote: >> Interestingly, there's been a bunch of reports of this in the past few >> days, and there weren't immediately after the malloc commit. I wonder if >> some other recent change has increased the amount of UMA memory allocated >> early in the boot, increasing the level of reports... > > Increase UMA_BOOT_PAGES to prevent a crash during initialization. See > http://docs.FreeBSD.org/cgi/mid.cgi?42AD8270.8060906 for a detailed > description of the crash. Yeah, this is the fix, but I guess I'm wondering what caused a recent spate of problem reports -- was it a delayed response to the malloc change as people gradually upgraded, or some other recent kernel change that caused increase demand for memory. Robert N M Watson From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 15:05:56 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 903BB16A41C; Thu, 16 Jun 2005 15:05:56 +0000 (GMT) (envelope-from jeffm@frob.org) Received: from triton.genwebhost.com (triton.genwebhost.com [209.9.226.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4EECD43D1D; Thu, 16 Jun 2005 15:05:56 +0000 (GMT) (envelope-from jeffm@frob.org) Received: from jmeegan by triton.genwebhost.com with local (Exim 4.43) id 1DivwD-0002T5-DY; Thu, 16 Jun 2005 11:05:49 -0400 Received: from 130.76.32.16 ([130.76.32.16]) (SquirrelMail authenticated user jeffm@frob.org) by www.frob.org with HTTP; Thu, 16 Jun 2005 11:05:49 -0400 (EDT) Message-ID: <18857.130.76.32.16.1118934349.squirrel@www.frob.org> In-Reply-To: <20050616144707.18bfa000.lists@yazzy.org> References: <20050615114556.6df96e8c.lists@yazzy.org> <1118925438.91936.2.camel@realtime.exit.com> <20050616144707.18bfa000.lists@yazzy.org> Date: Thu, 16 Jun 2005 11:05:49 -0400 (EDT) From: jeffm@frob.org To: "Marcin Jessa" User-Agent: SquirrelMail/1.4.4 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - triton.genwebhost.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [32337 32338] / [47 12] X-AntiAbuse: Sender Address Domain - frob.org X-Source: X-Source-Args: X-Source-Dir: X-Mailman-Approved-At: Fri, 17 Jun 2005 11:59:27 +0000 Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: Looking for networking solution. 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, 16 Jun 2005 15:05:56 -0000 > On Thu, 16 Jun 2005 05:37:18 -0700 > Frank Mayhar wrote: > >> On Wed, 2005-06-15 at 11:45 +0200, Marcin Jessa wrote: >> > I am looking for solution I could implement on a link with a huge >> latency when ping replies can go up to a few hundred miliseconds, e.g >> sateliete links. >> > What I was thinking about is some kind of virtual interface which >> could translate tcp to udp in one of the pears of the link and push >> the data it received from a 'normal' interface through the virtual >> interface without bothering about ack-timing. >> > The receiving end would have a similar interface which would translate >> the udp data stream to tcp and then route it out to the internet. >> > (normal network)tcp<-->virtual udp interface<-------->virtual udp >> interface<-->tcp(normal network) >> > >> > Is there something avaliable on FreeBSD that can be used for that >> purpose? >> > Maybe someone is working on such a thing in CURRENT ? >> > Any thoughts about that? Any sugestions for a solution? >> >> You want SCPS (the Space Communications Protocols Specification) >> software. Briefly, it fakes local TCP on either end while talking its >> own protocol over the high-latency link. I don't know if there is any >> open-source package available but there are certainly commercial >> solutions out there. >> -- > > Correct. That's why I asked about this problem here. > I was in doubt something like that existed for FreeBSD. > We are willing to pay someone to develop such a solution for FreeBSD. > I'd love to get in touch with someone willing to pick up that challenge. > > someone forwarded me this link (offlist) and said they have a fbsd implementation of SCPS. I have no other details. http://www.xiplink.com/ jeff > > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org" > From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 20:03: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 9A4BD16A41C for ; Thu, 16 Jun 2005 20:03:59 +0000 (GMT) (envelope-from snow@teardrop.org) Received: from imladris.teardrop.org (imladris.teardrop.org [66.92.66.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 68D1943D4C for ; Thu, 16 Jun 2005 20:03:59 +0000 (GMT) (envelope-from snow@teardrop.org) Received: by imladris.teardrop.org (Postfix, from userid 100) id DB9BDBF6AB; Thu, 16 Jun 2005 16:04:50 -0400 (EDT) Date: Thu, 16 Jun 2005 16:04:50 -0400 From: James Snow To: Sam Leffler Message-ID: <20050616200450.GB98695@teardrop.org> References: <20050616191450.GA98695@teardrop.org> <42B1D9D9.7040604@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42B1D9D9.7040604@errno.com> User-Agent: Mutt/1.4.2.1i X-Mailman-Approved-At: Fri, 17 Jun 2005 11:59:27 +0000 Cc: freebsd-current@freebsd.org Subject: Re: WPA Supplicant doesn't see my SSIDs? 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, 16 Jun 2005 20:03:59 -0000 On Thu, Jun 16, 2005 at 12:58:17PM -0700, Sam Leffler wrote: > > What does ifconfig ath0 list scan show? SSID BSSID CHAN RATE S:N INT CAPS 0... 00:0e:83:af:77:f5 40 54M 27:0 100 EP WPA WME 0... 00:0e:38:51:ca:6c 52 54M 28:0 100 EP WPA WME 0x000000000... 00:07:eb:30:c6:de 1 11M 27:0 100 EPS SDC-WAP-001 00:0f:66:18:20:00 6 11M 7:0 100 E My Windows box confirms that 00:0e:83:af:77:f5 is on channel 40, so there's definitely some communication taking place. > Try not setting scan_ssid in the network block; not sure that it does > anything useful. I've tried it both ways. I believe it handles APs that don't respond to broadcasts. It was unclear if these Aironet APs were or not. There's no obvious setting for it in their configuration. > Also you terminate the scan after one try; when a channel is crowded > sometimes the first scan may not find all ap's on it. I just did that for the sake of pasting the output. I've left it running while tweaking configuration options and running 'wpa_cli reconfigure' but I've never managed to get our SSID to appear in wpa_supplicant's output. Odd that it picks up SDC-WAP-001 no problem. > You can also build the 80211debug program in src/tools/tools/ath and > do 80211debug scan to get debug msgs from kernel sent to the console. Will do. -Snow From owner-freebsd-current@FreeBSD.ORG Thu Jun 16 20:44: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 1566416A41F for ; Thu, 16 Jun 2005 20:44:48 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (khavrinen.csail.mit.edu [128.30.28.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id B98DA43D48 for ; Thu, 16 Jun 2005 20:44:47 +0000 (GMT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: from khavrinen.csail.mit.edu (localhost.csail.mit.edu [127.0.0.1]) by khavrinen.csail.mit.edu (8.13.1/8.13.1) with ESMTP id j5GKijRf028893 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK CN=khavrinen.lcs.mit.edu issuer=SSL+20Client+20CA); Thu, 16 Jun 2005 16:44:46 -0400 (EDT) (envelope-from wollman@khavrinen.csail.mit.edu) Received: (from wollman@localhost) by khavrinen.csail.mit.edu (8.13.1/8.13.1/Submit) id j5GKif1x028888; Thu, 16 Jun 2005 16:44:41 -0400 (EDT) (envelope-from wollman) From: Garrett Wollman MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17073.58552.862249.81604@khavrinen.csail.mit.edu> Date: Thu, 16 Jun 2005 16:44:40 -0400 To: Brooks Davis In-Reply-To: <20050616201646.GC13900@odin.ac.hmc.edu> References: <200506161312.51857.jhb@FreeBSD.org> <42B1D823.5030108@errno.com> <20050616201646.GC13900@odin.ac.hmc.edu> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-1.6 (khavrinen.csail.mit.edu [127.0.0.1]); Thu, 16 Jun 2005 16:44:46 -0400 (EDT) X-Virus-Scanned: ClamAV 0.85.1/943/Thu Jun 16 13:24:01 2005 on khavrinen.csail.mit.edu X-Virus-Status: Clean X-Spam-Status: No, score=0.0 required=5.0 tests=none version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on khavrinen.csail.mit.edu X-Mailman-Approved-At: Fri, 17 Jun 2005 11:59:27 +0000 Cc: current@FreeBSD.ORG Subject: Re: New dhclient broke multiple domains in domain-name 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, 16 Jun 2005 20:44:48 -0000 < said: > The RFC is shockingly lacking in this area. It's rather odd that they > send a value for domain, but not for search (in resolv.conf). It's not > suprising that people ended up abusing this to set search. There is a standard (unless it didn't make it out of I-D) for doing this. The shocking thing is that isc-dhcp(d) has never supported it. I used to have something like this in my dhcpd.conf: #option domain-search-order code 119 = string; # # This was generated using the following command: # perl -e 'print "\3lcs\3mit\3edu\0\2ai\xc0\4\xc0\4\2w3\3org\0"' | hd # ...and represents the search-list lcs.mit.edu, ai.mit.edu, mit.edu, w3.org # in DNS compressed encoding. # #option domain-search-order 03:6c:63:73:03:6d:69:74:03:65:64:75:00:02:61:69:c0:0 4:c0:04:02:77:33:03:6f:72:67:00; AFAIK not even Microsoft clients bother to implement this. -GAWollman From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 01:53:27 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 960F416A41C; Fri, 17 Jun 2005 01:53:27 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from mail.cs.ait.ac.th (mail.cs.ait.ac.th [192.41.170.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 75F9743D1F; Fri, 17 Jun 2005 01:53:23 +0000 (GMT) (envelope-from on@cs.ait.ac.th) Received: from banyan.cs.ait.ac.th (banyan.cs.ait.ac.th [192.41.170.5]) by mail.cs.ait.ac.th (8.12.11/8.12.11) with ESMTP id j5H1qqwp039274 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2005 08:52:53 +0700 (ICT) Received: (from on@localhost) by banyan.cs.ait.ac.th (8.13.1/8.12.11) id j5H1qpBl035396; Fri, 17 Jun 2005 08:52:51 +0700 (ICT) Date: Fri, 17 Jun 2005 08:52:51 +0700 (ICT) Message-Id: <200506170152.j5H1qpBl035396@banyan.cs.ait.ac.th> From: Olivier Nicole To: lists@yazzy.org In-reply-to: <20050616144707.18bfa000.lists@yazzy.org> (message from Marcin Jessa on Thu, 16 Jun 2005 14:47:07 +0200) References: <20050615114556.6df96e8c.lists@yazzy.org> <1118925438.91936.2.camel@realtime.exit.com> <20050616144707.18bfa000.lists@yazzy.org> X-Virus-Scanned: on CSIM by amavisd-milter (http://www.amavis.org/) X-Mailman-Approved-At: Fri, 17 Jun 2005 11:59:27 +0000 Cc: freebsd-net@freebsd.org, current@freebsd.org Subject: Re: Looking for networking solution. 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, 17 Jun 2005 01:53:27 -0000 > I want to just dump all the packets between two satelite links > without checking for ack back and forth which creates latency and > long ping times. The latency is created by the satellite transmission delay, not by the ack. ACK suffer from the latency, but do not create it. > Correct. That's why I asked about this problem here. > I was in doubt something like that existed for FreeBSD. > We are willing to pay someone to develop such a solution for FreeBSD. > I'd love to get in touch with someone willing to pick up that challenge. I doubt that anyone will be interested in developping a protocol that do not care about the reliability of transmission. Just saying "drop the ack" is not the way to go. If you are talking about a protocole that does dialogue (like email), suppressing the ack will not help: one end must wait until it receives one question before it can answer, and then the ack is transmitted in the same paket as the answer. If you are talking about a more "one way" protocol (like http for ex. request one file and then wait for the file to flow), a better a pproach would be to allow a bigger chunk of data to get through before the first ack is due (to fill the pipe). That can be done by increading the window size of TCP, without damaging the retransmission capabilities. As the window size change would need to b done in every client and server, we were once considering to put two reverse NAT at each end of the satellite link. The NAT being in charge of changing the window size (I don't remember the full details, but it looked feasible). Olivier From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 11:11: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 8F90416A41C for ; Fri, 17 Jun 2005 11:11:37 +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 39B4843D1D for ; Fri, 17 Jun 2005 11:11: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 9FCDEEB09E7 for ; Fri, 17 Jun 2005 19:11:35 +0800 (CST) Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 8A64F131990; Fri, 17 Jun 2005 19:11:33 +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 79857-15; Fri, 17 Jun 2005 19:11:28 +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 424EE13153D; Fri, 17 Jun 2005 19:11:26 +0800 (CST) From: Xin LI To: Jiawei Ye In-Reply-To: References: <1118912651.860.17.camel@spirit> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-lF7h8I4fXt9z0WLU0YNH" Organization: The FreeBSD Simplified Chinese Project Date: Fri, 17 Jun 2005 19:11:23 +0800 Message-Id: <1119006683.734.8.camel@spirit> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port X-Virus-Scanned: amavisd-new at frontfree.net X-Mailman-Approved-At: Fri, 17 Jun 2005 11:59:27 +0000 Cc: freebsd-current@freebsd.org Subject: Re: Recent VFS locking vs kqueue 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, 17 Jun 2005 11:11:37 -0000 --=-lF7h8I4fXt9z0WLU0YNH Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Jiawei, =E5=9C=A8 2005-06-16=E5=9B=9B=E7=9A=84 17:46 +0800=EF=BC=8CJiawei Ye=E5=86= =99=E9=81=93=EF=BC=9A > Perhaps you could try compling Apache2 with KQUEUE and THREADS > support, then try exercise the httpd server with 'webbench -c 1000'. I > got several panics (alas, not dump available) during the last week > with such setup. After turning off KQUEUE and THREADS support in > Apache2, things calmed down. I can reproduce this on my laptop with -c 2000. This is different from the panic I have described in my previous post - it's caused by a NULL pointer deference. I will try to figure out what was happening. BTW. Do you have PREEMPTION, ULE, etc. in your kernel configuration? It would save me some time to re-compile kernels to narrow down the cause. Cheers, --=20 Xin LI http://www.delphij.net/ --=-lF7h8I4fXt9z0WLU0YNH 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) iD8DBQBCsq/b/cVsHxFZiIoRAr6XAJ9iJ070aiitRvJTUljwkCcWt33p+QCfSaLx 8ix25OaPCk52KbV9GBoMpEg= =XfFr -----END PGP SIGNATURE----- --=-lF7h8I4fXt9z0WLU0YNH-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 11:59: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 D1B9816A470; Fri, 17 Jun 2005 11:59:47 +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 01BA543D4C; Fri, 17 Jun 2005 11:59:46 +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 j5HBxjEx007374; Fri, 17 Jun 2005 06:59:46 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42B2BB31.7000809@centtech.com> Date: Fri, 17 Jun 2005 06:59:45 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050603 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> <20050616181820.E27625@fledge.watson.org> <42B1B784.8010405@videotron.ca> <20050616184127.L27625@fledge.watson.org> <20050617110902.C56734@fledge.watson.org> <42B2B4C0.1030504@centtech.com> <20050617123954.W56734@fledge.watson.org> In-Reply-To: <20050617123954.W56734@fledge.watson.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.org Subject: Re: Reboot while booting with new per-CPU allocator 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, 17 Jun 2005 11:59:48 -0000 Robert Watson wrote: > > On Fri, 17 Jun 2005, Eric Anderson wrote: > >>> Interestingly, there's been a bunch of reports of this in the past >>> few days, and there weren't immediately after the malloc commit. I >>> wonder if some other recent change has increased the amount of UMA >>> memory allocated early in the boot, increasing the level of reports... >> >> >> Increase UMA_BOOT_PAGES to prevent a crash during initialization. See >> http://docs.FreeBSD.org/cgi/mid.cgi?42AD8270.8060906 for a detailed >> description of the crash. > > > Yeah, this is the fix, but I guess I'm wondering what caused a recent > spate of problem reports -- was it a delayed response to the malloc > change as people gradually upgraded, or some other recent kernel change > that caused increase demand for memory. For me, it was the recent lack of apathy - finally getting around to trying some combos for suspending my laptop, I noticed that having apic+smp in my kernel made me crash on boot. Maybe it's some of the modules that have changed - the ones that caused the problems for me were: snd_pcm snd_ich sound vkbd If those weren't loaded via loader.conf, I was fine. Maybe the change is inside one of those. As I've said before, I'm no coder, so take all that with a grain of salt - but hopefully it's helpful to someone. 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 Jun 17 13:54: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 C315016A41C; Fri, 17 Jun 2005 13:54:55 +0000 (GMT) (envelope-from didier.wiroth@mcesr.etat.lu) Received: from postino-1.etat.lu (postino-1.etat.lu [194.154.205.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7B3A143D1D; Fri, 17 Jun 2005 13:54:55 +0000 (GMT) (envelope-from didier.wiroth@mcesr.etat.lu) Received: from avirus-1.cie.etat.lu (dispatch-1.cie.etat.lu [148.110.137.6]) by postino-1.etat.lu (Postfix) with ESMTP id 954A414B6D5F; Fri, 17 Jun 2005 15:54:54 +0200 (CEST) Received: from avirus-1.cie.etat.lu (dispatch-1.cie.etat.lu [148.110.137.6]) by localhost (CIE ESMTP Dispatch 1) with ESMTP id 93F0623B2E; Fri, 17 Jun 2005 15:54:54 +0200 (CEST) Received: from hermes-1.cie.etat.lu (hermes-1.cie.etat.lu [148.110.136.56]) by dispatch-1.cie.etat.lu (CIE ESMTP Dispatch 1) with ESMTP id 80F1723AE3; Fri, 17 Jun 2005 15:54:54 +0200 (CEST) Received: from hermes-1.cie.etat.lu (hermes-1.cie.etat.lu [148.110.136.56]) by store.etat.lu (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0II800270ENIFX40@store.etat.lu>; Fri, 17 Jun 2005 15:54:54 +0200 (MEST) Received: from lucy ([148.110.43.189]) by store.etat.lu (Sun Java System Messaging Server 6.1 HotFix 0.05 (built Oct 21 2004)) with ESMTP id <0II8003FOENF4G60@store.etat.lu>; Fri, 17 Jun 2005 15:54:54 +0200 (MEST) Date: Fri, 17 Jun 2005 15:54:54 +0200 From: Didier Wiroth In-reply-to: To: 'Remington L' , freebsd-questions@freebsd.org Message-id: <0II8003FRENI4G60@store.etat.lu> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcVypnCmYsr4iVTjT7ufCTUueMN+yQAnXVRg Cc: freebsd-current@freebsd.org Subject: Re: applying the vesa patch to stable for high console resolution 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, 17 Jun 2005 13:54:55 -0000 Hi, Sorry but I don't know. You should ask the freebsd-current list. Regards Didier -----Original Message----- From: Remington L [mailto:mrl0lz@gmail.com] Sent: Thursday, June 16, 2005 21:06 To: Didier Wiroth; freebsd-stable@freebsd.org; freebsd-questions@freebsd.org Subject: [SPAM-PAL] Re: applying the vesa patch to stable for high console resolution Yet another thing to ask. I have a wide screen laptop where the VBIOS does not report correct resolutions, has the system taken steps to correct this? ~Its an Intel i915GM, 15.4", native windows of 1200x800 From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 14:43: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 78F3816A41C; Fri, 17 Jun 2005 14:43:33 +0000 (GMT) (envelope-from spoerlein@informatik.uni-wuerzburg.de) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id E650D43D48; Fri, 17 Jun 2005 14:43:30 +0000 (GMT) (envelope-from spoerlein@informatik.uni-wuerzburg.de) Received: from wrzx30.rz.uni-wuerzburg.de (wrzx30.rz.uni-wuerzburg.de [132.187.1.30]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 06340DA5A8; Fri, 17 Jun 2005 16:43:30 +0200 (CEST) Received: from virusscan (localhost [127.0.0.1]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id D759C99BFA; Fri, 17 Jun 2005 16:43:29 +0200 (CEST) Received: from wrzx28.rz.uni-wuerzburg.de (wrzx28.rz.uni-wuerzburg.de [132.187.3.28]) by wrzx30.rz.uni-wuerzburg.de (Postfix) with ESMTP id BFDEC99B4E; Fri, 17 Jun 2005 16:43:29 +0200 (CEST) Received: from frodo.galgenberg.net (wwsx14.win-screen.uni-wuerzburg.de [132.187.253.14]) by wrzx28.rz.uni-wuerzburg.de (Postfix) with ESMTP id 9DAA7DA5A8; Fri, 17 Jun 2005 16:43:29 +0200 (CEST) Received: from coyote.q.local (gb-21-237.galgenberg.net [172.16.21.237]) by frodo.galgenberg.net (8.13.1/8.13.1) with ESMTP id j5HEhTLV027349; Fri, 17 Jun 2005 16:43:29 +0200 (CEST) (envelope-from spoerlein@informatik.uni-wuerzburg.de) Received: from igor.q.local (igor.q.local [192.168.0.147]) by coyote.q.local (8.13.3/8.13.1) with ESMTP id j5HEhSR5032179; Fri, 17 Jun 2005 16:43:29 +0200 (CEST) (envelope-from spoerlein@informatik.uni-wuerzburg.de) Received: from igor.q.local (localhost.q.local [127.0.0.1]) by igor.q.local (8.13.3/8.13.1) with ESMTP id j5HEhSTm085730; Fri, 17 Jun 2005 16:43:28 +0200 (CEST) (envelope-from spoerlein@informatik.uni-wuerzburg.de) Received: (from q@localhost) by igor.q.local (8.13.3/8.13.1/Submit) id j5HEhSiw085729; Fri, 17 Jun 2005 16:43:28 +0200 (CEST) (envelope-from spoerlein@informatik.uni-wuerzburg.de) Date: Fri, 17 Jun 2005 16:43:27 +0200 From: Ulrich Spoerlein To: John Baldwin Message-ID: <20050617144327.GA943@galgenberg.net> References: <200506161312.51857.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Qxx1br4bt0+wmkIi" Content-Disposition: inline In-Reply-To: <200506161312.51857.jhb@FreeBSD.org> User-Agent: Mutt/1.5.9i X-Virus-Scanned: by amavisd-new (Rechenzentrum Universitaet Wuerzburg) Cc: brooks@FreeBSD.org, current@FreeBSD.org Subject: Re: New dhclient broke multiple domains in domain-name 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, 17 Jun 2005 14:43:33 -0000 --Qxx1br4bt0+wmkIi Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, 16.06.2005 at 13:12:51 -0400, John Baldwin wrote: > A feature of both the old and new dhclient(8) is that it would take whate= ver=20 > was in the domain-name option returned by the DHCP server and stick it in= the=20 > 'search' line in /etc/resolv.conf. Thus, if you wanted to have DNS searc= h=20 > multiple domains, you could just pass a space separated list of domains t= o=20 > search in domain-name and it would just work. I've made use of this=20 > "feature" in several different environments in the past including my curr= ent=20 > test lab. It's even used in the example dhclient.conf in dhclient.conf(5= ): >=20 > interface "ep0" { > send host-name "andare.fugue.com"; > send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; > send dhcp-lease-time 3600; > supersede domain-name "fugue.com rc.vix.com home.vix.com"; > prepend domain-name-servers 127.0.0.1; > ... > } Interesting. I'm overwriting make_resolv_conf() in /etc/dhclient-enter-hooks to achieve the same result on 5-STABLE. If dhclient-enter-hooks is still supported, you could work around the issue. Ulrich Sp=F6rlein --=20 PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? --Qxx1br4bt0+wmkIi Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCsuGPmArGtfDbn0QRAhFBAKCtP9a/Su7BO9leZ3lGoCxIoXcX7wCeKami sBkzPbeMC8a3GysSMJlRw10= =dnEo -----END PGP SIGNATURE----- --Qxx1br4bt0+wmkIi-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 14:53: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 27D5616A41C for ; Fri, 17 Jun 2005 14:53:15 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id E100943D49 for ; Fri, 17 Jun 2005 14:53:14 +0000 (GMT) (envelope-from leafy7382@gmail.com) Received: by zproxy.gmail.com with SMTP id 40so541476nzk for ; Fri, 17 Jun 2005 07:53:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=Hw+fQ16YL+MEncHbFvTBoRZBIZHrR02DAUiL+OH96SAw+t9RD3CKsX/9XoWkAbe3ZJrD+/GlzzstNI8AX6/Edb+/8PdryauaY8ZwruutGvfSkOxg0nRpxX+3M7PaiVv2PKKi+7FTxZO3kvDmNg91VeJdymXACNaw84No/o1ecj0= Received: by 10.36.118.4 with SMTP id q4mr1348123nzc; Fri, 17 Jun 2005 07:53:14 -0700 (PDT) Received: by 10.36.88.8 with HTTP; Fri, 17 Jun 2005 07:53:14 -0700 (PDT) Message-ID: Date: Fri, 17 Jun 2005 22:53:14 +0800 From: Jiawei Ye To: Xin LI In-Reply-To: <1119006683.734.8.camel@spirit> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4085_410093.1119019994253" References: <1118912651.860.17.camel@spirit> <1119006683.734.8.camel@spirit> Cc: freebsd-current@freebsd.org Subject: Re: Recent VFS locking vs kqueue X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jiawei Ye List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 14:53:15 -0000 ------=_Part_4085_410093.1119019994253 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On 6/17/05, Xin LI wrote: > I can reproduce this on my laptop with -c 2000. This is different from > the panic I have described in my previous post - it's caused by a NULL > pointer deference. I will try to figure out what was happening. >=20 > BTW. Do you have PREEMPTION, ULE, etc. in your kernel configuration? > It would save me some time to re-compile kernels to narrow down the > cause. >=20 > Cheers, > -- > Xin LI http://www.delphij.net/ Thank you for looking into this. I have attached my kernel config file for your reference. BTW, did you happen to get a kernel crash dump when this happened? Though I have my dumpdev configured, these panics locks up my system which required hard resets. Regards, Jiawei --=20 "Without the userland, the kernel is useless." --inspired by The Tao of Programming ------=_Part_4085_410093.1119019994253 Content-Type: text/plain; name="GRC.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="GRC.txt" Iw0KIyBHRU5FUklDIC0tIEdlbmVyaWMga2VybmVsIGNvbmZpZ3VyYXRpb24gZmlsZSBmb3IgRnJl ZUJTRC9pMzg2DQojDQojIEZvciBtb3JlIGluZm9ybWF0aW9uIG9uIHRoaXMgZmlsZSwgcGxlYXNl IHJlYWQgdGhlIGhhbmRib29rIHNlY3Rpb24gb24NCiMgS2VybmVsIENvbmZpZ3VyYXRpb24gRmls ZXM6DQojDQojICAgIGh0dHA6Ly93d3cuRnJlZUJTRC5vcmcvZG9jL2VuX1VTLklTTzg4NTktMS9i b29rcy9oYW5kYm9vay9rZXJuZWxjb25maWctY29uZmlnLmh0bWwNCiMNCiMgVGhlIGhhbmRib29r IGlzIGFsc28gYXZhaWxhYmxlIGxvY2FsbHkgaW4gL3Vzci9zaGFyZS9kb2MvaGFuZGJvb2sNCiMg aWYgeW91J3ZlIGluc3RhbGxlZCB0aGUgZG9jIGRpc3RyaWJ1dGlvbiwgb3RoZXJ3aXNlIGFsd2F5 cyBzZWUgdGhlDQojIEZyZWVCU0QgV29ybGQgV2lkZSBXZWIgc2VydmVyIChodHRwOi8vd3d3LkZy ZWVCU0Qub3JnLykgZm9yIHRoZQ0KIyBsYXRlc3QgaW5mb3JtYXRpb24uDQojDQojIEFuIGV4aGF1 c3RpdmUgbGlzdCBvZiBvcHRpb25zIGFuZCBtb3JlIGRldGFpbGVkIGV4cGxhbmF0aW9ucyBvZiB0 aGUNCiMgZGV2aWNlIGxpbmVzIGlzIGFsc28gcHJlc2VudCBpbiB0aGUgLi4vLi4vY29uZi9OT1RF UyBhbmQgTk9URVMgZmlsZXMuDQojIElmIHlvdSBhcmUgaW4gZG91YnQgYXMgdG8gdGhlIHB1cnBv c2Ugb3IgbmVjZXNzaXR5IG9mIGEgbGluZSwgY2hlY2sgZmlyc3QNCiMgaW4gTk9URVMuDQojDQoj ICRGcmVlQlNEOiBzcmMvc3lzL2kzODYvY29uZi9HRU5FUklDLHYgMS40MjkgMjAwNS8wNS8yNCAx Njo0ODowNyBkYW1pZW4gRXhwICQNCg0KbWFjaGluZQkJaTM4Ng0KI2NwdQkJSTQ4Nl9DUFUNCiNj cHUJCUk1ODZfQ1BVDQpjcHUJCUk2ODZfQ1BVDQppZGVudAkJR1JDDQoNCiMgVG8gc3RhdGljYWxs eSBjb21waWxlIGluIGRldmljZSB3aXJpbmcgaW5zdGVhZCBvZiAvYm9vdC9kZXZpY2UuaGludHMN CiNoaW50cwkJIkdFTkVSSUMuaGludHMiCQkjIERlZmF1bHQgcGxhY2VzIHRvIGxvb2sgZm9yIGRl dmljZXMuDQoNCm1ha2VvcHRpb25zCURFQlVHPS1nCQkjIEJ1aWxkIGtlcm5lbCB3aXRoIGdkYigx KSBkZWJ1ZyBzeW1ib2xzDQoNCm9wdGlvbnMgCVNDSEVEX1VMRQkJIyBVTEUgc2NoZWR1bGVyDQoj b3B0aW9ucyAJU0NIRURfNEJTRAkJIyA0QlNEIHNjaGVkdWxlcg0Kb3B0aW9ucyAJUFJFRU1QVElP TgkJIyBFbmFibGUga2VybmVsIHRocmVhZCBwcmVlbXB0aW9uDQpvcHRpb25zIAlJTkVUCQkJIyBJ bnRlck5FVHdvcmtpbmcNCm9wdGlvbnMgCUlORVQ2CQkJIyBJUHY2IGNvbW11bmljYXRpb25zIHBy b3RvY29scw0Kb3B0aW9ucyAJRkZTCQkJIyBCZXJrZWxleSBGYXN0IEZpbGVzeXN0ZW0NCm9wdGlv bnMgCVNPRlRVUERBVEVTCQkjIEVuYWJsZSBGRlMgc29mdCB1cGRhdGVzIHN1cHBvcnQNCm9wdGlv bnMgCVVGU19BQ0wJCQkjIFN1cHBvcnQgZm9yIGFjY2VzcyBjb250cm9sIGxpc3RzDQpvcHRpb25z IAlVRlNfRElSSEFTSAkJIyBJbXByb3ZlIHBlcmZvcm1hbmNlIG9uIGJpZyBkaXJlY3Rvcmllcw0K b3B0aW9ucyAJTURfUk9PVAkJCSMgTUQgaXMgYSBwb3RlbnRpYWwgcm9vdCBkZXZpY2UNCm9wdGlv bnMgCU5GU0NMSUVOVAkJIyBOZXR3b3JrIEZpbGVzeXN0ZW0gQ2xpZW50DQpvcHRpb25zIAlORlNT RVJWRVIJCSMgTmV0d29yayBGaWxlc3lzdGVtIFNlcnZlcg0Kb3B0aW9ucyAJTkZTX1JPT1QJCSMg TkZTIHVzYWJsZSBhcyAvLCByZXF1aXJlcyBORlNDTElFTlQNCm9wdGlvbnMgCU1TRE9TRlMJCQkj IE1TRE9TIEZpbGVzeXN0ZW0NCm9wdGlvbnMgCUNEOTY2MAkJCSMgSVNPIDk2NjAgRmlsZXN5c3Rl bQ0Kb3B0aW9ucyAJUFJPQ0ZTCQkJIyBQcm9jZXNzIGZpbGVzeXN0ZW0gKHJlcXVpcmVzIFBTRVVE T0ZTKQ0Kb3B0aW9ucyAJUFNFVURPRlMJCSMgUHNldWRvLWZpbGVzeXN0ZW0gZnJhbWV3b3JrDQpv cHRpb25zIAlHRU9NX0dQVAkJIyBHVUlEIFBhcnRpdGlvbiBUYWJsZXMuDQpvcHRpb25zIAlDT01Q QVRfNDMJCSMgQ29tcGF0aWJsZSB3aXRoIEJTRCA0LjMgW0tFRVAgVEhJUyFdDQpvcHRpb25zIAlD T01QQVRfRlJFRUJTRDQJCSMgQ29tcGF0aWJsZSB3aXRoIEZyZWVCU0Q0DQpvcHRpb25zIAlTQ1NJ X0RFTEFZPTUwMDAJCSMgRGVsYXkgKGluIG1zKSBiZWZvcmUgcHJvYmluZyBTQ1NJDQpvcHRpb25z IAlLVFJBQ0UJCQkjIGt0cmFjZSgxKSBzdXBwb3J0DQpvcHRpb25zIAlTWVNWU0hNCQkJIyBTWVNW LXN0eWxlIHNoYXJlZCBtZW1vcnkNCm9wdGlvbnMgCVNZU1ZNU0cJCQkjIFNZU1Ytc3R5bGUgbWVz c2FnZSBxdWV1ZXMNCm9wdGlvbnMgCVNZU1ZTRU0JCQkjIFNZU1Ytc3R5bGUgc2VtYXBob3Jlcw0K b3B0aW9ucyAJX0tQT1NJWF9QUklPUklUWV9TQ0hFRFVMSU5HICMgUE9TSVggUDEwMDNfMUIgcmVh bC10aW1lIGV4dGVuc2lvbnMNCm9wdGlvbnMgCUtCRF9JTlNUQUxMX0NERVYJIyBpbnN0YWxsIGEg Q0RFViBlbnRyeSBpbiAvZGV2DQpvcHRpb25zIAlBSENfUkVHX1BSRVRUWV9QUklOVAkjIFByaW50 IHJlZ2lzdGVyIGJpdGZpZWxkcyBpbiBkZWJ1Zw0KCQkJCQkjIG91dHB1dC4gIEFkZHMgfjEyOGsg dG8gZHJpdmVyLg0Kb3B0aW9ucyAJQUhEX1JFR19QUkVUVFlfUFJJTlQJIyBQcmludCByZWdpc3Rl ciBiaXRmaWVsZHMgaW4gZGVidWcNCgkJCQkJIyBvdXRwdXQuICBBZGRzIH4yMTVrIHRvIGRyaXZl ci4NCm9wdGlvbnMgCUFEQVBUSVZFX0dJQU5UCQkjIEdpYW50IG11dGV4IGlzIGFkYXB0aXZlLg0K DQojIERlYnVnZ2luZyBmb3IgdXNlIGluIC1jdXJyZW50DQojb3B0aW9ucyAJS0RCCQkJIyBFbmFi bGUga2VybmVsIGRlYnVnZ2VyIHN1cHBvcnQuDQojb3B0aW9ucyAJRERCCQkJIyBTdXBwb3J0IERE Qi4NCiNvcHRpb25zIAlHREIJCQkjIFN1cHBvcnQgcmVtb3RlIEdEQi4NCiNvcHRpb25zIAlJTlZB UklBTlRTCQkjIEVuYWJsZSBjYWxscyBvZiBleHRyYSBzYW5pdHkgY2hlY2tpbmcNCiNvcHRpb25z IAlJTlZBUklBTlRfU1VQUE9SVAkjIEV4dHJhIHNhbml0eSBjaGVja3Mgb2YgaW50ZXJuYWwgc3Ry dWN0dXJlcywgcmVxdWlyZWQgYnkgSU5WQVJJQU5UUw0KI29wdGlvbnMgCVdJVE5FU1MJCQkjIEVu YWJsZSBjaGVja3MgdG8gZGV0ZWN0IGRlYWRsb2NrcyBhbmQgY3ljbGVzDQojb3B0aW9ucyAJV0lU TkVTU19TS0lQU1BJTgkjIERvbid0IHJ1biB3aXRuZXNzIG9uIHNwaW5sb2NrcyBmb3Igc3BlZWQN Cg0KIyBUbyBtYWtlIGFuIFNNUCBrZXJuZWwsIHRoZSBuZXh0IHR3byBsaW5lcyBhcmUgbmVlZGVk DQpvcHRpb25zIAlTTVAJCQkjIFN5bW1ldHJpYyBNdWx0aVByb2Nlc3NvciBLZXJuZWwNCmRldmlj ZQkJYXBpYwkJCSMgSS9PIEFQSUMNCg0KIyBCdXMgc3VwcG9ydC4gIERvIG5vdCByZW1vdmUgaXNh LCBldmVuIGlmIHlvdSBoYXZlIG5vIGlzYSBzbG90cw0KZGV2aWNlCQlpc2ENCiNkZXZpY2UJCWVp c2ENCmRldmljZQkJcGNpDQoNCiMgRmxvcHB5IGRyaXZlcw0KZGV2aWNlCQlmZGMNCg0KIyBBVEEg YW5kIEFUQVBJIGRldmljZXMNCmRldmljZQkJYXRhDQpkZXZpY2UJCWF0YWRpc2sJCSMgQVRBIGRp c2sgZHJpdmVzDQpkZXZpY2UJCWF0YXJhaWQJCSMgQVRBIFJBSUQgZHJpdmVzDQpkZXZpY2UJCWF0 YXBpY2QJCSMgQVRBUEkgQ0RST00gZHJpdmVzDQpkZXZpY2UJCWF0YXBpZmQJCSMgQVRBUEkgZmxv cHB5IGRyaXZlcw0KZGV2aWNlCQlhdGFwaXN0CQkjIEFUQVBJIHRhcGUgZHJpdmVzDQpvcHRpb25z IAlBVEFfU1RBVElDX0lECSMgU3RhdGljIGRldmljZSBudW1iZXJpbmcNCg0KIyBTQ1NJIENvbnRy b2xsZXJzDQpkZXZpY2UJCWFoYgkJIyBFSVNBIEFIQTE3NDIgZmFtaWx5DQpkZXZpY2UJCWFoYwkJ IyBBSEEyOTQwIGFuZCBvbmJvYXJkIEFJQzd4eHggZGV2aWNlcw0KZGV2aWNlCQlhaGQJCSMgQUhB MzkzMjAvMjkzMjAgYW5kIG9uYm9hcmQgQUlDNzl4eCBkZXZpY2VzDQpkZXZpY2UJCWFtZAkJIyBB TUQgNTNDOTc0IChUZWtyYW0gREMtMzkwKFQpKQ0KZGV2aWNlCQlpc3AJCSMgUWxvZ2ljIGZhbWls eQ0KI2RldmljZSAJaXNwZncJCSMgRmlybXdhcmUgZm9yIFFMb2dpYyBIQkFzLSBub3JtYWxseSBh IG1vZHVsZQ0KZGV2aWNlCQltcHQJCSMgTFNJLUxvZ2ljIE1QVC1GdXNpb24NCiNkZXZpY2UJCW5j cgkJIyBOQ1IvU3ltYmlvcyBMb2dpYw0KZGV2aWNlCQlzeW0JCSMgTkNSL1N5bWJpb3MgTG9naWMg KG5ld2VyIGNoaXBzZXRzICsgdGhvc2Ugb2YgYG5jcicpDQpkZXZpY2UJCXRybQkJIyBUZWtyYW0g REMzOTVVL1VXL0YgREMzMTVVIGFkYXB0ZXJzDQoNCmRldmljZQkJYWR2CQkjIEFkdmFuc3lzIFND U0kgYWRhcHRlcnMNCmRldmljZQkJYWR3CQkjIEFkdmFuc3lzIHdpZGUgU0NTSSBhZGFwdGVycw0K ZGV2aWNlCQlhaGEJCSMgQWRhcHRlYyAxNTR4IFNDU0kgYWRhcHRlcnMNCmRldmljZQkJYWljCQkj IEFkYXB0ZWMgMTVbMDEyXXggU0NTSSBhZGFwdGVycywgQUlDLTZbMjNdNjAuDQpkZXZpY2UJCWJ0 CQkjIEJ1c2xvZ2ljL015bGV4IE11bHRpTWFzdGVyIFNDU0kgYWRhcHRlcnMNCg0KZGV2aWNlCQlu Y3YJCSMgTkNSIDUzQzUwMA0KZGV2aWNlCQluc3AJCSMgV29ya2JpdCBOaW5qYSBTQ1NJLTMNCmRl dmljZQkJc3RnCQkjIFRNQyAxOEMzMC8xOEM1MA0KDQojIFNDU0kgcGVyaXBoZXJhbHMNCmRldmlj ZQkJc2NidXMJCSMgU0NTSSBidXMgKHJlcXVpcmVkIGZvciBTQ1NJKQ0KZGV2aWNlCQljaAkJIyBT Q1NJIG1lZGlhIGNoYW5nZXJzDQpkZXZpY2UJCWRhCQkjIERpcmVjdCBBY2Nlc3MgKGRpc2tzKQ0K ZGV2aWNlCQlzYQkJIyBTZXF1ZW50aWFsIEFjY2VzcyAodGFwZSBldGMpDQpkZXZpY2UJCWNkCQkj IENEDQpkZXZpY2UJCXBhc3MJCSMgUGFzc3Rocm91Z2ggZGV2aWNlIChkaXJlY3QgU0NTSSBhY2Nl c3MpDQpkZXZpY2UJCXNlcwkJIyBTQ1NJIEVudmlyb25tZW50YWwgU2VydmljZXMgKGFuZCBTQUYt VEUpDQoNCiMgUkFJRCBjb250cm9sbGVycyBpbnRlcmZhY2VkIHRvIHRoZSBTQ1NJIHN1YnN5c3Rl bQ0KZGV2aWNlCQlhbXIJCSMgQU1JIE1lZ2FSQUlEDQpkZXZpY2UJCWFyY21zcgkJIyBBcmVjYSBT QVRBIElJIFJBSUQNCmRldmljZQkJYXNyCQkjIERQVCBTbWFydFJBSUQgViwgVkkgYW5kIEFkYXB0 ZWMgU0NTSSBSQUlEDQpkZXZpY2UJCWNpc3MJCSMgQ29tcGFxIFNtYXJ0IFJBSUQgNSoNCmRldmlj ZQkJZHB0CQkjIERQVCBTbWFydGNhY2hlIElJSSwgSVYgLSBTZWUgTk9URVMgZm9yIG9wdGlvbnMN CmRldmljZQkJaHB0bXYJCSMgSGlnaHBvaW50IFJvY2tldFJBSUQgMTgyeA0KZGV2aWNlCQlpaXIJ CSMgSW50ZWwgSW50ZWdyYXRlZCBSQUlEDQpkZXZpY2UJCWlwcwkJIyBJQk0gKEFkYXB0ZWMpIFNl cnZlUkFJRA0KZGV2aWNlCQltbHkJCSMgTXlsZXggQWNjZWxlUkFJRC9lWHRyZW1lUkFJRA0KZGV2 aWNlCQl0d2EJCSMgM3dhcmUgOTAwMCBzZXJpZXMgUEFUQS9TQVRBIFJBSUQNCg0KIyBSQUlEIGNv bnRyb2xsZXJzDQpkZXZpY2UJCWFhYwkJIyBBZGFwdGVjIEZTQSBSQUlEDQpkZXZpY2UJCWFhY3AJ CSMgU0NTSSBwYXNzdGhyb3VnaCBmb3IgYWFjIChyZXF1aXJlcyBDQU0pDQpkZXZpY2UJCWlkYQkJ IyBDb21wYXEgU21hcnQgUkFJRA0KZGV2aWNlCQltbHgJCSMgTXlsZXggREFDOTYwIGZhbWlseQ0K ZGV2aWNlCQlwc3QJCSMgUHJvbWlzZSBTdXBlcnRyYWsgU1g2MDAwDQpkZXZpY2UJCXR3ZQkJIyAz d2FyZSBBVEEgUkFJRA0KDQojIGF0a2JkYzAgY29udHJvbHMgYm90aCB0aGUga2V5Ym9hcmQgYW5k IHRoZSBQUy8yIG1vdXNlDQpkZXZpY2UJCWF0a2JkYwkJIyBBVCBrZXlib2FyZCBjb250cm9sbGVy DQpkZXZpY2UJCWF0a2JkCQkjIEFUIGtleWJvYXJkDQpkZXZpY2UJCXBzbQkJIyBQUy8yIG1vdXNl DQoNCmRldmljZQkJdmdhCQkjIFZHQSB2aWRlbyBjYXJkIGRyaXZlcg0KDQpkZXZpY2UJCXNwbGFz aAkJIyBTcGxhc2ggc2NyZWVuIGFuZCBzY3JlZW4gc2F2ZXIgc3VwcG9ydA0KDQojIHN5c2NvbnMg aXMgdGhlIGRlZmF1bHQgY29uc29sZSBkcml2ZXIsIHJlc2VtYmxpbmcgYW4gU0NPIGNvbnNvbGUN CmRldmljZQkJc2MNCg0KIyBFbmFibGUgdGhpcyBmb3IgdGhlIHBjdnQgKFZUMjIwIGNvbXBhdGli bGUpIGNvbnNvbGUgZHJpdmVyDQojZGV2aWNlCQl2dA0KI29wdGlvbnMgCVhTRVJWRVIJCSMgc3Vw cG9ydCBmb3IgWCBzZXJ2ZXIgb24gYSB2dCBjb25zb2xlDQojb3B0aW9ucyAJRkFUX0NVUlNPUgkj IHN0YXJ0IHdpdGggYmxvY2sgY3Vyc29yDQoNCmRldmljZQkJYWdwCQkjIHN1cHBvcnQgc2V2ZXJh bCBBR1AgY2hpcHNldHMNCg0KIyBGbG9hdGluZyBwb2ludCBzdXBwb3J0IC0gZG8gbm90IGRpc2Fi bGUuDQpkZXZpY2UJCW5weA0KDQojIFBvd2VyIG1hbmFnZW1lbnQgc3VwcG9ydCAoc2VlIE5PVEVT IGZvciBtb3JlIG9wdGlvbnMpDQojZGV2aWNlCQlhcG0NCiMgQWRkIHN1c3BlbmQvcmVzdW1lIHN1 cHBvcnQgZm9yIHRoZSBpODI1NC4NCmRldmljZQkJcG10aW1lcg0KDQojIFBDQ0FSRCAoUENNQ0lB KSBzdXBwb3J0DQojIFBDTUNJQSBhbmQgY2FyZGJ1cyBicmlkZ2Ugc3VwcG9ydA0KZGV2aWNlCQlj YmIJCSMgY2FyZGJ1cyAoeWVudGEpIGJyaWRnZQ0KZGV2aWNlCQlwY2NhcmQJCSMgUEMgQ2FyZCAo MTYtYml0KSBidXMNCmRldmljZQkJY2FyZGJ1cwkJIyBDYXJkQnVzICgzMi1iaXQpIGJ1cw0KDQoj IFNlcmlhbCAoQ09NKSBwb3J0cw0KZGV2aWNlCQlzaW8JCSMgODI1MCwgMTZbNDVdNTAgYmFzZWQg c2VyaWFsIHBvcnRzDQoNCiMgUGFyYWxsZWwgcG9ydA0KZGV2aWNlCQlwcGMNCmRldmljZQkJcHBi dXMJCSMgUGFyYWxsZWwgcG9ydCBidXMgKHJlcXVpcmVkKQ0KZGV2aWNlCQlscHQJCSMgUHJpbnRl cg0KZGV2aWNlCQlwbGlwCQkjIFRDUC9JUCBvdmVyIHBhcmFsbGVsDQpkZXZpY2UJCXBwaQkJIyBQ YXJhbGxlbCBwb3J0IGludGVyZmFjZSBkZXZpY2UNCiNkZXZpY2UJCXZwbwkJIyBSZXF1aXJlcyBz Y2J1cyBhbmQgZGENCg0KIyBJZiB5b3UndmUgZ290IGEgImR1bWIiIHNlcmlhbCBvciBwYXJhbGxl bCBQQ0kgY2FyZCB0aGF0IGlzDQojIHN1cHBvcnRlZCBieSB0aGUgcHVjKDQpIGdsdWUgZHJpdmVy LCB1bmNvbW1lbnQgdGhlIGZvbGxvd2luZw0KIyBsaW5lIHRvIGVuYWJsZSBpdCAoY29ubmVjdHMg dG8gdGhlIHNpbyBhbmQvb3IgcHBjIGRyaXZlcnMpOg0KI2RldmljZQkJcHVjDQoNCiMgUENJIEV0 aGVybmV0IE5JQ3MuDQpkZXZpY2UJCWRlCQkjIERFQy9JbnRlbCBEQzIxeDR4IChgYFR1bGlwJycp DQpkZXZpY2UJCWVtCQkjIEludGVsIFBSTy8xMDAwIGFkYXB0ZXIgR2lnYWJpdCBFdGhlcm5ldCBD YXJkDQpkZXZpY2UJCWl4Z2IJCSMgSW50ZWwgUFJPLzEwR2JFIEV0aGVybmV0IENhcmQNCmRldmlj ZQkJdHhwCQkjIDNDb20gM2NSOTkwIChgYFR5cGhvb24nJykNCmRldmljZQkJdngJCSMgM0NvbSAz YzU5MCwgM2M1OTUgKGBgVm9ydGV4JycpDQoNCiMgUENJIEV0aGVybmV0IE5JQ3MgdGhhdCB1c2Ug dGhlIGNvbW1vbiBNSUkgYnVzIGNvbnRyb2xsZXIgY29kZS4NCiMgTk9URTogQmUgc3VyZSB0byBr ZWVwIHRoZSAnZGV2aWNlIG1paWJ1cycgbGluZSBpbiBvcmRlciB0byB1c2UgdGhlc2UgTklDcyEN CmRldmljZQkJbWlpYnVzCQkjIE1JSSBidXMgc3VwcG9ydA0KZGV2aWNlCQliZmUJCSMgQnJvYWRj b20gQkNNNDQweCAxMC8xMDAgRXRoZXJuZXQNCmRldmljZQkJYmdlCQkjIEJyb2FkY29tIEJDTTU3 MHh4IEdpZ2FiaXQgRXRoZXJuZXQNCmRldmljZQkJZGMJCSMgREVDL0ludGVsIDIxMTQzIGFuZCB2 YXJpb3VzIHdvcmthbGlrZXMNCmRldmljZQkJZnhwCQkjIEludGVsIEV0aGVyRXhwcmVzcyBQUk8v MTAwQiAoODI1NTcsIDgyNTU4KQ0KZGV2aWNlCQlsZ2UJCSMgTGV2ZWwgMSBMWFQxMDAxIGdpZ2Fi aXQgRXRoZXJuZXQNCmRldmljZQkJbmdlCQkjIE5hdFNlbWkgRFA4MzgyMCBnaWdhYml0IEV0aGVy bmV0DQpkZXZpY2UJCW52ZQkJIyBuVmlkaWEgbkZvcmNlIE1DUCBvbi1ib2FyZCBFdGhlcm5ldCBO ZXR3b3JraW5nDQpkZXZpY2UJCXBjbgkJIyBBTUQgQW03OUM5N3ggUENJIDEwLzEwMChwcmVjZWRl bmNlIG92ZXIgJ2xuYycpDQpkZXZpY2UJCXJlCQkjIFJlYWxUZWsgODEzOUMrLzgxNjkvODE2OVMv ODExMFMNCmRldmljZQkJcmwJCSMgUmVhbFRlayA4MTI5LzgxMzkNCmRldmljZQkJc2YJCSMgQWRh cHRlYyBBSUMtNjkxNSAoYGBTdGFyZmlyZScnKQ0KZGV2aWNlCQlzaXMJCSMgU2lsaWNvbiBJbnRl Z3JhdGVkIFN5c3RlbXMgU2lTIDkwMC9TaVMgNzAxNg0KZGV2aWNlCQlzawkJIyBTeXNLb25uZWN0 IFNLLTk4NHggJiBTSy05ODJ4IGdpZ2FiaXQgRXRoZXJuZXQNCmRldmljZQkJc3RlCQkjIFN1bmRh bmNlIFNUMjAxIChELUxpbmsgREZFLTU1MFRYKQ0KZGV2aWNlCQl0aQkJIyBBbHRlb24gTmV0d29y a3MgVGlnb24gSS9JSSBnaWdhYml0IEV0aGVybmV0DQpkZXZpY2UJCXRsCQkjIFRleGFzIEluc3Ry dW1lbnRzIFRodW5kZXJMQU4NCmRldmljZQkJdHgJCSMgU01DIEV0aGVyUG93ZXIgSUkgKDgzYzE3 MCBgYEVQSUMnJykNCmRldmljZQkJdmdlCQkjIFZJQSBWVDYxMnggZ2lnYWJpdCBFdGhlcm5ldA0K ZGV2aWNlCQl2cgkJIyBWSUEgUmhpbmUsIFJoaW5lIElJDQpkZXZpY2UJCXdiCQkjIFdpbmJvbmQg Vzg5Qzg0MEYNCmRldmljZQkJeGwJCSMgM0NvbSAzYzkweCAoYGBCb29tZXJhbmcnJywgYGBDeWNs b25lJycpDQoNCiMgSVNBIEV0aGVybmV0IE5JQ3MuICBwY2NhcmQgTklDcyBpbmNsdWRlZC4NCmRl dmljZQkJY3MJCSMgQ3J5c3RhbCBTZW1pY29uZHVjdG9yIENTODl4MCBOSUMNCiMgJ2RldmljZSBl ZCcgcmVxdWlyZXMgJ2RldmljZSBtaWlidXMnDQpkZXZpY2UJCWVkCQkjIE5FWzEyXTAwMCwgU01D IFVsdHJhLCAzYzUwMywgRFM4MzkwIGNhcmRzDQpkZXZpY2UJCWV4CQkjIEludGVsIEV0aGVyRXhw cmVzcyBQcm8vMTAgYW5kIFByby8xMCsNCmRldmljZQkJZXAJCSMgRXRoZXJsaW5rIElJSSBiYXNl ZCBjYXJkcw0KZGV2aWNlCQlmZQkJIyBGdWppdHN1IE1CODY5NnggYmFzZWQgY2FyZHMNCmRldmlj ZQkJaWUJCSMgRXRoZXJFeHByZXNzIDgvMTYsIDNDNTA3LCBTdGFyTEFOIDEwIGV0Yy4NCmRldmlj ZQkJbG5jCQkjIE5FMjEwMCwgTkUzMi1WTCBMYW5jZSBFdGhlcm5ldCBjYXJkcw0KZGV2aWNlCQlz bgkJIyBTTUMncyA5MDAwIHNlcmllcyBvZiBFdGhlcm5ldCBjaGlwcw0KZGV2aWNlCQl4ZQkJIyBY aXJjb20gcGNjYXJkIEV0aGVybmV0DQoNCiMgSVNBIGRldmljZXMgdGhhdCB1c2UgdGhlIG9sZCBJ U0Egc2hpbXMNCiNkZXZpY2UJCWxlDQoNCiMgV2lyZWxlc3MgTklDIGNhcmRzDQpkZXZpY2UJCXds YW4JCSMgODAyLjExIHN1cHBvcnQNCmRldmljZQkJYW4JCSMgQWlyb25ldCA0NTAwLzQ4MDAgODAy LjExIHdpcmVsZXNzIE5JQ3MuDQpkZXZpY2UJCWF3aQkJIyBCYXlTdGFjayA2NjAgYW5kIG90aGVy cw0KZGV2aWNlCQlyYWwJCSMgUmFsaW5rIFRlY2hub2xvZ3kgUlQyNTAwIHdpcmVsZXNzIE5JQ3Mu DQpkZXZpY2UJCXdpCQkjIFdhdmVMQU4vSW50ZXJzaWwvU3ltYm9sIDgwMi4xMSB3aXJlbGVzcyBO SUNzLg0KI2RldmljZQkJd2wJCSMgT2xkZXIgbm9uIDgwMi4xMSBXYXZlbGFuIHdpcmVsZXNzIE5J Qy4NCg0KIyBQc2V1ZG8gZGV2aWNlcy4NCmRldmljZQkJbG9vcAkJIyBOZXR3b3JrIGxvb3BiYWNr DQpkZXZpY2UJCW1lbQkJIyBNZW1vcnkgYW5kIGtlcm5lbCBtZW1vcnkgZGV2aWNlcw0KZGV2aWNl CQlpbwkJIyBJL08gZGV2aWNlDQpkZXZpY2UJCXJhbmRvbQkJIyBFbnRyb3B5IGRldmljZQ0KZGV2 aWNlCQlldGhlcgkJIyBFdGhlcm5ldCBzdXBwb3J0DQpkZXZpY2UJCXNsCQkjIEtlcm5lbCBTTElQ DQpkZXZpY2UJCXBwcAkJIyBLZXJuZWwgUFBQDQpkZXZpY2UJCXR1bgkJIyBQYWNrZXQgdHVubmVs Lg0KZGV2aWNlCQlwdHkJCSMgUHNldWRvLXR0eXMgKHRlbG5ldCBldGMpDQpkZXZpY2UJCW1kCQkj IE1lbW9yeSAiZGlza3MiDQpkZXZpY2UJCWdpZgkJIyBJUHY2IGFuZCBJUHY0IHR1bm5lbGluZw0K ZGV2aWNlCQlmYWl0aAkJIyBJUHY2LXRvLUlQdjQgcmVsYXlpbmcgKHRyYW5zbGF0aW9uKQ0KDQoj IFRoZSBgYnBmJyBkZXZpY2UgZW5hYmxlcyB0aGUgQmVya2VsZXkgUGFja2V0IEZpbHRlci4NCiMg QmUgYXdhcmUgb2YgdGhlIGFkbWluaXN0cmF0aXZlIGNvbnNlcXVlbmNlcyBvZiBlbmFibGluZyB0 aGlzIQ0KIyBOb3RlIHRoYXQgJ2JwZicgaXMgcmVxdWlyZWQgZm9yIERIQ1AuDQpkZXZpY2UJCWJw ZgkJIyBCZXJrZWxleSBwYWNrZXQgZmlsdGVyDQoNCiMgVVNCIHN1cHBvcnQNCmRldmljZQkJdWhj aQkJIyBVSENJIFBDSS0+VVNCIGludGVyZmFjZQ0KZGV2aWNlCQlvaGNpCQkjIE9IQ0kgUENJLT5V U0IgaW50ZXJmYWNlDQpkZXZpY2UJCWVoY2kJCSMgRUhDSSBQQ0ktPlVTQiBpbnRlcmZhY2UgKFVT QiAyLjApDQpkZXZpY2UJCXVzYgkJIyBVU0IgQnVzIChyZXF1aXJlZCkNCiNkZXZpY2UJCXVkYnAJ CSMgVVNCIERvdWJsZSBCdWxrIFBpcGUgZGV2aWNlcw0KZGV2aWNlCQl1Z2VuCQkjIEdlbmVyaWMN CmRldmljZQkJdWhpZAkJIyAiSHVtYW4gSW50ZXJmYWNlIERldmljZXMiDQpkZXZpY2UJCXVrYmQJ CSMgS2V5Ym9hcmQNCmRldmljZQkJdWxwdAkJIyBQcmludGVyDQpkZXZpY2UJCXVtYXNzCQkjIERp c2tzL01hc3Mgc3RvcmFnZSAtIFJlcXVpcmVzIHNjYnVzIGFuZCBkYQ0KZGV2aWNlCQl1bXMJCSMg TW91c2UNCmRldmljZQkJdXJhbAkJIyBSYWxpbmsgVGVjaG5vbG9neSBSVDI1MDBVU0Igd2lyZWxl c3MgTklDcw0KZGV2aWNlCQl1cmlvCQkjIERpYW1vbmQgUmlvIDUwMCBNUDMgcGxheWVyDQpkZXZp Y2UJCXVzY2FubmVyCSMgU2Nhbm5lcnMNCiMgVVNCIEV0aGVybmV0LCByZXF1aXJlcyBtaWlidXMN CmRldmljZQkJYXVlCQkjIEFETXRlayBVU0IgRXRoZXJuZXQNCmRldmljZQkJYXhlCQkjIEFTSVgg RWxlY3Ryb25pY3MgVVNCIEV0aGVybmV0DQpkZXZpY2UJCWNkY2UJCSMgR2VuZXJpYyBVU0Igb3Zl ciBFdGhlcm5ldA0KZGV2aWNlCQljdWUJCSMgQ0FUQyBVU0IgRXRoZXJuZXQNCmRldmljZQkJa3Vl CQkjIEthd2FzYWtpIExTSSBVU0IgRXRoZXJuZXQNCmRldmljZQkJcnVlCQkjIFJlYWxUZWsgUlRM ODE1MCBVU0IgRXRoZXJuZXQNCg0KIyBGaXJlV2lyZSBzdXBwb3J0DQpkZXZpY2UJCWZpcmV3aXJl CSMgRmlyZVdpcmUgYnVzIGNvZGUNCmRldmljZQkJc2JwCQkjIFNDU0kgb3ZlciBGaXJlV2lyZSAo UmVxdWlyZXMgc2NidXMgYW5kIGRhKQ0KZGV2aWNlCQlmd2UJCSMgRXRoZXJuZXQgb3ZlciBGaXJl V2lyZSAobm9uLXN0YW5kYXJkISkNCg0K ------=_Part_4085_410093.1119019994253-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 15:42: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 7561916A446 for ; Fri, 17 Jun 2005 15:42:00 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3247643D49 for ; Fri, 17 Jun 2005 15:42:00 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[216.133.140.1]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 17 Jun 2005 11:55:26 -0400 From: John Baldwin To: Brooks Davis Date: Fri, 17 Jun 2005 11:42:33 -0400 User-Agent: KMail/1.8 References: <200506161312.51857.jhb@FreeBSD.org> <20050616185022.GJ21733@odin.ac.hmc.edu> In-Reply-To: <20050616185022.GJ21733@odin.ac.hmc.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506171142.33489.jhb@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: New dhclient broke multiple domains in domain-name 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, 17 Jun 2005 15:42:00 -0000 On Thursday 16 June 2005 02:50 pm, Brooks Davis wrote: > On Thu, Jun 16, 2005 at 01:12:51PM -0400, John Baldwin wrote: > > I'd very much like the old behavior restored if possible, or an > > alternative way to achieve the same result (multiple domains in the > > 'search' part of /etc/resolv.conf). Note that the old domain-name trick > > has worked all the way back to at least 4.1 and maybe even back in the > > 3.x days IIRC. > > I know about the issue and plan to fix it before release, but will not > get to it for another week. This is a really annoying feature because > it's widely supported, but clearly invalid based on reading the DHCP > spec. It's a bug that isc-dhcpd sends domain-name with spaces in it > since it violates the strict send, lenient accept rule. Note that the new dhclient binary is now violating the rule as well since it's not being lenient. :) At the very least, it could just throw out the domain-name and keep the rest of the lease rather than rejecting the entire lease offer. I've worked around it for now though and can wait a week or two to see what you come up with. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 15:42:03 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 6187916A432; Fri, 17 Jun 2005 15:42:03 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0BB0C43D49; Fri, 17 Jun 2005 15:42:02 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[216.133.140.1]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 17 Jun 2005 11:55:26 -0400 From: John Baldwin To: Ulrich Spoerlein Date: Fri, 17 Jun 2005 11:40:18 -0400 User-Agent: KMail/1.8 References: <200506161312.51857.jhb@FreeBSD.org> <20050617144327.GA943@galgenberg.net> In-Reply-To: <20050617144327.GA943@galgenberg.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506171140.19233.jhb@FreeBSD.org> Cc: brooks@FreeBSD.org, current@FreeBSD.org Subject: Re: New dhclient broke multiple domains in domain-name 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, 17 Jun 2005 15:42:03 -0000 On Friday 17 June 2005 10:43 am, Ulrich Spoerlein wrote: > On Thu, 16.06.2005 at 13:12:51 -0400, John Baldwin wrote: > > A feature of both the old and new dhclient(8) is that it would take > > whatever was in the domain-name option returned by the DHCP server and > > stick it in the 'search' line in /etc/resolv.conf. Thus, if you wanted > > to have DNS search multiple domains, you could just pass a space > > separated list of domains to search in domain-name and it would just > > work. I've made use of this "feature" in several different environments > > in the past including my current test lab. It's even used in the example > > dhclient.conf in dhclient.conf(5): > > > > interface "ep0" { > > send host-name "andare.fugue.com"; > > send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; > > send dhcp-lease-time 3600; > > supersede domain-name "fugue.com rc.vix.com home.vix.com"; > > prepend domain-name-servers 127.0.0.1; > > ... > > } > > Interesting. > > I'm overwriting make_resolv_conf() in /etc/dhclient-enter-hooks to > achieve the same result on 5-STABLE. If dhclient-enter-hooks is still > supported, you could work around the issue. It just worked out of the box for me with the old dhclient. The problem is that dhclient throws the entire lease out when it sees it as well. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 15:46: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 A9BF516A41C for ; Fri, 17 Jun 2005 15:46:16 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3E90343D49 for ; Fri, 17 Jun 2005 15:46:16 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j5HFkB8w003316; Fri, 17 Jun 2005 17:46:11 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j5HFk7XN003311; Fri, 17 Jun 2005 11:46:07 -0400 (EDT) (envelope-from cracauer) Date: Fri, 17 Jun 2005 11:46:07 -0400 From: Martin Cracauer To: "M. Warner Losh" Message-ID: <20050617114607.A3198@cons.org> References: <20050616182421.A87199@cons.org> <20050616.210529.20240024.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050616.210529.20240024.imp@bsdimp.com>; from imp@bsdimp.com on Thu, Jun 16, 2005 at 09:05:29PM -0600 Cc: cracauer@cons.org, freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 15:46:16 -0000 M. Warner Losh wrote on Thu, Jun 16, 2005 at 09:05:29PM -0600: > In message: <20050616182421.A87199@cons.org> > Martin Cracauer writes: > : Loading the radeon module segfaults the kernel, 6.0-current of > : yesterday. > : > : I have a Thinkpad with Radeon mobility 7500. 5-stable works on the > : same hardware. > : > : ddb trace shows: > : > : bus_generic_activate_resource+0x64 > : bus_generic_activate_resource+0x64 > : bus_generic_activate_resource+0x64 > : pci_alloc_resource+0x226 > : pci_alloc_resource+0x7x > : drm_get_resource_len+0x2f > : radeon_preinit+0xa2 > : drm_attach+0x2d > : > : Not sure what is involved to use gdb at this time. Can I do serial > : gdb with a 6.0-current AMD64 machine running the display? Can I use a > : 5.x box? > : > : It is 100% reproducable so I can gather more info as needed. > > Is this a module you compiled, or a module that's vendor supplied? It is the FreeBSD module built with the kernel. I used the same procedure as with 5-stable where it worked fine (as in 3D graphics actually work, not just it didn't panic). Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 15:51: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 DFD3016A41C; Fri, 17 Jun 2005 15:51:52 +0000 (GMT) (envelope-from sepotvin@videotron.ca) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id B088F43D1D; Fri, 17 Jun 2005 15:51:52 +0000 (GMT) (envelope-from sepotvin@videotron.ca) Received: from [10.0.0.147] ([67.70.237.74]) by VL-MO-MR007.ip.videotron.ca (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTPA id <0II8006I3JZIAE@VL-MO-MR007.ip.videotron.ca>; Fri, 17 Jun 2005 11:50:09 -0400 (EDT) Date: Fri, 17 Jun 2005 11:50:06 -0400 From: "Stephane E. Potvin" In-reply-to: <20050617123954.W56734@fledge.watson.org> To: Robert Watson Message-id: <42B2F12E.5000005@videotron.ca> MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050330) X-Enigmail-Version: 0.91.0.0 References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> <20050616181820.E27625@fledge.watson.org> <42B1B784.8010405@videotron.ca> <20050616184127.L27625@fledge.watson.org> <20050617110902.C56734@fledge.watson.org> <42B2B4C0.1030504@centtech.com> <20050617123954.W56734@fledge.watson.org> Cc: alc@FreeBSD.org, freebsd-current@FreeBSD.org, Eric Anderson Subject: Re: Reboot while booting with new per-CPU allocator 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, 17 Jun 2005 15:51:53 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Watson wrote: > > On Fri, 17 Jun 2005, Eric Anderson wrote: > >>> Interestingly, there's been a bunch of reports of this in the past >>> few days, and there weren't immediately after the malloc commit. I >>> wonder if some other recent change has increased the amount of UMA >>> memory allocated early in the boot, increasing the level of reports... >> >> >> Increase UMA_BOOT_PAGES to prevent a crash during initialization. See >> http://docs.FreeBSD.org/cgi/mid.cgi?42AD8270.8060906 for a detailed >> description of the crash. > > > Yeah, this is the fix, but I guess I'm wondering what caused a recent > spate of problem reports -- was it a delayed response to the malloc > change as people gradually upgraded, or some other recent kernel change > that caused increase demand for memory. Well, I had this problem since the day of the commit. I didn't had time to investigate what was happening so I just reverted to an older known working kernel. It might be a peculiarity of my setup that caused it to fail earlier though. Steph -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCsvEumdOXtTCX/nsRAhuZAJ94ouxzf6Hl8O5QsStk4q7SG3WsgACdEGnO xTRTl6Ypo/sccfcfaOU7Zgk= =Km7g -----END PGP SIGNATURE----- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 16:03: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 0AEB416A41C for ; Fri, 17 Jun 2005 16:03:28 +0000 (GMT) (envelope-from steve@pepcross.com) Received: from anchor-post-31.mail.demon.net (anchor-post-31.mail.demon.net [194.217.242.89]) by mx1.FreeBSD.org (Postfix) with ESMTP id C0A5543D1D for ; Fri, 17 Jun 2005 16:03:27 +0000 (GMT) (envelope-from steve@pepcross.com) Received: from mail.lonres.com ([194.70.153.187]) by anchor-post-31.mail.demon.net with esmtp (Exim 4.42) id 1DjJFh-000PyY-4O; Fri, 17 Jun 2005 15:59:29 +0000 Received: from bibipentium.lonres.com (bibipentium.lonres.com [10.10.10.225]) by mail.lonres.com (Postfix) with SMTP id 468EC2E09E; Fri, 17 Jun 2005 17:03:25 +0100 (BST) Received: by bibipentium.lonres.com (sSMTP sendmail emulation); Fri, 17 Jun 2005 17:03:32 +0100 Date: Fri, 17 Jun 2005 17:03:32 +0100 From: Steve Roome To: Martin Cracauer Message-ID: <20050617160332.GG34777@bibipentium.lonres.com> References: <20050616182421.A87199@cons.org> <20050616.210529.20240024.imp@bsdimp.com> <20050617114607.A3198@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050617114607.A3198@cons.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.ORG, "M. Warner Losh" Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 16:03:28 -0000 If it's any iterest, I had a similar experience earlier this week. xorg-server-6.8.99.5 with a radeon 9600 X and -current as of Monday causes my entire machine to freeze up completely rather than just panic. It's fine if I take drm option out of the x config again - so it's only when I actually use DRM, and for me it's a black screen and hard lockup. Steve Roome On Fri, Jun 17, 2005 at 11:46:07AM -0400, Martin Cracauer wrote: > M. Warner Losh wrote on Thu, Jun 16, 2005 at 09:05:29PM -0600: > > In message: <20050616182421.A87199@cons.org> > > Martin Cracauer writes: > > : Loading the radeon module segfaults the kernel, 6.0-current of > > : yesterday. > > : > > : I have a Thinkpad with Radeon mobility 7500. 5-stable works on the > > : same hardware. > > : > > : ddb trace shows: > > : > > : bus_generic_activate_resource+0x64 > > : bus_generic_activate_resource+0x64 > > : bus_generic_activate_resource+0x64 > > : pci_alloc_resource+0x226 > > : pci_alloc_resource+0x7x > > : drm_get_resource_len+0x2f > > : radeon_preinit+0xa2 > > : drm_attach+0x2d > > : > > : Not sure what is involved to use gdb at this time. Can I do serial > > : gdb with a 6.0-current AMD64 machine running the display? Can I use a > > : 5.x box? > > : > > : It is 100% reproducable so I can gather more info as needed. > > > > Is this a module you compiled, or a module that's vendor supplied? > > It is the FreeBSD module built with the kernel. I used the same > procedure as with 5-stable where it worked fine (as in 3D graphics > actually work, not just it didn't panic). > > Martin > -- > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% > Martin Cracauer http://www.cons.org/cracauer/ > No warranty. This email is probably produced by one of my cats > stepping on the keys. No, I don't have an infinite number of cats. > _______________________________________________ > 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 Fri Jun 17 16:59: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 4A14B16A41C for ; Fri, 17 Jun 2005 16:59:47 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 083CE43D58 for ; Fri, 17 Jun 2005 16:59:46 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[216.133.140.1]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 17 Jun 2005 13:13:12 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 17 Jun 2005 13:00:06 -0400 User-Agent: KMail/1.8 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506171300.07350.jhb@FreeBSD.org> Cc: Matteo Riondato , Aymeric MUNTZ Subject: Re: Iso modification 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, 17 Jun 2005 16:59:47 -0000 On Monday 02 May 2005 04:57 pm, Aymeric MUNTZ wrote: > Thank you for your answer but I might have not been clear. > > I don't want to build a livecd, but I want to modify a bootable > installation FreeBSD iso in order to add my own files. > I am not able (don't know how) to make a bootable iso with the 3 bootable > disks. > > Thank you for your help > > Best regards The FreeBSD ISO's don't use the floppies to boot, they use the non-emulated boot mode. Thus, you need to pass '-b boot/cdboot --no-emul-boot' to mkisofs as the options to make your new ISO bootable. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 17:11: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 AFD6F16A41C for ; Fri, 17 Jun 2005 17:11:47 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7734E43D48 for ; Fri, 17 Jun 2005 17:11:47 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5HH8l0h057776; Fri, 17 Jun 2005 11:08:47 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 17 Jun 2005 11:08:47 -0600 (MDT) Message-Id: <20050617.110847.74692199.imp@bsdimp.com> To: cracauer@cons.org From: Warner Losh In-Reply-To: <20050617114607.A3198@cons.org> References: <20050616182421.A87199@cons.org> <20050616.210529.20240024.imp@bsdimp.com> <20050617114607.A3198@cons.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 17:11:47 -0000 From: Martin Cracauer Subject: Re: 6.0-current panic: loading radeon module Date: Fri, 17 Jun 2005 11:46:07 -0400 > M. Warner Losh wrote on Thu, Jun 16, 2005 at 09:05:29PM -0600: > > In message: <20050616182421.A87199@cons.org> > > Martin Cracauer writes: > > : Loading the radeon module segfaults the kernel, 6.0-current of > > : yesterday. > > : > > : I have a Thinkpad with Radeon mobility 7500. 5-stable works on the > > : same hardware. > > : > > : ddb trace shows: > > : > > : bus_generic_activate_resource+0x64 > > : bus_generic_activate_resource+0x64 > > : bus_generic_activate_resource+0x64 > > : pci_alloc_resource+0x226 > > : pci_alloc_resource+0x7x > > : drm_get_resource_len+0x2f > > : radeon_preinit+0xa2 > > : drm_attach+0x2d > > : > > : Not sure what is involved to use gdb at this time. Can I do serial > > : gdb with a 6.0-current AMD64 machine running the display? Can I use a > > : 5.x box? > > : > > : It is 100% reproducable so I can gather more info as needed. > > > > Is this a module you compiled, or a module that's vendor supplied? > > It is the FreeBSD module built with the kernel. I used the same > procedure as with 5-stable where it worked fine (as in 3D graphics > actually work, not just it didn't panic). OK. There were some changes to the number of pages we reserve for uma allocation of malloc types. Can you try those? Warner From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 17:15: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 41A9516A41C for ; Fri, 17 Jun 2005 17:15:13 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC89743D48 for ; Fri, 17 Jun 2005 17:15:12 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j5HHF9mS005477; Fri, 17 Jun 2005 19:15:09 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j5HHF9ob005476; Fri, 17 Jun 2005 13:15:09 -0400 (EDT) (envelope-from cracauer) Date: Fri, 17 Jun 2005 13:15:08 -0400 From: Martin Cracauer To: Warner Losh Message-ID: <20050617131508.A5421@cons.org> References: <20050616182421.A87199@cons.org> <20050616.210529.20240024.imp@bsdimp.com> <20050617114607.A3198@cons.org> <20050617.110847.74692199.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050617.110847.74692199.imp@bsdimp.com>; from imp@bsdimp.com on Fri, Jun 17, 2005 at 11:08:47AM -0600 Cc: cracauer@cons.org, freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 17:15:13 -0000 Warner Losh wrote on Fri, Jun 17, 2005 at 11:08:47AM -0600: > From: Martin Cracauer > Subject: Re: 6.0-current panic: loading radeon module > Date: Fri, 17 Jun 2005 11:46:07 -0400 > > > M. Warner Losh wrote on Thu, Jun 16, 2005 at 09:05:29PM -0600: > > > In message: <20050616182421.A87199@cons.org> > > > Martin Cracauer writes: > > > : Loading the radeon module segfaults the kernel, 6.0-current of > > > : yesterday. > > > : > > > : I have a Thinkpad with Radeon mobility 7500. 5-stable works on the > > > : same hardware. > > > : > > > : ddb trace shows: > > > : > > > : bus_generic_activate_resource+0x64 > > > : bus_generic_activate_resource+0x64 > > > : bus_generic_activate_resource+0x64 > > > : pci_alloc_resource+0x226 > > > : pci_alloc_resource+0x7x > > > : drm_get_resource_len+0x2f > > > : radeon_preinit+0xa2 > > > : drm_attach+0x2d > > > : > > > : Not sure what is involved to use gdb at this time. Can I do serial > > > : gdb with a 6.0-current AMD64 machine running the display? Can I use a > > > : 5.x box? > > > : > > > : It is 100% reproducable so I can gather more info as needed. > > > > > > Is this a module you compiled, or a module that's vendor supplied? > > > > It is the FreeBSD module built with the kernel. I used the same > > procedure as with 5-stable where it worked fine (as in 3D graphics > > actually work, not just it didn't panic). > > OK. There were some changes to the number of pages we reserve for uma > allocation of malloc types. Can you try those? Yes, the box is ready for scratch testing. (Famous last words :-) Where do I find the changes? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 17:18: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 4A55216A41C for ; Fri, 17 Jun 2005 17:18:25 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id D743F43D55 for ; Fri, 17 Jun 2005 17:18:24 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j5HHIMlK005577; Fri, 17 Jun 2005 19:18:22 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j5HHIMVx005576; Fri, 17 Jun 2005 13:18:22 -0400 (EDT) (envelope-from cracauer) Date: Fri, 17 Jun 2005 13:18:22 -0400 From: Martin Cracauer To: Steve Roome Message-ID: <20050617131822.A5495@cons.org> References: <20050616182421.A87199@cons.org> <20050616.210529.20240024.imp@bsdimp.com> <20050617114607.A3198@cons.org> <20050617160332.GG34777@bibipentium.lonres.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050617160332.GG34777@bibipentium.lonres.com>; from steve@pepcross.com on Fri, Jun 17, 2005 at 05:03:32PM +0100 Cc: Martin Cracauer , freebsd-current@FreeBSD.ORG, "M. Warner Losh" Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 17:18:25 -0000 Steve Roome wrote on Fri, Jun 17, 2005 at 05:03:32PM +0100: > If it's any iterest, I had a similar experience earlier this week. > > xorg-server-6.8.99.5 with a radeon 9600 X and -current as of Monday > causes my entire machine to freeze up completely rather than just > panic. > > It's fine if I take drm option out of the x config again - so it's > only when I actually use DRM, and for me it's a black screen and hard > lockup. This is odd. DRI (and hence DRM) only support radeons up to 9200 (really 9250 probably). Your 9600 series shouldn't have a need for the drm module in first place. Are you sure it's not a panic? What happens if you just load the radeon module and not start the X11 server? Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 17:23: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 846F016A41C for ; Fri, 17 Jun 2005 17:23:40 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 483CF43D55 for ; Fri, 17 Jun 2005 17:23:40 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5HHM4HZ057998; Fri, 17 Jun 2005 11:22:04 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 17 Jun 2005 11:22:03 -0600 (MDT) Message-Id: <20050617.112203.112567050.imp@bsdimp.com> To: cracauer@cons.org From: Warner Losh In-Reply-To: <20050617131508.A5421@cons.org> References: <20050617114607.A3198@cons.org> <20050617.110847.74692199.imp@bsdimp.com> <20050617131508.A5421@cons.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 17:23:40 -0000 From: Martin Cracauer Subject: Re: 6.0-current panic: loading radeon module Date: Fri, 17 Jun 2005 13:15:08 -0400 > Warner Losh wrote on Fri, Jun 17, 2005 at 11:08:47AM -0600: > > From: Martin Cracauer > > Subject: Re: 6.0-current panic: loading radeon module > > Date: Fri, 17 Jun 2005 11:46:07 -0400 > > > > > M. Warner Losh wrote on Thu, Jun 16, 2005 at 09:05:29PM -0600: > > > > In message: <20050616182421.A87199@cons.org> > > > > Martin Cracauer writes: > > > > : Loading the radeon module segfaults the kernel, 6.0-current of > > > > : yesterday. > > > > : > > > > : I have a Thinkpad with Radeon mobility 7500. 5-stable works on the > > > > : same hardware. > > > > : > > > > : ddb trace shows: > > > > : > > > > : bus_generic_activate_resource+0x64 > > > > : bus_generic_activate_resource+0x64 > > > > : bus_generic_activate_resource+0x64 > > > > : pci_alloc_resource+0x226 > > > > : pci_alloc_resource+0x7x > > > > : drm_get_resource_len+0x2f > > > > : radeon_preinit+0xa2 > > > > : drm_attach+0x2d > > > > : > > > > : Not sure what is involved to use gdb at this time. Can I do serial > > > > : gdb with a 6.0-current AMD64 machine running the display? Can I use a > > > > : 5.x box? > > > > : > > > > : It is 100% reproducable so I can gather more info as needed. > > > > > > > > Is this a module you compiled, or a module that's vendor supplied? > > > > > > It is the FreeBSD module built with the kernel. I used the same > > > procedure as with 5-stable where it worked fine (as in 3D graphics > > > actually work, not just it didn't panic). > > > > OK. There were some changes to the number of pages we reserve for uma > > allocation of malloc types. Can you try those? > > Yes, the box is ready for scratch testing. (Famous last words :-) > > Where do I find the changes? It was committed yesterday, I believe. Warner From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 17:29: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 4673516A41C for ; Fri, 17 Jun 2005 17:29:51 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (Odin.AC.HMC.Edu [134.173.32.75]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1756743D48 for ; Fri, 17 Jun 2005 17:29:51 +0000 (GMT) (envelope-from brdavis@odin.ac.hmc.edu) Received: from odin.ac.hmc.edu (localhost.localdomain [127.0.0.1]) by odin.ac.hmc.edu (8.13.0/8.13.0) with ESMTP id j5HHTC5d023538; Fri, 17 Jun 2005 10:29:12 -0700 Received: (from brdavis@localhost) by odin.ac.hmc.edu (8.13.0/8.13.0/Submit) id j5HHTBtp023537; Fri, 17 Jun 2005 10:29:11 -0700 Date: Fri, 17 Jun 2005 10:29:11 -0700 From: Brooks Davis To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20050617172911.GE20342@odin.ac.hmc.edu> References: <20050615061009.GA11914@odin.ac.hmc.edu> <001501c5720b$aceb84d0$0b2a15ac@SMILEY> <20050616164747.GB21733@odin.ac.hmc.edu> <86y899ct8l.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WBsA/oQW3eTA3LlM" Content-Disposition: inline In-Reply-To: <86y899ct8l.fsf@xps.des.no> User-Agent: Mutt/1.4.1i X-Virus-Scanned: by amavisd-new X-Spam-Status: No, hits=0.0 required=8.0 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on odin.ac.hmc.edu Cc: 'Vladimir Grebenschikov' , Darren Pilgrim , 'Matthew Emmerton' , freebsd-current@freebsd.org Subject: Re: HEADSUP: OpenBSD dhclient incoming 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, 17 Jun 2005 17:29:51 -0000 --WBsA/oQW3eTA3LlM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 17, 2005 at 09:55:38AM +0200, Dag-Erling Sm=F8rgrav wrote: > Brooks Davis writes: > > I'm seriously considering removing the following variables: > > > > network_interfaces >=20 > Don't. >=20 > If network_interfaces is left unspecified, the scripts will use > 'ifconfig -l' and everything is fine provided all the interfaces were > already attached (i.e. the drivers were compiled into the kernel or > listed in loader.conf). This is the common case. >=20 > However, if the driver wasn't already loaded for some reason, > network_interfaces + ifconfig_foo0 will take care of it. Without > network_interfaces, we lose this functionality, for no benefit at all > to anyone. I don't buy this. Removing network_interfaces reduces the amount of code we need to write and the weird edge cases a fair bit and either way you have to edit a file to cause the module to load. Why not edit /boot/loader.conf instead and actually acknowledge what you are doing? -- Brooks --=20 Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 --WBsA/oQW3eTA3LlM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFCswhlXY6L6fI4GtQRAimAAJ9jvpEOd00K0SZDqjljdXzODd5J6QCfXFl2 /XVqaApjO+Ew40wIT01ZHuE= =ALf1 -----END PGP SIGNATURE----- --WBsA/oQW3eTA3LlM-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 17:31: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 EC24116A41C for ; Fri, 17 Jun 2005 17:31:14 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A4D343D1D for ; Fri, 17 Jun 2005 17:31:14 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j5HHVB29006004; Fri, 17 Jun 2005 19:31:11 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j5HHVBrD006003; Fri, 17 Jun 2005 13:31:11 -0400 (EDT) (envelope-from cracauer) Date: Fri, 17 Jun 2005 13:31:11 -0400 From: Martin Cracauer To: Warner Losh Message-ID: <20050617133111.A5947@cons.org> References: <20050617114607.A3198@cons.org> <20050617.110847.74692199.imp@bsdimp.com> <20050617131508.A5421@cons.org> <20050617.112203.112567050.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050617.112203.112567050.imp@bsdimp.com>; from imp@bsdimp.com on Fri, Jun 17, 2005 at 11:22:03AM -0600 Cc: cracauer@cons.org, freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 17:31:15 -0000 Warner Losh wrote on Fri, Jun 17, 2005 at 11:22:03AM -0600: > From: Martin Cracauer > Subject: Re: 6.0-current panic: loading radeon module > Date: Fri, 17 Jun 2005 13:15:08 -0400 > > > Warner Losh wrote on Fri, Jun 17, 2005 at 11:08:47AM -0600: > > > From: Martin Cracauer > > > Subject: Re: 6.0-current panic: loading radeon module > > > Date: Fri, 17 Jun 2005 11:46:07 -0400 > > > > > > > M. Warner Losh wrote on Thu, Jun 16, 2005 at 09:05:29PM -0600: > > > > > In message: <20050616182421.A87199@cons.org> > > > > > Martin Cracauer writes: > > > > > : Loading the radeon module segfaults the kernel, 6.0-current of > > > > > : yesterday. > > > > > : > > > > > : I have a Thinkpad with Radeon mobility 7500. 5-stable works on the > > > > > : same hardware. > > > > > : > > > > > : ddb trace shows: > > > > > : > > > > > : bus_generic_activate_resource+0x64 > > > > > : bus_generic_activate_resource+0x64 > > > > > : bus_generic_activate_resource+0x64 > > > > > : pci_alloc_resource+0x226 > > > > > : pci_alloc_resource+0x7x > > > > > : drm_get_resource_len+0x2f > > > > > : radeon_preinit+0xa2 > > > > > : drm_attach+0x2d > > > > > : > > > > > : Not sure what is involved to use gdb at this time. Can I do serial > > > > > : gdb with a 6.0-current AMD64 machine running the display? Can I use a > > > > > : 5.x box? > > > > > : > > > > > : It is 100% reproducable so I can gather more info as needed. > > > > > > > > > > Is this a module you compiled, or a module that's vendor supplied? > > > > > > > > It is the FreeBSD module built with the kernel. I used the same > > > > procedure as with 5-stable where it worked fine (as in 3D graphics > > > > actually work, not just it didn't panic). > > > > > > OK. There were some changes to the number of pages we reserve for uma > > > allocation of malloc types. Can you try those? > > > > Yes, the box is ready for scratch testing. (Famous last words :-) > > > > Where do I find the changes? > > It was committed yesterday, I believe. I get the same panic with a kernel and modules compiled from today's source. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 17:40: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 2DE8F16A41C for ; Fri, 17 Jun 2005 17:40:33 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: from smtp837.mail.sc5.yahoo.com (smtp837.mail.sc5.yahoo.com [66.163.171.24]) by mx1.FreeBSD.org (Postfix) with SMTP id 07D1B43D1D for ; Fri, 17 Jun 2005 17:40:32 +0000 (GMT) (envelope-from noackjr@alumni.rice.edu) Received: (qmail 15506 invoked from network); 17 Jun 2005 17:40:32 -0000 Received: from unknown (HELO optimator.noacks.org) (noacks@swbell.net@70.240.178.151 with login) by smtp837.mail.sc5.yahoo.com with SMTP; 17 Jun 2005 17:40:32 -0000 Received: from localhost (localhost [127.0.0.1]) by optimator.noacks.org (Postfix) with ESMTP id D0F74612C; Fri, 17 Jun 2005 12:40:31 -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 54658-04-2; Fri, 17 Jun 2005 12:40:29 -0500 (CDT) Received: from [127.0.0.1] (optimator [192.168.1.11]) by optimator.noacks.org (Postfix) with ESMTP id 96EEA60D7; Fri, 17 Jun 2005 12:40:29 -0500 (CDT) Message-ID: <42B30B06.7070005@alumni.rice.edu> Date: Fri, 17 Jun 2005 12:40:22 -0500 From: Jonathan Noack User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Martin Cracauer References: <20050616182421.A87199@cons.org> <20050616.210529.20240024.imp@bsdimp.com> <20050617114607.A3198@cons.org> <20050617160332.GG34777@bibipentium.lonres.com> <20050617131822.A5495@cons.org> In-Reply-To: <20050617131822.A5495@cons.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="------------enig1AC07163AFD01155A2DF6707" X-Virus-Scanned: amavisd-new at noacks.org Cc: Steve Roome , freebsd-current@FreeBSD.ORG, "M. Warner Losh" Subject: Re: 6.0-current panic: loading radeon module 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: Fri, 17 Jun 2005 17:40:33 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig1AC07163AFD01155A2DF6707 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 6/17/2005 12:18 PM, Martin Cracauer wrote: > Steve Roome wrote on Fri, Jun 17, 2005 at 05:03:32PM +0100: >>If it's any iterest, I had a similar experience earlier this week. >> >>xorg-server-6.8.99.5 with a radeon 9600 X and -current as of Monday >>causes my entire machine to freeze up completely rather than just >>panic. >> >>It's fine if I take drm option out of the x config again - so it's >>only when I actually use DRM, and for me it's a black screen and hard >>lockup. > > This is odd. DRI (and hence DRM) only support radeons up to 9200 > (really 9250 probably). Your 9600 series shouldn't have a need for > the drm module in first place. The r300 project (http://r300.sourceforge.net) is getting tantalizingly close to usable DRI for newer radeons. I saw glxgears running at 2600+ fps for about 15 seconds before the 3D engine on my 9800 Pro locked up. I finally got tired of manually merging Mesa commits and translating linux drm changes to bsd so I'm no longer using it. If you're interested, here's the basic instructions: http://lists.freebsd.org/pipermail/freebsd-x11/2005-May/001903.html Note that it requires a decent amount of effort just to get it to compile, much less do anything useful. Abandon hope, all ye who enter here... -- Jonathan Noack | noackjr@alumni.rice.edu | OpenPGP: 0x991D8195 --------------enig1AC07163AFD01155A2DF6707 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 (MingW32) iD8DBQFCswsMUFz01pkdgZURAn8zAKCHYlM1rbSqGNqiD2148k6k76xZHQCcDiir Eq840CGFhEGlYPDaGbfymN8= =5gzJ -----END PGP SIGNATURE----- --------------enig1AC07163AFD01155A2DF6707-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 18:02: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 3473E16A41C for ; Fri, 17 Jun 2005 18:02:33 +0000 (GMT) (envelope-from peadar@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0E38F43D49 for ; Fri, 17 Jun 2005 18:02:33 +0000 (GMT) (envelope-from peadar@FreeBSD.org) Received: from freefall.freebsd.org (peadar@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j5HI2WOR026423 for ; Fri, 17 Jun 2005 18:02:32 GMT (envelope-from peadar@freefall.freebsd.org) Received: (from peadar@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j5HI2WBS026422 for current@freebsd.org; Fri, 17 Jun 2005 18:02:32 GMT (envelope-from peadar) Date: Fri, 17 Jun 2005 18:02:32 +0000 From: Peter Edwards To: current@freebsd.org Message-ID: <20050617180232.GA25818@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="HlL+5n6rz5pIUxbD" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: Subject: Towards a working "wine". [long] 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, 17 Jun 2005 18:02:33 -0000 --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Y'all, I wanted to run a substantial windows app using "wine", and failed miserably. Looking around, it appears to be an acknowledged fact that wine is borked on FreeBSD, so I did some hacking about. The problems I found are centered around address space allocation: Wine is inevitably somewhat sensitive to address space layout, seeing as it has to present the Win32 binaries with a reasonably familiar environment. (All this assumes standard kernel, etc. Fixed addresses are the order of the day) Problem 1: When starting up, Wine needs to mmap stuff at address 0x80000000, but does so without using MAP_FIXED: I think the intention is that the code involved should be "best effort" to map to the hint address supplied to mmap(), rather than an all-or-nothing thing. FreeBSD's mmap sees this as an address in the data segment (see problem 2 below), and shifts the hint along to an address past there. There appears to be a MAP_TRYFIXED flag that wine uses on some systems that affords the hint more weight, which is pretty trivial to implement (see wine_mmap.txt). That was enough to get my app running, but not for long. Problem 2: The "wine" executable itself is located strangely, so the text and data go right up near the 2G point to help out Win32. (actually at address 0x77f00000, or 2GB-129MB). This is causes the heap to appear at such a high address, as FreeBSD merges the data from the executable image with the heap space (which malloc uses). Once the mmap at 0x80000000 happens, that puts a nice hole in the data segment that means sbrk starts to fail after 128MB is allocated. (On linux, it appears that the brk point and load address of the data segment from the executable are unrelated, and malloc() pays little attention to [s]brk() anyhow.) End result is, that with the break point sitting where it does, and the mapped Windows stuff 129MB above it, wine is very low on malloc()able memory. There is a disasterously ugly hack attached, wine_malloc.txt that hacks on malloc(), and adds a "W" option to enable the hack. This works by trading the brk()/sbrk() calls for an mmapping starting at 0xa0000000, which should be able to grow towards the process stack. (phkmalloc works with a large contiguous heap, rather than a fragmented one, so a more "pure" mmap-based approach won't fit into it too smoothly.) WARNING: Don't put the malloc patch directly into libc unless you are in the mood to deal with a hosed libc. I ran it like this: > $ cd /tmp > $ cp /usr/src/lib/libc/stdlib/malloc.c ./wine_malloc.c > $ patch wine_malloc.c < /tmp/wine_malloc.txt > $ cc -I /usr/src/lib/libc/include -o wine_malloc.so \ > -shared wine_malloc.c Then invoke wine as $ env LD_PRELOAD=/tmp/wine_malloc.so MALLOC_OPTIONS=W wine ... With these patches, wine is much, much more stable for me. I'd like to commit the kernel part at some stage if someone can review it, but the malloc() part seems like a particularly ugly hack. It could be cleaned up and added as a patch to the port I suppose, but has anyone got any better ideas? --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="wine_malloc.txt" --- A.c Fri Jun 17 18:04:15 2005 +++ B.c Fri Jun 17 18:20:54 2005 @@ -285,6 +285,51 @@ static void ifree(void *ptr); static void *irealloc(void *ptr, size_t size); +/* + * Ugly Wine compatibility stuff: + * This trades brk/sbrk in the data segment for mmap() from WINE_HEAPBASE up + * to the process's stack. + */ + +static caddr_t heapbase; +static caddr_t heaptail; +#define WINE_HEAPBASE ((caddr_t)0xa0000000) + +static caddr_t +heapend() +{ + if (!heapbase) + return sbrk(0); + return heaptail; +} + +static int +heapset(caddr_t point) +{ + caddr_t end; + int error; + + if (!heapbase) + return brk(point); + + /* Page-align the current end point */ + end = (caddr_t)((intptr_t)(heaptail + malloc_pagesize - 1) & + ~(malloc_pagesize - 1)); + error = 0; + + /* Grow or shrink? */ + if (end > point) { + error = munmap(point, end - point); + } + if (end < point) { + error = mmap(end, point - heaptail, PROT_READ|PROT_WRITE, + MAP_ANON|MAP_PRIVATE, -1, 0) == MAP_FAILED ? -1 : 0; + } + if (!error) + heaptail = point; + return error; +} + static void wrtmessage(const char *p1, const char *p2, const char *p3, const char *p4) { @@ -328,12 +373,12 @@ { caddr_t result, tail; - result = (caddr_t)pageround((u_long)sbrk(0)); + result = (caddr_t)pageround((u_long)heapend()); tail = result + (pages << malloc_pageshift); if (tail < result) return (NULL); - if (brk(tail)) { + if (heapset(tail)) { #ifdef MALLOC_EXTRA_SANITY wrterror("(ES): map_pages fails\n"); #endif /* MALLOC_EXTRA_SANITY */ @@ -457,6 +502,7 @@ case 'X': malloc_xmalloc = 1; break; case 'z': malloc_zero = 0; break; case 'Z': malloc_zero = 1; break; + case 'W': heapbase = heaptail = WINE_HEAPBASE; break; default: _malloc_message(_getprogname(), malloc_func, " warning: ", "unknown char in MALLOC_OPTIONS\n"); @@ -485,7 +531,7 @@ * We need a maximum of malloc_pageshift buckets, steal these from the * front of the page_directory; */ - malloc_origo = ((u_long)pageround((u_long)sbrk(0))) >> malloc_pageshift; + malloc_origo = ((u_long)pageround((u_long)heapend())) >> malloc_pageshift; malloc_origo -= malloc_pageshift; malloc_ninfo = malloc_pagesize / sizeof *page_dir; @@ -532,7 +578,7 @@ wrterror("(ES): zero entry on free_list\n"); if (pf->page > pf->end) wrterror("(ES): sick entry on free_list\n"); - if ((void*)pf->page >= (void*)sbrk(0)) + if ((void*)pf->page >= (void*)heapend()) wrterror("(ES): entry on free_list past brk\n"); if (page_dir[ptr2index(pf->page)] != MALLOC_FREE) wrterror("(ES): non-free first page on free-list\n"); @@ -948,7 +994,7 @@ if (pf->next == NULL && /* If we're the last one, */ pf->size > malloc_cache && /* ..and the cache is full, */ pf->end == malloc_brk && /* ..and none behind us, */ - malloc_brk == sbrk(0)) { /* ..and it's OK to do... */ + malloc_brk == heapend()) { /* ..and it's OK to do... */ /* * Keep the cache intact. Notice that the '>' above guarantees that @@ -957,7 +1003,7 @@ pf->end = (char *)pf->page + malloc_cache; pf->size = malloc_cache; - brk(pf->end); + heapset(pf->end); malloc_brk = pf->end; index = ptr2index(pf->end); --HlL+5n6rz5pIUxbD Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="wine_mmap.txt" Index: sys/sys/mman.h =================================================================== RCS file: /usr/cvs/FreeBSD/src/sys/sys/mman.h,v retrieving revision 1.40 diff -u -r1.40 mman.h --- sys/sys/mman.h 2 Apr 2005 12:33:31 -0000 1.40 +++ sys/sys/mman.h 16 Jun 2005 15:20:32 -0000 @@ -87,6 +87,7 @@ * Extended flags */ #define MAP_NOCORE 0x00020000 /* dont include these pages in a coredump */ +#define MAP_TRYFIXED 0x00040000 /* take hint more seriously */ #endif /* __BSD_VISIBLE */ #if __POSIX_VISIBLE >= 199309 Index: sys/vm/vm_mmap.c =================================================================== RCS file: /usr/cvs/FreeBSD/src/sys/vm/vm_mmap.c,v retrieving revision 1.200 diff -u -r1.200 vm_mmap.c --- sys/vm/vm_mmap.c 14 Apr 2005 16:03:30 -0000 1.200 +++ sys/vm/vm_mmap.c 17 Jun 2005 17:34:32 -0000 @@ -256,6 +256,8 @@ addr -= pageoff; if (addr & PAGE_MASK) return (EINVAL); + } + if (flags & (MAP_FIXED | MAP_TRYFIXED)) { /* Address range must be all in user VM space. */ if (addr < vm_map_min(&vms->vm_map) || addr + size > vm_map_max(&vms->vm_map)) --HlL+5n6rz5pIUxbD-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 18:03: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 1910916A41C for ; Fri, 17 Jun 2005 18:03:26 +0000 (GMT) (envelope-from tarc@tarc.po.cs.msu.su) Received: from tarc.po.cs.msu.su (tarc.po.cs.msu.su [158.250.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60DDC43D49 for ; Fri, 17 Jun 2005 18:03:25 +0000 (GMT) (envelope-from tarc@tarc.po.cs.msu.su) Received: from tarc.po.cs.msu.su (localhost [127.0.0.1]) by tarc.po.cs.msu.su (8.13.4/8.13.3) with ESMTP id j5HI3MpD001195 for ; Fri, 17 Jun 2005 22:03:22 +0400 (MSD) (envelope-from tarc@tarc.po.cs.msu.su) Received: (from tarc@localhost) by tarc.po.cs.msu.su (8.13.4/8.13.3/Submit) id j5HI3Ma9001193 for freebsd-current@freebsd.org; Fri, 17 Jun 2005 22:03:22 +0400 (MSD) (envelope-from tarc) Date: Fri, 17 Jun 2005 22:03:21 +0400 From: Tarc To: freebsd-current Message-ID: <20050617180321.GA1131@tarc.po.cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: -CURRENT crashes on compilling 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, 17 Jun 2005 18:03:26 -0000 Please, help! I change my old computer to a new one (see dmesgs links below) and my computer begins to crash anywhere(cc1, sh, awk, ...) with (mainly page fault) very often. What happines? hardware is ok, I have tested it. all configuration stay same, CFLAGS and COPTFLAGS are "-O2 -pipe" kernel config: http://tarc.po.cs.msu.su/usr/tarc/kernels/TarcCurrent old dmesg: http://tarc.po.cs.msu.su/usr/tarc/kernels/dmesg current dmesg: http://tarc.po.cu.msu.su/tarc/kernels/current/dmesg -- Best regards, Arseny Nasokin From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 18:11: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 0CFE116A41C; Fri, 17 Jun 2005 18:11:26 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 92ADC43D55; Fri, 17 Jun 2005 18:11:25 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.49] (lesnik.portaone.com [195.140.246.50]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j5HIBM2W022441 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2005 20:11:23 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <42B31247.9010603@portaone.com> Date: Fri, 17 Jun 2005 21:11:19 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Edwards References: <20050617180232.GA25818@freefall.freebsd.org> In-Reply-To: <20050617180232.GA25818@freefall.freebsd.org> Content-Type: text/plain; charset=KOI8-U; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/944/Thu Jun 16 23:33:33 2005 on www.portaone.com X-Virus-Status: Clean Cc: current@FreeBSD.ORG Subject: Re: Towards a working "wine". [long] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim.Sobolev@portaone.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 18:11:26 -0000 Peter Edwards wrote: > Y'all, > > I wanted to run a substantial windows app using "wine", and failed > miserably. Looking around, it appears to be an acknowledged fact > that wine is borked on FreeBSD, so I did some hacking about. > > The problems I found are centered around address space allocation: > Wine is inevitably somewhat sensitive to address space layout, > seeing as it has to present the Win32 binaries with a reasonably > familiar environment. (All this assumes standard kernel, etc. Fixed > addresses are the order of the day) > > Problem 1: > > When starting up, Wine needs to mmap stuff at address 0x80000000, > but does so without using MAP_FIXED: I think the intention is that > the code involved should be "best effort" to map to the hint address > supplied to mmap(), rather than an all-or-nothing thing. > > FreeBSD's mmap sees this as an address in the data segment (see > problem 2 below), and shifts the hint along to an address past > there. There appears to be a MAP_TRYFIXED flag that wine uses on > some systems that affords the hint more weight, which is pretty > trivial to implement (see wine_mmap.txt). That was enough to get > my app running, but not for long. Well, there is really no point of adding another MAP_TRYFIXED flag, since wine can call mmap(2) with MAP_FIXED and then if that fails try to call mmap(2) without it and deal with consequences. This will provide the same functionality but you won't get dependency on particular FreeBSD version to get MAP_TRYFIXED define. -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 18:15: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 3FB2D16A41C for ; Fri, 17 Jun 2005 18:15:07 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id F03D143D48 for ; Fri, 17 Jun 2005 18:15:06 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice6.sentex.ca (pumice6.sentex.ca [64.7.153.21]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j5HIEhsL038617 for ; Fri, 17 Jun 2005 14:14:43 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice6.sentex.ca (8.13.3/8.13.3) with ESMTP id j5HIF5oL002908; Fri, 17 Jun 2005 14:15:05 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j5HIExxu087147 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2005 14:14:59 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050617141056.03ea3830@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Fri, 17 Jun 2005 14:15:24 -0400 To: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= ) From: Mike Tancsa In-Reply-To: <867jj5wyvf.fsf@xps.des.no> References: <6.2.1.2.0.20050412220212.055c5d48@64.7.153.2> <867jj5wyvf.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.21 Cc: freebsd-current@freebsd.org Subject: Re: ichwd fixes / patches 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, 17 Jun 2005 18:15:07 -0000 At 04:23 AM 14/04/2005, Dag-Erling Sm=F8rgrav wrote: >Mike Tancsa writes: > > Any chance someone could champion / commit the fixes in > > http://www.freebsd.org/cgi/query-pr.cgi?pr=3Dkern/79698 and perhaps MFC > > ? Its non functional right now and the patches provided there make it > > work once again. > >ichwd is mine... the PR originator sent me patches a couple of days >ago which I'll test. I have both ICH5 and ICH6 hardware to test on. Hi, Any chance to commit the patches in the above PR ? I know its not= =20 ideal, but at least it works where as its currently 100% broken in the tree. As to the issue of the ICH6 stuff, looking through the LINUX lists, it=20 seems a lot of ICH6 MBs dont actually hookup the onboard watchdog for some= =20 reason. ---Mike=20 From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 18:17: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 636B816A41C for ; Fri, 17 Jun 2005 18:17:16 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1F54D43D4C for ; Fri, 17 Jun 2005 18:17:15 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 672686104; Fri, 17 Jun 2005 20:17:10 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 57DE76100; Fri, 17 Jun 2005 20:17:10 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 4203F33C1D; Fri, 17 Jun 2005 20:17:10 +0200 (CEST) To: Tarc References: <20050617180321.GA1131@tarc.po.cs.msu.su> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Fri, 17 Jun 2005 20:17:10 +0200 In-Reply-To: <20050617180321.GA1131@tarc.po.cs.msu.su> (tarc@tarc.po.cs.msu.su's message of "Fri, 17 Jun 2005 22:03:21 +0400") Message-ID: <867jgskfvd.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Learn: ham X-Spam-Score: -5.2/5.0 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tim.des.no Cc: freebsd-current Subject: Re: -CURRENT crashes on compilling 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, 17 Jun 2005 18:17:16 -0000 Tarc writes: > I change my old computer to a new one (see dmesgs links below) and > my computer begins to crash anywhere(cc1, sh, awk, ...) with (mainly > page fault) very often. Bad hardware - most likely bad RAM, possibly a bad CPU. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 18:21:18 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 CD14F16A41F for ; Fri, 17 Jun 2005 18:21:18 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7A39543D1D for ; Fri, 17 Jun 2005 18:21:18 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so488779nzp for ; Fri, 17 Jun 2005 11:21:18 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=c0GGkVDZqYaiSPvzAm0X3rKIhQIF5jW7HtSsdSiMec8rMfzEYJ87R4rgvMy3OvPqgxeeMywwX4PshtCIUfakV+JDqiSjqJ7vl0XhslvhDCJThjvybMYCZh11K143tGm5jpOPv9sHjT+Wi1ME8wHHBjwn+lVUIAOy+zNADQMi2qU= Received: by 10.36.222.73 with SMTP id u73mr922752nzg; Fri, 17 Jun 2005 11:21:17 -0700 (PDT) Received: by 10.36.68.15 with HTTP; Fri, 17 Jun 2005 11:21:17 -0700 (PDT) Message-ID: <34cb7c840506171121cd0437f@mail.gmail.com> Date: Fri, 17 Jun 2005 19:21:17 +0100 From: Peter Edwards To: Maxim.Sobolev@portaone.com In-Reply-To: <42B31247.9010603@portaone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050617180232.GA25818@freefall.freebsd.org> <42B31247.9010603@portaone.com> Cc: Peter Edwards , current@freebsd.org Subject: Re: Towards a working "wine". [long] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Edwards List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 18:21:18 -0000 On 6/17/05, Maxim Sobolev wrote: > Peter Edwards wrote: > > Y'all, > > > > I wanted to run a substantial windows app using "wine", and failed > > miserably. Looking around, it appears to be an acknowledged fact > > that wine is borked on FreeBSD, so I did some hacking about. > > > > The problems I found are centered around address space allocation: > > Wine is inevitably somewhat sensitive to address space layout, > > seeing as it has to present the Win32 binaries with a reasonably > > familiar environment. (All this assumes standard kernel, etc. Fixed > > addresses are the order of the day) > > > > Problem 1: > > > > When starting up, Wine needs to mmap stuff at address 0x80000000, > > but does so without using MAP_FIXED: I think the intention is that > > the code involved should be "best effort" to map to the hint address > > supplied to mmap(), rather than an all-or-nothing thing. > > > > FreeBSD's mmap sees this as an address in the data segment (see > > problem 2 below), and shifts the hint along to an address past > > there. There appears to be a MAP_TRYFIXED flag that wine uses on > > some systems that affords the hint more weight, which is pretty > > trivial to implement (see wine_mmap.txt). That was enough to get > > my app running, but not for long. >=20 > Well, there is really no point of adding another MAP_TRYFIXED flag, > since wine can call mmap(2) with MAP_FIXED and then if that fails try to > call mmap(2) without it and deal with consequences. This will provide > the same functionality but you won't get dependency on particular > FreeBSD version to get MAP_TRYFIXED define. >=20 Nope: MAP_FIXED will unconditionally overwrite any existing mapping at the requested address. From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 18:38:28 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 8BDAD16A41C; Fri, 17 Jun 2005 18:38:28 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from www.portaone.com (support.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 02A3643D1D; Fri, 17 Jun 2005 18:38:27 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.49] (lesnik.portaone.com [195.140.246.50]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j5HIcPrf026942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 17 Jun 2005 20:38:26 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <42B3189E.6030408@portaone.com> Date: Fri, 17 Jun 2005 21:38:22 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Edwards References: <20050617180232.GA25818@freefall.freebsd.org> <42B31247.9010603@portaone.com> <34cb7c840506171121cd0437f@mail.gmail.com> In-Reply-To: <34cb7c840506171121cd0437f@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/944/Thu Jun 16 23:33:33 2005 on www.portaone.com X-Virus-Status: Clean Cc: Peter Edwards , current@freebsd.org Subject: Re: Towards a working "wine". [long] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim.Sobolev@portaone.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 18:38:28 -0000 Peter Edwards wrote: > On 6/17/05, Maxim Sobolev wrote: > >>Peter Edwards wrote: >> >>>Y'all, >>> >>>I wanted to run a substantial windows app using "wine", and failed >>>miserably. Looking around, it appears to be an acknowledged fact >>>that wine is borked on FreeBSD, so I did some hacking about. >>> >>>The problems I found are centered around address space allocation: >>>Wine is inevitably somewhat sensitive to address space layout, >>>seeing as it has to present the Win32 binaries with a reasonably >>>familiar environment. (All this assumes standard kernel, etc. Fixed >>>addresses are the order of the day) >>> >>>Problem 1: >>> >>>When starting up, Wine needs to mmap stuff at address 0x80000000, >>>but does so without using MAP_FIXED: I think the intention is that >>>the code involved should be "best effort" to map to the hint address >>>supplied to mmap(), rather than an all-or-nothing thing. >>> >>>FreeBSD's mmap sees this as an address in the data segment (see >>>problem 2 below), and shifts the hint along to an address past >>>there. There appears to be a MAP_TRYFIXED flag that wine uses on >>>some systems that affords the hint more weight, which is pretty >>>trivial to implement (see wine_mmap.txt). That was enough to get >>>my app running, but not for long. >> >>Well, there is really no point of adding another MAP_TRYFIXED flag, >>since wine can call mmap(2) with MAP_FIXED and then if that fails try to >>call mmap(2) without it and deal with consequences. This will provide >>the same functionality but you won't get dependency on particular >>FreeBSD version to get MAP_TRYFIXED define. >> > > > Nope: MAP_FIXED will unconditionally overwrite any existing mapping at > the requested address. Hmm, the manpage doesn't mention anything of the effect. It only says: MAP_FIXED Do not permit the system to select a different address than the one specified. If the specified address can- not be used, mmap() will fail. If MAP_FIXED is speci- fied, addr must be a multiple of the pagesize. Use of this option is discouraged. Nothing about "overwriting any existing mapping". So that maybe implementation should be adjusted to match documentation, not another functionality be invented to workaround misbehaving implementation? -Maxim From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 19:20:44 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 9CAD116A41C; Fri, 17 Jun 2005 19:20:44 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FC5D43D53; Fri, 17 Jun 2005 19:20:44 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[216.133.140.1]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 17 Jun 2005 15:34:10 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 17 Jun 2005 13:58:24 -0400 User-Agent: KMail/1.8 References: <200505032126.34797.josemi@redesjm.local> <20050503222632.GA17595@stack.nl> <200505040037.09315.josemi@redesjm.local> In-Reply-To: <200505040037.09315.josemi@redesjm.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-13" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200506171358.25796.jhb@FreeBSD.org> Cc: Marc Olzheim , Jose M Rodriguez , current@freebsd.org Subject: Re: About specific pxeboot support 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, 17 Jun 2005 19:20:44 -0000 On Tuesday 03 May 2005 06:37 pm, Jose M Rodriguez wrote: > El Mi=E9rcoles, 4 de Mayo de 2005 00:26, Marc Olzheim escribi=F3: > > On Tue, May 03, 2005 at 09:26:34PM +0200, Jose M Rodriguez wrote: > > > Now, remembering a thread in -stable, and make a whish for the > > > forthcomming FreeBSD-6. > > > > > > I think that the actual release build may be easy tweak to produce > > > a populated /tftpboot directory ready for pxe tftp installs. (a > > > tftp enabled pxeboot, a mfs rootfs based con boot_crunch ...). > > > > > > If this can be put in a tarball like tftpinstall.tar.gz in the ftp > > > area, test of snapshots, betas, RCs, and so on will be done via > > > bootp/tftp boots. > > > > Erhm... All you need is to mount the iso on your tftproot dir and > > boot from it with console=3Dcomconsole... > > And download the full CD and cope with some glitchs. Loock for the > thread on -stable. > > Right now, we do floppies, a FTP distribution and some isos. > > I only pointing that make release may be tweak to produce a some megs > tarball that you can expand on tftpboot. > > If we have the boot_crunch done and the root mfs, this additional target > can't be too complex. > > And it's easy to test that 'go floppies'. You can just use the contents of the bootonly ISO which is much smaller tha= n=20 the full CD. =2D-=20 John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 19:20: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 9CAD116A41C; Fri, 17 Jun 2005 19:20:44 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2FC5D43D53; Fri, 17 Jun 2005 19:20:44 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[216.133.140.1]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 17 Jun 2005 15:34:10 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 17 Jun 2005 13:58:24 -0400 User-Agent: KMail/1.8 References: <200505032126.34797.josemi@redesjm.local> <20050503222632.GA17595@stack.nl> <200505040037.09315.josemi@redesjm.local> In-Reply-To: <200505040037.09315.josemi@redesjm.local> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-13" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200506171358.25796.jhb@FreeBSD.org> Cc: Marc Olzheim , Jose M Rodriguez , current@freebsd.org Subject: Re: About specific pxeboot support 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, 17 Jun 2005 19:20:44 -0000 On Tuesday 03 May 2005 06:37 pm, Jose M Rodriguez wrote: > El Mi=E9rcoles, 4 de Mayo de 2005 00:26, Marc Olzheim escribi=F3: > > On Tue, May 03, 2005 at 09:26:34PM +0200, Jose M Rodriguez wrote: > > > Now, remembering a thread in -stable, and make a whish for the > > > forthcomming FreeBSD-6. > > > > > > I think that the actual release build may be easy tweak to produce > > > a populated /tftpboot directory ready for pxe tftp installs. (a > > > tftp enabled pxeboot, a mfs rootfs based con boot_crunch ...). > > > > > > If this can be put in a tarball like tftpinstall.tar.gz in the ftp > > > area, test of snapshots, betas, RCs, and so on will be done via > > > bootp/tftp boots. > > > > Erhm... All you need is to mount the iso on your tftproot dir and > > boot from it with console=3Dcomconsole... > > And download the full CD and cope with some glitchs. Loock for the > thread on -stable. > > Right now, we do floppies, a FTP distribution and some isos. > > I only pointing that make release may be tweak to produce a some megs > tarball that you can expand on tftpboot. > > If we have the boot_crunch done and the root mfs, this additional target > can't be too complex. > > And it's easy to test that 'go floppies'. You can just use the contents of the bootonly ISO which is much smaller tha= n=20 the full CD. =2D-=20 John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" =3D http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 19:20:44 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 9D19E16A41F; Fri, 17 Jun 2005 19:20:44 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1549343D48; Fri, 17 Jun 2005 19:20:43 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[216.133.140.1]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 17 Jun 2005 15:34:10 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 17 Jun 2005 14:34:47 -0400 User-Agent: KMail/1.8 References: <20050510223636.GA49927@xor.obsecurity.org> <20050529175056.GA99318@xor.obsecurity.org> In-Reply-To: <20050529175056.GA99318@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506171434.49008.jhb@FreeBSD.org> Cc: amd64@freebsd.org, current@freebsd.org, Kris Kennaway Subject: Re: Fatal trap 12 in exec_copyout_strings() 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, 17 Jun 2005 19:20:44 -0000 On Sunday 29 May 2005 01:50 pm, Kris Kennaway wrote: > On Tue, May 10, 2005 at 03:36:36PM -0700, Kris Kennaway wrote: > > Got this on a dual amd64 with 8GB RAM running 6.0 from last week: > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 1; apic id = 01 > > fault virtual address = 0xffffffffa9cdc000 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xffffffff8037759f > > stack pointer = 0x10:0xffffffffba1637d0 > > frame pointer = 0x10:0xffffffffba163820 > > 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 = 52247 (sh) > > [thread pid 52247 tid 100149 ] > > Stopped at exec_copyout_strings+0x12f: > > db> wh > > Tracing pid 52247 tid 100149 td 0xffffff016e5724c0 > > exec_copyout_strings() at exec_copyout_strings+0x12f > > do_execve() at do_execve+0x39a > > kern_execve() at kern_execve+0xab > > execve() at execve+0x49 > > syscall() at syscall+0x382 > > Xfast_syscall() at Xfast_syscall+0xa8 > > --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090622c, rsp = > > 0x7fffffffe058, rbp = 0xffffffff --- db> > > I've got this panic twice more since. Do you have a kernel.debug? Can you do 'list *exec_copyout_strings+0x12f'? I think I've seen reports of the linux32_exec_copyout_strings() having a similar fault as well on amd64. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 19:20: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 9D19E16A41F; Fri, 17 Jun 2005 19:20:44 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1549343D48; Fri, 17 Jun 2005 19:20:43 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[216.133.140.1]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 17 Jun 2005 15:34:10 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 17 Jun 2005 14:34:47 -0400 User-Agent: KMail/1.8 References: <20050510223636.GA49927@xor.obsecurity.org> <20050529175056.GA99318@xor.obsecurity.org> In-Reply-To: <20050529175056.GA99318@xor.obsecurity.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-6" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506171434.49008.jhb@FreeBSD.org> Cc: amd64@freebsd.org, current@freebsd.org, Kris Kennaway Subject: Re: Fatal trap 12 in exec_copyout_strings() 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, 17 Jun 2005 19:20:45 -0000 On Sunday 29 May 2005 01:50 pm, Kris Kennaway wrote: > On Tue, May 10, 2005 at 03:36:36PM -0700, Kris Kennaway wrote: > > Got this on a dual amd64 with 8GB RAM running 6.0 from last week: > > > > Fatal trap 12: page fault while in kernel mode > > cpuid = 1; apic id = 01 > > fault virtual address = 0xffffffffa9cdc000 > > fault code = supervisor read, page not present > > instruction pointer = 0x8:0xffffffff8037759f > > stack pointer = 0x10:0xffffffffba1637d0 > > frame pointer = 0x10:0xffffffffba163820 > > 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 = 52247 (sh) > > [thread pid 52247 tid 100149 ] > > Stopped at exec_copyout_strings+0x12f: > > db> wh > > Tracing pid 52247 tid 100149 td 0xffffff016e5724c0 > > exec_copyout_strings() at exec_copyout_strings+0x12f > > do_execve() at do_execve+0x39a > > kern_execve() at kern_execve+0xab > > execve() at execve+0x49 > > syscall() at syscall+0x382 > > Xfast_syscall() at Xfast_syscall+0xa8 > > --- syscall (59, FreeBSD ELF64, execve), rip = 0x80090622c, rsp = > > 0x7fffffffe058, rbp = 0xffffffff --- db> > > I've got this panic twice more since. Do you have a kernel.debug? Can you do 'list *exec_copyout_strings+0x12f'? I think I've seen reports of the linux32_exec_copyout_strings() having a similar fault as well on amd64. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 19:20: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 0E21616A41C for ; Fri, 17 Jun 2005 19:20:45 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from mv.twc.weather.com (mv.twc.weather.com [65.212.71.225]) by mx1.FreeBSD.org (Postfix) with ESMTP id B8D6243D48 for ; Fri, 17 Jun 2005 19:20:44 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: from [10.50.41.231] (Not Verified[216.133.140.1]) by mv.twc.weather.com with NetIQ MailMarshal (v6, 0, 3, 8) id ; Fri, 17 Jun 2005 15:34:10 -0400 From: John Baldwin To: freebsd-current@freebsd.org Date: Fri, 17 Jun 2005 14:50:42 -0400 User-Agent: KMail/1.8 References: <20050516113420.GA786@schweikhardt.net> <20050526205831.GA958@schweikhardt.net> <20050608190147.GA917@schweikhardt.net> In-Reply-To: <20050608190147.GA917@schweikhardt.net> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200506171450.44146.jhb@FreeBSD.org> Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Cc: Jens Schweikhardt 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: Fri, 17 Jun 2005 19:20:45 -0000 On Wednesday 08 June 2005 03:01 pm, Jens Schweikhardt wrote: > On Thu, May 26, 2005 at 10:58:31PM +0200, Jens Schweikhardt wrote: > # 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. > > Any chance this gets backed out, or worked around, e.g. with a > sysctl, device hint, or some other knob? Is this the patch you are running with? >Index: clock.c =================================================================== RCS file: /usr/cvs/src/sys/i386/isa/clock.c,v retrieving revision 1.220 diff -u -r1.220 clock.c --- clock.c 14 May 2005 09:10:01 -0000 1.220 +++ clock.c 27 May 2005 19:42:54 -0000 @@ -784,7 +784,7 @@ * clocks, setup the interrupt handler for the 8254 timer 0 so * that it can drive hardclock(). */ - if (!using_lapic_timer) { + if (!using_lapic_timer || 1) { intr_add_handler("clk", 0, (driver_intr_t *)clkintr, NULL, INTR_TYPE_CLK | INTR_FAST, NULL); i8254_intsrc = intr_lookup_source(0); Also, can you get the output of 'sysctl kern.clockrate' for both cases? -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 19:22: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 3A21616A41C for ; Fri, 17 Jun 2005 19:22:09 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: from imladris.teardrop.org (imladris.teardrop.org [66.92.66.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id DE60343D49 for ; Fri, 17 Jun 2005 19:22:06 +0000 (GMT) (envelope-from snow+freebsd-current@teardrop.org) Received: by imladris.teardrop.org (Postfix, from userid 100) id 4F739BF6FB; Fri, 17 Jun 2005 15:23:05 -0400 (EDT) Date: Fri, 17 Jun 2005 15:23:05 -0400 From: James Snow To: Sam Leffler Message-ID: <20050617192305.GA9955@teardrop.org> References: <20050616191450.GA98695@teardrop.org> <42B1D9D9.7040604@errno.com> <20050616200450.GB98695@teardrop.org> <42B1DD17.3000601@errno.com> <20050616204044.GC98695@teardrop.org> <42B1E97B.5070408@errno.com> <20050616210447.GD98695@teardrop.org> <20050616220327.GE98695@teardrop.org> <42B21790.4060301@errno.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42B21790.4060301@errno.com> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, James Snow Subject: Re: WPA Supplicant doesn't see my SSIDs? 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, 17 Jun 2005 19:22:09 -0000 On Thu, Jun 16, 2005 at 05:21:36PM -0700, Sam Leffler wrote: > > Sounds like you're using TKIP and the ap detects MIC errors in the > frames you are sending. When this happens it is required to enable > countermeasures that include dropping traffic for a period of time. This is exactly what it turned out to be on the AP side. Seems like a dubious feature to me. > Check if your station negotiated WME; there have been problems with > using h/w TKIP together with WME that require doing the MIC calculations > in s/w. The crypto support in current doesn't have all these changes. Apparently I did have WME enabled. I could have sworn I tried it both ways but, well, as you know I sometimes don't drink enough coffee. At any rate, I'm now typing this over our WPA network. Yay! Will send you some information about the hidden SSID off-list. Thanks again for your help. -Snow From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 19:23: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 8A9B016A41C for ; Fri, 17 Jun 2005 19:23: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 31A3843D5C for ; Fri, 17 Jun 2005 19:23: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.4/8.13.4) with ESMTP id j5HJNWDW015435; Fri, 17 Jun 2005 12:23:32 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5HJNW9b015434; Fri, 17 Jun 2005 12:23:32 -0700 (PDT) (envelope-from obrien) Date: Fri, 17 Jun 2005 12:23:32 -0700 From: "David O'Brien" To: Chuck Swiger Message-ID: <20050617192332.GE13006@dragon.NUXI.org> Mail-Followup-To: freebsd-current@freebsd.org, Chuck Swiger References: <20050615054209.L29741@beagle.kn.op.dlr.de> <20050615160741.GA55062@dragon.NUXI.org> <88862BDF-ED45-42CE-9B24-DEEED2E66C2C@mac.com> <20050615.212337.108191340.imp@bsdimp.com> <42B10804.2010308@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42B10804.2010308@mac.com> 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 Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: 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: Fri, 17 Jun 2005 19:23:33 -0000 On Thu, Jun 16, 2005 at 01:03:00AM -0400, Chuck Swiger wrote: > Perhaps there won't be a rush of code adoption from OpenSolaris into > FreeBSD, but it would be a surprise and a pity if there was nothing to be > learned. I'd imagine that the Solaris NFS code would be worth looking at, > for instance. > > Lots of license flavors are handled OK via src/contrib and throughout the > entire ports collection now. It's not as if CDDL-licensed code is going to > sneak up and infect existing BSD-licensed code; the two licenses are > miscible. ... > Well, there's no shortage of wacky opinions about people running > proprietary code on top of GPLed systems. For example, Eben Moglen and > Bruce Perens would like to sue ATI and nVidia for releasing proprietary > drivers for Linux. [1] So? Do we want FreeBSD to be in the middle of the courts again? 1994 was enough for me. We want free, do anything you damned well please code. Unless there is a *compelling reason*. > 4-sec% /usr/bin/nroff --version > GNU nroff (groff) version 1.19 > 5-sec% uname -a > FreeBSD sec.pkix.net 4.11-STABLE FreeBSD 4.11-STABLE #0: Sat Jun 11 > 00:25:38 EDT 2005 root@sec.pkix.net:/usr/obj/usr/src/sys/NORMAL i386 > > This seems to be from src/contrib/groff? Yes. But the issue is, why trade one piece of non-BSDL licensed code for another non-BSDL licensed piece of code?? What does changing from Groff to Solaris Troff actually buy us?? Groff is the standard in Roff. Even people writing books on systems with a native Troff install Groff to get a more powerful and easier to use Roff. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 19:30: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 8419316A41C for ; Fri, 17 Jun 2005 19:30:41 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: from mail.gmx.net (mail.gmx.de [213.165.64.20]) by mx1.FreeBSD.org (Postfix) with SMTP id CDC8B43D48 for ; Fri, 17 Jun 2005 19:30:40 +0000 (GMT) (envelope-from Emanuel.strobl@gmx.net) Received: (qmail invoked by alias); 17 Jun 2005 19:30:38 -0000 Received: from flb.schmalzbauer.de (EHLO cale.flintsbach.schmalzbauer.de) [62.245.232.135] by mail.gmx.net (mp019) with SMTP; 17 Jun 2005 21:30:38 +0200 X-Authenticated: #301138 From: Emanuel Strobl To: freebsd-current@freebsd.org Date: Fri, 17 Jun 2005 21:30:27 +0200 User-Agent: KMail/1.8 References: <20050615054209.L29741@beagle.kn.op.dlr.de> <42B10804.2010308@mac.com> <20050617192332.GE13006@dragon.NUXI.org> In-Reply-To: <20050617192332.GE13006@dragon.NUXI.org> X-Birthday: Oct. 6th 1972 X-CelPhone: +49 (0) 173 9967781 X-Tel: +49 (0) 89 18947781 X-Country: Germany X-Address: Munich, 80686 X-OS: FreeBSD MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2627598.EnFgRolohD"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506172130.36586@harrymail> X-Y-GMX-Trusted: 0 Subject: Re: groff alternative? 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, 17 Jun 2005 19:30:41 -0000 --nextPart2627598.EnFgRolohD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Am Freitag, 17. Juni 2005 21:23 schrieb David O'Brien: [...] > > This seems to be from src/contrib/groff? > > Yes. But the issue is, why trade one piece of non-BSDL licensed code > for another non-BSDL licensed piece of code?? What does changing from > Groff to Solaris Troff actually buy us?? Groff is the standard in Roff. Groff depends on c++ and is far to big for embedded systems. In fact its=20 bigger than the complete man pages for the OS. (~10MB). That's why I initially posted my question and Lyndon made the OpenSolaris=20 suggestion. I'd like to have a simple possibility to view unformated man=20 pages with reasonable sized tools. Preformatting man pages is not an=20 option for me since packages install unformatted man pages and I don't=20 know a suitable way to change that. =2DHarry=20 > Even people writing books on systems with a native Troff install Groff > to get a more powerful and easier to use Roff. --nextPart2627598.EnFgRolohD Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCsyTcBylq0S4AzzwRAig8AKCRS1Z9iYRwesL7rk8qqAzF762tugCgkJnJ xQ+n2XNNmZ8UNUHud8I1WXk= =u+ka -----END PGP SIGNATURE----- --nextPart2627598.EnFgRolohD-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 19:33: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 AD23616A41C; Fri, 17 Jun 2005 19:33:25 +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 798FD43D53; Fri, 17 Jun 2005 19:33:25 +0000 (GMT) (envelope-from obrien@NUXI.com) Received: from dragon.NUXI.org (obrien@localhost [127.0.0.1]) by dragon.NUXI.org (8.13.4/8.13.4) with ESMTP id j5HJXI8c015723; Fri, 17 Jun 2005 12:33:18 -0700 (PDT) (envelope-from obrien@dragon.NUXI.org) Received: (from obrien@localhost) by dragon.NUXI.org (8.13.4/8.13.1/Submit) id j5HJXH4s015722; Fri, 17 Jun 2005 12:33:17 -0700 (PDT) (envelope-from obrien) Date: Fri, 17 Jun 2005 12:33:17 -0700 From: "David O'Brien" To: Robert Watson Message-ID: <20050617193317.GA15570@dragon.NUXI.org> Mail-Followup-To: obrien@freebsd.org, Robert Watson , Eric Anderson , alc@freebsd.org, freebsd-current@freebsd.org References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> <20050616181820.E27625@fledge.watson.org> <42B1B784.8010405@videotron.ca> <20050616184127.L27625@fledge.watson.org> <20050617110902.C56734@fledge.watson.org> <42B2B4C0.1030504@centtech.com> <20050617123954.W56734@fledge.watson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050617123954.W56734@fledge.watson.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: alc@FreeBSD.org, freebsd-current@FreeBSD.org, Eric Anderson Subject: Re: Reboot while booting with new per-CPU allocator 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: Fri, 17 Jun 2005 19:33:25 -0000 On Fri, Jun 17, 2005 at 12:40:50PM +0100, Robert Watson wrote: > On Fri, 17 Jun 2005, Eric Anderson wrote: > >>Interestingly, there's been a bunch of reports of this in the past few > >>days, and there weren't immediately after the malloc commit. I wonder if > >>some other recent change has increased the amount of UMA memory allocated > >>early in the boot, increasing the level of reports... > > > > Increase UMA_BOOT_PAGES to prevent a crash during initialization. See > > http://docs.FreeBSD.org/cgi/mid.cgi?42AD8270.8060906 for a detailed > > description of the crash. > > Yeah, this is the fix, but I guess I'm wondering what caused a recent > spate of problem reports -- was it a delayed response to the malloc change > as people gradually upgraded, or some other recent kernel change that > caused increase demand for memory. The sys/dev/atkbdc commit is what pushed me over the limit, not the malloc changes. I am loading 15 modules. -- -- David (obrien@FreeBSD.org) From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 19:49: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 C87B416A420 for ; Fri, 17 Jun 2005 19:49:40 +0000 (GMT) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8413243D48 for ; Fri, 17 Jun 2005 19:49:40 +0000 (GMT) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id j5HJndI4011301 for ; Fri, 17 Jun 2005 15:49:39 -0400 (EDT) Received: (from dickey@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id j5HJndAR011300 for freebsd-current@freebsd.org; Fri, 17 Jun 2005 15:49:39 -0400 (EDT) Date: Fri, 17 Jun 2005 15:49:38 -0400 From: Thomas Dickey To: freebsd-current@freebsd.org Message-ID: <20050617194938.GA10194@saltmine.radix.net> References: <20050615054209.L29741@beagle.kn.op.dlr.de> <20050615160741.GA55062@dragon.NUXI.org> <88862BDF-ED45-42CE-9B24-DEEED2E66C2C@mac.com> <20050615.212337.108191340.imp@bsdimp.com> <42B10804.2010308@mac.com> <20050617192332.GE13006@dragon.NUXI.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="azLHFNyN32YCQGCU" Content-Disposition: inline In-Reply-To: <20050617192332.GE13006@dragon.NUXI.org> User-Agent: Mutt/1.3.27i Subject: Re: groff alternative? 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, 17 Jun 2005 19:49:40 -0000 --azLHFNyN32YCQGCU Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 17, 2005 at 12:23:32PM -0700, David O'Brien wrote: >=20 > Yes. But the issue is, why trade one piece of non-BSDL licensed code for > another non-BSDL licensed piece of code?? What does changing from Groff > to Solaris Troff actually buy us?? Groff is the standard in Roff. Even > people writing books on systems with a native Troff install Groff to get > a more powerful and easier to use Roff. Solaris Troff is less capable (it won't handle ncurses' terminfo manpage). Sun doesn't _use_ troff. They went to SGML years ago. Troff on Solaris is a dead program. --=20 Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --azLHFNyN32YCQGCU Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQFCsylQtIqByHxlDocRAvvhAJ9MkeA2WpGiYyT2nKX4qBFbz+/d5ACfRDk4 Fq3cBAhnEXhDW/cL2MwqX5A= =sjps -----END PGP SIGNATURE----- --azLHFNyN32YCQGCU-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 20:39: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 6721016A41C for ; Fri, 17 Jun 2005 20:39:13 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 174AB43D49 for ; Fri, 17 Jun 2005 20:39:13 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 7E9BD5F92 for ; Fri, 17 Jun 2005 16:39:12 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78457-03 for ; Fri, 17 Jun 2005 16:39:11 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-66-3.ny325.east.verizon.net [68.161.66.3]) by pi.codefab.com (Postfix) with ESMTP id 1CDCA5E00 for ; Fri, 17 Jun 2005 16:39:10 -0400 (EDT) Message-ID: <42B3356B.8040804@mac.com> Date: Fri, 17 Jun 2005 16:41:15 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20050615054209.L29741@beagle.kn.op.dlr.de> <20050615160741.GA55062@dragon.NUXI.org> <88862BDF-ED45-42CE-9B24-DEEED2E66C2C@mac.com> <20050615.212337.108191340.imp@bsdimp.com> <42B10804.2010308@mac.com> <20050617192332.GE13006@dragon.NUXI.org> In-Reply-To: <20050617192332.GE13006@dragon.NUXI.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Subject: Re: groff alternative? 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, 17 Jun 2005 20:39:13 -0000 David O'Brien wrote: > On Thu, Jun 16, 2005 at 01:03:00AM -0400, Chuck Swiger wrote: >> Perhaps there won't be a rush of code adoption from OpenSolaris into >> FreeBSD, but it would be a surprise and a pity if there was nothing to be >> learned. I'd imagine that the Solaris NFS code would be worth looking at, >> for instance. >> >> Lots of license flavors are handled OK via src/contrib and throughout the >> entire ports collection now. It's not as if CDDL-licensed code is going to >> sneak up and infect existing BSD-licensed code; the two licenses are >> miscible. > > So? Do we want FreeBSD to be in the middle of the courts again? 1994 > was enough for me. We want free, do anything you damned well please > code. Unless there is a *compelling reason*. Sure. There is a perfectly reasonable preference for BSD-licensed code, and I guess I support efforts like Tim's to come up with a "completely free" version of libarchive and tar. On the other hand, I am not convinced that solving the same old problems under a different software license is really the most effective way to move forwards, either. You should know that being involved in a lawsuit generally has nothing to do with the actual merits of the situation, it takes nothing more than one party being unreasonable and looking for anything they can think of to make claims. For someone in the EU-- or Australia, or a lot of places, apparently-- that could be something as simple as the "DISCLAIMER" section of the BSD license, since those jurisdictions do not permit liability to be completely disclaimed. [ I'd rather not worry about it, myself, until a problem actually happens. ] >>4-sec% /usr/bin/nroff --version >>GNU nroff (groff) version 1.19 >>5-sec% uname -a >>FreeBSD sec.pkix.net 4.11-STABLE FreeBSD 4.11-STABLE #0: Sat Jun 11 >>00:25:38 EDT 2005 root@sec.pkix.net:/usr/obj/usr/src/sys/NORMAL i386 >> >>This seems to be from src/contrib/groff? > > Yes. But the issue is, why trade one piece of non-BSDL licensed code for > another non-BSDL licensed piece of code?? What does changing from Groff > to Solaris Troff actually buy us?? Groff is the standard in Roff. Even > people writing books on systems with a native Troff install Groff to get > a more powerful and easier to use Roff. Frankly, I no longer remember the specific problem that someone thought Solaris troff might help with, it's earlier in the thread. It would be wrong to state that I suggested changing the existing roff from groff. It would also be wrong to suggest that FreeBSD is using a BSD-licensed roff when /usr/bin/nroff is groff. If I wanted to make a suggestion with regard to this matter-- and I'm not sure I do, since some people seem to want to argue rather than help others-- it might be that if Solaris troff solves a problem for someone, maybe somebody ought to make that into a port. -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 21:05: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 ECCE416A41C for ; Fri, 17 Jun 2005 21:05:27 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 691CC43D4C for ; Fri, 17 Jun 2005 21:05:27 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j5HL5Nou010594; Fri, 17 Jun 2005 23:05:23 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j5HL5NPi010593; Fri, 17 Jun 2005 17:05:23 -0400 (EDT) (envelope-from cracauer) Date: Fri, 17 Jun 2005 17:05:23 -0400 From: Martin Cracauer To: Warner Losh Message-ID: <20050617170523.A10560@cons.org> References: <20050617114607.A3198@cons.org> <20050617.110847.74692199.imp@bsdimp.com> <20050617131508.A5421@cons.org> <20050617.112203.112567050.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050617.112203.112567050.imp@bsdimp.com>; from imp@bsdimp.com on Fri, Jun 17, 2005 at 11:22:03AM -0600 Cc: cracauer@cons.org, freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 21:05:28 -0000 Warner Losh wrote on Fri, Jun 17, 2005 at 11:22:03AM -0600: > From: Martin Cracauer > Subject: Re: 6.0-current panic: loading radeon module > Date: Fri, 17 Jun 2005 13:15:08 -0400 > > > Warner Losh wrote on Fri, Jun 17, 2005 at 11:08:47AM -0600: > > > From: Martin Cracauer > > > Subject: Re: 6.0-current panic: loading radeon module > > > Date: Fri, 17 Jun 2005 11:46:07 -0400 > > > > > > > M. Warner Losh wrote on Thu, Jun 16, 2005 at 09:05:29PM -0600: > > > > > In message: <20050616182421.A87199@cons.org> > > > > > Martin Cracauer writes: > > > > > : Loading the radeon module segfaults the kernel, 6.0-current of > > > > > : yesterday. > > > > > : > > > > > : I have a Thinkpad with Radeon mobility 7500. 5-stable works on the > > > > > : same hardware. > > > > > : > > > > > : ddb trace shows: > > > > > : > > > > > : bus_generic_activate_resource+0x64 > > > > > : bus_generic_activate_resource+0x64 > > > > > : bus_generic_activate_resource+0x64 > > > > > : pci_alloc_resource+0x226 > > > > > : pci_alloc_resource+0x7x > > > > > : drm_get_resource_len+0x2f > > > > > : radeon_preinit+0xa2 > > > > > : drm_attach+0x2d > > > > > : > > > > > : Not sure what is involved to use gdb at this time. Can I do serial > > > > > : gdb with a 6.0-current AMD64 machine running the display? Can I use a > > > > > : 5.x box? > > > > > : > > > > > : It is 100% reproducable so I can gather more info as needed. > > > > > > > > > > Is this a module you compiled, or a module that's vendor supplied? > > > > > > > > It is the FreeBSD module built with the kernel. I used the same > > > > procedure as with 5-stable where it worked fine (as in 3D graphics > > > > actually work, not just it didn't panic). > > > > > > OK. There were some changes to the number of pages we reserve for uma > > > allocation of malloc types. Can you try those? > > > > Yes, the box is ready for scratch testing. (Famous last words :-) > > > > Where do I find the changes? > > It was committed yesterday, I believe. I also tried bumping UMA_BOOT_PAGES to 256 (was bumped to 48 yesterday). No change in that panic. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 21:12: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 1DB3E16A41C; Fri, 17 Jun 2005 21:12:40 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout06.sul.t-online.com (mailout06.sul.t-online.com [194.25.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id C5BFF43D1F; Fri, 17 Jun 2005 21:12:39 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd26.aul.t-online.de by mailout06.sul.t-online.com with smtp id 1DjO8j-00088w-00; Fri, 17 Jun 2005 23:12:37 +0200 Received: from Andro-Beta.Leidinger.net (Tz5hYOZU8e3ONHl0swjbMWyvVwSR6Gx-xkfkWWqPGaox2MQkZTxV6u@[84.165.239.20]) by fwd26.sul.t-online.de with esmtp id 1DjO8f-0whfKy0; Fri, 17 Jun 2005 23:12:33 +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 j5HLCOwY005723; Fri, 17 Jun 2005 23:12:25 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Fri, 17 Jun 2005 23:13:00 +0200 From: Alexander Leidinger To: Robert Watson Message-ID: <20050617231300.4096db78@Magellan.Leidinger.net> In-Reply-To: <20050617110050.O56734@fledge.watson.org> References: <42B18536.3080200@videotron.ca> <20050616151502.X27625@fledge.watson.org> <42B192D2.7000505@videotron.ca> <20050616181820.E27625@fledge.watson.org> <42B1B784.8010405@videotron.ca> <20050616184127.L27625@fledge.watson.org> <20050617113729.i78gx3wiokw48g8k@netchild.homeip.net> <20050617110050.O56734@fledge.watson.org> X-Mailer: Sylpheed-Claws 1.9.11 (GTK+ 2.6.7; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: Tz5hYOZU8e3ONHl0swjbMWyvVwSR6Gx-xkfkWWqPGaox2MQkZTxV6u@t-dialin.net X-TOI-MSGID: f9bfc3a6-6313-4208-a062-4809608920d9 Cc: alc@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: Reboot while booting with new per-CPU allocator 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, 17 Jun 2005 21:12:40 -0000 On Fri, 17 Jun 2005 11:02:43 +0100 (BST) Robert Watson wrote: > > I try to load as much as possible as modules. Can you quantify "large > > number of modules"? I could load some more modules for testing purposes > > at the weekend. > > Well, it looked like 30 was enough to exceed the 40 page UMA threshold, > but it's now been bumped to 48 in HEAD. However, what actually matters is > malloc types, not modules, so I think two routes would be productive: to > add a debugging printf to UMA to show how much of the boot page space is > used at the time it transitions to non-boot pages, and to try creating a > module that creates various numbers of malloc types. % grep _load= /boot/loader.conf | grep -v '^#' | wc -l 51 I try to get some time tomorrow to update from a Jun 11 kernel to a recent -current. It will at least serve as a datapoint. Bye, Alexander. -- The computer revolution is over. The computers won. 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 Fri Jun 17 21:14: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 5CED116A41C for ; Fri, 17 Jun 2005 21:14:01 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0175D43D4C for ; Fri, 17 Jun 2005 21:14:00 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 5EA7E5E16; Fri, 17 Jun 2005 17:14:00 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 78642-01; Fri, 17 Jun 2005 17:13:58 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-66-3.ny325.east.verizon.net [68.161.66.3]) by pi.codefab.com (Postfix) with ESMTP id 128CB5C44; Fri, 17 Jun 2005 17:13:57 -0400 (EDT) Message-ID: <42B33D92.1080109@mac.com> Date: Fri, 17 Jun 2005 17:16:02 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Allen References: <20050617205415.GT18614@philemon.caltech.edu> In-Reply-To: <20050617205415.GT18614@philemon.caltech.edu> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: freebsd-current@freebsd.org Subject: Re: groff alternative? 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, 17 Jun 2005 21:14:01 -0000 Paul Allen wrote: > On Fri, 17 Jun 2005, Chuck Swiger wrote: >> You should know that being involved in a lawsuit generally has nothing to do >> with the actual merits of the situation, it takes nothing more than one party >> being unreasonable and looking for anything they can think of to make claims. >> For someone in the EU-- or Australia, or a lot of places, apparently-- that >> could be something as simple as the "DISCLAIMER" section of the BSD license, >> since those jurisdictions do not permit liability to be completely disclaimed. > > I beg your pardon? I highly doubt that there is a jurisdiction on the > planet that supports the principle of one-sided contracts. The BSD license isn't a contract, Paul: it's not phrased as one and it doesn't have what the legal types call a "proffer". > The DISCLAIMER gains its power precisely because you did not pay for the > work being disclaimed and you voluntarily made use of that work. This is > distinguished say from the necessity of good-samaratian laws which apply > when people give aid without compensation to individuals who are not in a > state in which they may consent. Yeah, yeah, I know. I don't even disagree, but I've got news for you: the law doesn't always make sense. > Please provide case citations with such speculation in the future. A good > engineer knows that many things can go wrong, but he worries only about those > things he feels are likely. Go read HIPPA or European contract law (cf German "Cecil" section 315, apparently). I'm not qualified to give legal advice; go pay for an attourney. But here are two comments from people who are: From: "Lawrence Rosen" To: "'Donnal Walter'" , Subject: RE: open source medical software Message-ID: <20050127143025.GA15353@mail26c.sbc-webhosting.com> [ ... ] Software distributors must obey the law regardless of what an open source license says. So if you must obtain FDA approval before you can distribute certain software intended for patient care, the license doesn't override that requirement. You may be required by law to perform certain tests or peer review before distributing the software; a mere license won't let you avoid that. However, the open source license you use cannot *require* licensees to obtain FDA approval or get peer review. The only thing you can do is remind licensees of *their* duty to obey the law as they understand the law. This is similar to the issue of export regulations. As a distributor of software in the United States, you are required by law to obey US export regulations. But you can't impose that requirement on your customers who live and work in other countries. It is up to them to obey the law as they understand that law. So OSI has never accepted a license that expressly requires licensees to obey specific US export law. Your open source license cannot impose specific restrictions on how to copy, modify or redistribute the work, or restrict such activities to certain professionals. As for whether you must include a warranty, that too is often a subject of legal regulation. A disclaimer of warranty or limitation of liability in an open source license may not be enforceable in some jurisdictions and for some forms of injury. In these cases, you and your customers should probably consult an attorney specializing in the requirements of the FDA and other government agencies. --------------- From: "Axel Metzger" To: Subject: AW: For Approval: German Free Software License Message-ID: <84D511A814FAF742BF6927D883CF67C177BECC@mpg-hap-info.mpipriv-hh.mpg.de> Hi Chuck, thanks for your comments. I will try to address your critical remarks. Chuck Swiger wrote: [ ... ] >>>Distribution: The public passing on of material copies to third >>>parties, in particular, onto storage devices or in connection with >>>hardware. > > One is also redistributing the software if you pass the software on in > private, say to your relative or to another member of your company. > > I believe your intent is to enable people to change the software for their > private use without making their changes public, but require the source > code to be made available when public redistribution, so it would be helpful > to clarify these terms a bit. Here once again, we followed the wording of German and European Copyright law. Do you have a realistic idea how many problems of interpretation European lawyers have with the US-based licenses? This is one of the major reasons why the Ministry wanted to have a more "European" license. >>>Section 7 Liability and Warranty >>>(1) The Entitled Persons are only liable for conflicting third-party >>>rights if they were aware of such rights without informing you. >>> >>>(2) Liability for errors and/or other defects in the Program shall >>>be governed by agreements concluded between you and the Entitled >>>Person beyond the scope of this License or, if no such agreement >>>exists, by the pertinent statutory provisions. > > If I modify a program covered by the GFSL, and I want to redistribute my > version without any warranty (ie, the standard DISCLAIMER found in the BSD > and other licenses which disclaims liability since the software is being made > available free of charge), may I do so? No, under German and European contract law it is impossible to exclude any warranty and liability. The consequences are not to severe - as long as you redistribute the program without charging a fee. Under the German Cicil Code you are only liable if you knew that the program has defects etc. > Can a project like FreeBSD, NetBSD, etc, or a Linux distro like Debian, > Redhat, etc, adopt GFSL code without conflict with their existing > disclaimers? The disclaimers are invalid under German and European contract law. Sorry, they are legally inexistent in Europe. [ ... ] -- -Chuck From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 21:19: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 75D1316A41C for ; Fri, 17 Jun 2005 21:19:51 +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 573C643D4C for ; Fri, 17 Jun 2005 21:19:51 +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.4/8.13.4) with ESMTP id j5HLJpiq041758 for ; Fri, 17 Jun 2005 14:19:51 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j5HLJo3a041757 for freebsd-current@freebsd.org; Fri, 17 Jun 2005 14:19:50 -0700 (PDT) (envelope-from sgk) Date: Fri, 17 Jun 2005 14:19:50 -0700 From: Steve Kargl To: freebsd-current@freebsd.org Message-ID: <20050617211950.GA41720@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Subject: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 17 Jun 2005 21:19:51 -0000 I have taken mined(1) from DragonFlyBSD and integrated into the FreeBSD source tree. This is a very lightweight full screen editor with builtin support for cons25 and xterm. Yes, it is limited in its capabilites compared with /rescue/vi, but saves use 360 kB of diskspace and it does not require a termcap file. In replacing /rescue/vi, I have installed /bin/mined, /rescue/mined, and /rescue/edit (as an alias to mined). The installation into /bin/mined is due to my limited understanding of the rescue/Makefile structure. If someone wants to eliminate /bin/mined, it's fine with me. Yes, I'm aware of PR bin/80256, but that appears to stalled in a state of limbo. I have a diff to src/bin and src/rescue if anyone is interested. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 21:26: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 B37E816A41C for ; Fri, 17 Jun 2005 21:26:35 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6A19943D55 for ; Fri, 17 Jun 2005 21:26:35 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5HLPObx066609; Fri, 17 Jun 2005 15:25:24 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 17 Jun 2005 15:25:24 -0600 (MDT) Message-Id: <20050617.152524.71154336.imp@bsdimp.com> To: cracauer@cons.org From: Warner Losh In-Reply-To: <20050617170523.A10560@cons.org> References: <20050617131508.A5421@cons.org> <20050617.112203.112567050.imp@bsdimp.com> <20050617170523.A10560@cons.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 21:26:35 -0000 > I also tried bumping UMA_BOOT_PAGES to 256 (was bumped to 48 > yesterday). No change in that panic. OK. looks like a plain ordinary bug. Any chance you can get line numbers and arguments for us to look at? Warner From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 21:30: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 2CB0516A41C for ; Fri, 17 Jun 2005 21:30:12 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id B86E043D1D for ; Fri, 17 Jun 2005 21:30:11 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j5HLU9FP011301; Fri, 17 Jun 2005 23:30:09 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j5HLU9H8011300; Fri, 17 Jun 2005 17:30:09 -0400 (EDT) (envelope-from cracauer) Date: Fri, 17 Jun 2005 17:30:08 -0400 From: Martin Cracauer To: Warner Losh Message-ID: <20050617173008.A11142@cons.org> References: <20050617131508.A5421@cons.org> <20050617.112203.112567050.imp@bsdimp.com> <20050617170523.A10560@cons.org> <20050617.152524.71154336.imp@bsdimp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050617.152524.71154336.imp@bsdimp.com>; from imp@bsdimp.com on Fri, Jun 17, 2005 at 03:25:24PM -0600 Cc: cracauer@cons.org, freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 21:30:12 -0000 Warner Losh wrote on Fri, Jun 17, 2005 at 03:25:24PM -0600: > > I also tried bumping UMA_BOOT_PAGES to 256 (was bumped to 48 > > yesterday). No change in that panic. > > OK. looks like a plain ordinary bug. Any chance you can get line > numbers and arguments for us to look at? The machine doesn't have a serial port. While I have a USB->serial adapter I don't think that works with kgdb. Any other way? Can I dump a corefile and get a backtrace out of that one? I have a similar card for AGP that I could slam into some temporary computer. If the panic happens with AMD64 I could get it quickly, but otherwise I won't make it this weekend as I have no i386 installation on a desktop harddrive. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 21:36: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 CDFCA16A41C for ; Fri, 17 Jun 2005 21:36:40 +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 9033C43D4C for ; Fri, 17 Jun 2005 21:36:40 +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 A421C1EC308 for ; Fri, 17 Jun 2005 23:36:39 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.4/8.13.3) with ESMTP id j5HLaWw6058719; Fri, 17 Jun 2005 23:36:35 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Steve Kargl From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 17 Jun 2005 14:19:50 PDT." <20050617211950.GA41720@troutmask.apl.washington.edu> Date: Fri, 17 Jun 2005 23:36:32 +0200 Message-ID: <58718.1119044192@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 17 Jun 2005 21:36:40 -0000 In message <20050617211950.GA41720@troutmask.apl.washington.edu>, Steve Kargl w rites: >I have taken mined(1) from DragonFlyBSD and integrated into the >FreeBSD source tree. man 1 ee -- 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 Fri Jun 17 21:39:25 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 59DC816A41C; Fri, 17 Jun 2005 21:39:25 +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 1B6A843D4C; Fri, 17 Jun 2005 21:39:25 +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 3B8321EC31E; Fri, 17 Jun 2005 23:39:24 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.4/8.13.3) with ESMTP id j5HLdLEu058748; Fri, 17 Jun 2005 23:39:21 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Peter Edwards From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 17 Jun 2005 18:02:32 -0000." <20050617180232.GA25818@freefall.freebsd.org> Date: Fri, 17 Jun 2005 23:39:21 +0200 Message-ID: <58747.1119044361@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: current@FreeBSD.org Subject: Re: Towards a working "wine". [long] 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, 17 Jun 2005 21:39:25 -0000 In message <20050617180232.GA25818@freefall.freebsd.org>, Peter Edwards writes: >There is a disasterously ugly hack attached, wine_malloc.txt that >hacks on malloc(), and adds a "W" option to enable the hack. This >works by trading the brk()/sbrk() calls for an mmapping starting >at 0xa0000000, which should be able to grow towards the process >stack. (phkmalloc works with a large contiguous heap, rather than >a fragmented one, so a more "pure" mmap-based approach won't fit >into it too smoothly.) phkmalloc works just fine with a fragmented heap, but allocates too much memory for the page-map if all the memory is too far away from "_end". The correct (and portable) fix is to give phkmalloc a treee-structure instead of a linear array to manage the page table. -- 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 Fri Jun 17 21:46: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 A782016A41C for ; Fri, 17 Jun 2005 21:46:59 +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 874BB43D1D for ; Fri, 17 Jun 2005 21:46:59 +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.4/8.13.4) with ESMTP id j5HLkxkC042063; Fri, 17 Jun 2005 14:46:59 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j5HLkw54042062; Fri, 17 Jun 2005 14:46:58 -0700 (PDT) (envelope-from sgk) Date: Fri, 17 Jun 2005 14:46:58 -0700 From: Steve Kargl To: Poul-Henning Kamp Message-ID: <20050617214658.GA41804@troutmask.apl.washington.edu> References: <20050617211950.GA41720@troutmask.apl.washington.edu> <58718.1119044192@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58718.1119044192@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 17 Jun 2005 21:46:59 -0000 On Fri, Jun 17, 2005 at 11:36:32PM +0200, Poul-Henning Kamp wrote: > In message <20050617211950.GA41720@troutmask.apl.washington.edu>, Steve Kargl w > rites: > >I have taken mined(1) from DragonFlyBSD and integrated into the > >FreeBSD source tree. > > man 1 ee > troutmask:kargl[203] ldd /usr/bin/ee /usr/bin/ee: libncurses.so.5 => /lib/libncurses.so.5 (0x20063a000) libc.so.6 => /lib/libc.so.6 (0x200795000) troutmask:kargl[204] find /usr/src/rescue -name Make\* | xargs grep ncurses -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 21:49: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 2762716A41F for ; Fri, 17 Jun 2005 21:49:17 +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 DCBF743D53 for ; Fri, 17 Jun 2005 21:49:16 +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 0A0301EC316 for ; Fri, 17 Jun 2005 23:49:15 +0200 (CEST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.13.4/8.13.3) with ESMTP id j5HLnBAW058827; Fri, 17 Jun 2005 23:49:12 +0200 (CEST) (envelope-from phk@critter.freebsd.dk) To: Steve Kargl From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 17 Jun 2005 14:46:58 PDT." <20050617214658.GA41804@troutmask.apl.washington.edu> Date: Fri, 17 Jun 2005 23:49:11 +0200 Message-ID: <58826.1119044951@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: freebsd-current@freebsd.org Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 17 Jun 2005 21:49:17 -0000 In message <20050617214658.GA41804@troutmask.apl.washington.edu>, Steve Kargl w rites: >On Fri, Jun 17, 2005 at 11:36:32PM +0200, Poul-Henning Kamp wrote: >> In message <20050617211950.GA41720@troutmask.apl.washington.edu>, Steve Kargl w >> rites: >> >I have taken mined(1) from DragonFlyBSD and integrated into the >> >FreeBSD source tree. >> >> man 1 ee >> > >troutmask:kargl[203] ldd /usr/bin/ee >/usr/bin/ee: > libncurses.so.5 => /lib/libncurses.so.5 (0x20063a000) > libc.so.6 => /lib/libc.so.6 (0x200795000) >troutmask:kargl[204] find /usr/src/rescue -name Make\* | xargs grep ncurses yes, and ? If you want a non-curses editor it's called ed(1). If you want a static curses editor, compile ee(1) -static. -- 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 Fri Jun 17 22:02: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 D2D9316A41C for ; Fri, 17 Jun 2005 22:02:22 +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 B16FF43D1F for ; Fri, 17 Jun 2005 22:02:22 +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.4/8.13.4) with ESMTP id j5HM2Mqs048535; Fri, 17 Jun 2005 15:02:22 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j5HM2M67048534; Fri, 17 Jun 2005 15:02:22 -0700 (PDT) (envelope-from sgk) Date: Fri, 17 Jun 2005 15:02:22 -0700 From: Steve Kargl To: Poul-Henning Kamp Message-ID: <20050617220222.GA42080@troutmask.apl.washington.edu> References: <20050617214658.GA41804@troutmask.apl.washington.edu> <58826.1119044951@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58826.1119044951@critter.freebsd.dk> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 17 Jun 2005 22:02:22 -0000 On Fri, Jun 17, 2005 at 11:49:11PM +0200, Poul-Henning Kamp wrote: > In message <20050617214658.GA41804@troutmask.apl.washington.edu>, Steve Kargl w > rites: > >On Fri, Jun 17, 2005 at 11:36:32PM +0200, Poul-Henning Kamp wrote: > >> In message <20050617211950.GA41720@troutmask.apl.washington.edu>, Steve Kargl w > >> rites: > >> >I have taken mined(1) from DragonFlyBSD and integrated into the > >> >FreeBSD source tree. > >> > >> man 1 ee > >> > > > >troutmask:kargl[203] ldd /usr/bin/ee > >/usr/bin/ee: > > libncurses.so.5 => /lib/libncurses.so.5 (0x20063a000) > > libc.so.6 => /lib/libc.so.6 (0x200795000) > >troutmask:kargl[204] find /usr/src/rescue -name Make\* | xargs grep ncurses > > yes, and ? > > If you want a non-curses editor it's called ed(1). We're trying to help our user base recover from a disaster. I suspect ed(1) is not well-known through out the FreeBSD user base. mined(1) is a full-screen editor, which of course allows one to see what she is editing. mined(1) also has on-line help for all possible key-binding actions in a 1 page listing. > If you want a static curses editor, compile ee(1) -static. Well, this will help me, but how exactly does it help our user base. Currently, /rescue/vi is useless if a termcap file is not available (as in /usr is hosed). -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 22:06: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 AB6D416A41C for ; Fri, 17 Jun 2005 22:06:54 +0000 (GMT) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 692B743D55 for ; Fri, 17 Jun 2005 22:06:54 +0000 (GMT) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id j5HM6rI4001761 for ; Fri, 17 Jun 2005 18:06:53 -0400 (EDT) Received: (from dickey@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id j5HM6rJ4001760 for freebsd-current@freebsd.org; Fri, 17 Jun 2005 18:06:53 -0400 (EDT) Date: Fri, 17 Jun 2005 18:06:53 -0400 From: Thomas Dickey To: freebsd-current@freebsd.org Message-ID: <20050617220653.GA114@saltmine.radix.net> References: <20050617214658.GA41804@troutmask.apl.washington.edu> <58826.1119044951@critter.freebsd.dk> <20050617220222.GA42080@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <20050617220222.GA42080@troutmask.apl.washington.edu> User-Agent: Mutt/1.3.27i Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 17 Jun 2005 22:06:54 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 17, 2005 at 03:02:22PM -0700, Steve Kargl wrote: >=20 > Well, this will help me, but how exactly does it help our > user base. Currently, /rescue/vi is useless if a termcap > file is not available (as in /usr is hosed). This topic comes up about every 3 months. ncurses can be compiled to have embedded terminal descriptions. That's one choice. Another is to have a small termcap file. That's another choice. Of course another choice is to change the editor (though stating that it has support for cons25 and xterm sounds suspicious, since they do differ). --=20 Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQFCs0l7tIqByHxlDocRAmQeAJ9xYUQOLptiYWXVx0NGZEd4SZtKDwCfQsAO OEbSJRb7wZY9S2iYwYQtKrk= =Kh/y -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 22:13: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 8CA8616A41C for ; Fri, 17 Jun 2005 22:13:53 +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 6B00043D53 for ; Fri, 17 Jun 2005 22:13:53 +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.4/8.13.4) with ESMTP id j5HMDrbG050266; Fri, 17 Jun 2005 15:13:53 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j5HMDr3M050265; Fri, 17 Jun 2005 15:13:53 -0700 (PDT) (envelope-from sgk) Date: Fri, 17 Jun 2005 15:13:53 -0700 From: Steve Kargl To: Thomas Dickey Message-ID: <20050617221353.GA48584@troutmask.apl.washington.edu> References: <20050617214658.GA41804@troutmask.apl.washington.edu> <58826.1119044951@critter.freebsd.dk> <20050617220222.GA42080@troutmask.apl.washington.edu> <20050617220653.GA114@saltmine.radix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050617220653.GA114@saltmine.radix.net> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 17 Jun 2005 22:13:53 -0000 On Fri, Jun 17, 2005 at 06:06:53PM -0400, Thomas Dickey wrote: > On Fri, Jun 17, 2005 at 03:02:22PM -0700, Steve Kargl wrote: > > > > Well, this will help me, but how exactly does it help our > > user base. Currently, /rescue/vi is useless if a termcap > > file is not available (as in /usr is hosed). > > This topic comes up about every 3 months. ncurses can be compiled to have > embedded terminal descriptions. That's one choice. Another is to have a > small termcap file. That's another choice. Of course another choice is > to change the editor (though stating that it has support for cons25 and > xterm sounds suspicious, since they do differ). > I've already stated that I'm aware of the PR that has a minimalist termcap, which needs to be installed somewhere that /rescue/vi can find it. -r-xr-xr-x 129 root wheel 3669272 Jun 17 15:09 /rescue/ee* -r-xr-xr-x 1 root wheel 3564216 Jun 17 14:50 /rescue/mined* -r-xr-xr-x 2 root wheel 3940176 Jun 16 15:56 /rescue/vi* This is an editor meant for recovering a system. It's not a full blown kitchen sink. It can be used in an xterm and it can be used from the console. -- Steve From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 22:41: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 9FCF416A41F for ; Fri, 17 Jun 2005 22:41:09 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3809B43D48 for ; Fri, 17 Jun 2005 22:41:09 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j5HMf5WO013026; Sat, 18 Jun 2005 00:41:05 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j5HMf5UI013025; Fri, 17 Jun 2005 18:41:05 -0400 (EDT) (envelope-from cracauer) Date: Fri, 17 Jun 2005 18:41:05 -0400 From: Martin Cracauer To: Warner Losh Message-ID: <20050617184104.A12956@cons.org> References: <20050617131508.A5421@cons.org> <20050617.112203.112567050.imp@bsdimp.com> <20050617170523.A10560@cons.org> <20050617.152524.71154336.imp@bsdimp.com> <20050617173008.A11142@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050617173008.A11142@cons.org>; from cracauer@cons.org on Fri, Jun 17, 2005 at 05:30:08PM -0400 Cc: cracauer@cons.org, freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 22:41:09 -0000 I wrote: > Any other way? Can I dump a corefile and get a backtrace out of that > one? Please don't bother replying, I am just suffering from postlinuxal amnesis. I know how to do this. Only problem is I nuked the kernel with the symbols, I thought a copy is in /boot/kernel/. So I have to rebuild. Martin -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 23:08:01 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 D57D716A41C; Fri, 17 Jun 2005 23:08:01 +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 8D3BD43D1F; Fri, 17 Jun 2005 23:08:01 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B379451259; Fri, 17 Jun 2005 19:08:00 -0400 (EDT) Date: Fri, 17 Jun 2005 19:08:00 -0400 From: Kris Kennaway To: John Baldwin Message-ID: <20050617230800.GA72019@xor.obsecurity.org> References: <20050510223636.GA49927@xor.obsecurity.org> <20050529175056.GA99318@xor.obsecurity.org> <200506171434.49008.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <200506171434.49008.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: amd64@freebsd.org, freebsd-current@freebsd.org, current@freebsd.org, Kris Kennaway Subject: Re: Fatal trap 12 in exec_copyout_strings() 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, 17 Jun 2005 23:08:02 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 17, 2005 at 02:34:47PM -0400, John Baldwin wrote: > On Sunday 29 May 2005 01:50 pm, Kris Kennaway wrote: > > On Tue, May 10, 2005 at 03:36:36PM -0700, Kris Kennaway wrote: > > > Got this on a dual amd64 with 8GB RAM running 6.0 from last week: > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid =3D 1; apic id =3D 01 > > > fault virtual address =3D 0xffffffffa9cdc000 > > > fault code =3D supervisor read, page not present > > > instruction pointer =3D 0x8:0xffffffff8037759f > > > stack pointer =3D 0x10:0xffffffffba1637d0 > > > frame pointer =3D 0x10:0xffffffffba163820 > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > > current process =3D 52247 (sh) > > > [thread pid 52247 tid 100149 ] > > > Stopped at exec_copyout_strings+0x12f: > > > db> wh > > > Tracing pid 52247 tid 100149 td 0xffffff016e5724c0 > > > exec_copyout_strings() at exec_copyout_strings+0x12f > > > do_execve() at do_execve+0x39a > > > kern_execve() at kern_execve+0xab > > > execve() at execve+0x49 > > > syscall() at syscall+0x382 > > > Xfast_syscall() at Xfast_syscall+0xa8 > > > --- syscall (59, FreeBSD ELF64, execve), rip =3D 0x80090622c, rsp =3D > > > 0x7fffffffe058, rbp =3D 0xffffffff --- db> > > > > I've got this panic twice more since. >=20 > Do you have a kernel.debug? Can you do 'list *exec_copyout_strings+0x12f= '? I=20 > think I've seen reports of the linux32_exec_copyout_strings() having a=20 > similar fault as well on amd64. If (when) it happens again I'll do this (unfortunately I can't dump on this machine, though). Thanks for the response. Kris --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCs1fQWry0BWjoQKURAvZtAJ4uI7edNhqHxiLhSVNGmWW3R1/mQwCfcLYJ kfKV8J73pOcy7oIXm0SHd1M= =XMEj -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 23:08: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 D57D716A41C; Fri, 17 Jun 2005 23:08:01 +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 8D3BD43D1F; Fri, 17 Jun 2005 23:08:01 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id B379451259; Fri, 17 Jun 2005 19:08:00 -0400 (EDT) Date: Fri, 17 Jun 2005 19:08:00 -0400 From: Kris Kennaway To: John Baldwin Message-ID: <20050617230800.GA72019@xor.obsecurity.org> References: <20050510223636.GA49927@xor.obsecurity.org> <20050529175056.GA99318@xor.obsecurity.org> <200506171434.49008.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <200506171434.49008.jhb@FreeBSD.org> User-Agent: Mutt/1.4.2.1i Cc: amd64@freebsd.org, freebsd-current@freebsd.org, current@freebsd.org, Kris Kennaway Subject: Re: Fatal trap 12 in exec_copyout_strings() 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, 17 Jun 2005 23:08:02 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 17, 2005 at 02:34:47PM -0400, John Baldwin wrote: > On Sunday 29 May 2005 01:50 pm, Kris Kennaway wrote: > > On Tue, May 10, 2005 at 03:36:36PM -0700, Kris Kennaway wrote: > > > Got this on a dual amd64 with 8GB RAM running 6.0 from last week: > > > > > > Fatal trap 12: page fault while in kernel mode > > > cpuid =3D 1; apic id =3D 01 > > > fault virtual address =3D 0xffffffffa9cdc000 > > > fault code =3D supervisor read, page not present > > > instruction pointer =3D 0x8:0xffffffff8037759f > > > stack pointer =3D 0x10:0xffffffffba1637d0 > > > frame pointer =3D 0x10:0xffffffffba163820 > > > code segment =3D base 0x0, limit 0xfffff, type 0x1b > > > =3D DPL 0, pres 1, long 1, def32 0, gran 1 > > > processor eflags =3D interrupt enabled, resume, IOPL =3D 0 > > > current process =3D 52247 (sh) > > > [thread pid 52247 tid 100149 ] > > > Stopped at exec_copyout_strings+0x12f: > > > db> wh > > > Tracing pid 52247 tid 100149 td 0xffffff016e5724c0 > > > exec_copyout_strings() at exec_copyout_strings+0x12f > > > do_execve() at do_execve+0x39a > > > kern_execve() at kern_execve+0xab > > > execve() at execve+0x49 > > > syscall() at syscall+0x382 > > > Xfast_syscall() at Xfast_syscall+0xa8 > > > --- syscall (59, FreeBSD ELF64, execve), rip =3D 0x80090622c, rsp =3D > > > 0x7fffffffe058, rbp =3D 0xffffffff --- db> > > > > I've got this panic twice more since. >=20 > Do you have a kernel.debug? Can you do 'list *exec_copyout_strings+0x12f= '? I=20 > think I've seen reports of the linux32_exec_copyout_strings() having a=20 > similar fault as well on amd64. If (when) it happens again I'll do this (unfortunately I can't dump on this machine, though). Thanks for the response. Kris --cNdxnHkX5QqsyA0e Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCs1fQWry0BWjoQKURAvZtAJ4uI7edNhqHxiLhSVNGmWW3R1/mQwCfcLYJ kfKV8J73pOcy7oIXm0SHd1M= =XMEj -----END PGP SIGNATURE----- --cNdxnHkX5QqsyA0e-- From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 23:13: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 8127516A41C for ; Fri, 17 Jun 2005 23:13:53 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2DC6043D4C for ; Fri, 17 Jun 2005 23:13:53 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so569044nzp for ; Fri, 17 Jun 2005 16:13:52 -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=lwfzyhQ4S1UHdUT360LwXb56BvanD5e8r8I0oQcvgB3K6o+GxFXlD700glpkLZ5Je7AvZ5CXIMNjzgsJp8mR5VjG0xabaRRzW+wt1GRBymNMMug3HmqywGuB/32Hco3af5BtIQNbOjT5cnoBuXF13bjASf6AwVeoudP6QR+tv/8= Received: by 10.36.23.9 with SMTP id 9mr1758299nzw; Fri, 17 Jun 2005 16:13:52 -0700 (PDT) Received: by 10.36.68.15 with HTTP; Fri, 17 Jun 2005 16:13:52 -0700 (PDT) Message-ID: <34cb7c8405061716139488699@mail.gmail.com> Date: Sat, 18 Jun 2005 00:13:52 +0100 From: Peter Edwards To: Poul-Henning Kamp In-Reply-To: <58747.1119044361@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050617180232.GA25818@freefall.freebsd.org> <58747.1119044361@critter.freebsd.dk> Cc: Peter Edwards , current@freebsd.org Subject: Re: Towards a working "wine". [long] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Edwards List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 23:13:53 -0000 On 6/17/05, Poul-Henning Kamp wrote: > phkmalloc works just fine with a fragmented heap, but allocates too > much memory for the page-map if all the memory is too far away > from "_end". >=20 > The correct (and portable) fix is to give phkmalloc a treee-structure > instead of a linear array to manage the page table. >=20 Sorry, I didn't mean to imply that it was just never going to work, just the structure of the mapping from addresses to the page table: the god-awful hack was the quickest way to test that things would work better in wine. I'll get some decent patches done RSN, but I'd imagine there'll be a minor amount of overhead involved. (eg, ptr2index would never be as simple as it is now) The change would also affect the behaviour of applications in terms of how MAXDSIZ impacted them (it'd be pretty much meaningless for a non-brk-based malloc, but that's not neccessarily a bad thing) From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 23:32: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 E283616A41C for ; Fri, 17 Jun 2005 23:32:51 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.195]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8BB2E43D55 for ; Fri, 17 Jun 2005 23:32:51 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so572431nzp for ; Fri, 17 Jun 2005 16:32:51 -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=mEWIGFElWA1IBXtmwFqJAD12hb/Tgcg6SOmAbot/WLqGnLj7pQu4u5POLGOYpIJpPtS/nF2bU0xytmLIufd9byC/0EbnJFLiyqG3IgMaT7AD7altJvuOnmrn1PJZZgUV6WsEF3wnyUr4TZeQpDTldvh4Gx9hrFhWwIe4/gVlynU= Received: by 10.36.61.12 with SMTP id j12mr1715189nza; Fri, 17 Jun 2005 16:32:51 -0700 (PDT) Received: by 10.36.68.15 with HTTP; Fri, 17 Jun 2005 16:32:51 -0700 (PDT) Message-ID: <34cb7c8405061716327ca4c6d7@mail.gmail.com> Date: Sat, 18 Jun 2005 00:32:51 +0100 From: Peter Edwards To: Maxim.Sobolev@portaone.com In-Reply-To: <42B3189E.6030408@portaone.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050617180232.GA25818@freefall.freebsd.org> <42B31247.9010603@portaone.com> <34cb7c840506171121cd0437f@mail.gmail.com> <42B3189E.6030408@portaone.com> Cc: Peter Edwards , current@freebsd.org Subject: Re: Towards a working "wine". [long] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Edwards List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 23:32:52 -0000 > >>... wine can call mmap(2) with MAP_FIXED and then if that fails try to > >>call mmap(2) without it and deal with consequences. This will provide > >>the same functionality but you won't get dependency on particular > >>FreeBSD version to get MAP_TRYFIXED define. > >> > > > > > > Nope: MAP_FIXED will unconditionally overwrite any existing mapping at > > the requested address. >=20 > Hmm, the manpage doesn't mention anything of the effect. It only says: >=20 > MAP_FIXED Do not permit the system to select a different address > than the one specified. If the specified address can- > not be used, mmap() will fail. If MAP_FIXED is speci- > fied, addr must be a multiple of the pagesize. Use of > this option is discouraged. >=20 > Nothing about "overwriting any existing mapping". So that maybe > implementation should be adjusted to match documentation, not another > functionality be invented to workaround misbehaving implementation? Well, It's definitely behaved that way "traditionally" (where traditionally means on any platform I've had to use mmap() on), and the manpage is less than specific about what "cannot be used" means. SUSv3 has this to say: > If a MAP_FIXED request is successful, the mapping established by mmap()= =20 > replaces any previous mappings for the process' pages in the range=20 > [pa,pa+len). Again, it's very hazy, but it at least explicitly mentions that MAP_FIXED may replace previous mappings. Really, MAP_TRYFIXED is just a hack to avoid the trouble the kernel goes to in an effort to avoid mmap() and sbrk() from stomping on eachother. It doesn't matter in Linux because sbrk() has much less effect on things. (It's not a sytem call) I'd imagine it better to add an explicit flag for this corner case than to change the behaviour of existing applications. Apps using MAP_FIXED already are likely to be quite sensitive to such a change. From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 23:46: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 0F32016A41C for ; Fri, 17 Jun 2005 23:46:49 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper.zs64.net [212.12.50.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3BA0D43D5F for ; Fri, 17 Jun 2005 23:46:48 +0000 (GMT) (envelope-from cracauer@schlepper.zs64.net) Received: from schlepper.zs64.net (schlepper [212.12.50.230]) by schlepper.zs64.net (8.13.1/8.12.9) with ESMTP id j5HNkhZt014154; Sat, 18 Jun 2005 01:46:43 +0200 (CEST) (envelope-from cracauer@schlepper.zs64.net) Received: (from cracauer@localhost) by schlepper.zs64.net (8.13.1/8.12.9/Submit) id j5HNkd3X014142; Fri, 17 Jun 2005 19:46:39 -0400 (EDT) (envelope-from cracauer) Date: Fri, 17 Jun 2005 19:46:39 -0400 From: Martin Cracauer To: Warner Losh Message-ID: <20050617194638.A13394@cons.org> References: <20050617131508.A5421@cons.org> <20050617.112203.112567050.imp@bsdimp.com> <20050617170523.A10560@cons.org> <20050617.152524.71154336.imp@bsdimp.com> <20050617173008.A11142@cons.org> <20050617184104.A12956@cons.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20050617184104.A12956@cons.org>; from cracauer@cons.org on Fri, Jun 17, 2005 at 06:41:05PM -0400 Cc: cracauer@cons.org, freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module 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, 17 Jun 2005 23:46:49 -0000 Hmmmmm, this doesn't look quite right. I am probably missing the debug info from within the radeon module. But since I don't have the base address for the module I'm not sure how to add its symbols when debugging the vmcore. Let me know how useful this is. Martin (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc052db30 in boot (howto=260) at ../../../kern/kern_shutdown.c:397 #2 0xc052ddf4 in panic (fmt=0xc06caa94 "from debugger") at ../../../kern/kern_shutdown.c:553 #3 0xc0450711 in db_panic (addr=-1066780860, have_addr=0, count=-1, modif=0xf5a3d770 "") at ../../../ddb/db_command.c:435 #4 0xc04506a8 in db_command (last_cmdp=0xc0737444, cmd_table=0x0, aux_cmd_tablep=0xc06fcdf4, aux_cmd_tablep_end=0xc06fcdf8) at ../../../ddb/db_command.c:349 #5 0xc0450770 in db_command_loop () at ../../../ddb/db_command.c:455 #6 0xc0452305 in db_trap (type=12, code=0) at ../../../ddb/db_main.c:221 #7 0xc05462df in kdb_trap (type=12, code=0, tf=0xf5a3d904) at ../../../kern/subr_kdb.c:471 #8 0xc06a5bcb in trap_fatal (frame=0xf5a3d904, eva=3221094400) at ../../../i386/i386/trap.c:826 #9 0xc06a593f in trap_pfault (frame=0xf5a3d904, usermode=0, eva=3221094400) at ../../../i386/i386/trap.c:749 #10 0xc06a5561 in trap (frame= {tf_fs = -1067122680, tf_es = -1056702424, tf_ds = 40, tf_edi = 256, tf_esi = -533393408, tf_ebp = -173811368, tf_isp = -173811408, tf_ebx = 130740224, tf_edx = 1015808, tf_ecx = -134217728, tf_eax = -533393149, tf_trapno = 12, tf_err = 2, tf_eip = -1066780860, tf_cs = 32, tf_eflags = 590470, tf_esp = 0, tf_ss = -137695232}) at ../../../i386/i386/trap.c:439 ---Type to continue, or q to quit--- #11 0xc069538a in calltrap () at ../../../i386/i386/exception.s:139 #12 0xc0650008 in ufs_setattr (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:564 #13 0xc069fe39 in nexus_activate_resource (bus=0xc2703d00, child=0xc2821000, type=3, rid=16, r=0xc281dd80) at ../../../i386/i386/nexus.c:419 #14 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, type=3, rid=16, r=0xc281dd80) at bus_if.h:290 #15 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, type=3, rid=16, r=0xc281dd80) at bus_if.h:290 #16 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, type=3, rid=16, r=0xc281dd80) at bus_if.h:290 #17 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, type=3, rid=16, r=0xc281dd80) at bus_if.h:290 #18 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, type=3, rid=16, r=0xc281dd80) at bus_if.h:290 #19 0xc04addaa in pci_alloc_resource (dev=0xc2821080, child=0xc2821000, type=3, rid=0xf5a3db2c, start=0, end=4294967295, count=1, flags=6) at ../../../dev/pci/pci.c:1753 #20 0xc0543a88 in bus_alloc_resource (dev=0x0, type=3, rid=0xf5a3db2c, start=0, end=4294967295, count=1, flags=6) at bus_if.h:262 #21 0xc2b9a273 in ?? () #22 0xc2821000 in ?? () #23 0x00000003 in ?? () #24 0xf5a3db2c in ?? () ---Type to continue, or q to quit--- #25 0x00000000 in ?? () #26 0xffffffff in ?? () #27 0x00000001 in ?? () #28 0x00000006 in ?? () #29 0xc2b0a000 in ?? () #30 0xc2b09000 in ?? () #31 0xc2b0a000 in ?? () #32 0xf5a3db48 in ?? () #33 0xc2b85386 in ?? () #34 0xc2b0a000 in ?? () #35 0x00000010 in ?? () #36 0x00000000 in ?? () #37 0x00000000 in ?? () #38 0x00000010 in ?? () #39 0xc2b0a000 in ?? () #40 0xc2821080 in ?? () #41 0xc2821000 in ?? () #42 0xf5a3db7c in ?? () #43 0xc2b9d3fd in ?? () #44 0xc2b0a000 in ?? () #45 0x00000000 in ?? () #46 0xc2b0a0e8 in ?? () #47 0x00000000 in ?? () ---Type to continue, or q to quit--- #48 0x00000000 in ?? () #49 0x00000000 in ?? () #50 0x00000001 in ?? () #51 0x0000000b in ?? () #52 0xc2b0a000 in ?? () #53 0xc2821000 in ?? () #54 0x00000000 in ?? () #55 0xf5a3db94 in ?? () #56 0xc2b8555d in ?? () #57 0xc2821000 in ?? () #58 0xc2b93200 in ?? () #59 0xc2821000 in ?? () #60 0xc2821000 in ?? () #61 0xf5a3dba8 in ?? () #62 0xc054292c in device_attach (dev=0xc2b0a000) at device_if.h:177 (kgdb) -- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Martin Cracauer http://www.cons.org/cracauer/ No warranty. This email is probably produced by one of my cats stepping on the keys. No, I don't have an infinite number of cats. From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 00:33: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 4568316A41C for ; Sat, 18 Jun 2005 00:33:40 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03C7843D58 for ; Sat, 18 Jun 2005 00:33:39 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from localhost (unknown [192.168.99.10]) by mail.yazzy.org (Postfix) with SMTP id C145439864; Sat, 18 Jun 2005 02:34:10 +0200 (CEST) Date: Sat, 18 Jun 2005 02:33:35 +0200 From: Marcin Jessa To: Steve Kargl Message-Id: <20050618023335.0f7d9b45.lists@yazzy.org> In-Reply-To: <20050617211950.GA41720@troutmask.apl.washington.edu> References: <20050617211950.GA41720@troutmask.apl.washington.edu> Organization: YazzY.org X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 18 Jun 2005 00:33:40 -0000 On Fri, 17 Jun 2005 14:19:50 -0700 Steve Kargl wrote: > I have taken mined(1) from DragonFlyBSD and integrated into the > FreeBSD source tree. This is a very lightweight full screen > editor with builtin support for cons25 and xterm. Yes, it is > limited in its capabilites compared with /rescue/vi, but saves > use 360 kB of diskspace and it does not require a termcap file. Great, this will make a good alternative for embedded systems. From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 00:51: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 7E44316A41C for ; Sat, 18 Jun 2005 00:51:19 +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 4431E43D1D for ; Sat, 18 Jun 2005 00:51:19 +0000 (GMT) (envelope-from kris@obsecurity.org) Received: by obsecurity.dyndns.org (Postfix, from userid 1000) id 5EB6E51282; Fri, 17 Jun 2005 20:51:18 -0400 (EDT) Date: Fri, 17 Jun 2005 20:51:18 -0400 From: Kris Kennaway To: current@FreeBSD.org Message-ID: <20050618005118.GA97030@xor.obsecurity.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i Cc: jroberson@chesapeake.net Subject: "panic: mutex Giant not owned" in do_execve() 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, 18 Jun 2005 00:51:19 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline quad e450 running up-to-date -current: panic: mutex Giant not owned at ../../../kern/kern_mutex.c:299 cpuid = 0 KDB: enter: panic [thread pid 52851 tid 100456 ] Stopped at kdb_enter+0x3c: ta %xcc, 1 db> wh Tracing pid 52851 tid 100456 td 0xfffff80077c61560 panic() at panic+0x16c _mtx_assert() at _mtx_assert+0x6c _mtx_unlock_flags() at _mtx_unlock_flags+0x68 do_execve() at do_execve+0xa0c kern_execve() at kern_execve+0x7c execve() at execve+0x38 syscall() at syscall+0x2d4 -- reserved %o7=0 -- userland() at 0x40223400 user trace: trap %o7=0 pc 0x40223400, sp 0x7fdffffd021 done #12 0x00000000c01525cc in do_execve (td=0xfffff80077c61560, args=0xc, mac_p=0x0) at ../../../kern/kern_exec.c:789 #13 0x00000000c0151b3c in kern_execve (td=0xfffff80077c61560, args=0xeea6f670, mac_p=0x0) at ../../../kern/kern_exec.c:250 #14 0x00000000c0151a78 in execve (td=0xfffff80077c61560, uap=0xeea6f8c0) at ../../../kern/kern_exec.c:185 #15 0x00000000c02f3cd4 in syscall (tf=0xeea6f880) at ../../../sparc64/sparc64/trap.c:592 (kgdb) frame 12 #12 0x00000000c01525cc in do_execve (td=0xfffff80077c61560, args=0xc, mac_p=0x0) at ../../../kern/kern_exec.c:789 789 VFS_UNLOCK_GIANT(vfslocked); (kgdb) list 784 #ifdef MAC 785 mac_execve_exit(imgp); 786 if (interplabel != NULL) 787 mac_vnode_label_free(interplabel); 788 #endif 789 VFS_UNLOCK_GIANT(vfslocked); 790 return (error); 791 } 792 793 int (kgdb) frame 13 #13 0x00000000c0151b3c in kern_execve (td=0xfffff80077c61560, args=0xeea6f670, mac_p=0x0) at ../../../kern/kern_exec.c:250 250 error = do_execve(td, args, mac_p); (kgdb) list 245 return (ERESTART); /* Try again later. */ 246 } 247 PROC_UNLOCK(p); 248 } 249 250 error = do_execve(td, args, mac_p); 251 252 if (p->p_flag & P_HADTHREADS) { 253 PROC_LOCK(p); 254 /* (kgdb) frame 14 #14 0x00000000c0151a78 in execve (td=0xfffff80077c61560, uap=0xeea6f8c0) at ../../../kern/kern_exec.c:185 185 error = kern_execve(td, &args, NULL); Kris --GvXjxJ+pjyke8COw Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQFCs3AGWry0BWjoQKURAslPAKCb+BwKL6UTTjvJeXcTqEC+wxTq7ACeOV5O 2aAsc9lYjbKG6piRBk8OqaE= =jHQH -----END PGP SIGNATURE----- --GvXjxJ+pjyke8COw-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 00:59:38 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 DE9B216A41C; Sat, 18 Jun 2005 00:59:38 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: from regurgitate.ugcs.caltech.edu (regurgitate.ugcs.caltech.edu [131.215.176.97]) by mx1.FreeBSD.org (Postfix) with ESMTP id B402C43D1F; Sat, 18 Jun 2005 00:59:38 +0000 (GMT) (envelope-from jd@ugcs.caltech.edu) Received: by regurgitate.ugcs.caltech.edu (Postfix, from userid 3640) id 392F3E816; Fri, 17 Jun 2005 17:59:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by regurgitate.ugcs.caltech.edu (Postfix) with ESMTP id 23694E815; Fri, 17 Jun 2005 17:59:38 -0700 (PDT) Date: Fri, 17 Jun 2005 17:59:38 -0700 (PDT) From: Jon Dama To: Peter Edwards In-Reply-To: <34cb7c8405061716327ca4c6d7@mail.gmail.com> Message-ID: References: <20050617180232.GA25818@freefall.freebsd.org> <42B31247.9010603@portaone.com> <34cb7c840506171121cd0437f@mail.gmail.com> <42B3189E.6030408@portaone.com> <34cb7c8405061716327ca4c6d7@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Peter Edwards , Maxim.Sobolev@portaone.com, current@freebsd.org Subject: Re: Towards a working "wine". [long] 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, 18 Jun 2005 00:59:39 -0000 My intuition says that mmap should ignore requests to map into the existing brk region but not reject requests that are merely between the existing brk region and the DS limit. Is this what happens now? -Jon On Sat, 18 Jun 2005, Peter Edwards wrote: > > >>... wine can call mmap(2) with MAP_FIXED and then if that fails try to > > >>call mmap(2) without it and deal with consequences. This will provide > > >>the same functionality but you won't get dependency on particular > > >>FreeBSD version to get MAP_TRYFIXED define. > > >> > > > > > > > > > Nope: MAP_FIXED will unconditionally overwrite any existing mapping at > > > the requested address. > > > > Hmm, the manpage doesn't mention anything of the effect. It only says: > > > > MAP_FIXED Do not permit the system to select a different address > > than the one specified. If the specified address can- > > not be used, mmap() will fail. If MAP_FIXED is speci- > > fied, addr must be a multiple of the pagesize. Use of > > this option is discouraged. > > > > Nothing about "overwriting any existing mapping". So that maybe > > implementation should be adjusted to match documentation, not another > > functionality be invented to workaround misbehaving implementation? > > Well, It's definitely behaved that way "traditionally" (where > traditionally means on any platform I've had to use mmap() on), and > the manpage is less than specific about what "cannot be used" means. > SUSv3 has this to say: > > > If a MAP_FIXED request is successful, the mapping established by mmap() > > replaces any previous mappings for the process' pages in the range > > [pa,pa+len). > > Again, it's very hazy, but it at least explicitly mentions that > MAP_FIXED may replace previous mappings. > > Really, MAP_TRYFIXED is just a hack to avoid the trouble the kernel > goes to in an effort to avoid mmap() and sbrk() from stomping on > eachother. It doesn't matter in Linux because sbrk() has much less > effect on things. (It's not a sytem call) I'd imagine it better to add > an explicit flag for this corner case than to change the behaviour of > existing applications. Apps using MAP_FIXED already are likely to be > quite sensitive to such a change. > _______________________________________________ > 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 Sat Jun 18 01:24: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 32DD716A41C for ; Sat, 18 Jun 2005 01:24:34 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (69-30-77-85.dq1sn.easystreet.com [69.30.77.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id D850843D48 for ; Sat, 18 Jun 2005 01:24:32 +0000 (GMT) (envelope-from eta@lclark.edu) Received: from leguin.anholt.net (localhost [127.0.0.1]) by leguin.anholt.net (8.13.4/8.13.1) with ESMTP id j5I1Ns1n096241; Fri, 17 Jun 2005 18:23:54 -0700 (PDT) (envelope-from eta@lclark.edu) Received: (from anholt@localhost) by leguin.anholt.net (8.13.4/8.13.1/Submit) id j5I1NlNk096240; Fri, 17 Jun 2005 18:23:47 -0700 (PDT) (envelope-from eta@lclark.edu) X-Authentication-Warning: leguin.anholt.net: anholt set sender to eta@lclark.edu using -f From: Eric Anholt To: Martin Cracauer In-Reply-To: <20050617194638.A13394@cons.org> References: <20050617131508.A5421@cons.org> <20050617.112203.112567050.imp@bsdimp.com> <20050617170523.A10560@cons.org> <20050617.152524.71154336.imp@bsdimp.com> <20050617173008.A11142@cons.org> <20050617184104.A12956@cons.org> <20050617194638.A13394@cons.org> Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Fri, 17 Jun 2005 18:23:47 -0700 Message-Id: <1119057827.16634.1.camel@leguin> Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 FreeBSD GNOME Team Port Cc: freebsd-current@freebsd.org, Warner Losh Subject: Re: 6.0-current panic: loading radeon module 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, 18 Jun 2005 01:24:34 -0000 On Fri, 2005-06-17 at 19:46 -0400, Martin Cracauer wrote: > Hmmmmm, this doesn't look quite right. I am probably missing the > debug info from within the radeon module. But since I don't have the > base address for the module I'm not sure how to add its symbols when > debugging the vmcore. > > Let me know how useful this is. > > Martin > > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc052db30 in boot (howto=260) at ../../../kern/kern_shutdown.c:397 > #2 0xc052ddf4 in panic (fmt=0xc06caa94 "from debugger") > at ../../../kern/kern_shutdown.c:553 > #3 0xc0450711 in db_panic (addr=-1066780860, have_addr=0, count=-1, > modif=0xf5a3d770 "") at ../../../ddb/db_command.c:435 > #4 0xc04506a8 in db_command (last_cmdp=0xc0737444, cmd_table=0x0, > aux_cmd_tablep=0xc06fcdf4, aux_cmd_tablep_end=0xc06fcdf8) > at ../../../ddb/db_command.c:349 > #5 0xc0450770 in db_command_loop () at ../../../ddb/db_command.c:455 > #6 0xc0452305 in db_trap (type=12, code=0) at ../../../ddb/db_main.c:221 > #7 0xc05462df in kdb_trap (type=12, code=0, tf=0xf5a3d904) > at ../../../kern/subr_kdb.c:471 > #8 0xc06a5bcb in trap_fatal (frame=0xf5a3d904, eva=3221094400) > at ../../../i386/i386/trap.c:826 > #9 0xc06a593f in trap_pfault (frame=0xf5a3d904, usermode=0, eva=3221094400) > at ../../../i386/i386/trap.c:749 > #10 0xc06a5561 in trap (frame= > {tf_fs = -1067122680, tf_es = -1056702424, tf_ds = 40, tf_edi = 256, tf_esi = -533393408, tf_ebp = -173811368, tf_isp = -173811408, tf_ebx = 130740224, tf_edx = 1015808, tf_ecx = -134217728, tf_eax = -533393149, tf_trapno = 12, tf_err = 2, tf_eip = -1066780860, tf_cs = 32, tf_eflags = 590470, tf_esp = 0, tf_ss = -137695232}) at ../../../i386/i386/trap.c:439 > ---Type to continue, or q to quit--- > #11 0xc069538a in calltrap () at ../../../i386/i386/exception.s:139 > #12 0xc0650008 in ufs_setattr (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:564 > #13 0xc069fe39 in nexus_activate_resource (bus=0xc2703d00, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at ../../../i386/i386/nexus.c:419 > #14 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #15 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #16 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #17 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #18 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #19 0xc04addaa in pci_alloc_resource (dev=0xc2821080, child=0xc2821000, > type=3, rid=0xf5a3db2c, start=0, end=4294967295, count=1, flags=6) > at ../../../dev/pci/pci.c:1753 > #20 0xc0543a88 in bus_alloc_resource (dev=0x0, type=3, rid=0xf5a3db2c, > start=0, end=4294967295, count=1, flags=6) at bus_if.h:262 > #21 0xc2b9a273 in ?? () Assuming that those ??s are in the radeon module, this is a new backtrace to me. There's been one happening to some people where pmap_mapdev fails to allocate enough memory, which results in a panic, but I haven't been able to reproduce it here. My systems are working just fine on fresh -current :( -- Eric Anholt eta@lclark.edu http://people.freebsd.org/~anholt/ anholt@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 01:39: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 E1EF616A41C for ; Sat, 18 Jun 2005 01:39:03 +0000 (GMT) (envelope-from raj@cserv62.csub.edu) Received: from cserv62.csub.edu (cserv62.csub.edu [136.168.10.62]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3237E43D49 for ; Sat, 18 Jun 2005 01:39:03 +0000 (GMT) (envelope-from raj@cserv62.csub.edu) Received: from localhost. (adsl-66-126-39-251.dsl.anhm01.pacbell.net [66.126.39.251]) by cserv62.csub.edu (8.13.3/8.13.1) with ESMTP id j5I1Z3ji078191 for ; Fri, 17 Jun 2005 18:35:04 -0700 (PDT) (envelope-from raj@cserv62.csub.edu) Received: (from raj@localhost) by localhost. (8.13.3/8.13.3/Submit) id j5I1d26u000951 for freebsd-current@freebsd.org; Fri, 17 Jun 2005 18:39:02 -0700 (PDT) (envelope-from raj) Date: Fri, 17 Jun 2005 18:39:02 -0700 From: Russell Jackson To: freebsd-current@freebsd.org Message-ID: <20050618013902.GA756@localhost.homelan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i Subject: nvidia-driver and bus_memio.h 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, 18 Jun 2005 01:39:05 -0000 The removal of bus_memio.h broke the nvidia driver. -- Russell A. Jackson Rudin's Law: If there is a wrong way to do something, most people will do it every time. Rudin's Second Law: In a crisis that forces a choice to be made among alternative courses of action, people tend to choose the worst possible course. From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 03:01: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 3DA7816A41F for ; Sat, 18 Jun 2005 03:01:15 +0000 (GMT) (envelope-from ups@tree.com) Received: from smtp.speedfactory.net (talon.speedfactory.net [66.23.216.215]) by mx1.FreeBSD.org (Postfix) with ESMTP id E094D43D55 for ; Sat, 18 Jun 2005 03:01:14 +0000 (GMT) (envelope-from ups@tree.com) Received: (qmail 396 invoked from network); 18 Jun 2005 03:01:16 +0000 Received: from 66-23-216-49.clients.speedfactory.net (HELO palm.tree.com) (66.23.216.49) by smtp.speedfactory.net with AES256-SHA encrypted SMTP; 18 Jun 2005 03:01:16 +0000 Received: from [127.0.0.1] (ups@localhost.tree.com [127.0.0.1]) by palm.tree.com (8.12.10/8.12.10) with ESMTP id j5I31CpP044610; Fri, 17 Jun 2005 23:01:13 -0400 (EDT) (envelope-from ups@tree.com) From: Stephan Uphoff To: Daniel Eriksson In-Reply-To: <4F9C9299A10AE74E89EA580D14AA10A6028579@royal64.emp.zapto.org> References: <4F9C9299A10AE74E89EA580D14AA10A6028579@royal64.emp.zapto.org> Content-Type: text/plain Message-Id: <1119063671.27369.134679.camel@palm> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 17 Jun 2005 23:01:11 -0400 Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: IPI_PREEMPTION, something to test for normal 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, 18 Jun 2005 03:01:15 -0000 On Thu, 2005-06-16 at 04:01, Daniel Eriksson wrote: > On a regular SMP server running 6-CURRENT, is IPI_PREEMPTION something > to try? > I've looked around for an explanation of what it does and what possible > pitfalls there are, but I haven't really found anything. It's only in > NOTES at the moment, indicating that it isn't for general consumption > yet(?). IPI_PREEMPTION allows the scheduler running on CPU A to preempt a thread on CPU B. This should reduce latency in some circumstances. More benchmarks are needed to find out if this actually helps or if additional context switch overhead slows down typical workloads. The preemption IPI could also be (ab)used later to add security fixes for hyperthreading as proposed by Colin Percival. Stephan From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 03:33: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 7E5DE16A41C for ; Sat, 18 Jun 2005 03:33:31 +0000 (GMT) (envelope-from snort_sam@yahoo.com) Received: from web54408.mail.yahoo.com (web54408.mail.yahoo.com [68.142.225.164]) by mx1.FreeBSD.org (Postfix) with SMTP id 152E743D49 for ; Sat, 18 Jun 2005 03:33:30 +0000 (GMT) (envelope-from snort_sam@yahoo.com) Received: (qmail 4675 invoked by uid 60001); 18 Jun 2005 03:33:30 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=wRuqaQgJ67BZMaNqKDfn8p/jMXl00droA7TKG4H5wdHnOuDf6s2JB18OfjC9inftsIIGYmUcubdKTmHjnD0b6EIj3wkGwcvwNBoyxW/nCFEFmjabK4PnXOCpZxgZc8C0SM7axz5IXwlXHSzOQBAph0PfzahoE9uNhNfullv9MQU= ; Message-ID: <20050618033330.4673.qmail@web54408.mail.yahoo.com> Received: from [60.230.124.196] by web54408.mail.yahoo.com via HTTP; Fri, 17 Jun 2005 20:33:30 PDT Date: Fri, 17 Jun 2005 20:33:30 -0700 (PDT) From: snort Snort To: freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: tty and serial console com port 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, 18 Jun 2005 03:33:31 -0000 Hi, I just read thru the tty.h file and the tty command, and have a feeling that the tty command and the tty.h file does not handle the serial console com port directly. Can anyone tell me which part of the tty source does invoke serial console com port? Thanks Sam __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 04:14: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 E26D016A41C for ; Sat, 18 Jun 2005 04:14:45 +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 BFB7143D49 for ; Sat, 18 Jun 2005 04:14:45 +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.4/8.13.4) with ESMTP id j5I4EjJj052251; Fri, 17 Jun 2005 21:14:45 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j5I4EhJt052250; Fri, 17 Jun 2005 21:14:43 -0700 (PDT) (envelope-from sgk) Date: Fri, 17 Jun 2005 21:14:43 -0700 From: Steve Kargl To: Marcin Jessa Message-ID: <20050618041443.GA52211@troutmask.apl.washington.edu> References: <20050617211950.GA41720@troutmask.apl.washington.edu> <20050618023335.0f7d9b45.lists@yazzy.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050618023335.0f7d9b45.lists@yazzy.org> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 18 Jun 2005 04:14:46 -0000 On Sat, Jun 18, 2005 at 02:33:35AM +0200, Marcin Jessa wrote: > On Fri, 17 Jun 2005 14:19:50 -0700 > Steve Kargl wrote: > > > I have taken mined(1) from DragonFlyBSD and integrated into the > > FreeBSD source tree. This is a very lightweight full screen > > editor with builtin support for cons25 and xterm. Yes, it is > > limited in its capabilites compared with /rescue/vi, but saves > > use 360 kB of diskspace and it does not require a termcap file. > > Great, this will make a good alternative for embedded systems. phk has tersely spoken out against mined(1), so I doubt it will ever meet the FreeBSD src tree. From my search, I've found that /rescue/vi has been present since 29 Jun 03. PR bin/80256, which notes that /rescue/vi needs a termcap file, was opened on 22 Apr 2005. After a short discussion (see PR audit trail), a 4 kB termcap file was stuck in the PR and there it sits. So, we can conclude (1) that no one uses /rescue/vi, or (2) /rescue/vi alsways works because a panic usr will never ever destroy /usr/share/misc/termcap, or (3) the entire FreeBSD user base is familiar the arcane ed(1). -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 04:48: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 1B2FB16A41C for ; Sat, 18 Jun 2005 04:48:08 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC72243D49 for ; Sat, 18 Jun 2005 04:48:07 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j5I4m5v3009487; Sat, 18 Jun 2005 00:48:06 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050617211950.GA41720@troutmask.apl.washington.edu> References: <20050617211950.GA41720@troutmask.apl.washington.edu> Date: Sat, 18 Jun 2005 00:48:04 -0400 To: Steve Kargl , freebsd-current@FreeBSD.org From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 Cc: Subject: Re: Replace /rescue/vi with mined(1) with a BSD license 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, 18 Jun 2005 04:48:08 -0000 At 2:19 PM -0700 6/17/05, Steve Kargl wrote: >I have taken mined(1) from DragonFlyBSD and integrated into the >FreeBSD source tree. This is a very lightweight full screen >editor with builtin support for cons25 and xterm. It would probably be helpful to add a bit more background history. FreeBSD *had* src/release/picobsd/tinyware/mined for a short while (a matter of days...). Unfortunately the project had to remove it because the license did not permit us to distribute it. What Matt did was contact the original author and get the editor put under a BSD license, and then he went on to make a few improvements to it. It is a nice, minimalist full-screen editor. I have been meaning to try out mined (and make sure it compiles on all our hardware platforms, etc), and see about adding back to FreeBSD. >Yes, it is limited in its capabilites compared with /rescue/vi, >but saves use 360 kB of diskspace and it does not require a >termcap file. >Yes, I'm aware of PR bin/80256, but that appears to stalled in >a state of limbo. I've also been meaning to do something about that idea of a small termcap file. I don't remember what the PR says, but someone had a good idea of generating the minimal termcap file from the standard one, and putting that in /rescue. I have a few ideas of my own so the system would automatically pick up that minimal file. Just a matter of finding the time to test it all... :-) I think these are two separate issues, and that both are worth doing. I'm sure other developers will have other opinions. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 05:23: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 B88B516A41C; Sat, 18 Jun 2005 05:23:45 +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 965F243D1F; Sat, 18 Jun 2005 05:23:45 +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.4/8.13.4) with ESMTP id j5I5NjId052775; Fri, 17 Jun 2005 22:23:45 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j5I5NjPp052774; Fri, 17 Jun 2005 22:23:45 -0700 (PDT) (envelope-from sgk) Date: Fri, 17 Jun 2005 22:23:45 -0700 From: Steve Kargl To: Garance A Drosehn Message-ID: <20050618052345.GA52745@troutmask.apl.washington.edu> References: <20050617211950.GA41720@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org Subject: Re: Replace /rescue/vi with mined(1) with a BSD license 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, 18 Jun 2005 05:23:45 -0000 On Sat, Jun 18, 2005 at 12:48:04AM -0400, Garance A Drosehn wrote: > > What Matt did was contact the original author and get the editor put > under a BSD license, and then he went on to make a few improvements > to it. It is a nice, minimalist full-screen editor. I have been > meaning to try out mined (and make sure it compiles on all our hardware > platforms, etc), and see about adding back to FreeBSD. > It compiles without warning and functions on amd64. In looking over the mined.1 man page, I noticed the key bindings weren't discussed (only the F1 help key is mentioned). So, I update the manpagei with the key bindings, sent it to DragonFlyBSD, and my patch was committed within an hour. I suspect it will take much longer for anyone to asks for the diffs. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 05:32: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 D6DC316A41C for ; Sat, 18 Jun 2005 05:32:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8FFAC43D49 for ; Sat, 18 Jun 2005 05:32:43 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j5I5UtUZ090683; Fri, 17 Jun 2005 23:30:56 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Fri, 17 Jun 2005 23:30:55 -0600 (MDT) Message-Id: <20050617.233055.41723867.imp@bsdimp.com> To: cracauer@cons.org From: Warner Losh In-Reply-To: <20050617194638.A13394@cons.org> References: <20050617173008.A11142@cons.org> <20050617184104.A12956@cons.org> <20050617194638.A13394@cons.org> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-current@FreeBSD.ORG Subject: Re: 6.0-current panic: loading radeon module 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, 18 Jun 2005 05:32:44 -0000 From: Martin Cracauer Subject: Re: 6.0-current panic: loading radeon module Date: Fri, 17 Jun 2005 19:46:39 -0400 > Hmmmmm, this doesn't look quite right. I am probably missing the > debug info from within the radeon module. But since I don't have the > base address for the module I'm not sure how to add its symbols when > debugging the vmcore. > > Let me know how useful this is. > > Martin > > (kgdb) bt > #0 doadump () at pcpu.h:165 > #1 0xc052db30 in boot (howto=260) at ../../../kern/kern_shutdown.c:397 > #2 0xc052ddf4 in panic (fmt=0xc06caa94 "from debugger") > at ../../../kern/kern_shutdown.c:553 > #3 0xc0450711 in db_panic (addr=-1066780860, have_addr=0, count=-1, > modif=0xf5a3d770 "") at ../../../ddb/db_command.c:435 > #4 0xc04506a8 in db_command (last_cmdp=0xc0737444, cmd_table=0x0, > aux_cmd_tablep=0xc06fcdf4, aux_cmd_tablep_end=0xc06fcdf8) > at ../../../ddb/db_command.c:349 > #5 0xc0450770 in db_command_loop () at ../../../ddb/db_command.c:455 > #6 0xc0452305 in db_trap (type=12, code=0) at ../../../ddb/db_main.c:221 > #7 0xc05462df in kdb_trap (type=12, code=0, tf=0xf5a3d904) > at ../../../kern/subr_kdb.c:471 > #8 0xc06a5bcb in trap_fatal (frame=0xf5a3d904, eva=3221094400) > at ../../../i386/i386/trap.c:826 > #9 0xc06a593f in trap_pfault (frame=0xf5a3d904, usermode=0, eva=3221094400) > at ../../../i386/i386/trap.c:749 > #10 0xc06a5561 in trap (frame= > {tf_fs = -1067122680, tf_es = -1056702424, tf_ds = 40, tf_edi = 256, tf_esi = -533393408, tf_ebp = -173811368, tf_isp = -173811408, tf_ebx = 130740224, tf_edx = 1015808, tf_ecx = -134217728, tf_eax = -533393149, tf_trapno = 12, tf_err = 2, tf_eip = -1066780860, tf_cs = 32, tf_eflags = 590470, tf_esp = 0, tf_ss = -137695232}) at ../../../i386/i386/trap.c:439 > ---Type to continue, or q to quit--- > #11 0xc069538a in calltrap () at ../../../i386/i386/exception.s:139 > #12 0xc0650008 in ufs_setattr (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:564 > #13 0xc069fe39 in nexus_activate_resource (bus=0xc2703d00, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at ../../../i386/i386/nexus.c:419 > #14 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #15 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #16 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #17 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #18 0xc05436b0 in bus_generic_activate_resource (dev=0x0, child=0xc2821000, > type=3, rid=16, r=0xc281dd80) at bus_if.h:290 > #19 0xc04addaa in pci_alloc_resource (dev=0xc2821080, child=0xc2821000, > type=3, rid=0xf5a3db2c, start=0, end=4294967295, count=1, flags=6) > at ../../../dev/pci/pci.c:1753 > #20 0xc0543a88 in bus_alloc_resource (dev=0x0, type=3, rid=0xf5a3db2c, > start=0, end=4294967295, count=1, flags=6) at bus_if.h:262 > #21 0xc2b9a273 in ?? () This is your problem. dev == 0 isn't allowed here. I'm surprised it gets as far as it does. But I'm not entirely sure I believe it because dev is supposed to have its parent taken to walk up the tree. And there's no way that ufs attr is being called from nexus resource manager.... Warner From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 06:15: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 41B1116A41C for ; Sat, 18 Jun 2005 06:15:36 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED8D243D48 for ; Sat, 18 Jun 2005 06:15:35 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 26BCA60F3; Sat, 18 Jun 2005 08:15:29 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 0B99C60F2; Sat, 18 Jun 2005 08:15:29 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 98EBC33C23; Sat, 18 Jun 2005 08:15:28 +0200 (CEST) To: Mike Tancsa References: <6.2.1.2.0.20050412220212.055c5d48@64.7.153.2> <867jj5wyvf.fsf@xps.des.no> <6.2.1.2.0.20050617141056.03ea3830@64.7.153.2> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sat, 18 Jun 2005 08:15:28 +0200 In-Reply-To: <6.2.1.2.0.20050617141056.03ea3830@64.7.153.2> (Mike Tancsa's message of "Fri, 17 Jun 2005 14:15:24 -0400") Message-ID: <86hdfwi41r.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Learn: ham X-Spam-Score: -5.2/5.0 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tim.des.no Cc: freebsd-current@freebsd.org Subject: Re: ichwd fixes / patches 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, 18 Jun 2005 06:15:36 -0000 Mike Tancsa writes: > Any chance to commit the patches in the above PR ? I know its not > ideal, but at least it works where as its currently 100% broken in > the tree. That's the problem: the patch *doesn't* work. I need to sit down with the docs and painstakingly check everything and figure out why. > As to the issue of the ICH6 stuff, looking through the LINUX lists, it > seems a lot of ICH6 MBs dont actually hookup the onboard watchdog for > some reason. I know. The ichwd driver has logic to detect that. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 06:16: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 48EB416A41C for ; Sat, 18 Jun 2005 06:16:08 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from mail18.syd.optusnet.com.au (mail18.syd.optusnet.com.au [211.29.132.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id CC73143D48 for ; Sat, 18 Jun 2005 06:16:07 +0000 (GMT) (envelope-from PeterJeremy@optushome.com.au) Received: from cirb503493.alcatel.com.au (c220-239-8-51.belrs4.nsw.optusnet.com.au [220.239.8.51]) by mail18.syd.optusnet.com.au (8.12.11/8.12.11) with ESMTP id j5I6G5NQ029446 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sat, 18 Jun 2005 16:16:05 +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 j5I6G4Rx062673; Sat, 18 Jun 2005 16:16:04 +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 j5I6G4bt062672; Sat, 18 Jun 2005 16:16:04 +1000 (EST) (envelope-from pjeremy) Date: Sat, 18 Jun 2005 16:16:04 +1000 From: Peter Jeremy To: Steve Kargl Message-ID: <20050618061603.GM50157@cirb503493.alcatel.com.au> References: <20050617214658.GA41804@troutmask.apl.washington.edu> <58826.1119044951@critter.freebsd.dk> <20050617220222.GA42080@troutmask.apl.washington.edu> <20050617220653.GA114@saltmine.radix.net> <20050617221353.GA48584@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050617221353.GA48584@troutmask.apl.washington.edu> User-Agent: Mutt/1.4.2i Cc: freebsd-current@freebsd.org, Thomas Dickey Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 18 Jun 2005 06:16:08 -0000 On Fri, 2005-Jun-17 15:13:53 -0700, Steve Kargl wrote: >On Fri, Jun 17, 2005 at 06:06:53PM -0400, Thomas Dickey wrote: >> This topic comes up about every 3 months. ncurses can be compiled to have >> embedded terminal descriptions. That's one choice. Another is to have a >> small termcap file. That's another choice. Of course another choice is >> to change the editor (though stating that it has support for cons25 and >> xterm sounds suspicious, since they do differ). It's possible to write a full-screen editor using a fairly minimal set of ANSI sequences (CUP and EL would do, but adding more sequences will help) that is common to cons25 and xterm (and VT100 etc). This may not be as "efficient" as an application that is tuned to use all the features available in the terminal but that is totally irrelevant for an application running on the console. >I've already stated that I'm aware of the PR that has >a minimalist termcap, which needs to be installed somewhere >that /rescue/vi can find it. > >-r-xr-xr-x 129 root wheel 3669272 Jun 17 15:09 /rescue/ee* >-r-xr-xr-x 1 root wheel 3564216 Jun 17 14:50 /rescue/mined* >-r-xr-xr-x 2 root wheel 3940176 Jun 16 15:56 /rescue/vi* Exactly what are you comparing here? Are these all crunched binaries built identically except for the embedded editor? If you're looking for ways to save space in /rescue, there are other low-hanging fruit before you start moving to yet another editor: - It's difficult to justify both sh and [t]csh. - echo (which is builtin both sh and [t]csh) - test (which is builtin to sh) - clri (which is builtin to fsdb) - routed, rtquery, rtsol (recovering a hosed system shouldn't need a routing daemon - a static route to the backup server should do) - pax (when the new libarchive tar is available) - id (there's no 'su' so how can I be anything other than root?) If someone really wants to spend time developing a stripped down application that would be useful in /rescue, they should look at ssh. A cut-down ssh/libssl would be far more appreciated. >This is an editor meant for recovering a system. It's not >a full blown kitchen sink. I don't think anyone is suggesting that we include emacs in /rescue :-) -- Peter Jeremy From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 06:30:11 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 0A74416A41C for ; Sat, 18 Jun 2005 06:30:11 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from mailout09.sul.t-online.com (mailout09.sul.t-online.com [194.25.134.84]) by mx1.FreeBSD.org (Postfix) with ESMTP id B4B6643D49 for ; Sat, 18 Jun 2005 06:30:10 +0000 (GMT) (envelope-from Alexander@Leidinger.net) Received: from fwd32.aul.t-online.de by mailout09.sul.t-online.com with smtp id 1DjWqF-0003xK-00; Sat, 18 Jun 2005 08:30:07 +0200 Received: from Andro-Beta.Leidinger.net (X6T+t4ZD8eVMcI4UB8WNGcFClMS3v3Ivzxqn7TqKuGG1lUR2t6icYo@[84.165.239.20]) by fwd32.sul.t-online.de with esmtp id 1DjWq5-0gghjU0; Sat, 18 Jun 2005 08:29:57 +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 j5I6To6N007577; Sat, 18 Jun 2005 08:29:50 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Date: Sat, 18 Jun 2005 08:30:26 +0200 From: Alexander Leidinger To: Jon Dama Message-ID: <20050618083026.26238653@Magellan.Leidinger.net> In-Reply-To: References: <20050617180232.GA25818@freefall.freebsd.org> <42B31247.9010603@portaone.com> <34cb7c840506171121cd0437f@mail.gmail.com> <42B3189E.6030408@portaone.com> <34cb7c8405061716327ca4c6d7@mail.gmail.com> X-Mailer: Sylpheed-Claws 1.9.11 (GTK+ 2.6.7; i386-portbld-freebsd6.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-ID: X6T+t4ZD8eVMcI4UB8WNGcFClMS3v3Ivzxqn7TqKuGG1lUR2t6icYo@t-dialin.net X-TOI-MSGID: 583e4dbc-3a21-48f1-b112-8293d471862e Cc: Maxim.Sobolev@portaone.com, current@freebsd.org, Peter Edwards Subject: Re: Towards a working "wine". [long] 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, 18 Jun 2005 06:30:11 -0000 On Fri, 17 Jun 2005 17:59:38 -0700 (PDT) Jon Dama wrote: > My intuition says that mmap should ignore requests to map into the > existing brk region but not reject requests that are merely between the > existing brk region and the DS limit. Have you seen Martin Cracauer's mail ("My hacks to make the memory map fit") on emulation@ which deals with the memory map? Maybe it's of help here... Bye, Alexander. -- Give a man a fish and you feed him for a day; teach him to use the Net and he won't bother you for weeks. 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 Sat Jun 18 08: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 85D1316A41C for ; Sat, 18 Jun 2005 08:19:07 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3CEF843D4C for ; Sat, 18 Jun 2005 08:19:07 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 3684E6106; Sat, 18 Jun 2005 10:19:01 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 23BDB6105; Sat, 18 Jun 2005 10:19:01 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 0EB2033C29; Sat, 18 Jun 2005 10:19:01 +0200 (CEST) To: Peter Jeremy References: <20050617214658.GA41804@troutmask.apl.washington.edu> <58826.1119044951@critter.freebsd.dk> <20050617220222.GA42080@troutmask.apl.washington.edu> <20050617220653.GA114@saltmine.radix.net> <20050617221353.GA48584@troutmask.apl.washington.edu> <20050618061603.GM50157@cirb503493.alcatel.com.au> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sat, 18 Jun 2005 10:19:00 +0200 In-Reply-To: <20050618061603.GM50157@cirb503493.alcatel.com.au> (Peter Jeremy's message of "Sat, 18 Jun 2005 16:16:04 +1000") Message-ID: <861x70gjrf.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Learn: ham X-Spam-Score: -5.2/5.0 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tim.des.no Cc: freebsd-current@freebsd.org, Thomas Dickey , Steve Kargl Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 18 Jun 2005 08:19:07 -0000 Peter Jeremy writes: > It's possible to write a full-screen editor using a fairly minimal set > of ANSI sequences (CUP and EL would do, but adding more sequences will > help) that is common to cons25 and xterm (and VT100 etc). I believe VT100 is (in large part) a subset of both cons25 and xterm. > - routed, rtquery, rtsol (recovering a hosed system shouldn't need a > routing daemon - a static route to the backup server should do) In IPv6 land, setting a static route may not be as trivial as you think. DES --=20 Dag-Erling Sm=F8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 10:55: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 6092316A41C for ; Sat, 18 Jun 2005 10:55:04 +0000 (GMT) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (saltmine.radix.net [207.192.128.40]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1E2D443D48 for ; Sat, 18 Jun 2005 10:55:03 +0000 (GMT) (envelope-from dickey@saltmine.radix.net) Received: from saltmine.radix.net (localhost [127.0.0.1]) by saltmine.radix.net (8.12.2/8.12.2) with ESMTP id j5IAt1I4019510; Sat, 18 Jun 2005 06:55:01 -0400 (EDT) Received: (from dickey@localhost) by saltmine.radix.net (8.12.2/8.12.2/Submit) id j5IAt1Sm019505; Sat, 18 Jun 2005 06:55:01 -0400 (EDT) Date: Sat, 18 Jun 2005 06:55:01 -0400 From: Thomas Dickey To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= Message-ID: <20050618105500.GA16565@saltmine.radix.net> References: <20050617214658.GA41804@troutmask.apl.washington.edu> <58826.1119044951@critter.freebsd.dk> <20050617220222.GA42080@troutmask.apl.washington.edu> <20050617220653.GA114@saltmine.radix.net> <20050617221353.GA48584@troutmask.apl.washington.edu> <20050618061603.GM50157@cirb503493.alcatel.com.au> <861x70gjrf.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline In-Reply-To: <861x70gjrf.fsf@xps.des.no> User-Agent: Mutt/1.3.27i Cc: freebsd-current@freebsd.org Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 18 Jun 2005 10:55:04 -0000 --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 18, 2005 at 10:19:00AM +0200, Dag-Erling Sm=F8rgrav wrote: > Peter Jeremy writes: > > It's possible to write a full-screen editor using a fairly minimal set > > of ANSI sequences (CUP and EL would do, but adding more sequences will > > help) that is common to cons25 and xterm (and VT100 etc). >=20 > I believe VT100 is (in large part) a subset of both cons25 and xterm. no - there's a subset of vt100 that overlaps with cons25. cons25 is not a vt100 emulator. It is possible to code around this by sticking to the subset. Does anyone have a URL to point to the source for mined? google isn't showing me anything useful. --=20 Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (SunOS) Comment: For info see http://www.gnupg.org iD8DBQFCs/2DtIqByHxlDocRAgnyAJ0d64GBJbFbfNyQJJtRdLRXLFXdDQCeJvVB 1ZpYbSaRU3VATQrGxScfe7M= =0RRr -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 10:56: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 4C48C16A41C for ; Sat, 18 Jun 2005 10:56:30 +0000 (GMT) (envelope-from tarc@tarc.po.cs.msu.su) Received: from tarc.po.cs.msu.su (tarc.po.cs.msu.su [158.250.16.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id CDF1943D49 for ; Sat, 18 Jun 2005 10:56:29 +0000 (GMT) (envelope-from tarc@tarc.po.cs.msu.su) Received: from tarc.po.cs.msu.su (localhost [127.0.0.1]) by tarc.po.cs.msu.su (8.13.4/8.13.3) with ESMTP id j5IAuMBT000751; Sat, 18 Jun 2005 14:56:22 +0400 (MSD) (envelope-from tarc@tarc.po.cs.msu.su) Received: (from tarc@localhost) by tarc.po.cs.msu.su (8.13.4/8.13.3/Submit) id j5IAuMO3000750; Sat, 18 Jun 2005 14:56:22 +0400 (MSD) (envelope-from tarc) Date: Sat, 18 Jun 2005 14:56:22 +0400 From: Tarc To: Dag-Erling =?koi8-r?Q?Sm=F8rgrav?= Message-ID: <20050618105622.GA723@tarc.po.cs.msu.su> References: <20050617180321.GA1131@tarc.po.cs.msu.su> <867jgskfvd.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <867jgskfvd.fsf@xps.des.no> User-Agent: Mutt/1.5.9i Cc: freebsd-current Subject: Re: -CURRENT crashes on compilling 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, 18 Jun 2005 10:56:30 -0000 On Fri, Jun 17, 2005 at 08:17:10PM +0200, Dag-Erling Smørgrav wrote: > Tarc writes: > > I change my old computer to a new one (see dmesgs links below) and > > my computer begins to crash anywhere(cc1, sh, awk, ...) with (mainly > > page fault) very often. > > Bad hardware - most likely bad RAM, possibly a bad CPU. > > DES > -- > Dag-Erling Smørgrav - des@des.no > > _______________________________________________ > 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" Hmm... I thinked about this, but RAM is ok. How test processor? -- Best regards, Arseny Nasokin From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 10:59:39 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 9568416A41C; Sat, 18 Jun 2005 10:59:39 +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 4BA1343D4C; Sat, 18 Jun 2005 10:59:38 +0000 (GMT) (envelope-from schweikh@schweikhardt.net) Received: by bremen.shuttle.de (Postfix, from userid 10) id BA41B3B980; Sat, 18 Jun 2005 12:59:35 +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 j5IAxJLG063734; Sat, 18 Jun 2005 12:59:19 +0200 (CEST) (envelope-from schweikh@hal9000.schweikhardt.net) Received: (from schweikh@localhost) by hal9000.schweikhardt.net (8.13.3/8.13.3/Submit) id j5IAxJYT063733; Sat, 18 Jun 2005 12:59:19 +0200 (CEST) (envelope-from schweikh) Date: Sat, 18 Jun 2005 12:59:18 +0200 From: Jens Schweikhardt To: John Baldwin Message-ID: <20050618105918.GA1551@schweikhardt.net> References: <20050516113420.GA786@schweikhardt.net> <20050526205831.GA958@schweikhardt.net> <20050608190147.GA917@schweikhardt.net> <200506171450.44146.jhb@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506171450.44146.jhb@FreeBSD.org> 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: Sat, 18 Jun 2005 10:59:39 -0000 On Fri, Jun 17, 2005 at 02:50:42PM -0400, John Baldwin wrote: ... # Is this the patch you are running with? Yes, with if (1) instead, which we know is the same. # >Index: clock.c # =================================================================== # RCS file: /usr/cvs/src/sys/i386/isa/clock.c,v # retrieving revision 1.220 # diff -u -r1.220 clock.c # --- clock.c 14 May 2005 09:10:01 -0000 1.220 # +++ clock.c 27 May 2005 19:42:54 -0000 # @@ -784,7 +784,7 @@ # * clocks, setup the interrupt handler for the 8254 timer 0 so # * that it can drive hardclock(). # */ # - if (!using_lapic_timer) { # + if (!using_lapic_timer || 1) { # intr_add_handler("clk", 0, (driver_intr_t *)clkintr, NULL, # INTR_TYPE_CLK | INTR_FAST, NULL); # i8254_intsrc = intr_lookup_source(0); # # Also, can you get the output of 'sysctl kern.clockrate' for both cases? As reported upthread, it's the same for both cases, $ sysctl -a | grep hz kern.clockrate: { hz = 1000, tick = 1000, profhz = 666, stathz = 133 } debug.psm.hz: 20 See http://lists.freebsd.org/pipermail/freebsd-current/2005-May/050210.html for the whole thread. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 11:43:57 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 B7DF616A41C for ; Sat, 18 Jun 2005 11:43:57 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.192]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7519C43D55 for ; Sat, 18 Jun 2005 11:43:57 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so35980nzp for ; Sat, 18 Jun 2005 04:43: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=N3t9N0oPE4ecwxNV3EzU6rRGzPIN8Kgg2HehOdH0MrN2y3wyDqRGwInavl3Fue9C+TPV4SVt/MIf0TX/+Xz4zJdRs0uNuv33iIVEzVgCvfZ+gJtzvQgfBEX8tr+aC47o9kGDoPBdyWgcz+MAyDrtPdn9rXpCjOTzdSCcjAgO7C8= Received: by 10.36.18.8 with SMTP id 8mr1979861nzr; Sat, 18 Jun 2005 04:43:56 -0700 (PDT) Received: by 10.36.68.15 with HTTP; Sat, 18 Jun 2005 04:43:56 -0700 (PDT) Message-ID: <34cb7c840506180443586ac065@mail.gmail.com> Date: Sat, 18 Jun 2005 12:43:56 +0100 From: Peter Edwards To: Jon Dama In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050617180232.GA25818@freefall.freebsd.org> <42B31247.9010603@portaone.com> <34cb7c840506171121cd0437f@mail.gmail.com> <42B3189E.6030408@portaone.com> <34cb7c8405061716327ca4c6d7@mail.gmail.com> Cc: Peter Edwards , Maxim.Sobolev@portaone.com, current@freebsd.org Subject: Re: Towards a working "wine". [long] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Edwards List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2005 11:43:57 -0000 On 6/18/05, Jon Dama wrote: > My intuition says that mmap should ignore requests to map into the > existing brk region but not reject requests that are merely between the > existing brk region and the DS limit. >=20 > Is this what happens now? >=20 For the non-MAP_FIXED case, if the hint is in the data segment (ie, in the range [daddr, daddr + RLIMIT_DATA), _not_ [daddr, break)), or is NULL, it's adjusted to be just beyond the data segment. So, by default, mmap() starts looking for space after the data segment. So a low "hint", ie., one before the start of the data segment _wont_ be adjusted. The hint itself is used as the starting address for the search for enough address space to use: this search will return as soon as its found enough room in the processes memory map. Actually, there's a bit of a problem here: if you specify a low address before the data segment, you can actually get mmap to deliver memory inside the possible limits of the data segment, but after the current position of the "break". It's certainly confusing behaviour, but it might have some historical significance: Comments, anyone? From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 14:59: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 8E76116A41C for ; Fri, 17 Jun 2005 14:59:55 +0000 (GMT) (envelope-from Eric.Boutilier@Sun.COM) Received: from brmea-mail-4.sun.com (brmea-mail-4.Sun.COM [192.18.98.36]) by mx1.FreeBSD.org (Postfix) with ESMTP id 37FD843D1F for ; Fri, 17 Jun 2005 14:59:55 +0000 (GMT) (envelope-from Eric.Boutilier@Sun.COM) Received: from phys-ita01-1 ([129.153.224.1]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5HExqr4009114 for ; Fri, 17 Jun 2005 08:59:54 -0600 (MDT) Received: from conversion-daemon.ita01-mail1.central.sun.com by ita01-mail1.central.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0II800D01H14KS@ita01-mail1.central.sun.com> (original mail from Eric.Boutilier@Sun.COM) for freebsd-current@freebsd.org; Fri, 17 Jun 2005 09:57:56 -0500 (CDT) Received: from sr-uita01-02 (sr-uita01-02.Central.Sun.COM [129.153.224.6]) by ita01-mail1.central.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0II800IP7HKJVO@ita01-mail1.central.sun.com> for freebsd-current@freebsd.org; Fri, 17 Jun 2005 09:57:56 -0500 (CDT) Date: Fri, 17 Jun 2005 09:57:55 -0500 (CDT) From: Eric Boutilier In-reply-to: <20050615160741.GA55062@dragon.NUXI.org> X-X-Sender: bout@sr-uita01-02 To: freebsd-current@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <200504262010.49509@harrymail> <20050429200029.GC232@cirb503493.alcatel.com.au> <200506141824.17451@harrymail> <20050614185923.GA12375@dragon.NUXI.org> <20050615054209.L29741@beagle.kn.op.dlr.de> <20050615160741.GA55062@dragon.NUXI.org> X-Mailman-Approved-At: Sat, 18 Jun 2005 11:57:40 +0000 Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Eric Boutilier List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2005 14:59:55 -0000 On Wed, 15 Jun 2005, David O'Brien wrote: > On Wed, Jun 15, 2005 at 05:47:26AM +0000, Harti Brandt wrote: > > On Tue, 14 Jun 2005, David O'Brien wrote: > > > > DO>On Tue, Jun 14, 2005 at 06:24:07PM +0200, Emanuel Strobl wrote: > > DO>> today I read a news article (http://www.heise.de/newsticker/meldung/60600) > > DO>> about OpenSolaris beeing released, but is there also the groff alternative > > DO>> included? > > DO>> I'd love to see a lean replacment for our current gnu version. > > DO> > > DO>Before everyone gets all happy thinking we can incorporate all kinds of > > DO>bits from Open Solaris - one should read the license agrement first. > > DO> > > DO> COMMON DEVELOPMENT AND DISTRIBUTION LICENSE Version 1.0 > > DO> .. > > DO> 3.1. Availability of Source Code. > > DO> Any Covered Software that You distribute or otherwise make available > > DO> in Executable form must also be made available in Source Code form > > DO> and that Source Code form must be distributed only under the terms of > > DO> this License. > > DO> > > DO>this puts the CDDL1.0 in the same boat as GPL'ed code from a BSD stand > > DO>point. > > > > I think that's not entirely correct. > .. > > In this case you don't need to distribute the pieces > > that are covered by the other license. > .. > > You don't need to distribute the new file > > with that function. Of course that new file will not be CDDL covered. > > I never said CDDL was viral. It is like the GPL (LGPL if you like) in > that you must deliver the source with the binary... I think we (Sun) have a loose interpretation of the "made available" phrase (in 3.1 of the CDDL). I don't think it means "must deliver" the source with the binary. For example, I think if you make source available for download on an ftp server that's fine. IANA(Sun)L, so I certainly can't say anything definitive in this regard, but if you do end up wanting to consider incorporating Sun groff or any other Sun open-source code, I or any of my colleagues on the OpenSolaris Team would be happy to check into it for you. Eric Boutilier http://blogs.sun.com/eric_boutilier From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 20:54: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 9CA7916A41C for ; Fri, 17 Jun 2005 20:54:27 +0000 (GMT) (envelope-from jd@philemon.async.caltech.edu) Received: from philemon.caltech.edu (philemon.async.caltech.edu [131.215.39.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8016F43D48 for ; Fri, 17 Jun 2005 20:54:27 +0000 (GMT) (envelope-from jd@philemon.async.caltech.edu) Received: from philemon.caltech.edu (localhost.caltech.edu [127.0.0.1]) by philemon.caltech.edu (8.13.1/8.12.9) with ESMTP id j5HKsF3v049745; Fri, 17 Jun 2005 13:54:15 -0700 (PDT) (envelope-from jd@philemon.async.caltech.edu) Received: (from jd@localhost) by philemon.caltech.edu (8.13.1/8.12.9/Submit) id j5HKsFg7049744; Fri, 17 Jun 2005 13:54:15 -0700 (PDT) Date: Fri, 17 Jun 2005 13:54:15 -0700 From: Paul Allen To: freebsd-current@freebsd.org Message-ID: <20050617205415.GT18614@philemon.caltech.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Mailman-Approved-At: Sat, 18 Jun 2005 11:57:40 +0000 Cc: Subject: Re: groff alternative? 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, 17 Jun 2005 20:54:27 -0000 On Fri, 17 Jun 2005, Chuck Swiger wrote: > You should know that being involved in a lawsuit generally has nothing to do > with the actual merits of the situation, it takes nothing more than one party > being unreasonable and looking for anything they can think of to make claims. > For someone in the EU-- or Australia, or a lot of places, apparently-- that > could be something as simple as the "DISCLAIMER" section of the BSD license, > since those jurisdictions do not permit liability to be completely disclaimed. I beg your pardon? I highly doubt that there is a jurisdiction on the planet that supports the principle of one-sided contracts. The DISCLAIMER gains its power precisely because you did not pay for the work being disclaimed and you voluntarily made use of that work. This is distinguished say from the necessity of good-samaratian laws which apply when people give aid without compensation to individuals who are not in a state in which they may consent. Please provide case citations with such speculation in the future. A good engineer knows that many things can go wrong, but he worries only about those things he feels are likely. -Paul From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 22:13: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 0ABF816A41C for ; Fri, 17 Jun 2005 22:13:26 +0000 (GMT) (envelope-from jd@philemon.async.caltech.edu) Received: from philemon.caltech.edu (philemon.async.caltech.edu [131.215.39.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id A9DA843D48 for ; Fri, 17 Jun 2005 22:13:25 +0000 (GMT) (envelope-from jd@philemon.async.caltech.edu) Received: from philemon.caltech.edu (localhost.caltech.edu [127.0.0.1]) by philemon.caltech.edu (8.13.1/8.12.9) with ESMTP id j5HMDE8h050019; Fri, 17 Jun 2005 15:13:14 -0700 (PDT) (envelope-from jd@philemon.async.caltech.edu) Received: (from jd@localhost) by philemon.caltech.edu (8.13.1/8.12.9/Submit) id j5HMDDtn050018; Fri, 17 Jun 2005 15:13:13 -0700 (PDT) Date: Fri, 17 Jun 2005 15:13:13 -0700 From: Paul Allen To: Chuck Swiger Message-ID: <20050617221313.GV18614@philemon.caltech.edu> References: <20050617205415.GT18614@philemon.caltech.edu> <42B33D92.1080109@mac.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42B33D92.1080109@mac.com> X-Mailman-Approved-At: Sat, 18 Jun 2005 11:57:40 +0000 Cc: freebsd-current@freebsd.org Subject: Re: groff alternative? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: freebsd-chat@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: Fri, 17 Jun 2005 22:13:26 -0000 (reply-to set to freebsd-chat, this discussion doesn't belong on -current) Well I am not here to give you legal advice, as I am not a lawyer. Luckily, rational people are free to discuss their views on the law purely for the sake of discussion. So I have to say I disagree with your conclusions based on the context of your sources. See: http://www.law.qut.edu.au/files/open_source_book.pdf for lots of information. There are two problems, one is whether the license can hold. In the BSD case this is essentially irrelevant. If the license is nullifed because a jurisdiction enforces a punative rule that any improper terms nullify the entire license, the result is to return the code to the BSD state. Thus, the BSD license is essentially a tautology whereas the GPL is not and this is a signficant problem for people who want to impose its totalitarian view of the meaning of free. Now let us discuss the disclaimers. It is true that Australian law has certain supposedly undisclaimible implied warrantees. See sections 66 to 74 of the "Trade Practices Act" of 1974 Now section 68A of the TPA permits the liability to be restricted to the "cost of resupply" which is of course zero in the case of free software distributed over the internet. As you do not seem to be aware, let me tell you that it is not a point of settled law in Australia that software as mere information as one would download over the internet is even actually a good in trade under the law. To phrase this generally, when "distributing" things over the internet, you never distribute the information yourself. You merely distribute a right to people to access your computer system in a restricted fashion. They do so and in the process "take" information from you. At no point have you established the existance of a good in trade. If you and phk sit in a bar and he reads outloud the text of /usr/src and you write it down, no "good" has been distributed. Finally, most of the anaylsis on this subject is VERY GPL centric. The trouble with the GPL is that actually attempts to bind the user. The BSD license reads: 1) this code is released into the public domain 2) this code may not be taken out of the public domain (vacuous duplication of #1) 3) during redistribution you may not conceal that this code is in the public domain (vacuous duplication of #2) 4) I declare my opinion that I am not offering something which induces liability on myself. (vacuous duplication of #1) The same cannot be said of the GPL. You should mull-over how it is that FreeBSD is placed in the public domain but it is completely nonsensical for a good to be placed in the public domain. As for people distributing CDs of FreeBSD you can reasonably argue that their obligation is to supply a readible and correct image of the FreeBSD information--which is what they claim to provide. Oh. And if you haven't figured it out yet, lawyers are in the business of inventing liability and possible liability. THAT IS HOW THEY MAKE MONEY. If you don't want to be suffocated by such lawyers its best to speak loudly and with a clear voice as to how you read the law. -Paul >From Chuck Swiger , Fri, Jun 17, 2005 at 05:16:02PM -0400: > Paul Allen wrote: > >On Fri, 17 Jun 2005, Chuck Swiger wrote: > >>You should know that being involved in a lawsuit generally has nothing to > >>do > >>with the actual merits of the situation, it takes nothing more than one > >>party > >>being unreasonable and looking for anything they can think of to make > >>claims. > >>For someone in the EU-- or Australia, or a lot of places, apparently-- > >>that could be something as simple as the "DISCLAIMER" section of the BSD > >>license, since those jurisdictions do not permit liability to be > >>completely disclaimed. > > > >I beg your pardon? I highly doubt that there is a jurisdiction on the > >planet that supports the principle of one-sided contracts. > > The BSD license isn't a contract, Paul: it's not phrased as one and it > doesn't have what the legal types call a "proffer". > > >The DISCLAIMER gains its power precisely because you did not pay for the > >work being disclaimed and you voluntarily made use of that work. This is > >distinguished say from the necessity of good-samaratian laws which apply > >when people give aid without compensation to individuals who are not in a > >state in which they may consent. > > Yeah, yeah, I know. I don't even disagree, but I've got news for you: > the law doesn't always make sense. > > >Please provide case citations with such speculation in the future. A good > >engineer knows that many things can go wrong, but he worries only about > >those things he feels are likely. > > Go read HIPPA or European contract law (cf German "Cecil" section 315, > apparently). I'm not qualified to give legal advice; go pay for an > attourney. But here are two comments from people who are: > > From: "Lawrence Rosen" > To: "'Donnal Walter'" , > > Subject: RE: open source medical software > Message-ID: <20050127143025.GA15353@mail26c.sbc-webhosting.com> > [ ... ] > > Software distributors must obey the law regardless of what an open source > license says. So if you must obtain FDA approval before you can distribute > certain software intended for patient care, the license doesn't override > that requirement. You may be required by law to perform certain tests or > peer review before distributing the software; a mere license won't let you > avoid that. > > However, the open source license you use cannot *require* licensees to > obtain FDA approval or get peer review. The only thing you can do is remind > licensees of *their* duty to obey the law as they understand the law. > > This is similar to the issue of export regulations. As a distributor of > software in the United States, you are required by law to obey US export > regulations. But you can't impose that requirement on your customers who > live and work in other countries. It is up to them to obey the law as they > understand that law. So OSI has never accepted a license that expressly > requires licensees to obey specific US export law. > > Your open source license cannot impose specific restrictions on how to copy, > modify or redistribute the work, or restrict such activities to certain > professionals. > > As for whether you must include a warranty, that too is often a subject of > legal regulation. A disclaimer of warranty or limitation of liability in an > open source license may not be enforceable in some jurisdictions and for > some forms of injury. > > In these cases, you and your customers should probably consult an attorney > specializing in the requirements of the FDA and other government agencies. > > --------------- > > From: "Axel Metzger" > To: > Subject: AW: For Approval: German Free Software License > Message-ID: > <84D511A814FAF742BF6927D883CF67C177BECC@mpg-hap-info.mpipriv-hh.mpg.de> > > Hi Chuck, > > thanks for your comments. I will try to address your critical remarks. > > Chuck Swiger wrote: > [ ... ] > >>>Distribution: The public passing on of material copies to third > >>>parties, in particular, onto storage devices or in connection with > >>>hardware. > > > > One is also redistributing the software if you pass the software on in > > private, say to your relative or to another member of your company. > > > > I believe your intent is to enable people to change the software for their > > private use without making their changes public, but require the source > > code to be made available when public redistribution, so it would be > helpful > > to clarify these terms a bit. > > Here once again, we followed the wording of German and European Copyright > law. Do you have a realistic idea how many problems of interpretation > European lawyers have with the US-based licenses? This is one of the major > reasons why the Ministry wanted to have a more "European" license. > > >>>Section 7 Liability and Warranty > >>>(1) The Entitled Persons are only liable for conflicting third-party > >>>rights if they were aware of such rights without informing you. > >>> > >>>(2) Liability for errors and/or other defects in the Program shall > >>>be governed by agreements concluded between you and the Entitled > >>>Person beyond the scope of this License or, if no such agreement > >>>exists, by the pertinent statutory provisions. > > > > If I modify a program covered by the GFSL, and I want to redistribute my > > version without any warranty (ie, the standard DISCLAIMER found in the BSD > > and other licenses which disclaims liability since the software is being > made > > available free of charge), may I do so? > > No, under German and European contract law it is impossible to exclude any > warranty and liability. The consequences are not to severe - as long as you > redistribute the program without charging a fee. Under the German Cicil Code > you are only liable if you knew that the program has defects etc. > > > Can a project like FreeBSD, NetBSD, etc, or a Linux distro like Debian, > > Redhat, etc, adopt GFSL code without conflict with their existing > > disclaimers? > > The disclaimers are invalid under German and European contract law. Sorry, > they are legally inexistent in Europe. > > [ ... ] > > -- > -Chuck -- From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 12:06:37 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 4C42616A41C for ; Sat, 18 Jun 2005 12:06:37 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.196]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1280243D53 for ; Sat, 18 Jun 2005 12:06:36 +0000 (GMT) (envelope-from peadar.edwards@gmail.com) Received: by zproxy.gmail.com with SMTP id 12so39515nzp for ; Sat, 18 Jun 2005 05:06:36 -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=umq+klUD0CeuXcZc4N0k72Tt4JLQeGnsFjX1ug5UD0YFFOBjYhNxnhc4s+YhzN7tVVo26rdnbQ2NLOfE37+aMA3XR5HLeO5Hq2Uf0ijoz48elYaJl5d/Bzp2JZlCERybqYkbhzRKM7GYN5Rb1UQLhT2/htFCeuJ1h0qgRrLn4ho= Received: by 10.36.24.6 with SMTP id 6mr2031269nzx; Sat, 18 Jun 2005 05:06:36 -0700 (PDT) Received: by 10.36.68.15 with HTTP; Sat, 18 Jun 2005 05:06:36 -0700 (PDT) Message-ID: <34cb7c84050618050623db6187@mail.gmail.com> Date: Sat, 18 Jun 2005 13:06:36 +0100 From: Peter Edwards To: Alexander Leidinger In-Reply-To: <20050618083026.26238653@Magellan.Leidinger.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20050617180232.GA25818@freefall.freebsd.org> <42B31247.9010603@portaone.com> <34cb7c840506171121cd0437f@mail.gmail.com> <42B3189E.6030408@portaone.com> <34cb7c8405061716327ca4c6d7@mail.gmail.com> <20050618083026.26238653@Magellan.Leidinger.net> Cc: current@freebsd.org Subject: Re: Towards a working "wine". [long] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Peter Edwards List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2005 12:06:37 -0000 On 6/18/05, Alexander Leidinger wrote: > On Fri, 17 Jun 2005 17:59:38 -0700 (PDT) > Jon Dama wrote: >=20 > > My intuition says that mmap should ignore requests to map into the > > existing brk region but not reject requests that are merely between the > > existing brk region and the DS limit. >=20 > Have you seen Martin Cracauer's mail ("My hacks to make the memory map > fit") on emulation@ which deals with the memory map? Maybe it's of help > here... No I hadn't seen them, thanks for the reference. These won't help in this case: It's almost the opposite problem. I think. Martin's hack leaves a gap between the data segment and the area that mmap starts looking in for address space. However, because of the format of the wine binary, it's data segment is very high in memory, and the area required by wine's mmap actually falls inside it. i.e., Martins fix pushes out the starting point for mmap searches, but wine needs hit dragged in. Jean-Marc DETREZ posted an interesting patch to emulation@ and wine's patches list around the same time that's more promising, though: "patch for unbreaking wine on freebsd" This uses mincore() + mmap(... MAP_FIXED ...) when mincore returns EFAULT. I'll have a read of it. It looks like both OpenBSD and NetBSD now incorporate a MAP_TRYFIXED, though. And, from a comment on the OpenBSD 3.4 changelog, adding it to the linuxulator may also help compatibility there. From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 12:32: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 4277516A41C for ; Sat, 18 Jun 2005 12:32:15 +0000 (GMT) (envelope-from mike@sentex.net) Received: from smarthost1.sentex.ca (smarthost1.sentex.ca [64.7.153.18]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3ABF43D1F for ; Sat, 18 Jun 2005 12:32:14 +0000 (GMT) (envelope-from mike@sentex.net) Received: from pumice6.sentex.ca (pumice6.sentex.ca [64.7.153.21]) by smarthost1.sentex.ca (8.13.3/8.13.3) with ESMTP id j5ICVoRu072449 for ; Sat, 18 Jun 2005 08:31:50 -0400 (EDT) (envelope-from mike@sentex.net) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by pumice6.sentex.ca (8.13.3/8.13.3) with ESMTP id j5ICWB7C038411; Sat, 18 Jun 2005 08:32:11 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.13.3/8.13.3) with ESMTP id j5ICW3Be090169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jun 2005 08:32:04 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.2.1.2.0.20050618082423.038680d0@64.7.153.2> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Sat, 18 Jun 2005 08:32:33 -0400 To: des@des.no (Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= ) From: Mike Tancsa In-Reply-To: <86hdfwi41r.fsf@xps.des.no> References: <6.2.1.2.0.20050412220212.055c5d48@64.7.153.2> <867jj5wyvf.fsf@xps.des.no> <6.2.1.2.0.20050617141056.03ea3830@64.7.153.2> <86hdfwi41r.fsf@xps.des.no> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-Virus-Scanned: by amavisd-new X-Scanned-By: MIMEDefang 2.51 on 64.7.153.18 X-Scanned-By: MIMEDefang 2.51 on 64.7.153.21 Cc: freebsd-current@freebsd.org Subject: Re: ichwd fixes / patches 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, 18 Jun 2005 12:32:15 -0000 At 02:15 AM 18/06/2005, Dag-Erling Sm=F8rgrav wrote: >Mike Tancsa writes: > > Any chance to commit the patches in the above PR ? I know its not > > ideal, but at least it works where as its currently 100% broken in > > the tree. > >That's the problem: the patch *doesn't* work. I need to sit down with >the docs and painstakingly check everything and figure out why. But it does as long as you add debug.acpi.disabled=3D"sysresource" to=20 loader.conf. I know thats not perfect, but its better than whats there. ---Mike=20 From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 12:46:39 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 3A05816A41C for ; Sat, 18 Jun 2005 12:46:39 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from mail.yazzy.org (mail.yazzy.org [217.8.140.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id EC05443D49 for ; Sat, 18 Jun 2005 12:46:36 +0000 (GMT) (envelope-from lists@yazzy.org) Received: from localhost (unknown [192.168.99.10]) by mail.yazzy.org (Postfix) with SMTP id DA9E239864; Sat, 18 Jun 2005 14:47:07 +0200 (CEST) Date: Sat, 18 Jun 2005 14:46:32 +0200 From: Marcin Jessa To: Thomas Dickey Message-Id: <20050618144632.1c8f1fe7.lists@yazzy.org> In-Reply-To: <20050618105500.GA16565@saltmine.radix.net> References: <20050617214658.GA41804@troutmask.apl.washington.edu> <58826.1119044951@critter.freebsd.dk> <20050617220222.GA42080@troutmask.apl.washington.edu> <20050617220653.GA114@saltmine.radix.net> <20050617221353.GA48584@troutmask.apl.washington.edu> <20050618061603.GM50157@cirb503493.alcatel.com.au> <861x70gjrf.fsf@xps.des.no> <20050618105500.GA16565@saltmine.radix.net> Organization: YazzY.org X-Mailer: Sylpheed version 1.9.12 (GTK+ 2.6.7; i386-portbld-freebsd5.4) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-current@freebsd.org Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 18 Jun 2005 12:46:39 -0000 On Sat, 18 Jun 2005 06:55:01 -0400 Thomas Dickey wrote: > On Sat, Jun 18, 2005 at 10:19:00AM +0200, Dag-Erling Sm=F8rgrav wrote: > > Peter Jeremy writes: > > > It's possible to write a full-screen editor using a fairly minimal set > > > of ANSI sequences (CUP and EL would do, but adding more sequences will > > > help) that is common to cons25 and xterm (and VT100 etc). > >=20 > > I believe VT100 is (in large part) a subset of both cons25 and xterm. >=20 > no - there's a subset of vt100 that overlaps with cons25. > cons25 is not a vt100 emulator. It is possible to code around > this by sticking to the subset. >=20 > Does anyone have a URL to point to the source for mined? > google isn't showing me anything useful. cat /usr/ports/editors/mined/pkg-descr |grep -i http WWW: http://towo.net/mined/ From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 12:53: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 6A2AA16A41C for ; Sat, 18 Jun 2005 12:53:47 +0000 (GMT) (envelope-from bazerka@beardz.net) Received: from beardz.net (host81-153-67-52.range81-153.btcentralplus.com [81.153.67.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9E65243D55 for ; Sat, 18 Jun 2005 12:53:45 +0000 (GMT) (envelope-from bazerka@beardz.net) Received: from [127.0.0.1] ([127.0.0.1]) by localhost with MailEnable ESMTP; Sat, 18 Jun 2005 13:48:48 +0100 Message-ID: <42B41830.4030203@beardz.net> Date: Sat, 18 Jun 2005 13:48:48 +0100 From: Jase Thew User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <20050617214658.GA41804@troutmask.apl.washington.edu> <58826.1119044951@critter.freebsd.dk> <20050617220222.GA42080@troutmask.apl.washington.edu> <20050617220653.GA114@saltmine.radix.net> <20050617221353.GA48584@troutmask.apl.washington.edu> <20050618061603.GM50157@cirb503493.alcatel.com.au> <861x70gjrf.fsf@xps.des.no> <20050618105500.GA16565@saltmine.radix.net> In-Reply-To: <20050618105500.GA16565@saltmine.radix.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 18 Jun 2005 12:53:47 -0000 Thomas Dickey wrote: > > Does anyone have a URL to point to the source for mined? > google isn't showing me anything useful. > http://alxl.info/cgi-bin/cvsweb.cgi/src/bin/mined/ HTH -Jase From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 12:57: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 209E616A41C; Sat, 18 Jun 2005 12:57:12 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 876CD43D1D; Sat, 18 Jun 2005 12:57:11 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id AB9B91E32; Sat, 18 Jun 2005 08:57:02 -0400 (EDT) Received: from billdog.local.linnet.org (dsl-212-74-113-66.access.uk.tiscali.com [212.74.113.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id F349287; Sat, 18 Jun 2005 08:56:58 -0400 (EDT) Received: from lists by billdog.local.linnet.org with local (Exim 4.50 (FreeBSD)) id 1Djcsj-0000DG-AC; Sat, 18 Jun 2005 13:57:05 +0100 Date: Sat, 18 Jun 2005 13:57:05 +0100 From: Brian Candler To: Garance A Drosehn Message-ID: <20050618125705.GA721@uk.tiscali.com> References: <20050617211950.GA41720@troutmask.apl.washington.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="GvXjxJ+pjyke8COw" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@FreeBSD.org, FreeBSD-gnats-submit@freebsd.org, Steve Kargl Subject: Re: bin/80256: /rescue/vi doesn't work without terminal database in /usr 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, 18 Jun 2005 12:57:12 -0000 --GvXjxJ+pjyke8COw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [from freebsd-current] On Sat, Jun 18, 2005 at 12:48:04AM -0400, Garance A Drosehn wrote: > >Yes, I'm aware of PR bin/80256, but that appears to stalled in > >a state of limbo. > > I've also been meaning to do something about that idea of a small > termcap file. I don't remember what the PR says, but someone had a > good idea of generating the minimal termcap file from the standard > one, and putting that in /rescue. I have a few ideas of my own so > the system would automatically pick up that minimal file. Just a > matter of finding the time to test it all... :-) I started that PR. Subsequently there was a short discussion off-list where it turned out that Warner Losh had a compact termcap file which could be committed - it's attached below. However nothing further happened. Anybody care to commit it? I guess some rescue/Makefile magic needs updating to install it in the right place. Regards, Brian. --GvXjxJ+pjyke8COw Content-Type: message/rfc822 Content-Disposition: inline Return-path: Envelope-to: lists@localhost Delivery-date: Sat, 18 Jun 2005 13:54:07 +0100 Received: from brian by billdog.local.linnet.org with local (Exim 4.50 (FreeBSD)) id 1Djcpr-0000CU-4z for lists@localhost; Sat, 18 Jun 2005 13:54:07 +0100 Received: from localhost ([127.0.0.1]) by billdog.local.linnet.org with esmtp (Exim 4.43 (FreeBSD)) id 1DQsxR-0000IW-8v for brian@localhost; Wed, 27 Apr 2005 21:16:29 +0100 Received: from pop3.linnet.org by localhost with POP3 (fetchmail-6.2.5) for brian@localhost (single-drop); Wed, 27 Apr 2005 21:16:29 +0100 (BST) Received: from [212.74.113.145] (helo=cheese.org) by mk-mx-3.b2b.uk.tiscali.com with esmtp (Exim 4.24) id 1DQsWe-000Euh-BY for brian@linnet.org; Wed, 27 Apr 2005 20:48:48 +0100 Received: from majesty.pobox.com ([208.210.124.70]) by cheese.org with esmtp (Exim 4.43 (FreeBSD)) id 1DQsWm-000Nk0-9s for brian@cheese.org; Wed, 27 Apr 2005 20:48:58 +0100 Received: from majesty.pobox.com (localhost [127.0.0.1]) by majesty.pobox.com (Postfix) with ESMTP id 4B03212801F for ; Wed, 27 Apr 2005 15:49:27 -0400 (EDT) Delivered-To: b.candler@pobox.com Received: from harmony.village.org (rover.village.org [168.103.84.182]) by majesty.pobox.com (Postfix) with ESMTP id 2CB7412CB4D for ; Wed, 27 Apr 2005 15:49:25 -0400 (EDT) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j3RJjku8089058; Wed, 27 Apr 2005 13:45:51 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 27 Apr 2005 13:45:46 -0600 (MDT) Message-Id: <20050427.134546.74663528.imp@bsdimp.com> To: B.Candler@pobox.com Cc: simon@freebsd.org, kientzle@freebsd.org Subject: Re: Small termcap file From: Warner Losh In-Reply-To: <20050427193044.GA866@uk.tiscali.com> References: <20050423205209.GH84120@zaphod.nitro.dk> <426AC0A4.4050004@freebsd.org> <20050427193044.GA866@uk.tiscali.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Multipart/Mixed; boundary="--Next_Part(Wed_Apr_27_13:45:46_2005_920)--" Content-Transfer-Encoding: 7bit Resent-From: brian@uk.tiscali.com Resent-Date: Sat, 18 Jun 2005 13:54:07 +0100 Resent-To: lists@localhost Resent-Message-Id: ----Next_Part(Wed_Apr_27_13:45:46_2005_920)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Brian Candler Subject: Small termcap file Date: Wed, 27 Apr 2005 20:30:44 +0100 > On Sat, Apr 23, 2005 at 02:39:48PM -0700, Tim Kientzle wrote: > > I seem to recall that Warner (imp@) has a compact termcap file that he uses > > with embedded projects. That might be suitable here. > > Hello, > > Your name was mentioned in a discussion at PR bin/80256. We need a small > termcap file which can be installed as /rescue/termcap. Do you have > something which might be suitable? > > I reckon it needs at least cons25, ansi, and perhaps xterm (if you are under > X and running tip/cu via a serial cable to the target machine). Yes. I have something suitable. Warner ----Next_Part(Wed_Apr_27_13:45:46_2005_920)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename=termcap vt200|vt220|vt220am|vt200am|dec-vt220|dec-vt200|dec vt200 series with jump scroll:\ :@7=\E[4~:kD=\E[3~:kI=\E[2~:kN=\E[6~:kP=\E[5~:kh=\E[1~:\ :k6=\E[17~:k7=\E[18~:k8=\E[19~:k9=\E[20~:k;=\E[21~:\ :k1=\E[11~:k2=\E[12~:k3=\E[13~:k4=\E[14~:k5=\E[15~:\ :ve=\E[?25h:vi=\E[?25l:k0@:im@:ei@:\ :F1=\E[23~:F2=\E[24~:ic=\E[@:IC=\E[%d@:ec=\E[%dX:tc=vt102: vt100|dec-vt100|vt100-am|vt100am|dec vt100:\ :do=2\E[B:co#80:li#24:cl=50\E[H\E[J:sf=2*\ED:\ :le=^H:bs:am:cm=5\E[%i%d;%dH:nd=2\E[C:up=2\E[A:\ :ce=3\E[K:cd=50\E[J:so=2\E[7m:se=2\E[m:us=2\E[4m:ue=2\E[m:\ :md=2\E[1m:mr=2\E[7m:mb=2\E[5m:me=2\E[m:\ :is=\E>\E[?1;3;4;5l\E[?7;8h\E[1;24r\E[24;1H:\ :if=/usr/share/tabset/vt100:nw=2\EE:ho=\E[H:\ :as=2\E(0:ae=2\E(B:ac=llmmkkjjuuttvvwwqqxxnnpprr``aa:\ :rs=\E>\E[?1;3;4;5l\E[?7;8h:ks=\E[?1h\E=:ke=\E[?1l\E>:\ :ku=\EOA:kd=\EOB:kr=\EOC:kl=\EOD:kb=\177:\ :k0=\EOy:k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:k5=\EOt:\ :k6=\EOu:k7=\EOv:k8=\EOl:k9=\EOw:k;=\EOx:@8=\EOM:\ :K1=\EOq:K2=\EOr:K3=\EOs:K4=\EOp:K5=\EOn:pt:sr=2*\EM:vt#3:xn:\ :sc=2\E7:rc=2\E8:cs=5\E[%i%d;%dr:UP=2\E[%dA:DO=2\E[%dB:RI=2\E[%dC:\ :LE=2\E[%dD:ct=2\E[3g:st=2\EH:ta=^I:ms:bl=^G:cr=^M:eo:it#8:ut:\ :RA=\E[?7l:SA=\E[?7h: vt102|dec-vt102-am|vt102am|vt100 w/adv. video:\ :al=\E[L:dl=\E[M:im=\E[4h:ei=\E[4l:mi:dc=\E[P:\ :AL=\E[%dL:DL=\E[%dM:DC=\E[%dP:tc=vt100-np: vt100-np|dec-vt100-np|vt100 with no padding (for psl games):\ :do=\E[B:cl=\E[H\E[J:sf=\ED:as=\E(0:ae=\E(B:\ :cm=\E[%i%d;%dH:nd=\E[C:up=\E[A:nw=\EE:\ :ce=\E[K:cd=\E[J:so=\E[7m:se=\E[m:us=\E[4m:ue=\E[m:\ :md=\E[1m:mr=\E[7m:mb=\E[5m:me=\E[m:sr=\EM:\ :sc=\E7:rc=\E8:cs=\E[%i%d;%dr:UP=\E[%dA:DO=\E[%dB:RI=\E[%dC:\ :LE=\E[%dD:ct=\E[3g:st=\EH:tc=vt100-am: xterm|vs100|xterm terminal emulator (X window system):\ :li#65:\ :kh=\EOH:@7=\EOF:kb=^H:kD=^?:\ :k1=\EOP:k2=\EOQ:k3=\EOR:k4=\EOS:km:\ :is=\E>\E[?1;3;4;5l\E[?7;8h\E[1;65r\E[65;1H:\ :rs=\E>\E[?1;3;4;5l\E[?7;8h:\ :tc=vt220: xterms|vs100s|xterm terminal emulator (small)(X window system):\ :is=\E>\E[?1;3;4;5l\E[?7;8h\E[1;24r\E[24;1H:\ :li#24:tc=xterm: # for syscons # common entry without semigraphics cons25w|ansiw|ansi80x25-raw:\ :al=\E[L:am:bs:NP:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:co#80:\ :dc=\E[P:dl=\E[M:do=\E[B:bt=\E[Z:ho=\E[H:ic=\E[@:li#25:cb=\E[1K:\ :ms:nd=\E[C:pt:rs=\E[x\E[m\Ec:so=\E[7m:se=\E[m:up=\E[A:\ :pa#64:Co#8:AF=\E[3%dm:AB=\E[4%dm:op=\E[x:sc=\E7:rc=\E8:\ :k1=\E[M:k2=\E[N:k3=\E[O:k4=\E[P:k5=\E[Q:k6=\E[R:k7=\E[S:k8=\E[T:\ :k9=\E[U:k;=\E[V:F1=\E[W:F2=\E[X:K2=\E[E:nw=\E[E:ec=\E[%dX:\ :kb=^H:kh=\E[H:ku=\E[A:kd=\E[B:kl=\E[D:kr=\E[C:le=^H:eo:sf=\E[S:sr=\E[T:\ :kN=\E[G:kP=\E[I:@7=\E[F:kI=\E[L:kD=\177:kB=\E[Z:\ :IC=\E[%d@:DC=\E[%dP:SF=\E[%dS:SR=\E[%dT:AL=\E[%dL:DL=\E[%dM:\ :DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:cv=\E[%i%dd:ch=\E[%i%d`:bw:\ :mb=\E[5m:md=\E[1m:mh=\E[30;1m:mr=\E[7m:me=\E[m:bl=^G:ut:it#8:km: cons25|ansis|ansi80x25:\ :ac=l\332m\300k\277j\331u\264t\303v\301w\302q\304x\263n\305`^Da\260f\370g\361~\371.^Y-^Xh\261I^U0\333y\363z\362:\ :tc=cons25w: dosansi|ANSI.SYS standard crt:\ :am:bs:ce=\E[K:cl=\E[2J:cm=\E[%i%d;%dH:co#80:\ :do=\E[B:li#25:mi:nd=\E[C:\ :se=\E[m:so=\E[7m:up=\E[A:us=\E[4m:ue=\E[m:\ :md=\E[1m:mh=\E[m:mb=\E[5m:me=\E[m:\ :kh=\EG:kb=^h:ku=\EH:kd=\EP:kl=\EK:kr=\EM:\ :k1=\E;:k2=\E<:k3=\E=:k4=\E>:k5=\E?:\ :k6=\E@:k7=\EA:k8=\EB:k9=\EC:k0=\ED: network|dialup|du|dumb|un|unknown:\ :am:co#80:do=^J: ansi|any ansi terminal with pessimistic assumptions:\ :co#80:li#24:cl=50\E[;H\E[2J:bs:am:cm=\E[%i%d;%dH:\ :nd=\E[C:up=\E[A:ce=\E[K:ho=\E[H:pt: ----Next_Part(Wed_Apr_27_13:45:46_2005_920)---- --GvXjxJ+pjyke8COw Content-Type: message/rfc822 Content-Disposition: inline Return-path: Envelope-to: lists@localhost Delivery-date: Sat, 18 Jun 2005 13:54:07 +0100 Received: from brian by billdog.local.linnet.org with local (Exim 4.50 (FreeBSD)) id 1Djcpr-0000CX-6E for lists@localhost; Sat, 18 Jun 2005 13:54:07 +0100 Received: from localhost ([127.0.0.1]) by billdog.local.linnet.org with esmtp (Exim 4.43 (FreeBSD)) id 1DQsxR-0000IW-Fu for brian@localhost; Wed, 27 Apr 2005 21:16:29 +0100 Received: from pop3.linnet.org by localhost with POP3 (fetchmail-6.2.5) for brian@localhost (single-drop); Wed, 27 Apr 2005 21:16:29 +0100 (BST) Received: from [212.74.113.145] (helo=cheese.org) by mk-mx-1.b2b.uk.tiscali.com with esmtp (Exim 4.24) id 1DQsf9-000Bgf-Qi for brian@linnet.org; Wed, 27 Apr 2005 20:57:35 +0100 Received: from gold.pobox.com ([208.210.124.73]) by cheese.org with esmtp (Exim 4.43 (FreeBSD)) id 1DQsfW-000NlM-8f for brian@cheese.org; Wed, 27 Apr 2005 20:57:58 +0100 Received: from gold.pobox.com (localhost [127.0.0.1]) by gold.pobox.com (Postfix) with ESMTP id C3A94724D6 for ; Wed, 27 Apr 2005 15:57:32 -0400 (EDT) Delivered-To: b.candler@pobox.com Received: from harmony.village.org (rover.village.org [168.103.84.182]) by gold.pobox.com (Postfix) with ESMTP id 87F0C724EE for ; Wed, 27 Apr 2005 15:57:32 -0400 (EDT) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j3RJtX3c089133; Wed, 27 Apr 2005 13:55:33 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Wed, 27 Apr 2005 13:55:33 -0600 (MDT) Message-Id: <20050427.135533.85323427.imp@bsdimp.com> To: B.Candler@pobox.com Cc: simon@freebsd.org, kientzle@freebsd.org Subject: Re: Small termcap file From: Warner Losh In-Reply-To: <20050427193044.GA866@uk.tiscali.com> References: <20050423205209.GH84120@zaphod.nitro.dk> <426AC0A4.4050004@freebsd.org> <20050427193044.GA866@uk.tiscali.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Resent-From: brian@uk.tiscali.com Resent-Date: Sat, 18 Jun 2005 13:54:07 +0100 Resent-To: lists@localhost Resent-Message-Id: From: Brian Candler Subject: Small termcap file Date: Wed, 27 Apr 2005 20:30:44 +0100 > On Sat, Apr 23, 2005 at 02:39:48PM -0700, Tim Kientzle wrote: > > I seem to recall that Warner (imp@) has a compact termcap file that he uses > > with embedded projects. That might be suitable here. > > Hello, > > Your name was mentioned in a discussion at PR bin/80256. We need a small > termcap file which can be installed as /rescue/termcap. Do you have > something which might be suitable? > > I reckon it needs at least cons25, ansi, and perhaps xterm (if you are under > X and running tip/cu via a serial cable to the target machine). BTW, the one I gave you also has vt200/vt100/vt102 and friends in it because those are very popular emulations. xterm for when you're logged into the serial port via an X terminal, and cons25* for the console. Oh, and dosansi and ansi for the brave. I think it is a reasonable thing to install. It is only 3k. There's a /etc/termcap.small also which is just under 8k which also wouldn't be bad. Warner --GvXjxJ+pjyke8COw-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 13:02: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 01A4816A41C for ; Sat, 18 Jun 2005 13:02:17 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb.pobox.com (orb.pobox.com [207.8.226.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id C4DF943D55 for ; Sat, 18 Jun 2005 13:02:16 +0000 (GMT) (envelope-from discussion-lists@linnet.org) Received: from orb (localhost [127.0.0.1]) by orb.pobox.com (Postfix) with ESMTP id 4B47F1E32; Sat, 18 Jun 2005 09:02:08 -0400 (EDT) Received: from billdog.local.linnet.org (dsl-212-74-113-66.access.uk.tiscali.com [212.74.113.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by orb.sasl.smtp.pobox.com (Postfix) with ESMTP id E113287; Sat, 18 Jun 2005 09:02:05 -0400 (EDT) Received: from lists by billdog.local.linnet.org with local (Exim 4.50 (FreeBSD)) id 1Djcxg-0000Di-ND; Sat, 18 Jun 2005 14:02:12 +0100 Date: Sat, 18 Jun 2005 14:02:12 +0100 From: Brian Candler To: Tarc Message-ID: <20050618130212.GB721@uk.tiscali.com> References: <20050617180321.GA1131@tarc.po.cs.msu.su> <867jgskfvd.fsf@xps.des.no> <20050618105622.GA723@tarc.po.cs.msu.su> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050618105622.GA723@tarc.po.cs.msu.su> User-Agent: Mutt/1.4.2.1i Cc: Dag-Erling Sm?rgrav , freebsd-current Subject: Re: -CURRENT crashes on compilling 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, 18 Jun 2005 13:02:17 -0000 On Sat, Jun 18, 2005 at 02:56:22PM +0400, Tarc wrote: > On Fri, Jun 17, 2005 at 08:17:10PM +0200, Dag-Erling Sm?rgrav wrote: > > Tarc writes: > > > I change my old computer to a new one (see dmesgs links below) and > > > my computer begins to crash anywhere(cc1, sh, awk, ...) with (mainly > > > page fault) very often. > > > > Bad hardware - most likely bad RAM, possibly a bad CPU. > > > > DES > > -- > > Dag-Erling Sm?rgrav - des@des.no > > > > _______________________________________________ > > 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" > Hmm... I thinked about this, but RAM is ok. > How test processor? Doing a FreeBSD buildworld is a very good way to test your system :-) You'll find a much more detailled description of the possible problems and solutions in the SIG 11 FAQ, which you can find here: http://www.bitwizard.nl/sig11/ Since the individual components of your system interact with each other in so many ways, if the problem is actually a faulty component, usually the best approach is to swap components one at a time from another (working) system. But it could be that you have BIOS settings wrong for CPU clock or RAM timing etc. Regards, Brian. From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 15:05: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 1CFD816A41C for ; Sat, 18 Jun 2005 15:05:02 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (tim.des.no [194.63.250.121]) by mx1.FreeBSD.org (Postfix) with ESMTP id C753D43D1D for ; Sat, 18 Jun 2005 15:05:01 +0000 (GMT) (envelope-from des@des.no) Received: from tim.des.no (localhost [127.0.0.1]) by spam.des.no (Postfix) with ESMTP id 89BB260F3; Sat, 18 Jun 2005 17:04:47 +0200 (CEST) Received: from xps.des.no (des.no [80.203.228.37]) by tim.des.no (Postfix) with ESMTP id 1DF7260F2; Sat, 18 Jun 2005 17:04:47 +0200 (CEST) Received: by xps.des.no (Postfix, from userid 1001) id 00C8533C23; Sat, 18 Jun 2005 17:04:46 +0200 (CEST) To: Tarc References: <20050617180321.GA1131@tarc.po.cs.msu.su> <867jgskfvd.fsf@xps.des.no> <20050618105622.GA723@tarc.po.cs.msu.su> From: des@des.no (=?iso-8859-1?q?Dag-Erling_Sm=F8rgrav?=) Date: Sat, 18 Jun 2005 17:04:46 +0200 In-Reply-To: <20050618105622.GA723@tarc.po.cs.msu.su> (tarc@tarc.po.cs.msu.su's message of "Sat, 18 Jun 2005 14:56:22 +0400") Message-ID: <86k6krg0z5.fsf@xps.des.no> User-Agent: Gnus/5.110002 (No Gnus v0.2) Emacs/21.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Learn: ham X-Spam-Score: -5.2/5.0 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on tim.des.no Cc: freebsd-current Subject: Re: -CURRENT crashes on compilling 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, 18 Jun 2005 15:05:02 -0000 Tarc writes: > On Fri, Jun 17, 2005 at 08:17:10PM +0200, Dag-Erling Sm=D0=ACrgrav wrote: > > Bad hardware - most likely bad RAM, possibly a bad CPU. > Hmm... I thinked about this, but RAM is ok. How do you know? Most software memory testers don't load the system enough to trip over marginal RAM; 'make buildworld' does. > How test processor? 'make buildworld' with known-good RAM is a pretty good indicator. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 15:26:44 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 72D4016A41C; Sat, 18 Jun 2005 15:26:44 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from www.portaone.com (web.portaone.com [195.70.151.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id DC07643D4C; Sat, 18 Jun 2005 15:26:43 +0000 (GMT) (envelope-from sobomax@portaone.com) Received: from [192.168.0.49] (lesnik.portaone.com [195.140.246.50]) (authenticated bits=0) by www.portaone.com (8.12.11/8.12.11) with ESMTP id j5IFQdlI046187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Jun 2005 17:26:40 +0200 (CEST) (envelope-from sobomax@portaone.com) Message-ID: <42B43D2B.2060900@portaone.com> Date: Sat, 18 Jun 2005 18:26:35 +0300 From: Maxim Sobolev Organization: Porta Software Ltd User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Edwards References: <20050617180232.GA25818@freefall.freebsd.org> <42B31247.9010603@portaone.com> <34cb7c840506171121cd0437f@mail.gmail.com> <42B3189E.6030408@portaone.com> <34cb7c8405061716327ca4c6d7@mail.gmail.com> In-Reply-To: <34cb7c8405061716327ca4c6d7@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.83/945/Sat Jun 18 11:51:33 2005 on www.portaone.com X-Virus-Status: Clean Cc: Peter Edwards , current@freebsd.org Subject: Re: Towards a working "wine". [long] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Maxim.Sobolev@portaone.com List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2005 15:26:44 -0000 Then at least manpage should be fixed to match actual behaviour I think. -Maxim Peter Edwards wrote: >>>>... wine can call mmap(2) with MAP_FIXED and then if that fails try to >>>>call mmap(2) without it and deal with consequences. This will provide >>>>the same functionality but you won't get dependency on particular >>>>FreeBSD version to get MAP_TRYFIXED define. >>>> >>> >>> >>>Nope: MAP_FIXED will unconditionally overwrite any existing mapping at >>>the requested address. >> >>Hmm, the manpage doesn't mention anything of the effect. It only says: >> >>MAP_FIXED Do not permit the system to select a different address >> than the one specified. If the specified address can- >> not be used, mmap() will fail. If MAP_FIXED is speci- >> fied, addr must be a multiple of the pagesize. Use of >> this option is discouraged. >> >>Nothing about "overwriting any existing mapping". So that maybe >>implementation should be adjusted to match documentation, not another >>functionality be invented to workaround misbehaving implementation? > > > Well, It's definitely behaved that way "traditionally" (where > traditionally means on any platform I've had to use mmap() on), and > the manpage is less than specific about what "cannot be used" means. > SUSv3 has this to say: > > >>If a MAP_FIXED request is successful, the mapping established by mmap() >>replaces any previous mappings for the process' pages in the range >>[pa,pa+len). > > > Again, it's very hazy, but it at least explicitly mentions that > MAP_FIXED may replace previous mappings. > > Really, MAP_TRYFIXED is just a hack to avoid the trouble the kernel > goes to in an effort to avoid mmap() and sbrk() from stomping on > eachother. It doesn't matter in Linux because sbrk() has much less > effect on things. (It's not a sytem call) I'd imagine it better to add > an explicit flag for this corner case than to change the behaviour of > existing applications. Apps using MAP_FIXED already are likely to be > quite sensitive to such a change. > > > From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 15:35: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 B4DA916A41C for ; Sat, 18 Jun 2005 15:35:51 +0000 (GMT) (envelope-from dhawkins@tamu.edu) Received: from aspen.ne.tamu.edu (aspen.ne.tamu.edu [165.91.242.172]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8B1E743D48 for ; Sat, 18 Jun 2005 15:35:51 +0000 (GMT) (envelope-from dhawkins@tamu.edu) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Sat, 18 Jun 2005 10:35:59 -0500 Message-ID: <1B77CE3519729C4F86F409F0F3B43A0E069EE6@aspen.ne.tamu.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ichwd fixes / patches Thread-Index: AcVzzUar7aHbK2wqR/C8rK0u8/Bs5AATbyqQ From: "Wm. Daryl Hawkins" To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= Cc: freebsd-current@freebsd.org, Mike Tancsa Subject: RE: ichwd fixes / patches 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, 18 Jun 2005 15:35:51 -0000 Can you give me an idea of what doesn't work with the patches? They've = worked on every system I've tested them on (with the exception of = ICH6... and I don't expect them to work there), but I only have a = limited number of systems to test with. It's definitely something I'll = get fixed if they are broken. Thanks, Daryl > -----Original Message----- > From: owner-freebsd-current@freebsd.org=20 > [mailto:owner-freebsd-current@freebsd.org] On Behalf Of=20 > Dag-Erling Sm=F8rgrav > Sent: Saturday, June 18, 2005 1:15 AM > To: Mike Tancsa > Cc: freebsd-current@freebsd.org > Subject: Re: ichwd fixes / patches >=20 > Mike Tancsa writes: > > Any chance to commit the patches in the above PR ? I know its not > > ideal, but at least it works where as its currently 100% broken in > > the tree. >=20 > That's the problem: the patch *doesn't* work. I need to sit down with > the docs and painstakingly check everything and figure out why. >=20 > > As to the issue of the ICH6 stuff, looking through the=20 > LINUX lists, it > > seems a lot of ICH6 MBs dont actually hookup the onboard=20 > watchdog for > > some reason. >=20 > I know. The ichwd driver has logic to detect that. >=20 > DES > --=20 > Dag-Erling Sm=F8rgrav - des@des.no >=20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to=20 > "freebsd-current-unsubscribe@freebsd.org" >=20 From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 15:56: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 9FDF816A41C for ; Sat, 18 Jun 2005 15:56:30 +0000 (GMT) (envelope-from caelian@gmail.com) Received: from zproxy.gmail.com (zproxy.gmail.com [64.233.162.199]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D78D43D48 for ; Sat, 18 Jun 2005 15:56:30 +0000 (GMT) (envelope-from caelian@gmail.com) Received: by zproxy.gmail.com with SMTP id 9so171928nzo for ; Sat, 18 Jun 2005 08:56:24 -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=r+jcfJSv1mffg6hukWSWIbGvzhnGP0Yg5nDa2jZeFdzSkgKLmdUBIAmsU7qs6kSfq78BeV+O9sIfiuIg/ogALrw6a/IlzLqtghcVCvP5EUUPw+y1ilXJ1qTFPDV+gjmpNwxwL3gLZ2GuXxYOe4ybvnHTaNvYkQ7U1pwk+jis5bU= Received: by 10.36.84.4 with SMTP id h4mr2060665nzb; Sat, 18 Jun 2005 08:56:24 -0700 (PDT) Received: by 10.36.42.19 with HTTP; Sat, 18 Jun 2005 08:56:24 -0700 (PDT) Message-ID: Date: Sat, 18 Jun 2005 08:56:24 -0700 From: Pascal Hofstee To: Rainer Hungershausen In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: Cc: freebsd-current@freebsd.org Subject: Re: if_ral + wpa_supplicant stack backtrace X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Pascal Hofstee List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2005 15:56:30 -0000 Hi, I am seeing period occurances of the same system call with the same WITNESS warning and similar backtrace on yesterday's AMD64 CURRENT. ---------------------- ral0: link state changed to DOWN malloc(M_WAITOK) of "32", forcing M_NOWAIT with the following non-sleepable locks held: exclusive sleep mutex ral0 (network driver) r =3D 0 (0xffffffff80c64de8) locked @ /usr/src/sys/dev/ral/if_ral.c:2167 KDB: stack backtrace: kdb_backtrace() at kdb_backtrace+0x37 witness_warn() at witness_warn+0x2c1 uma_zalloc_arg() at uma_zalloc_arg+0x69 malloc() at malloc+0xf5 ieee80211_ioctl_setoptie() at ieee80211_ioctl_setoptie+0x4b ieee80211_ioctl_set80211() at ieee80211_ioctl_set80211+0x64e ieee80211_ioctl() at ieee80211_ioctl+0x125 ral_ioctl() at ral_ioctl+0xa4 in_control() at in_control+0xc2f ifioctl() at ifioctl+0x1f6 soo_ioctl() at soo_ioctl+0x38c ioctl() at ioctl+0x476 syscall() at syscall+0x332 Xfast_syscall() at Xfast_syscall+0xa8 --- syscall (54, FreeBSD ELF64, ioctl), rip =3D 0x8007c2d4c, rsp =3D 0x7fffffffdfd8, rbp =3D 0x18 --- ral0: link state changed to UP ---------------------- I am indeed curious to understand what exactly is causing these WITNESS war= nings Regards, Pascal Hofstee From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 16:01: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 3C58C16A41C for ; Sat, 18 Jun 2005 16:01:36 +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 02B1143D1D for ; Sat, 18 Jun 2005 16:01:35 +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.4/8.13.4) with ESMTP id j5IG1Pn1055527; Sat, 18 Jun 2005 09:01:25 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j5IG1Grn055526; Sat, 18 Jun 2005 09:01:16 -0700 (PDT) (envelope-from sgk) Date: Sat, 18 Jun 2005 09:01:16 -0700 From: Steve Kargl To: Peter Jeremy Message-ID: <20050618160116.GA55448@troutmask.apl.washington.edu> References: <20050617214658.GA41804@troutmask.apl.washington.edu> <58826.1119044951@critter.freebsd.dk> <20050617220222.GA42080@troutmask.apl.washington.edu> <20050617220653.GA114@saltmine.radix.net> <20050617221353.GA48584@troutmask.apl.washington.edu> <20050618061603.GM50157@cirb503493.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050618061603.GM50157@cirb503493.alcatel.com.au> User-Agent: Mutt/1.4.2.1i Cc: freebsd-current@freebsd.org, Thomas Dickey Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 18 Jun 2005 16:01:36 -0000 On Sat, Jun 18, 2005 at 04:16:04PM +1000, Peter Jeremy wrote: > > > >-r-xr-xr-x 129 root wheel 3669272 Jun 17 15:09 /rescue/ee* > >-r-xr-xr-x 1 root wheel 3564216 Jun 17 14:50 /rescue/mined* > >-r-xr-xr-x 2 root wheel 3940176 Jun 16 15:56 /rescue/vi* > > Exactly what are you comparing here? /rescue/ee, /rescue/mined, and /rescue/vi. > Are these all crunched binaries built identically except > for the embedded editor? Sigh, of course! > If you're looking for ways to save space in /rescue, there are other > low-hanging fruit before you start moving to yet another editor: It's not just space. mined is a small, completely, self-contained editor that is SUFFICIENT for system recovery. It has the nice feature that F1 will print every key binding action on an 80x25 screen. > - It's difficult to justify both sh and [t]csh. > - echo (which is builtin both sh and [t]csh) > - test (which is builtin to sh) > - clri (which is builtin to fsdb) > - routed, rtquery, rtsol (recovering a hosed system shouldn't need a > routing daemon - a static route to the backup server should do) Go for it. Delete the above and submit a patch. I'll enjoy the ensuing religious war over sh and csh. > - pax (when the new libarchive tar is available) This is the freebsd-current mailing list. > - id (there's no 'su' so how can I be anything other than root?) Look at the Makefile. > >This is an editor meant for recovering a system. It's not > >a full blown kitchen sink. > > I don't think anyone is suggesting that we include emacs in /rescue :-) The crunched /rescue/vi is 360 kB larger than the crunched /rescue/mined. It may not be THE kitcken sink of editors, but it is certainly overkill for system recovery. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 16:04: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 D409516A41C for ; Sat, 18 Jun 2005 16:04:19 +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 B142843D4C for ; Sat, 18 Jun 2005 16:04:19 +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.4/8.13.4) with ESMTP id j5IG4Ere055552; Sat, 18 Jun 2005 09:04:14 -0700 (PDT) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.13.4/8.13.1/Submit) id j5IG4EWm055551; Sat, 18 Jun 2005 09:04:14 -0700 (PDT) (envelope-from sgk) Date: Sat, 18 Jun 2005 09:04:14 -0700 From: Steve Kargl To: Thomas Dickey Message-ID: <20050618160414.GB55448@troutmask.apl.washington.edu> References: <20050617214658.GA41804@troutmask.apl.washington.edu> <58826.1119044951@critter.freebsd.dk> <20050617220222.GA42080@troutmask.apl.washington.edu> <20050617220653.GA114@saltmine.radix.net> <20050617221353.GA48584@troutmask.apl.washington.edu> <20050618061603.GM50157@cirb503493.alcatel.com.au> <861x70gjrf.fsf@xps.des.no> <20050618105500.GA16565@saltmine.radix.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050618105500.GA16565@saltmine.radix.net> User-Agent: Mutt/1.4.2.1i Cc: Dag-Erling Sm?rgrav , freebsd-current@freebsd.org Subject: Re: Replace /rescue/vi with mined(1) from DragonFlyBSD 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, 18 Jun 2005 16:04:19 -0000 On Sat, Jun 18, 2005 at 06:55:01AM -0400, Thomas Dickey wrote: > On Sat, Jun 18, 2005 at 10:19:00AM +0200, Dag-Erling Sm?rgrav wrote: > > Peter Jeremy writes: > > > It's possible to write a full-screen editor using a fairly minimal set > > > of ANSI sequences (CUP and EL would do, but adding more sequences will > > > help) that is common to cons25 and xterm (and VT100 etc). > > > > I believe VT100 is (in large part) a subset of both cons25 and xterm. > > no - there's a subset of vt100 that overlaps with cons25. > cons25 is not a vt100 emulator. It is possible to code around > this by sticking to the subset. > > Does anyone have a URL to point to the source for mined? > google isn't showing me anything useful. > The version that I am using and is the topic of my post comes from www.dragonflybsd.org. You can browse the source in their cvs respository. -- Steve From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 16:20: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 3A04416A41C for ; Sat, 18 Jun 2005 16:20:52 +0000 (GMT) (envelope-from michael@weiser.dinsnail.net) Received: from heinz.dinsnail.net (p15110767.pureserver.info [217.160.166.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id A822243D1D for ; Sat, 18 Jun 2005 16:20:50 +0000 (GMT) (envelope-from michael@weiser.dinsnail.net) Received: from heinz.dinsnail.net (heinz.dinsnail.net [127.0.0.1]) by heinz.dinsnail.net (8.13.4/8.13.4) with ESMTP id j5IGKgIr025935 for ; Sat, 18 Jun 2005 18:20:42 +0200 Received: from khazad-dum.weiser.dinsnail.net (uucp@localhost) by heinz.dinsnail.net (8.13.4/8.13.4/Submit) with bsmtp id j5IGKgxG025934 for freebsd-current@freebsd.org; Sat, 18 Jun 2005 18:20:42 +0200 Received: from khazad-dum.weiser.dinsnail.net (localhost [127.0.0.1]) by khazad-dum.weiser.dinsnail.net (8.13.4/8.13.4) with ESMTP id j5IGHjhO001050 for ; Sat, 18 Jun 2005 18:17:45 +0200 (CEST) (envelope-from michael@khazad-dum.weiser.dinsnail.net) Received: (from michael@localhost) by khazad-dum.weiser.dinsnail.net (8.13.4/8.13.4/Submit) id j5IGHiYq001049 for freebsd-current@freebsd.org; Sat, 18 Jun 2005 18:17:44 +0200 (CEST) (envelope-from michael) Date: Sat, 18 Jun 2005 18:17:44 +0200 From: Michael Weiser To: freebsd-current@freebsd.org Message-ID: <20050618161744.GA993@weiser.dinsnail.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.4.2.1i X-MailScanner: Found to be clean X-MailScanner-From: michael@weiser.dinsnail.net Subject: ata explicit idle/standby 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, 18 Jun 2005 16:20:52 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, I've done a small patch to the -CURRENT atacontrol and ata driver to allow explicit switch of drives to idle or standby mode and query the current mode. I use it to spin down disks needed only very inregularly. If extended by a means to set the idle timeout this might be particularly useful to notebook users as well. Or have I actually missed the some already present functionality to achieve the same? -- Cheers, Micha --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="ata-sleep.patch" --- sys/dev/ata/ata-all.c.orig Tue Jun 7 17:33:23 2005 +++ sys/dev/ata/ata-all.c Sat Jun 18 17:12:48 2005 @@ -493,6 +493,38 @@ case IOCATAGMODE: *mode = atadev->mode; return 0; + + case IOCATASTANDBY: + if (atadev->param.support.command2 & ATA_SUPPORT_FLUSHCACHE) + ata_controlcmd(dev, ATA_FLUSHCACHE, 0, 0, 0); + + ata_controlcmd(dev, ATA_STANDBY_IMMEDIATE, 0, 0, 0); + return 0; + + case IOCATAIDLE: + if (atadev->param.support.command2 & ATA_SUPPORT_FLUSHCACHE) + ata_controlcmd(dev, ATA_FLUSHCACHE, 0, 0, 0); + + ata_controlcmd(dev, ATA_IDLE_IMMEDIATE, 0, 0, 0); + return 0; + + case IOCATACHECKPWRMODE: + if (!(request = ata_alloc_request())) + return ENOMEM; + + request->dev = dev; + request->u.ata.command = ATA_CHECK_PWR_MODE; + request->u.ata.lba = 0; + request->u.ata.count = 0; + request->u.ata.feature = 0; + request->flags = ATA_R_CONTROL; + request->timeout = 1; + request->retries = 0; + ata_queue_request(request); + *mode = request->u.ata.count; + ata_free_request(request); + return 0; + default: return ENOTTY; } --- sbin/atacontrol/atacontrol.c.orig Tue Jun 7 17:27:41 2005 +++ sbin/atacontrol/atacontrol.c Sat Jun 18 17:10:47 2005 @@ -109,6 +109,9 @@ " atacontrol status array\n" " atacontrol mode device [mode]\n" " atacontrol cap device\n" + " atacontrol pwrstatus device\n" + " atacontrol standby device\n" + " atacontrol idle device\n" ); exit(EX_USAGE); } @@ -337,6 +340,77 @@ if ((fd = open(device, O_RDONLY)) < 0) err(1, "device not found"); ata_cap_print(fd); + exit(EX_OK); + } + if (!strcmp(argv[1], "idle") && argc == 3) { + int disk; + char device[64]; + + if (!(sscanf(argv[2], "ad%d", &disk) == 1 || + sscanf(argv[2], "acd%d", &disk) == 1 || + sscanf(argv[2], "afd%d", &disk) == 1 || + sscanf(argv[2], "ast%d", &disk) == 1)) { + fprintf(stderr, "atacontrol: Invalid device %s\n", + argv[2]); + exit(EX_USAGE); + } + sprintf(device, "/dev/%s", argv[2]); + if ((fd = open(device, O_RDONLY)) < 0) + err(1, "device not found"); + if (ioctl(fd, IOCATAIDLE, &disk) < 0) + err(1, "ioctl(ATAIDLE)"); + exit(EX_OK); + } + if (!strcmp(argv[1], "standby") && argc == 3) { + int disk; + char device[64]; + + if (!(sscanf(argv[2], "ad%d", &disk) == 1 || + sscanf(argv[2], "acd%d", &disk) == 1 || + sscanf(argv[2], "afd%d", &disk) == 1 || + sscanf(argv[2], "ast%d", &disk) == 1)) { + fprintf(stderr, "atacontrol: Invalid device %s\n", + argv[2]); + exit(EX_USAGE); + } + sprintf(device, "/dev/%s", argv[2]); + if ((fd = open(device, O_RDONLY)) < 0) + err(1, "device not found"); + if (ioctl(fd, IOCATASTANDBY, &disk) < 0) + err(1, "ioctl(ATASTANDBY)"); + exit(EX_OK); + } + if (!strcmp(argv[1], "pwrstatus") && argc == 3) { + int disk; + char device[64]; + + if (!(sscanf(argv[2], "ad%d", &disk) == 1 || + sscanf(argv[2], "acd%d", &disk) == 1 || + sscanf(argv[2], "afd%d", &disk) == 1 || + sscanf(argv[2], "ast%d", &disk) == 1)) { + fprintf(stderr, "atacontrol: Invalid device %s\n", + argv[2]); + exit(EX_USAGE); + } + sprintf(device, "/dev/%s", argv[2]); + if ((fd = open(device, O_RDONLY)) < 0) + err(1, "device not found"); + if (ioctl(fd, IOCATACHECKPWRMODE, &disk) < 0) + err(1, "ioctl(ATACHECKPWRMODE)"); + switch (disk) { + case 0x00: + printf("device is in standby mode\n"); + break; + case 0x80: + printf("device is in idle mode\n"); + break; + case 0xff: + printf("device is in active or idle mode\n"); + break; + default: + printf("unknown mode\n"); + break; + } exit(EX_OK); } --- sys/sys/ata.h.orig Tue Jun 7 17:42:52 2005 +++ sys/sys/ata.h Sat Jun 18 18:01:30 2005 @@ -252,6 +252,7 @@ #define ATA_STANDBY_CMD 0xe2 /* standby */ #define ATA_IDLE_CMD 0xe3 /* idle */ #define ATA_READ_BUFFER 0xe4 /* read buffer */ +#define ATA_CHECK_PWR_MODE 0xe5 /* check power mode */ #define ATA_SLEEP 0xe6 /* sleep */ #define ATA_FLUSHCACHE 0xe7 /* flush cache to disk */ #define ATA_FLUSHCACHE48 0xea /* flush cache to disk */ @@ -372,6 +373,9 @@ #define IOCATAGPARM _IOR('a', 101, struct ata_params) #define IOCATAGMODE _IOR('a', 102, int) #define IOCATASMODE _IOW('a', 103, int) +#define IOCATAIDLE _IOW('a', 131, int) +#define IOCATASTANDBY _IOW('a', 132, int) +#define IOCATACHECKPWRMODE _IOR('a', 133, int) struct ata_ioc_raid_config { --qDbXVdCdHGoSgWSk-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 16:42: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 D8C0116A41C; Sat, 18 Jun 2005 16:42:53 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from smtp2.server.rpi.edu (smtp2.server.rpi.edu [128.113.2.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 9BEB943D1F; Sat, 18 Jun 2005 16:42:53 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp2.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j5IGgqha002023; Sat, 18 Jun 2005 12:42:52 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20050618125705.GA721@uk.tiscali.com> References: <20050617211950.GA41720@troutmask.apl.washington.edu> <20050618125705.GA721@uk.tiscali.com> Date: Sat, 18 Jun 2005 12:42:51 -0400 To: Brian Candler From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.2 Cc: freebsd-current@FreeBSD.org, FreeBSD-gnats-submit@FreeBSD.org Subject: Re: bin/80256: /rescue/vi doesn't work without terminal database in /usr 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, 18 Jun 2005 16:42:54 -0000 At 1:57 PM +0100 6/18/05, Brian Candler wrote: >[from freebsd-current] >On Sat, Jun 18, 2005 at 12:48:04AM -0400, Garance A Drosehn wrote: >> >Yes, I'm aware of PR bin/80256, but that appears to stalled in >> >a state of limbo. >> >> I've also been meaning to do something about that idea of a small >> termcap file. I don't remember what the PR says, but someone had a >> good idea of generating the minimal termcap file from the standard >> one, and putting that in /rescue. I have a few ideas of my own so >> the system would automatically pick up that minimal file. Just a >> matter of finding the time to test it all... :-) > >I started that PR. Subsequently there was a short discussion off-list >where it turned out that Warner Losh had a compact termcap file >which could be committed - it's attached below. However nothing >further happened. I am aware of Warner's termcap file, and I had talked with him earlier this year about committing something along those lines. I forget if I was going to commit his exact termcap file, or some auto-generated alternative, but I do have the emails around here somewhere. I know that *at the time* I knew what I had planned to do, and that Warner had nodded in general agreement to whatever that was... Right now I am busy finishing off some changes to `env', which will fix some problems introduced by a different change that I made earlier this year. Once I have those changes sorted out, I'll go back and look at my emails on this termcap idea. (Unless, of course, anyone else wants to do it before I get to it!) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 16:53: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 31D5B16A41C for ; Sat, 18 Jun 2005 16:53:38 +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 8537243D1F for ; Sat, 18 Jun 2005 16:53:35 +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.13.4/8.13.4) with ESMTP id j5IGr7Hx044269; Sun, 19 Jun 2005 02:23:28 +0930 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" To: freebsd-current@freebsd.org Date: Sun, 19 Jun 2005 02:22:41 +0930 User-Agent: KMail/1.8 References: <20050618161744.GA993@weiser.dinsnail.net> In-Reply-To: <20050618161744.GA993@weiser.dinsnail.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2234823.hKex3ltprg"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506190222.42111.doconnor@gsoft.com.au> X-Spam-Score: -2.4 () ALL_TRUSTED X-Scanned-By: MIMEDefang 2.51 on 203.31.81.10 Cc: Michael Weiser Subject: Re: ata explicit idle/standby 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, 18 Jun 2005 16:53:38 -0000 --nextPart2234823.hKex3ltprg Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Sun, 19 Jun 2005 01:47, Michael Weiser wrote: > I've done a small patch to the -CURRENT atacontrol and ata driver to > allow explicit switch of drives to idle or standby mode and query the > current mode. I use it to spin down disks needed only very inregularly. > If extended by a means to set the idle timeout this might be > particularly useful to notebook users as well. Yes..=20 Combine with=20 http://lists.freebsd.org/pipermail/freebsd-mobile/2003-May/000681.html to=20 allow you to turn the drive off for a reasonable amount of time :) (That diff doesn't apply directly but it's trivial to apply by hand) > Or have I actually missed the some already present functionality to > achieve the same? There is a port (ataidle) which does this but I think having it in atacontr= ol=20 is a good idea. =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 --nextPart2234823.hKex3ltprg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (FreeBSD) iD8DBQBCtFFa5ZPcIHs/zowRAshFAJ9tjim2Ebau52kaTlREuBPyKJ8ygACdEO71 D/zIXdbHh/wuvKdFp2loYrw= =dn3F -----END PGP SIGNATURE----- --nextPart2234823.hKex3ltprg-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 17:12: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 F15DC16A41C for ; Sat, 18 Jun 2005 17:12:41 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 545E643D49 for ; Sat, 18 Jun 2005 17:12:40 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: (qmail 5366 invoked by uid 207); 18 Jun 2005 17:12:38 -0000 Received: from keramida@freebsd.org by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.19/3.81. Clear:RC:1(81.186.70.232):. Processed in 1.664648 secs); 18 Jun 2005 17:12:38 -0000 Received: from dialup232.ach.sch.gr (HELO gothmog.gr) ([81.186.70.232]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Jun 2005 17:12:35 -0000 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.4/8.13.4) with ESMTP id j5IHCNs9000866 for ; Sat, 18 Jun 2005 20:12:23 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.4/8.13.4/Submit) id j5IHCNvu000848 for freebsd-current@freebsd.org; Sat, 18 Jun 2005 20:12:23 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sat, 18 Jun 2005 20:12:16 +0300 From: Giorgos Keramidas To: freebsd-current@freebsd.org Message-ID: <20050618171216.GA661@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-7 Content-Disposition: inline Content-Transfer-Encoding: 8bit Subject: panics with today'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: Sat, 18 Jun 2005 17:12:42 -0000 Today's current panics whenever I try to build mail/procmail a little after the following appears on the screen: Jun 18 19:50:13 gothmog kernel: Acquiring lockmgr lock "ufs" with the following non-sleepable locks held: Jun 18 19:50:13 gothmog kernel: exclusive sleep mutex vnode pollinfo r = 0 (0xc1ebc000) locked @ /usr/src/sys/kern/kern_event.c:881 Jun 18 19:50:13 gothmog kernel: KDB: stack backtrace: Jun 18 19:50:13 gothmog kernel: kdb_backtrace(1,3001,c1e75c2c,c1bcb300,da92fa5c) at kdb_backtrace+0x29 Jun 18 19:50:13 gothmog kernel: witness_warn(5,c074cb78,c06cdc34,c06d670a) at witness_warn+0x18e Jun 18 19:50:13 gothmog kernel: lockmgr(c1e75c08,3001,c1e75c2c,c1bcb300,da92fa88) at lockmgr+0x8d Jun 18 19:50:13 gothmog kernel: vop_stdlock(da92facc,c07327a0,da92facc,da92fa98,c063eaf4) at vop_stdlock+0x1e Jun 18 19:50:13 gothmog kernel: VOP_LOCK_APV(c0732ce0,da92facc,da92faac,c06a7eb3,da92facc) at VOP_LOCK_APV+0x87 Jun 18 19:50:13 gothmog kernel: ffs_lock(da92facc,1001,c1e75bb0,da92fae8,c059a4cc) at ffs_lock+0x10 Jun 18 19:50:13 gothmog kernel: VOP_LOCK_APV(c07327a0,da92facc) at VOP_LOCK_APV+0x87 Jun 18 19:50:13 gothmog kernel: vn_lock(c1e75bb0,1001,c1bcb300) at vn_lock+0xa8 Jun 18 19:50:13 gothmog kernel: filt_vfsread(c1d2f4c8,0,0,ffffffff,0) at filt_vfsread+0x3a Jun 18 19:50:13 gothmog kernel: kqueue_register(c1e12c00,da92fbf4,c1bcb300,1,0) at kqueue_register+0x668 Jun 18 19:50:13 gothmog kernel: kern_kevent(c1bcb300,4,1,0,da92fcc8) at kern_kevent+0xc9 Jun 18 19:50:13 gothmog kernel: kevent(c1bcb300,da92fd04,6,2,292) at kevent+0x55 Jun 18 19:50:13 gothmog kernel: syscall(3b,3b,3b,1,804e068) at syscall+0x22f Jun 18 19:50:13 gothmog kernel: Xint0x80_syscall() at Xint0x80_syscall+0x1f Jun 18 19:50:13 gothmog kernel: --- syscall (363, FreeBSD ELF32, kevent), eip = 0x280b7cfb, esp = 0xbfbfe67c, ebp = 0xbfbfe6c8 --- A crash dump seems to panic at this spot: (kgdb) bt #0 doadump () at pcpu.h:165 #1 0xc04787e6 in db_fncall (dummy1=0, dummy2=0, dummy3=-1066924621, dummy4=0xd56b5aac "ØZkÕØZkÕ4égÀÀÁ{Àp\f") at /usr/src/sys/ddb/db_command.c:531 #2 0xc04785f4 in db_command (last_cmdp=0xc0744904, cmd_table=0x0, aux_cmd_tablep=0xc06f12f0, aux_cmd_tablep_end=0xc06f12f4) at /usr/src/sys/ddb/db_command.c:349 #3 0xc04786bc in db_command_loop () at /usr/src/sys/ddb/db_command.c:455 #4 0xc047a241 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:221 #5 0xc0553f5f in kdb_trap (type=3, code=0, tf=0xd56b5bec) at /usr/src/sys/kern/subr_kdb.c:471 #6 0xc0695ff4 in trap (frame= {tf_fs = -714407928, tf_es = -1068171224, tf_ds = -1066598360, tf_edi = 1, tf_esi = -1066587760, tf_ebp = -714384340, tf_isp = -714384360, tf_ebx = -714384296, tf_edx = 0, tf_ecx = -1056878592, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1068155677, tf_cs = 32, tf_eflags = 524418, tf_esp = -714384308, tf_ss = -1068251993}) at /usr/src/sys/i386/i386/trap.c:598 #7 0xc068900a in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #8 0xd56b0008 in ?? () #9 0xc0550028 in device_probe_child (dev=0xc06cf8bc, child=0x1) at /usr/src/sys/kern/subr_bus.c:1800 #10 0xc053c4a7 in panic (fmt=0x20
) at /usr/src/sys/kern/kern_shutdown.c:537 #11 0xc055acd3 in propagate_priority (td=0xc1bcb300) at /usr/src/sys/kern/subr_turnstile.c:190 #12 0xc055b0e3 in turnstile_adjust (td=0xc1e92000, oldpri=181 'µ') at /usr/src/sys/kern/subr_turnstile.c:403 #13 0xc054c7b8 in sched_prio (td=0xc1e92000, prio=180 '´') at /usr/src/sys/kern/sched_4bsd.c:860 #14 0xc054c3e8 in resetpriority_thread (td=0xc1e92000, kg=0x0) at /usr/src/sys/kern/sched_4bsd.c:606 #15 0xc054c27f in schedcpu () at /usr/src/sys/kern/sched_4bsd.c:526 #16 0xc054c2ed in schedcpu_thread () at /usr/src/sys/kern/sched_4bsd.c:543 #17 0xc0529798 in fork_exit (callout=0xc054c2dc , arg=0x0, frame=0xd56b5d38) at /usr/src/sys/kern/kern_fork.c:789 #18 0xc068906c in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:208 (kgdb) up 11 #11 0xc055acd3 in propagate_priority (td=0xc1bcb300) at /usr/src/sys/kern/subr_turnstile.c:190 190 KASSERT(!TD_IS_SLEEPING(td), From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 17:20: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 5AC2816A41C for ; Sat, 18 Jun 2005 17:20:21 +0000 (GMT) (envelope-from michael@weiser.dinsnail.net) Received: from heinz.dinsnail.net (p15110767.pureserver.info [217.160.166.159]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9A3E43D1D for ; Sat, 18 Jun 2005 17:20:20 +0000 (GMT) (envelope-from michael@weiser.dinsnail.net) Received: from heinz.dinsnail.net (heinz.dinsnail.net [127.0.0.1]) by heinz.dinsnail.net (8.13.4/8.13.4) with ESMTP id j5IHKBLV029033; Sat, 18 Jun 2005 19:20:11 +0200 Received: from khazad-dum.weiser.dinsnail.net (uucp@localhost) by heinz.dinsnail.net (8.13.4/8.13.4/Submit) with bsmtp id j5IHK8Qs029026; Sat, 18 Jun 2005 19:20:08 +0200 Received: from khazad-dum.weiser.dinsnail.net (localhost [127.0.0.1]) by khazad-dum.weiser.dinsnail.net (8.13.4/8.13.4) with ESMTP id j5IHC77w001725; Sat, 18 Jun 2005 19:12:07 +0200 (CEST) (envelope-from michael@khazad-dum.weiser.dinsnail.net) Received: (from michael@localhost) by khazad-dum.weiser.dinsnail.net (8.13.4/8.13.4/Submit) id j5IHC7pc001724; Sat, 18 Jun 2005 19:12:07 +0200 (CEST) (envelope-from michael) Date: Sat, 18 Jun 2005 19:12:07 +0200 From: Michael Weiser To: "Daniel O'Connor" Message-ID: <20050618171207.GB993@weiser.dinsnail.net> References: <20050618161744.GA993@weiser.dinsnail.net> <200506190222.42111.doconnor@gsoft.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200506190222.42111.doconnor@gsoft.com.au> User-Agent: Mutt/1.4.2.1i X-MailScanner: Found to be clean X-MailScanner-From: michael@weiser.dinsnail.net Cc: freebsd-current@freebsd.org Subject: Re: ata explicit idle/standby 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, 18 Jun 2005 17:20:21 -0000 On Sun, Jun 19, 2005 at 02:22:41AM +0930, Daniel O'Connor wrote: > > I've done a small patch to the -CURRENT atacontrol and ata driver to > > allow explicit switch of drives to idle or standby mode and query the > > current mode. I use it to spin down disks needed only very inregularly. > > If extended by a means to set the idle timeout this might be > > particularly useful to notebook users as well. > Yes.. > Combine with > http://lists.freebsd.org/pipermail/freebsd-mobile/2003-May/000681.html to > allow you to turn the drive off for a reasonable amount of time :) > (That diff doesn't apply directly but it's trivial to apply by hand) In my case I dismount the disks anyway, so I don't need to hold off cache flushes and the like. > > Or have I actually missed the some already present functionality to > > achieve the same? > There is a port (ataidle) which does this but I think having it in atacontrol > is a good idea. I went to patching because ataidle is broken on 6.0-CURRENT. -- bye, Micha From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 18:01: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 8347E16A41C for ; Sat, 18 Jun 2005 18:01:20 +0000 (GMT) (envelope-from morten@oslonett.no) Received: from smarthost2.tiscali.dk (smarthost2.tiscali.dk [62.79.79.28]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0DE5F43D48 for ; Sat, 18 Jun 2005 18:01:19 +0000 (GMT) (envelope-from morten@oslonett.no) Received: from cpmail.dk.tiscali.com (mail.tiscali.dk [212.54.64.159]) by smarthost2.tiscali.dk (8.13.1/8.13.1) with ESMTP id j5II1I5M083052 for ; Sat, 18 Jun 2005 20:01:18 +0200 (CEST) (envelope-from morten@oslonett.no) Received: from [10.10.10.7] (82.164.251.12) by cpmail.dk.tiscali.com (6.7.018) id 42B209C3000076A0 for freebsd-current@freebsd.org; Sat, 18 Jun 2005 20:01:18 +0200 Message-ID: <42B46171.2070606@oslonett.no> Date: Sat, 18 Jun 2005 20:01:21 +0200 From: Morten Johansen User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050425) X-Accept-Language: en-us, en MIME-Version: 1.0 To: freebsd-current@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [patch] panic executing shell-script 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, 18 Jun 2005 18:01:20 -0000 Hi -current, When executing a shell-script where interpreter-name has 2 or more trailing whitespace, kernel panics. E.g. bin/jetty.sh from port www/jetty. Fix: --- imgact_shell.c Thu Jun 9 02:27:02 2005 +++ imgact_shell.c.mj Sat Jun 18 19:33:00 2005 @@ -161,7 +161,7 @@ exec_shell_imgact(imgp) while (ihp < maxp && ((*ihp != '\n') && (*ihp != '\0'))) ihp++; opte = ihp; - while (--ihp > interpe && ((*ihp == ' ') || (*ihp == '\t'))) + while (--ihp > optb && ((*ihp == ' ') || (*ihp == '\t'))) opte = ihp; /* From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 19:09: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 A6C7616A41F for ; Sat, 18 Jun 2005 19:09:31 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from camay.yandex.ru (camay.yandex.ru [213.180.200.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 886EF43D48 for ; Sat, 18 Jun 2005 19:09:30 +0000 (GMT) (envelope-from polachok@narod.ru) Received: from YAMAIL (camay.yandex.ru) by mail.yandex.ru id ; Sat, 18 Jun 2005 23:09:12 +0400 Date: Sat, 18 Jun 2005 23:09:11 +0400 (MSD) From: "Polakov Alexander" Sender: polachok@narod.ru Message-Id: <42B47157.000001.26107@camay.yandex.ru> MIME-Version: 1.0 X-Mailer: Yamail [ http://yandex.ru ] Errors-To: polachok@narod.ru To: freebsd-current@freebsd.org In-Reply-To: <0II8003FRENI4G60@store.etat.lu> References: <0II8003FRENI4G60@store.etat.lu> X-Source-Ip: 213.158.3.127 Content-Type: Multipart/Mixed; boundary="------------Boundary-00=_BVNA40MWKGMMYJ0CCJD0" Subject: Re: applying the vesa patch to stable for high console resolution X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: polachok@narod.ru List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jun 2005 19:09:31 -0000 --------------Boundary-00=_BVNA40MWKGMMYJ0CCJD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit >Hi, >Sorry but I don't know. >You should ask the freebsd-current list. >Regards >Didier > >-----Original Message----- >From: Remington L [mailto:mrl0lz@gmail.com] >Sent: Thursday, June 16, 2005 21:06 >To: Didier Wiroth; freebsd-stable@freebsd.org; >freebsd-questions@freebsd.org >Subject: [SPAM-PAL] Re: applying the vesa patch to stable for high >console resolution I hacked vidcontrol patch a bit, so it worked for me fine just a few weeks ago. The kernel part doesn't need any modifications. -- Alexander Polakov --------------Boundary-00=_BVNA40MWKGMMYJ0CCJD0 Content-Disposition: attachment; Filename="vcc.diff.txt" Content-Type: text/plain; name="vcc.diff.txt" Content-Transfer-Encoding: base64 LS0tIC4vdmlkY29udHJvbC5jLm9yaWcJTW9uIE1heSAgOSAwMDowMjo0MiAyMDA1CisrKyAuL3Zp ZGNvbnRyb2wuYwlNb24gTWF5ICA5IDAwOjA5OjMxIDIwMDUKQEAgLTI2LDYgKzI2LDcgQEAKICAq IFRISVMgU09GVFdBUkUsIEVWRU4gSUYgQURWSVNFRCBPRiBUSEUgUE9TU0lCSUxJVFkgT0YgU1VD SCBEQU1BR0UuCiAgKi8KIAorCiAjaWZuZGVmIGxpbnQKIHN0YXRpYyBjb25zdCBjaGFyIHJjc2lk W10gPQogICAiJEZyZWVCU0Q6IHNyYy91c3Iuc2Jpbi92aWRjb250cm9sL3ZpZGNvbnRyb2wuYyx2 IDEuNDcgMjAwMy8wOS8xOCAxNjoyMDozMiBlaXZpbmQgRXhwICQiOwpAQCAtNDksNyArNTAsNyBA QAogI2RlZmluZSBfVkVTQV84MDB4NjAwX0RGTF9DT0xTIDgwCiAjZGVmaW5lIF9WRVNBXzgwMHg2 MDBfREZMX1JPV1MgMjUKICNkZWZpbmUgX1ZFU0FfODAweDYwMF9ERkxfRk5TWiAxNgotCisjZGVm aW5lCURBVEFTSVpFKHgpCSgoeCkudyAqICh4KS5oICogMjU2IC8gOCkKIC8qIFNjcmVlbiBkdW1w IG1vZGVzICovCiAjZGVmaW5lIERVTVBfRk1UX1JBVwkxCiAjZGVmaW5lIERVTVBfRk1UX1RYVAky CkBAIC02NSwxMyArNjYsMTE5IEBACiAJImdyZXkiLCAibGlnaHRibHVlIiwgImxpZ2h0Z3JlZW4i LCAibGlnaHRjeWFuIiwKIAkibGlnaHRyZWQiLCAibGlnaHRtYWdlbnRhIiwgInllbGxvdyIsICJs aWdodHdoaXRlIgogfTsKLWludCAJaGV4ID0gMDsKLWludCAJbnVtYmVyOwotaW50CXZlc2FfY29s cyA9IF9WRVNBXzgwMHg2MDBfREZMX0NPTFM7Ci1pbnQJdmVzYV9yb3dzID0gX1ZFU0FfODAweDYw MF9ERkxfUk9XUzsKLWNoYXIgCWxldHRlcjsKLXN0cnVjdCAJdmlkX2luZm8gaW5mbzsKKy8vaW50 IAloZXggPSAwOworLy9pbnQgCW51bWJlcjsKKy8vaW50CXZlc2FfY29scyA9IF9WRVNBXzgwMHg2 MDBfREZMX0NPTFM7CisvL2ludAl2ZXNhX3Jvd3MgPSBfVkVTQV84MDB4NjAwX0RGTF9ST1dTOwor Ly9jaGFyIAlsZXR0ZXI7CisvL3N0cnVjdCAJdmlkX2luZm8gaW5mbzsKK3N0cnVjdCB7CisJaW50 CQkJYWN0aXZlX3Z0eTsKKwl2aWRfaW5mb190CQljb25zb2xlX2luZm87CisJdW5zaWduZWQgY2hh cgkJc2NyZWVuX21hcFsyNTZdOworCWludAkJCXZpZGVvX21vZGVfbnVtYmVyOworCXN0cnVjdCB2 aWRlb19pbmZvCXZpZGVvX21vZGVfaW5mbzsKK30gY3VyX2luZm87CisKK2ludAloZXggPSAwOwor aW50CW51bWJlcjsKK2ludAl2ZXNhX2NvbHM7CitpbnQJdmVzYV9yb3dzOworaW50CWZvbnRfaGVp Z2h0OworaW50CWNvbG9yc19jaGFuZ2VkOworaW50CXZpZGVvX21vZGVfY2hhbmdlZDsKK2ludAlu b3JtYWxfZm9yZV9jb2xvciwgbm9ybWFsX2JhY2tfY29sb3I7CitpbnQJcmV2ZXJzX2ZvcmVfY29s b3IsIHJldmVyc19iYWNrX2NvbG9yOworY2hhcglsZXR0ZXI7CitzdHJ1Y3QJdmlkX2luZm8gaW5m bzsKK3N0cnVjdAl2aWRlb19pbmZvIG5ld19tb2RlX2luZm87CisKKworLyoKKyAqIEluaXRpYWxp emUgcmV2ZXJ0IGRhdGEuCisgKgorICogTk9URTogdGhlIGZvbGxvd2luZyBwYXJhbWV0ZXJzIGFy ZSBub3QgeWV0IHNhdmVkL3Jlc3RvcmVkOgorICoKKyAqICAgc2NyZWVuIHNhdmVyIHRpbWVvdXQK KyAqICAgY3Vyc29yIHR5cGUKKyAqICAgbW91c2UgY2hhcmFjdGVyIGFuZCBtb3VzZSBzaG93L2hp ZGUgc3RhdGUKKyAqICAgdnR5IHN3aXRjaGluZyBvbi9vZmYgc3RhdGUKKyAqICAgaGlzdG9yeSBi dWZmZXIgc2l6ZQorICogICBoaXN0b3J5IGNvbnRlbnRzCisgKiAgIGZvbnQgbWFwcworICovCisK K3N0YXRpYyB2b2lkCitpbml0KHZvaWQpCit7CisJaWYgKGlvY3RsKDAsIFZUX0dFVEFDVElWRSwg JmN1cl9pbmZvLmFjdGl2ZV92dHkpID09IC0xKQorCQllcnJjKDEsIGVycm5vLCAiZ2V0dGluZyBh Y3RpdmUgdnR5Iik7CisKKwljdXJfaW5mby5jb25zb2xlX2luZm8uc2l6ZSA9IHNpemVvZihjdXJf aW5mby5jb25zb2xlX2luZm8pOworCisJaWYgKGlvY3RsKDAsIENPTlNfR0VUSU5GTywgJmN1cl9p bmZvLmNvbnNvbGVfaW5mbykgPT0gLTEpCisJCWVycmMoMSwgZXJybm8sICJnZXR0aW5nIGNvbnNv bGUgaW5mb3JtYXRpb24iKTsKKworCWlmIChpb2N0bCgwLCBHSU9fU0NSTk1BUCwgJmN1cl9pbmZv LnNjcmVlbl9tYXApID09IC0xKQorCQllcnJjKDEsIGVycm5vLCAiZ2V0dGluZyBzY3JlZW4gbWFw Iik7CisKKwlpZiAoaW9jdGwoMCwgQ09OU19HRVQsICZjdXJfaW5mby52aWRlb19tb2RlX251bWJl cikgPT0gLTEpCisJCWVycmMoMSwgZXJybm8sICJnZXR0aW5nIHZpZGVvIG1vZGUgbnVtYmVyIik7 CisKKwljdXJfaW5mby52aWRlb19tb2RlX2luZm8udmlfbW9kZSA9IGN1cl9pbmZvLnZpZGVvX21v ZGVfbnVtYmVyOworCisJaWYgKGlvY3RsKDAsIENPTlNfTU9ERUlORk8sICZjdXJfaW5mby52aWRl b19tb2RlX2luZm8pID09IC0xKQorCQllcnJjKDEsIGVycm5vLCAiZ2V0dGluZyB2aWRlbyBtb2Rl IHBhcmFtZXRlcnMiKTsKKworCW5vcm1hbF9mb3JlX2NvbG9yID0gY3VyX2luZm8uY29uc29sZV9p bmZvLm12X25vcm0uZm9yZTsKKwlub3JtYWxfYmFja19jb2xvciA9IGN1cl9pbmZvLmNvbnNvbGVf aW5mby5tdl9ub3JtLmJhY2s7CisJcmV2ZXJzX2ZvcmVfY29sb3IgPSBjdXJfaW5mby5jb25zb2xl X2luZm8ubXZfcmV2LmZvcmU7CisJcmV2ZXJzX2JhY2tfY29sb3IgPSBjdXJfaW5mby5jb25zb2xl X2luZm8ubXZfcmV2LmJhY2s7Cit9CisKKworLyoKKyAqIElmIHNvbWV0aGluZyBnb2VzIHdyb25n IGFsb25nIHRoZSB3YXkgd2UgY2FsbCByZXZlcnQoKSB0byBnbyBiYWNrIHRvIHRoZQorICogY29u c29sZSBzdGF0ZSB3ZSBjYW1lIGZyb20gKHdoaWNoIGlzIGFzc3VtZWQgdG8gYmUgd29ya2luZyku CisgKgorICogTk9URTogcGxlYXNlIGFsc28gcmVhZCB0aGUgY29tbWVudHMgb2YgaW5pdCgpLgor ICovCisKK3N0YXRpYyB2b2lkCityZXZlcnQodm9pZCkKK3sKKwlpbnQgc2l6ZVszXTsKIAorCWlv Y3RsKDAsIFZUX0FDVElWQVRFLCAoY2FkZHJfdCkgKGxvbmcpIGN1cl9pbmZvLmFjdGl2ZV92dHkp OworCisJZnByaW50ZihzdGRlcnIsICIbWz0lZEEiLCBjdXJfaW5mby5jb25zb2xlX2luZm8ubXZf b3ZzY2FuKTsKKwlmcHJpbnRmKHN0ZGVyciwgIhtbPSVkRiIsIGN1cl9pbmZvLmNvbnNvbGVfaW5m by5tdl9ub3JtLmZvcmUpOworZnByaW50ZihzdGRlcnIsICIbWz0lZEciLCBjdXJfaW5mby5jb25z b2xlX2luZm8ubXZfbm9ybS5iYWNrKTsKKwlmcHJpbnRmKHN0ZGVyciwgIhtbPSVkSCIsIGN1cl9p bmZvLmNvbnNvbGVfaW5mby5tdl9yZXYuZm9yZSk7CisJZnByaW50ZihzdGRlcnIsICIbWz0lZEki LCBjdXJfaW5mby5jb25zb2xlX2luZm8ubXZfcmV2LmJhY2spOworCisJaW9jdGwoMCwgUElPX1ND Uk5NQVAsICZjdXJfaW5mby5zY3JlZW5fbWFwKTsKKworCWlmIChjdXJfaW5mby52aWRlb19tb2Rl X251bWJlciA+PSBNX1ZFU0FfQkFTRSkKKwkJaW9jdGwoMCwgX0lPKCdWJywgY3VyX2luZm8udmlk ZW9fbW9kZV9udW1iZXIgLSBNX1ZFU0FfQkFTRSksCisJCSAgICAgIE5VTEwpOworCWVsc2UKKwkJ aW9jdGwoMCwgX0lPKCdTJywgY3VyX2luZm8udmlkZW9fbW9kZV9udW1iZXIpLCBOVUxMKTsKKwor CWlmIChjdXJfaW5mby52aWRlb19tb2RlX2luZm8udmlfZmxhZ3MgJiBWX0lORk9fR1JBUEhJQ1Mp IHsKKwkJc2l6ZVswXSA9IGN1cl9pbmZvLnZpZGVvX21vZGVfaW5mby52aV93aWR0aCAvIDg7CisJ CXNpemVbMV0gPSBjdXJfaW5mby52aWRlb19tb2RlX2luZm8udmlfaGVpZ2h0IC8KKwkJCSAgY3Vy X2luZm8uY29uc29sZV9pbmZvLmZvbnRfc2l6ZTsKKwkJc2l6ZVsyXSA9IGN1cl9pbmZvLmNvbnNv bGVfaW5mby5mb250X3NpemU7CisKKwkJaW9jdGwoMCwgS0RSQVNURVIsIHNpemUpOworCX0KK30K KworCisvKgorICogUHJpbnQgYSBzaG9ydCB1c2FnZSBzdHJpbmcgZGVzY3JpYmluZyBhbGwgb3B0 aW9ucywgdGhlbiBleGl0LgorICovCiAKIHN0YXRpYyB2b2lkCiB1c2FnZSgpCkBAIC04NSwxNiAr MTkyLDMxIEBACiAJZXhpdCgxKTsKIH0KIAorLyoKKyAqIFJldHJpZXZlIHRoZSBuZXh0IGFyZ3Vt ZW50IGZyb20gdGhlIGNvbW1hbmQgbGluZSAoZm9yIG9wdGlvbnMgdGhhdCByZXF1aXJlCisgKiBt b3JlIHRoYW4gb25lIGFyZ3VtZW50KS4KKyAqLworCiBjaGFyICoKIG5leHRhcmcoaW50IGFjLCBj aGFyICoqYXYsIGludCAqaW5kcCwgaW50IG9jLCBpbnQgc3RyaWN0KQogewogCWlmICgqaW5kcCA8 IGFjKQogCQlyZXR1cm4oYXZbKCppbmRwKSsrXSk7Ci0JaWYgKHN0cmljdCAhPSAwKQorLy8JaWYg KHN0cmljdCAhPSAwKQorCWlmIChzdHJpY3QgIT0gMCkgeworCQlyZXZlcnQoKTsKIAkJZXJyeCgx LCAib3B0aW9uIHJlcXVpcmVzIHR3byBhcmd1bWVudHMgLS0gJWMiLCBvYyk7Cit9CisKIAlyZXR1 cm4oTlVMTCk7CiB9CiAKKworLyoKKyAqIEd1ZXNzIHdoaWNoIGZpbGUgdG8gb3Blbi4gVHJ5IHRv IG9wZW4gZWFjaCBjb21iaW5hdGlvbiBvZiBhIHNwZWNpZmllZCBzZXQKKyAqIG9mIGZpbGUgbmFt ZSBjb21wb25lbnRzLgorICovCisKIEZJTEUgKgogb3Blbmd1ZXNzKGNoYXIgKmFbXSwgY2hhciAq YltdLCBjaGFyICpjW10sIGNoYXIgKmRbXSwgY2hhciAqKm5hbWUpCiB7CkBAIC0xMDUsMTEgKzIy NywxNSBAQAogCQlmb3IgKGogPSAwOyBiW2pdICE9IE5VTEw7IGorKykgewogCQkJZm9yIChrID0g MDsgY1trXSAhPSBOVUxMOyBrKyspIHsKIAkJCQlmb3IgKGwgPSAwOyBkW2xdICE9IE5VTEw7IGwr KykgewotCQkJCQlhc3ByaW50ZihuYW1lLCAiJXMlcyVzJXMiLCBhW2ldLCBiW2pdLAotCQkJCQkg ICAgY1trXSwgZFtsXSk7CisJLy8JCQkJYXNwcmludGYobmFtZSwgIiVzJXMlcyVzIiwgYVtpXSwg YltqXSwKKwkvLwkJCQkgICAgY1trXSwgZFtsXSk7CisgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGFzcHJpbnRmKG5hbWUsICIlcyVzJXMlcyIsCisgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhW2ldLCBiW2pdLCBjW2tdLCBk W2xdKTsKIAkJCQkJZiA9IGZvcGVuKCpuYW1lLCAiciIpOworCiAJCQkJCWlmIChmICE9IE5VTEwp CiAJCQkJCQlyZXR1cm4gKGYpOworCiAJCQkJCWZyZWUoKm5hbWUpOwogCQkJCX0KIAkJCX0KQEAg LTExOCw2ICsyNDQsMTAgQEAKIAlyZXR1cm4gKE5VTEwpOwogfQogCisvKgorICogTG9hZCBhIHNj cmVlbm1hcCBmcm9tIGEgZmlsZSBhbmQgc2V0IGl0LgorICovCisKIHZvaWQKIGxvYWRfc2Nybm1h cChjaGFyICpmaWxlbmFtZSkKIHsKQEAgLTEzMSwyNCArMjYxLDM4IEBACiAJY2hhciAqZFtdID0g eyIiLCBOVUxMfTsKIAogCWZkID0gb3Blbmd1ZXNzKGEsIGIsIGMsIGQsICZuYW1lKTsKKwogCWlm IChmZCA9PSBOVUxMKSB7Ci0JCXdhcm4oInNjcmVlbm1hcCBmaWxlIG5vdCBmb3VuZCIpOwotCQly ZXR1cm47CisvLwkJd2Fybigic2NyZWVubWFwIGZpbGUgbm90IGZvdW5kIik7CisvLwkJcmV0dXJu OworCQlyZXZlcnQoKTsKKwkJZXJyeCgxLCAic2NyZWVubWFwIGZpbGUgbm90IGZvdW5kIik7CiAJ fQorCiAJc2l6ZSA9IHNpemVvZihzY3JubWFwKTsKIAlpZiAoZGVjb2RlKGZkLCAoY2hhciAqKSZz Y3JubWFwLCBzaXplKSAhPSBzaXplKSB7CiAJCXJld2luZChmZCk7Ci0JCWlmIChmcmVhZCgmc2Ny bm1hcCwgMSwgc2l6ZSwgZmQpICE9IHNpemUpIHsKKy8vCQlpZiAoZnJlYWQoJnNjcm5tYXAsIDEs IHNpemUsIGZkKSAhPSBzaXplKSB7CisgICAgICAgICAgICAgICAgICAgIGlmIChmcmVhZCgmc2Ny bm1hcCwgMSwgc2l6ZSwgZmQpICE9IChzaXplX3Qpc2l6ZSkgewogCQkJd2FybngoImJhZCBzY3Jl ZW5tYXAgZmlsZSIpOwogCQkJZmNsb3NlKGZkKTsKLQkJCXJldHVybjsKKy8vCQkJcmV0dXJuOwor CQkJcmV2ZXJ0KCk7CisJCQllcnJ4KDEsICJiYWQgc2NyZWVubWFwIGZpbGUiKTsKIAkJfQogCX0K LQlpZiAoaW9jdGwoMCwgUElPX1NDUk5NQVAsICZzY3JubWFwKSA8IDApCi0JCXdhcm4oImNhbid0 IGxvYWQgc2NyZWVubWFwIik7CisJaWYgKGlvY3RsKDAsIFBJT19TQ1JOTUFQLCAmc2Nybm1hcCkg PT0gLTEpCit7CisgICAgICAgICAgICAgcmV2ZXJ0KCk7CisJCWVycmMoMSwgZXJybm8sICJjYW4n dCBsb2FkIHNjcmVlbm1hcCIpOworfQogCWZjbG9zZShmZCk7CiB9CiAKKy8qCisgKiBTZXQgdGhl IGRlZmF1bHQgc2NyZWVubWFwLgorICovCisKIHZvaWQKIGxvYWRfZGVmYXVsdF9zY3JubWFwKCkK IHsKQEAgLTE1NywyNCArMzAxLDM2IEBACiAKIAlmb3IgKGk9MDsgaTwyNTY7IGkrKykKIAkJKigo Y2hhciopJnNjcm5tYXAgKyBpKSA9IGk7Ci0JaWYgKGlvY3RsKDAsIFBJT19TQ1JOTUFQLCAmc2Ny bm1hcCkgPCAwKQotCQl3YXJuKCJjYW4ndCBsb2FkIGRlZmF1bHQgc2NyZWVubWFwIik7CisvLwlp ZiAoaW9jdGwoMCwgUElPX1NDUk5NQVAsICZzY3JubWFwKSA8IDApCisvLwkJd2FybigiY2FuJ3Qg bG9hZCBkZWZhdWx0IHNjcmVlbm1hcCIpOworCisJaWYgKGlvY3RsKDAsIFBJT19TQ1JOTUFQLCAm c2Nybm1hcCkgPT0gLTEpIHsKKwkJcmV2ZXJ0KCk7CisJCWVycmMoMSwgZXJybm8sICJsb2FkaW5n IGRlZmF1bHQgc2NyZWVubWFwIik7CisJfQogfQogCisvKgorICogUHJpbnQgdGhlIGN1cnJlbnQg c2NyZWVubWFwIHRvIHN0ZG91dC4KKyAqLworCiB2b2lkCiBwcmludF9zY3JubWFwKCkKIHsKIAl1 bnNpZ25lZCBjaGFyIG1hcFsyNTZdOwogCWludCBpOwogCi0JaWYgKGlvY3RsKDAsIEdJT19TQ1JO TUFQLCAmbWFwKSA8IDApIHsKLQkJd2FybigiZ2V0dGluZyBzY3JlZW5tYXAiKTsKLQkJcmV0dXJu OworLy8JaWYgKGlvY3RsKDAsIEdJT19TQ1JOTUFQLCAmbWFwKSA8IDApIHsKKy8vCQl3YXJuKCJn ZXR0aW5nIHNjcmVlbm1hcCIpOworLy8JCXJldHVybjsKKwlpZiAoaW9jdGwoMCwgR0lPX1NDUk5N QVAsICZtYXApID09IC0xKSB7CisJCXJldmVydCgpOworCQllcnJjKDEsIGVycm5vLCAiZ2V0dGlu ZyBzY3JlZW5tYXAiKTsKIAl9CiAJZm9yIChpPTA7IGk8c2l6ZW9mKG1hcCk7IGkrKykgewogCQlp ZiAoaSA+IDAgJiYgaSAlIDE2ID09IDApCiAJCQlmcHJpbnRmKHN0ZG91dCwgIlxuIik7Ci0JCWlm IChoZXgpCisJCWlmIChoZXggIT0gMCkKIAkJCWZwcmludGYoc3Rkb3V0LCAiICUwMngiLCBtYXBb aV0pOwogCQllbHNlCiAJCQlmcHJpbnRmKHN0ZG91dCwgIiAlMDNkIiwgbWFwW2ldKTsKQEAgLTE4 Myw2ICszMzksMTAgQEAKIAogfQogCisvKgorICogRGV0ZXJtaW5lIGEgZmlsZSdzIHNpemUuCisg Ki8KKwogaW50CiBmc2l6ZShGSUxFICpmaWxlKQogewpAQCAtMTk0LDcgKzM1NCwxMCBAQAogCQly ZXR1cm4gLTE7CiB9CiAKLSNkZWZpbmUgREFUQVNJWkUoeCkgKCh4KS53ICogKHgpLmggKiAyNTYg LyA4KQorLy8jZGVmaW5lIERBVEFTSVpFKHgpICgoeCkudyAqICh4KS5oICogMjU2IC8gOCkKKy8q CisgKiBMb2FkIGEgZm9udCBmcm9tIGZpbGUgYW5kIHNldCBpdC4KKyAqLwogCiB2b2lkCiBsb2Fk X2ZvbnQoY2hhciAqdHlwZSwgY2hhciAqZmlsZW5hbWUpCkBAIC0yMjAsMjggKzM4MywzOSBAQAog CiAJaW5mby5zaXplID0gc2l6ZW9mKGluZm8pOwogCWlmIChpb2N0bCgwLCBDT05TX0dFVElORk8s ICZpbmZvKSA9PSAtMSkgeworICAgICAgICAgICAgICAgICAgICByZXZlcnQoKTsKIAkJd2Fybigi ZmFpbGVkIHRvIG9idGFpbiBjdXJyZW50IHZpZGVvIG1vZGUgcGFyYW1ldGVycyIpOwogCQlyZXR1 cm47CiAJfQorCiAJc25wcmludGYoc2l6ZV9zdWZ4LCBzaXplb2Yoc2l6ZV9zdWZ4KSwgIi04eCVk IiwgaW5mby5mb250X3NpemUpOwogCWZkID0gb3Blbmd1ZXNzKGEsIGIsIGMsIGQsICZuYW1lKTsK IAlpZiAoZmQgPT0gTlVMTCkgewotCQl3YXJuKCIlczogY2FuJ3QgbG9hZCBmb250IGZpbGUiLCBm aWxlbmFtZSk7Ci0JCXJldHVybjsKKy8vCQl3YXJuKCIlczogY2FuJ3QgbG9hZCBmb250IGZpbGUi LCBmaWxlbmFtZSk7CisvLwkJcmV0dXJuOworCQlyZXZlcnQoKTsKKwkJZXJyeCgxLCAiJXM6IGNh bid0IGxvYWQgZm9udCBmaWxlIiwgZmlsZW5hbWUpOwogCX0KKwogCWlmICh0eXBlICE9IE5VTEwp IHsKIAkJc2l6ZSA9IDA7Ci0JCWlmIChzc2NhbmYodHlwZSwgIiVkeCVkIiwgJncsICZoKSA9PSAy KQotCQkJZm9yIChpID0gMDsgc2l6ZXNbaV0udyAhPSAwOyBpKyspCisvLwkJaWYgKHNzY2FuZih0 eXBlLCAiJWR4JWQiLCAmdywgJmgpID09IDIpCisvLwkJCWZvciAoaSA9IDA7IHNpemVzW2ldLncg IT0gMDsgaSsrKQorCQlpZiAoc3NjYW5mKHR5cGUsICIlZHglZCIsICZ3LCAmaCkgPT0gMikgewor CQkJZm9yIChpID0gMDsgc2l6ZXNbaV0udyAhPSAwOyBpKyspIHsKIAkJCQlpZiAoc2l6ZXNbaV0u dyA9PSB3ICYmIHNpemVzW2ldLmggPT0gaCkgewogCQkJCQlzaXplID0gREFUQVNJWkUoc2l6ZXNb aV0pOwogCQkJCQlpbyA9IHNpemVzW2ldLmlvOworCQkJCQlmb250X2hlaWdodCA9IHNpemVzW2ld Lmg7CiAJCQkJfQotCit9Cit9CiAJCWlmIChzaXplID09IDApIHsKLQkJCXdhcm54KCIlczogYmFk IGZvbnQgc2l6ZSBzcGVjaWZpY2F0aW9uIiwgdHlwZSk7CisvLwkJCXdhcm54KCIlczogYmFkIGZv bnQgc2l6ZSBzcGVjaWZpY2F0aW9uIiwgdHlwZSk7CiAJCQlmY2xvc2UoZmQpOwotCQkJcmV0dXJu OworLy8JCQlyZXR1cm47CisJCQlyZXZlcnQoKTsKKwkJZXJyeCgxLCAiJXM6IGJhZCBmb250IHNp emUgc3BlY2lmaWNhdGlvbiIsIHR5cGUpOwogCQl9CiAJfSBlbHNlIHsKIAkJLyogQXBwbHkgaGV1 cmlzdGljcyAqLwpAQCAtMjU1LDE5ICs0MjksMjUgQEAKIAkJZnJlZShmb250bWFwKTsKIAogCQlz aXplID0gMDsKLQkJZm9yIChqID0gMDsgaiA8IDI7IGorKykKLQkJCWZvciAoaSA9IDA7IHNpemVz W2ldLncgIT0gMDsgaSsrKQorLy8JCWZvciAoaiA9IDA7IGogPCAyOyBqKyspCisvLwkJCWZvciAo aSA9IDA7IHNpemVzW2ldLncgIT0gMDsgaSsrKQorCQlmb3IgKGogPSAwOyBqIDwgMjsgaisrKSB7 CisJCQlmb3IgKGkgPSAwOyBzaXplc1tpXS53ICE9IDA7IGkrKykgewogCQkJCWlmIChEQVRBU0la RShzaXplc1tpXSkgPT0gZHNpemVbal0pIHsKIAkJCQkJc2l6ZSA9IGRzaXplW2pdOwogCQkJCQlp byA9IHNpemVzW2ldLmlvOworCQkJCQlmb250X2hlaWdodCA9IHNpemVzW2ldLmg7CiAJCQkJCWog PSAyOwkvKiBYWFggKi8KIAkJCQkJYnJlYWs7CiAJCQkJfQotCit9Cit9CiAJCWlmIChzaXplID09 IDApIHsKLQkJCXdhcm54KCIlczogY2FuJ3QgZ3Vlc3MgZm9udCBzaXplIiwgZmlsZW5hbWUpOwor CS8vCQl3YXJueCgiJXM6IGNhbid0IGd1ZXNzIGZvbnQgc2l6ZSIsIGZpbGVuYW1lKTsKIAkJCWZj bG9zZShmZCk7Ci0JCQlyZXR1cm47CisJLy8JCXJldHVybjsKKwkJCXJldmVydCgpOworCQkJZXJy eCgxLCAiJXM6IGNhbid0IGd1ZXNzIGZvbnQgc2l6ZSIsIGZpbGVuYW1lKTsKIAkJfQogCQlyZXdp bmQoZmQpOwogCX0KQEAgLTI3NSwzNyArNDU1LDYwIEBACiAJZm9udG1hcCA9IChjaGFyKikgbWFs bG9jKHNpemUpOwogCWlmIChkZWNvZGUoZmQsIGZvbnRtYXAsIHNpemUpICE9IHNpemUpIHsKIAkJ cmV3aW5kKGZkKTsKLQkJaWYgKGZzaXplKGZkKSAhPSBzaXplIHx8IGZyZWFkKGZvbnRtYXAsIDEs IHNpemUsIGZkKSAhPSBzaXplKSB7CisvLwkJaWYgKGZzaXplKGZkKSAhPSBzaXplIHx8IGZyZWFk KGZvbnRtYXAsIDEsIHNpemUsIGZkKSAhPSBzaXplKSB7CisJCWlmIChmc2l6ZShmZCkgIT0gc2l6 ZSB8fAorCQkgICAgZnJlYWQoZm9udG1hcCwgMSwgc2l6ZSwgZmQpICE9IChzaXplX3Qpc2l6ZSkg ewogCQkJd2FybngoIiVzOiBiYWQgZm9udCBmaWxlIiwgZmlsZW5hbWUpOwogCQkJZmNsb3NlKGZk KTsKIAkJCWZyZWUoZm9udG1hcCk7Ci0JCQlyZXR1cm47CisvLwkJCXJldHVybjsKKwkJCXJldmVy dCgpOworCQkJZXJyeCgxLCAiJXM6IGJhZCBmb250IGZpbGUiLCBmaWxlbmFtZSk7CiAJCX0KIAl9 Ci0JaWYgKGlvY3RsKDAsIGlvLCBmb250bWFwKSA8IDApCi0JCXdhcm4oImNhbid0IGxvYWQgZm9u dCIpOworLy8JaWYgKGlvY3RsKDAsIGlvLCBmb250bWFwKSA8IDApCisvLwkJd2FybigiY2FuJ3Qg bG9hZCBmb250Iik7CisKKwlpZiAoaW9jdGwoMCwgaW8sIGZvbnRtYXApID09IC0xKSB7CisJCXJl dmVydCgpOworCQllcnJjKDEsIGVycm5vLCAibG9hZGluZyBmb250Iik7CisJfQogCWZjbG9zZShm ZCk7CiAJZnJlZShmb250bWFwKTsKIH0KIAorLyoKKyAqIFNldCB0aGUgdGltZW91dCBmb3IgdGhl IHNjcmVlbnNhdmVyLgorICovCisKIHZvaWQKIHNldF9zY3JlZW5zYXZlcl90aW1lb3V0KGNoYXIg KmFyZykKIHsKIAlpbnQgbnNlYzsKIAotCWlmICghc3RyY21wKGFyZywgIm9mZiIpKQorCWlmICgh c3RyY21wKGFyZywgIm9mZiIpKSB7CiAJCW5zZWMgPSAwOwotCWVsc2UgeworCX0gZWxzZSB7CiAJ CW5zZWMgPSBhdG9pKGFyZyk7CiAJCWlmICgoKmFyZyA9PSAnXDAnKSB8fCAobnNlYyA8IDEpKSB7 Ci0JCQl3YXJueCgiYXJndW1lbnQgbXVzdCBiZSBhIHBvc2l0aXZlIG51bWJlciIpOwotCQkJcmV0 dXJuOworLy8JCQl3YXJueCgiYXJndW1lbnQgbXVzdCBiZSBhIHBvc2l0aXZlIG51bWJlciIpOwor Ly8JCQlyZXR1cm47CisJCQlyZXZlcnQoKTsKKwkJCWVycngoMSwgImFyZ3VtZW50IG11c3QgYmUg YSBwb3NpdGl2ZSBudW1iZXIiKTsKIAkJfQogCX0KLQlpZiAoaW9jdGwoMCwgQ09OU19CTEFOS1RJ TUUsICZuc2VjKSA9PSAtMSkKLQkJd2Fybigic2V0dGluZyBzY3JlZW5zYXZlciBwZXJpb2QiKTsK Ky8vCWlmIChpb2N0bCgwLCBDT05TX0JMQU5LVElNRSwgJm5zZWMpID09IC0xKQorLy8JCXdhcm4o InNldHRpbmcgc2NyZWVuc2F2ZXIgcGVyaW9kIik7CisJaWYgKGlvY3RsKDAsIENPTlNfQkxBTktU SU1FLCAmbnNlYykgPT0gLTEpIHsKKwkJcmV2ZXJ0KCk7CisJCWVycmMoMSwgZXJybm8sICJzZXR0 aW5nIHNjcmVlbnNhdmVyIHBlcmlvZCIpOworCX0KIH0KIAorLyoKKyAqIFNldCB0aGUgY3Vyc29y J3Mgc2hhcGUvdHlwZS4KKyAqLworCiB2b2lkCiBzZXRfY3Vyc29yX3R5cGUoY2hhciAqYXBwZWFy ZW5jZSkKIHsKQEAgLTMxOCw1MSArNTIxLDY0IEBACiAJZWxzZSBpZiAoIXN0cmNtcChhcHBlYXJl bmNlLCAiZGVzdHJ1Y3RpdmUiKSkKIAkJdHlwZSA9IDM7CiAJZWxzZSB7Ci0JCXdhcm54KCJhcmd1 bWVudCB0byAtYyBtdXN0IGJlIG5vcm1hbCwgYmxpbmsgb3IgZGVzdHJ1Y3RpdmUiKTsKLQkJcmV0 dXJuOwotCX0KLQlpb2N0bCgwLCBDT05TX0NVUlNPUlRZUEUsICZ0eXBlKTsKKy8vCQl3YXJueCgi YXJndW1lbnQgdG8gLWMgbXVzdCBiZSBub3JtYWwsIGJsaW5rIG9yIGRlc3RydWN0aXZlIik7Cisv LwkJcmV0dXJuOworCQlyZXZlcnQoKTsKKwkJZXJyeCgxLCAiYXJndW1lbnQgdG8gLWMgbXVzdCBi ZSBub3JtYWwsIGJsaW5rIG9yIGRlc3RydWN0aXZlIik7CisJfQorCQlpZiAoaW9jdGwoMCwgQ09O U19DVVJTT1JUWVBFLCAmdHlwZSkgPT0gLTEpIHsKKwlyZXZlcnQoKTsKKwllcnJjKDEsIGVycm5v LCAic2V0dGluZyBjdXJzb3IgdHlwZSIpOwogfQorLy8JaW9jdGwoMCwgQ09OU19DVVJTT1JUWVBF LCAmdHlwZSk7Cit9CisKKy8qCisgKiBTZXQgdGhlIHZpZGVvIG1vZGUuCisgKi8KIAogaW50Ci12 aWRlb19tb2RlKGludCBhcmdjLCBjaGFyICoqYXJndiwgaW50ICppbmRleCkKK3ZpZGVvX21vZGUo aW50IGFyZ2MsIGNoYXIgKiphcmd2LCBpbnQgKm1vZGVfaW5kZXgpCiB7CiAJc3RhdGljIHN0cnVj dCB7CiAJCWNoYXIgKm5hbWU7CiAJCXVuc2lnbmVkIGxvbmcgbW9kZTsKKwkJdW5zaWduZWQgbG9u ZyBtb2RlX251bTsKIAl9IG1vZGVzW10gPSB7Ci0JCXsgIjgweDI1IiwJCVNXX1RFWFRfODB4MjUg fSwKLQkJeyAiODB4MzAiLAkJU1dfVEVYVF84MHgzMCB9LAotCQl7ICI4MHg0MyIsCQlTV19URVhU XzgweDQzIH0sCi0JCXsgIjgweDUwIiwJCVNXX1RFWFRfODB4NTAgfSwKLQkJeyAiODB4NjAiLAkJ U1dfVEVYVF84MHg2MCB9LAotCQl7ICIxMzJ4MjUiLAkJU1dfVEVYVF8xMzJ4MjUgfSwKLQkJeyAi MTMyeDMwIiwJCVNXX1RFWFRfMTMyeDMwIH0sCi0JCXsgIjEzMng0MyIsCQlTV19URVhUXzEzMng0 MyB9LAotCQl7ICIxMzJ4NTAiLAkJU1dfVEVYVF8xMzJ4NTAgfSwKLQkJeyAiMTMyeDYwIiwJCVNX X1RFWFRfMTMyeDYwIH0sCi0JCXsgIlZHQV80MHgyNSIsCQlTV19WR0FfQzQweDI1IH0sCi0JCXsg IlZHQV84MHgyNSIsCQlTV19WR0FfQzgweDI1IH0sCi0JCXsgIlZHQV84MHgzMCIsCQlTV19WR0Ff QzgweDMwIH0sCi0JCXsgIlZHQV84MHg1MCIsCQlTV19WR0FfQzgweDUwIH0sCi0JCXsgIlZHQV84 MHg2MCIsCQlTV19WR0FfQzgweDYwIH0sCisJCXsgIjgweDI1IiwgICAgICAgIFNXX1RFWFRfODB4 MjUsICAgTV9URVhUXzgweDI1IH0sCisJCXsgIjgweDMwIiwgICAgICAgIFNXX1RFWFRfODB4MzAs ICAgTV9URVhUXzgweDMwIH0sCisJCXsgIjgweDQzIiwgICAgICAgIFNXX1RFWFRfODB4NDMsICAg TV9URVhUXzgweDQzIH0sCisJCXsgIjgweDUwIiwgICAgICAgIFNXX1RFWFRfODB4NTAsICAgTV9U RVhUXzgweDUwIH0sCisJCXsgIjgweDYwIiwgICAgICAgIFNXX1RFWFRfODB4NjAsICAgTV9URVhU XzgweDYwIH0sCisJCXsgIjEzMngyNSIsICAgICAgIFNXX1RFWFRfMTMyeDI1LCAgTV9URVhUXzEz MngyNSB9LAorCQl7ICIxMzJ4MzAiLCAgICAgICBTV19URVhUXzEzMngzMCwgIE1fVEVYVF8xMzJ4 MzAgfSwKKwkJeyAiMTMyeDQzIiwgICAgICAgU1dfVEVYVF8xMzJ4NDMsICBNX1RFWFRfMTMyeDQz IH0sCisJCXsgIjEzMng1MCIsICAgICAgIFNXX1RFWFRfMTMyeDUwLCAgTV9URVhUXzEzMng1MCB9 LAorCQl7ICIxMzJ4NjAiLCAgICAgICBTV19URVhUXzEzMng2MCwgIE1fVEVYVF8xMzJ4NjAgfSwK KwkJeyAiVkdBXzQweDI1IiwgICAgU1dfVkdBX0M0MHgyNSwgICBNX1ZHQV9DNDB4MjUgfSwKKwkJ eyAiVkdBXzgweDI1IiwgICAgU1dfVkdBX0M4MHgyNSwgICBNX1ZHQV9DODB4MjUgfSwKKwkJeyAi VkdBXzgweDMwIiwgICAgU1dfVkdBX0M4MHgzMCwgICBNX1ZHQV9DODB4MzAgfSwKKwkJeyAiVkdB XzgweDUwIiwgICAgU1dfVkdBX0M4MHg1MCwgICBNX1ZHQV9DODB4NTAgfSwKKwkJeyAiVkdBXzgw eDYwIiwgICAgU1dfVkdBX0M4MHg2MCwgICBNX1ZHQV9DODB4NjAgfSwKICNpZmRlZiBTV19WR0Ff QzkweDI1Ci0JCXsgIlZHQV85MHgyNSIsCQlTV19WR0FfQzkweDI1IH0sCi0JCXsgIlZHQV85MHgz MCIsCQlTV19WR0FfQzkweDMwIH0sCi0JCXsgIlZHQV85MHg0MyIsCQlTV19WR0FfQzkweDQzIH0s Ci0JCXsgIlZHQV85MHg1MCIsCQlTV19WR0FfQzkweDUwIH0sCi0JCXsgIlZHQV85MHg2MCIsCQlT V19WR0FfQzkweDYwIH0sCisJCXsgIlZHQV85MHgyNSIsICAgIFNXX1ZHQV9DOTB4MjUsICAgTV9W R0FfQzkweDI1IH0sCisJCXsgIlZHQV85MHgzMCIsICAgIFNXX1ZHQV9DOTB4MzAsICAgTV9WR0Ff QzkweDMwIH0sCisJCXsgIlZHQV85MHg0MyIsICAgIFNXX1ZHQV9DOTB4NDMsICAgTV9WR0FfQzkw eDQzIH0sCisJCXsgIlZHQV85MHg1MCIsICAgIFNXX1ZHQV9DOTB4NTAsICAgTV9WR0FfQzkweDUw IH0sCisJCXsgIlZHQV85MHg2MCIsICAgIFNXX1ZHQV9DOTB4NjAsICAgTV9WR0FfQzkweDYwIH0s CiAjZW5kaWYKLQkJeyAiVkdBXzMyMHgyMDAiLAlTV19WR0FfQ0czMjAgfSwKLQkJeyAiRUdBXzgw eDI1IiwJCVNXX0VOSF9DODB4MjUgfSwKLQkJeyAiRUdBXzgweDQzIiwJCVNXX0VOSF9DODB4NDMg fSwKLQkJeyAiVkVTQV8xMzJ4MjUiLAlTV19WRVNBX0MxMzJ4MjUgfSwKLQkJeyAiVkVTQV8xMzJ4 NDMiLAlTV19WRVNBX0MxMzJ4NDMgfSwKLQkJeyAiVkVTQV8xMzJ4NTAiLAlTV19WRVNBX0MxMzJ4 NTAgfSwKLQkJeyAiVkVTQV8xMzJ4NjAiLAlTV19WRVNBX0MxMzJ4NjAgfSwKLQkJeyAiVkVTQV84 MDB4NjAwIiwJU1dfVkVTQV84MDB4NjAwIH0sCi0JCXsgTlVMTCB9LAorCQl7ICJWR0FfMzIweDIw MCIsCVNXX1ZHQV9DRzMyMCwJTV9DRzMyMCB9LAorCQl7ICJFR0FfODB4MjUiLAkJU1dfRU5IX0M4 MHgyNSwJTV9FTkhfQzgweDI1IH0sCisJCXsgIkVHQV84MHg0MyIsCQlTV19FTkhfQzgweDQzLAlN X0VOSF9DODB4NDMgfSwKKwkJeyAiVkVTQV8xMzJ4MjUiLAlTV19WRVNBX0MxMzJ4MjUsTV9WRVNB X0MxMzJ4MjUgfSwKKwkJeyAiVkVTQV8xMzJ4NDMiLAlTV19WRVNBX0MxMzJ4NDMsTV9WRVNBX0Mx MzJ4NDMgfSwKKwkJeyAiVkVTQV8xMzJ4NTAiLAlTV19WRVNBX0MxMzJ4NTAsTV9WRVNBX0MxMzJ4 NTAgfSwKKwkJeyAiVkVTQV8xMzJ4NjAiLAlTV19WRVNBX0MxMzJ4NjAsTV9WRVNBX0MxMzJ4NjAg fSwKKyAgICAgICAgICAJeyAiVkVTQV84MDB4NjAwIiwJU1dfVkVTQV84MDB4NjAwLE1fVkVTQV84 MDB4NjAwIH0sCisJCXsgTlVMTCwgMCwgMCB9LAogCX07CisKKyAgICAgICAgICBpbnQgbmV3X21v ZGVfbnVtID0gMDsKIAl1bnNpZ25lZCBsb25nIG1vZGUgPSAwOwogCWludCBjdXJfbW9kZTsgCiAJ aW50IGlvZXJyOwpAQCAtMzcxLDM5ICs1ODcsOTQgQEAKIAogCWlmIChpb2N0bCgwLCBDT05TX0dF VCwgJmN1cl9tb2RlKSA8IDApCiAJCWVycigxLCAiY2Fubm90IGdldCB0aGUgY3VycmVudCB2aWRl byBtb2RlIik7Ci0JaWYgKCppbmRleCA8IGFyZ2MpIHsKLQkJZm9yIChpID0gMDsgbW9kZXNbaV0u bmFtZSAhPSBOVUxMOyArK2kpIHsKLQkJCWlmICghc3RyY21wKGFyZ3ZbKmluZGV4XSwgbW9kZXNb aV0ubmFtZSkpIHsKLQkJCQltb2RlID0gbW9kZXNbaV0ubW9kZTsKLQkJCQlicmVhazsKKworCS8q CisJICogUGFyc2UgdGhlIHZpZGVvIG1vZGUgYXJndW1lbnQuLi4KKwkgKi8KKworCWlmICgqbW9k ZV9pbmRleCA8IGFyZ2MpIHsKKwkJaWYgKCFzdHJuY21wKGFyZ3ZbKm1vZGVfaW5kZXhdLCAiTU9E RV8iLCA1KSkgeworCQkJaWYgKCFpc251bWJlcihhcmd2Wyptb2RlX2luZGV4XVs1XSkpCisJCQkJ ZXJyeCgxLCAiaW52YWxpZCB2aWRlbyBtb2RlIG51bWJlciIpOworCisJCQluZXdfbW9kZV9udW0g PSBhdG9pKCZhcmd2Wyptb2RlX2luZGV4XVs1XSk7CisJfSBlbHNlIHsKKwkJCWZvciAoaSA9IDA7 IG1vZGVzW2ldLm5hbWUgIT0gTlVMTDsgKytpKSB7CisJCQkJaWYgKCFzdHJjbXAoYXJndlsqbW9k ZV9pbmRleF0sIG1vZGVzW2ldLm5hbWUpKSB7CisJCQkJCW1vZGUgPSBtb2Rlc1tpXS5tb2RlOwor CQkJCQluZXdfbW9kZV9udW0gPSBtb2Rlc1tpXS5tb2RlX251bTsKKwkJCQkJYnJlYWs7CisJCQkJ fQogCQkJfQorCisJCQlpZiAobW9kZXNbaV0ubmFtZSA9PSBOVUxMKQorCQkJCXJldHVybiBFWElU X0ZBSUxVUkU7CisJCQlpZiAoaW9jdGwoMCwgbW9kZSwgTlVMTCkgPCAwKSB7CisJCQkJd2Fybigi Y2Fubm90IHNldCB2aWRlb21vZGUiKTsKKwkJCQlyZXR1cm4gRVhJVF9GQUlMVVJFOworCQkJfQor CQl9CisKKwkJLyoKKwkJICogQ29sbGVjdCBlbm91Z2ggaW5mb3JtYXRpb24gYWJvdXQgdGhlIG5l dyB2aWRlbyBtb2RlLi4uCisJCSAqLworCisJCW5ld19tb2RlX2luZm8udmlfbW9kZSA9IG5ld19t b2RlX251bTsKKworCQlpZiAoaW9jdGwoMCwgQ09OU19NT0RFSU5GTywgJm5ld19tb2RlX2luZm8p ID09IC0xKSB7CisJCQlyZXZlcnQoKTsKKwkJCWVycmMoMSwgZXJybm8sICJvYnRhaW5pbmcgbmV3 IHZpZGVvIG1vZGUgcGFyYW1ldGVycyIpOwogCQl9Ci0JCWlmIChtb2Rlc1tpXS5uYW1lID09IE5V TEwpCi0JCQlyZXR1cm4gRVhJVF9GQUlMVVJFOwotCQlpZiAoaW9jdGwoMCwgbW9kZSwgTlVMTCkg PCAwKSB7Ci0JCQl3YXJuKCJjYW5ub3Qgc2V0IHZpZGVvbW9kZSIpOwotCQkJcmV0dXJuIEVYSVRf RkFJTFVSRTsKLQkJfQotCQlpZiAobW9kZSA9PSBTV19WRVNBXzgwMHg2MDApIHsKLQkJCS8qIGNv bHVtbnMgKi8KLQkJCWlmICgodmVzYV9jb2xzICogOCA+IDgwMCkgfHwgKHZlc2FfY29scyA8PSAw KSkgewotCQkJCXdhcm54KCJpbmNvcnJlY3QgbnVtYmVyIG9mIGNvbHVtbnM6ICVkIiwKLQkJCQkg ICAgICB2ZXNhX2NvbHMpOwotCQkJCXNpemVbMF0gPSBfVkVTQV84MDB4NjAwX0RGTF9DT0xTOwor CisJCWlmIChtb2RlID09IDApIHsKKwkJCWlmIChuZXdfbW9kZV9udW0gPj0gTV9WRVNBX0JBU0Up CisJCQkJbW9kZSA9IF9JTygnVicsIG5ld19tb2RlX251bSAtIE1fVkVTQV9CQVNFKTsKKwkJCWVs c2UKKwkJCQltb2RlID0gX0lPKCdTJywgbmV3X21vZGVfbnVtKTsKKwl9CisKKwkJLyoKKwkJICog VHJ5IHNldHRpbmcgdGhlIG5ldyBtb2RlLgorCQkgKi8KKworCQlpZiAoaW9jdGwoMCwgbW9kZSwg TlVMTCkgPT0gLTEpIHsKKwkJCXJldmVydCgpOworCQkJZXJyYygxLCBlcnJubywgInNldHRpbmcg dmlkZW8gbW9kZSIpOworCQl9CisKKwkJLyoKKwkJICogRm9yIHJhc3RlciBtb2RlcyBpdCdzIG5v dCBlbm91Z2ggdG8ganVzdCBzZXQgdGhlIG1vZGUuCisJCSAqIFdlIGFsc28gbmVlZCB0byBleHBs aWNpdGx5IHNldCB0aGUgcmFzdGVyIG1vZGUuCisJCSAqLworCisJCWlmIChuZXdfbW9kZV9pbmZv LnZpX2ZsYWdzICYgVl9JTkZPX0dSQVBISUNTKSB7CisJCQkvKiBmb250IHNpemUgKi8KKworCQkJ aWYgKGZvbnRfaGVpZ2h0ID09IDApCisJCQkJZm9udF9oZWlnaHQgPSBjdXJfaW5mby5jb25zb2xl X2luZm8uZm9udF9zaXplOworCisJCQlzaXplWzJdID0gZm9udF9oZWlnaHQ7CisKKwkJCS8qIGFk anVzdCBjb2x1bW5zICovCisKKwkJCWlmICgodmVzYV9jb2xzICogOCA+IG5ld19tb2RlX2luZm8u dmlfd2lkdGgpIHx8CisJCQkgICAgKHZlc2FfY29scyA8PSAwKSkgeworCQkJCXNpemVbMF0gPSBu ZXdfbW9kZV9pbmZvLnZpX3dpZHRoIC8gODsKIAkJCX0gZWxzZSB7CiAJCQkJc2l6ZVswXSA9IHZl c2FfY29sczsKIAkJCX0KLQkJCS8qIHJvd3MgKi8KLQkJCWlmICgodmVzYV9yb3dzICogX1ZFU0Ff ODAweDYwMF9ERkxfRk5TWiA+IDYwMCkgfHwKLQkJCSAgICAodmVzYV9yb3dzIDw9MCkpIHsKLQkJ CQl3YXJueCgiaW5jb3JyZWN0IG51bWJlciBvZiByb3dzOiAlZCIsCi0JCQkJICAgICAgdmVzYV9y b3dzKTsKLQkJCQlzaXplWzFdID0gX1ZFU0FfODAweDYwMF9ERkxfUk9XUzsKKwkJCS8qIGFkanVz dCByb3dzICovCisKKwkJCWlmICgodmVzYV9yb3dzICogZm9udF9oZWlnaHQgPiBuZXdfbW9kZV9p bmZvLnZpX2hlaWdodCkgfHwKKwkJCSAgICAodmVzYV9yb3dzIDw9IDApKSB7CisJCQkJc2l6ZVsx XSA9IG5ld19tb2RlX2luZm8udmlfaGVpZ2h0IC8KKwkJCQkJICBmb250X2hlaWdodDsKIAkJCX0g ZWxzZSB7CiAJCQkJc2l6ZVsxXSA9IHZlc2Ffcm93czsKIAkJCX0KLQkJCS8qIGZvbnQgc2l6ZSAq LwotCQkJc2l6ZVsyXSA9IF9WRVNBXzgwMHg2MDBfREZMX0ZOU1o7CisvLwkJCS8qIGZvbnQgc2l6 ZSAqLworLy8JCQlzaXplWzJdID0gX1ZFU0FfODAweDYwMF9ERkxfRk5TWjsKKy8qIHNldCByYXN0 ZXIgbW9kZSAqLwogCQkJaWYgKGlvY3RsKDAsIEtEUkFTVEVSLCBzaXplKSkgewogCQkJCWlvZXJy ID0gZXJybm87CiAJCQkJaWYgKGN1cl9tb2RlID49IE1fVkVTQV9CQVNFKQpAQCAtNDEyLDQ1ICs2 ODMsNjQgQEAKIAkJCQkJICAgIE5VTEwpOwogCQkJCWVsc2UKIAkJCQkJaW9jdGwoMCwgX0lPKCdT JywgY3VyX21vZGUpLCBOVUxMKTsKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICByZXZlcnQoKTsKIAkJCQl3YXJuYyhpb2VyciwgImNhbm5vdCBhY3RpdmF0ZSByYXN0ZXIg ZGlzcGxheSIpOwogCQkJCXJldHVybiBFWElUX0ZBSUxVUkU7CiAJCQl9CiAJCX0KLQkJKCppbmRl eCkrKzsKKy8vCQkoKmluZGV4KSsrOworCisJCXZpZGVvX21vZGVfY2hhbmdlZCA9IDE7CisKKwkJ KCptb2RlX2luZGV4KSsrOwogCX0KIAlyZXR1cm4gRVhJVF9TVUNDRVNTOwogfQogCisvKgorICog UmV0dXJuIHRoZSBudW1iZXIgZm9yIGEgc3BlY2lmaWVkIGNvbG9yIG5hbWUuCisgKi8KKwogaW50 CiBnZXRfY29sb3JfbnVtYmVyKGNoYXIgKmNvbG9yKQogewogCWludCBpOwogCiAJZm9yIChpPTA7 IGk8MTY7IGkrKykKK3sKIAkJaWYgKCFzdHJjbXAoY29sb3IsIGxlZ2FsX2NvbG9yc1tpXSkpCiAJ CQlyZXR1cm4gaTsKK30KIAlyZXR1cm4gLTE7CiB9CiAKKy8qCisgKiBHZXQgbm9ybWFsIHRleHQg YW5kIGJhY2tncm91bmQgY29sb3JzLgorICovCisKIHZvaWQKLXNldF9ub3JtYWxfY29sb3JzKGlu dCBhcmdjLCBjaGFyICoqYXJndiwgaW50ICppbmRleCkKK2dldF9ub3JtYWxfY29sb3JzKGludCBh cmdjLCBjaGFyICoqYXJndiwgaW50ICpfaW5kZXgpCiB7CiAJaW50IGNvbG9yOwogCi0JaWYgKCpp bmRleCA8IGFyZ2MgJiYgKGNvbG9yID0gZ2V0X2NvbG9yX251bWJlcihhcmd2WyppbmRleF0pKSAh PSAtMSkgewotCQkoKmluZGV4KSsrOworCWlmICgqX2luZGV4IDwgYXJnYyAmJiAoY29sb3IgPSBn ZXRfY29sb3JfbnVtYmVyKGFyZ3ZbKl9pbmRleF0pKSAhPSAtMSkgeworCQkoKl9pbmRleCkrKzsK IAkJZnByaW50ZihzdGRlcnIsICIbWz0lZEYiLCBjb2xvcik7Ci0JCWlmICgqaW5kZXggPCBhcmdj Ci0JCSAgICAmJiAoY29sb3IgPSBnZXRfY29sb3JfbnVtYmVyKGFyZ3ZbKmluZGV4XSkpICE9IC0x CisJCWlmICgqX2luZGV4IDwgYXJnYworCQkgICAgJiYgKGNvbG9yID0gZ2V0X2NvbG9yX251bWJl cihhcmd2WypfaW5kZXhdKSkgIT0gLTEKIAkJICAgICYmIGNvbG9yIDwgOCkgewotCQkJKCppbmRl eCkrKzsKKwkJCSgqX2luZGV4KSsrOwogCQkJZnByaW50ZihzdGRlcnIsICIbWz0lZEciLCBjb2xv cik7CiAJCX0KIAl9CiB9CiAKKy8qCisgKiBHZXQgcmV2ZXJzZSB0ZXh0IGFuZCBiYWNrZ3JvdW5k IGNvbG9ycy4KKyAqLworCiB2b2lkCi1zZXRfcmV2ZXJzZV9jb2xvcnMoaW50IGFyZ2MsIGNoYXIg Kiphcmd2LCBpbnQgKmluZGV4KQorZ2V0X3JldmVyc2VfY29sb3JzKGludCBhcmdjLCBjaGFyICoq YXJndiwgaW50ICppbmRleCkKIHsKIAlpbnQgY29sb3I7CiAKQEAgLTQ2NSwyMyArNzU1LDUyIEBA CiAJfQogfQogCisvKgorICogU2V0IG5vcm1hbCBhbmQgcmV2ZXJzZSBmb3JlZ3JvdW5kIGFuZCBi YWNrZ3JvdW5kIGNvbG9ycy4KKyAqLworCitzdGF0aWMgdm9pZAorc2V0X2NvbG9ycyh2b2lkKQor eworCWZwcmludGYoc3RkZXJyLCAiG1s9JWRGIiwgbm9ybWFsX2ZvcmVfY29sb3IpOworCWZwcmlu dGYoc3RkZXJyLCAiG1s9JWRHIiwgbm9ybWFsX2JhY2tfY29sb3IpOworCWZwcmludGYoc3RkZXJy LCAiG1s9JWRIIiwgcmV2ZXJzX2ZvcmVfY29sb3IpOworCWZwcmludGYoc3RkZXJyLCAiG1s9JWRJ IiwgcmV2ZXJzX2JhY2tfY29sb3IpOworfQorCisKKy8qCisgKiBTd2l0Y2ggdG8gdmlydHVhbCB0 ZXJtaW5hbCAjYXJnLgorICovCisKIHZvaWQKIHNldF9jb25zb2xlKGNoYXIgKmFyZykKIHsKIAlp bnQgbjsKIAotCWlmKCAhYXJnIHx8IHN0cnNwbihhcmcsIjAxMjM0NTY3ODkiKSAhPSBzdHJsZW4o YXJnKSkgewotCQl3YXJueCgiYmFkIGNvbnNvbGUgbnVtYmVyIik7Ci0JCXJldHVybjsKKy8vCWlm KCAhYXJnIHx8IHN0cnNwbihhcmcsIjAxMjM0NTY3ODkiKSAhPSBzdHJsZW4oYXJnKSkgeworLy8J CXdhcm54KCJiYWQgY29uc29sZSBudW1iZXIiKTsKKy8vCQlyZXR1cm47CisJaWYoIWFyZyB8fCBz dHJzcG4oYXJnLCIwMTIzNDU2Nzg5IikgIT0gc3RybGVuKGFyZykpIHsKKwkJcmV2ZXJ0KCk7CisJ CWVycngoMSwgImJhZCBjb25zb2xlIG51bWJlciIpOwogCX0KIAogCW4gPSBhdG9pKGFyZyk7CiAJ aWYgKG4gPCAxIHx8IG4gPiAxNikgewotCQl3YXJueCgiY29uc29sZSBudW1iZXIgb3V0IG9mIHJh bmdlIik7Ci0JfSBlbHNlIGlmIChpb2N0bCgwLCBWVF9BQ1RJVkFURSwgKGNhZGRyX3QpIChsb25n KSBuKSA9PSAtMSkKLQkJd2FybigiaW9jdGwoVlRfQUNUSVZBVEUpIik7CisvLwkJd2FybngoImNv bnNvbGUgbnVtYmVyIG91dCBvZiByYW5nZSIpOworLy8JfSBlbHNlIGlmIChpb2N0bCgwLCBWVF9B Q1RJVkFURSwgKGNhZGRyX3QpIChsb25nKSBuKSA9PSAtMSkKKy8vCQl3YXJuKCJpb2N0bChWVF9B Q1RJVkFURSkiKTsKKwkJcmV2ZXJ0KCk7CisJCWVycngoMSwgImNvbnNvbGUgbnVtYmVyIG91dCBv ZiByYW5nZSIpOworCX0gZWxzZSBpZiAoaW9jdGwoMCwgVlRfQUNUSVZBVEUsIChjYWRkcl90KSAo bG9uZykgbikgPT0gLTEpIHsKKwkJcmV2ZXJ0KCk7CisJCWVycmMoMSwgZXJybm8sICJzd2l0Y2hp bmcgdnR5Iik7CisJfQogfQotCisvKgorICogU2V0cyB0aGUgYm9yZGVyIGNvbG9yLgorICovCiB2 b2lkCiBzZXRfYm9yZGVyX2NvbG9yKGNoYXIgKmFyZykKIHsKQEAgLTUwMiwxMiArODIxLDE3IEBA CiAKIAlsID0gc3RydG9sKGFyZywgTlVMTCwgMCk7CiAJaWYgKChsIDwgMCkgfHwgKGwgPiBVQ0hB Ul9NQVggLSAzKSkgeworICAgICAgICAgICAgICAgICAgICByZXZlcnQoKTsKIAkJd2FybngoImFy Z3VtZW50IHRvIC1NIG11c3QgYmUgMCB0aHJvdWdoICVkIiwgVUNIQVJfTUFYIC0gMyk7CiAJCXJl dHVybjsKIAl9CiAJbW91c2Uub3BlcmF0aW9uID0gTU9VU0VfTU9VU0VDSEFSOwogCW1vdXNlLnUu bW91c2VfY2hhciA9IChpbnQpbDsKLQlpb2N0bCgwLCBDT05TX01PVVNFQ1RMLCAmbW91c2UpOwor Ly8JaW9jdGwoMCwgQ09OU19NT1VTRUNUTCwgJm1vdXNlKTsKKwlpZiAoaW9jdGwoMCwgQ09OU19N T1VTRUNUTCwgJm1vdXNlKSA9PSAtMSkgeworCQlyZXZlcnQoKTsKKwkJZXJyYygxLCBlcnJubywg InNldHRpbmcgbW91c2UgY2hhcmFjdGVyIik7CisJfQogfQogCiB2b2lkCkBAIC01MTUsMTUgKzgz OSwyNSBAQAogewogCXN0cnVjdCBtb3VzZV9pbmZvIG1vdXNlOwogCi0JaWYgKCFzdHJjbXAoYXJn LCAib24iKSkKKwlpZiAoIXN0cmNtcChhcmcsICJvbiIpKSB7CiAJCW1vdXNlLm9wZXJhdGlvbiA9 IE1PVVNFX1NIT1c7Ci0JZWxzZSBpZiAoIXN0cmNtcChhcmcsICJvZmYiKSkKKwl9IGVsc2UgaWYg KCFzdHJjbXAoYXJnLCAib2ZmIikpIHsKIAkJbW91c2Uub3BlcmF0aW9uID0gTU9VU0VfSElERTsK LQllbHNlIHsKLQkJd2FybngoImFyZ3VtZW50IHRvIC1tIG11c3QgYmUgZWl0aGVyIG9uIG9yIG9m ZiIpOwotCQlyZXR1cm47CisvLwllbHNlIHsKKy8vCQl3YXJueCgiYXJndW1lbnQgdG8gLW0gbXVz dCBiZSBlaXRoZXIgb24gb3Igb2ZmIik7CisvLwkJcmV0dXJuOworCX0KKyAgICAgICAgICBlbHNl IHsKKwkJcmV2ZXJ0KCk7CisJCWVycngoMSwgImFyZ3VtZW50IHRvIC1tIG11c3QgYmUgZWl0aGVy IG9uIG9yIG9mZiIpOwogCX0KLQlpb2N0bCgwLCBDT05TX01PVVNFQ1RMLCAmbW91c2UpOworCisJ aWYgKGlvY3RsKDAsIENPTlNfTU9VU0VDVEwsICZtb3VzZSkgPT0gLTEpIHsKKwkJcmV2ZXJ0KCk7 CisJCWVycmMoMSwgZXJybm8sICIlc2luZyB0aGUgbW91c2UiLAorCQkgICAgIG1vdXNlLm9wZXJh dGlvbiA9PSBNT1VTRV9TSE9XID8gInNob3ciIDogImhpZCIpOworCX0KKy8vCWlvY3RsKDAsIENP TlNfTU9VU0VDVEwsICZtb3VzZSk7CiB9CiAKIHZvaWQKQEAgLTUzMSwxNiArODY1LDI1IEBACiB7 CiAJaW50IGRhdGE7CiAKLQlpZiAoIXN0cmNtcChhcmcsICJvZmYiKSkKKwlpZiAoIXN0cmNtcChh cmcsICJvZmYiKSkgewogCQlkYXRhID0gMHgwMTsKLQllbHNlIGlmICghc3RyY21wKGFyZywgIm9u IikpCisJfSBlbHNlIGlmICghc3RyY21wKGFyZywgIm9uIikpIHsKIAkJZGF0YSA9IDB4MDI7Ci0J ZWxzZSB7Ci0JCXdhcm54KCJhcmd1bWVudCB0byAtUyBtdXN0IGJlIGVpdGhlciBvbiBvciBvZmYi KTsKLQkJcmV0dXJuOworLy8JfSBlbHNlIHsKKy8vCQl3YXJueCgiYXJndW1lbnQgdG8gLVMgbXVz dCBiZSBlaXRoZXIgb24gb3Igb2ZmIik7CisvLwkJcmV0dXJuOworCX0gZWxzZSB7CisJCXJldmVy dCgpOworCQllcnJ4KDEsICJhcmd1bWVudCB0byAtUyBtdXN0IGJlIGVpdGhlciBvbiBvciBvZmYi KTsKIAl9Ci0JaWYgKGlvY3RsKDAsIFZUX0xPQ0tTV0lUQ0gsICZkYXRhKSA9PSAtMSkKLQkJd2Fy bigiaW9jdGwoVlRfTE9DS1NXSVRDSCkiKTsKKworaWYgKGlvY3RsKDAsIFZUX0xPQ0tTV0lUQ0gs ICZkYXRhKSA9PSAtMSkgeworCQlyZXZlcnQoKTsKKwkJZXJyYygxLCBlcnJubywgInR1cm5pbmcg JXMgdnR5IHN3aXRjaGluZyIsCisJCSAgICAgZGF0YSA9PSAweDAxID8gIm9mZiIgOiAib24iKTsK Kwl9CisvLwlpZiAoaW9jdGwoMCwgVlRfTE9DS1NXSVRDSCwgJmRhdGEpID09IC0xKQorLy8JCXdh cm4oImlvY3RsKFZUX0xPQ0tTV0lUQ0gpIik7CiB9CiAKIHN0YXRpYyBjaGFyCkBAIC01NjcsMTUg KzkxMCwyMiBAQAogICAgIHJldHVybiBuYW1lc1tpXS5uYW1lOwogfQogCisvKgorICogU2hvdyBn cmFwaGljcyBhZGFwdGVyIGluZm9ybWF0aW9uLgorICovCisKIHZvaWQKIHNob3dfYWRhcHRlcl9p bmZvKHZvaWQpCiB7CiAJc3RydWN0IHZpZGVvX2FkYXB0ZXJfaW5mbyBhZDsKIAogCWFkLnZhX2lu ZGV4ID0gMDsKLQlpZiAoaW9jdGwoMCwgQ09OU19BRFBJTkZPLCAmYWQpKSB7Ci0JCXdhcm4oImZh aWxlZCB0byBvYnRhaW4gYWRhcHRlciBpbmZvcm1hdGlvbiIpOwotCQlyZXR1cm47CisvLwlpZiAo aW9jdGwoMCwgQ09OU19BRFBJTkZPLCAmYWQpKSB7CisvLwkJd2FybigiZmFpbGVkIHRvIG9idGFp biBhZGFwdGVyIGluZm9ybWF0aW9uIik7CisvLwkJcmV0dXJuOworCWlmIChpb2N0bCgwLCBDT05T X0FEUElORk8sICZhZCkgPT0gLTEpIHsKKwkJcmV2ZXJ0KCk7CisJCWVycmMoMSwgZXJybm8sICJv YnRhaW5pbmcgYWRhcHRlciBpbmZvcm1hdGlvbiIpOwogCX0KIAogCXByaW50ZigiZmIlZDpcbiIs IGFkLnZhX2luZGV4KTsKQEAgLTU5Myw3ICs5NDMsOSBAQAogCSAgICAgICBhZC52YV9kaXNwX3N0 YXJ0LngsIGFkLnZhX2Rpc3Bfc3RhcnQueSwgYWQudmFfbGluZV93aWR0aCk7CiAJcHJpbnRmKCIg ICAgcmVzZXJ2ZWQ6MHgleFxuIiwgYWQudmFfdW51c2VkMCk7CiB9Ci0KKy8qCisgKiBTaG93IHZp ZGVvIG1vZGUgaW5mb3JtYXRpb24uCisgKi8KIHZvaWQKIHNob3dfbW9kZV9pbmZvKHZvaWQpCiB7 CkBAIC02NDUsOCArOTk3LDEwIEBACiAJZWxzZSBpZiAoIXN0cmNtcChhcmcsICJtb2RlIikpCiAJ CXNob3dfbW9kZV9pbmZvKCk7CiAJZWxzZSB7Ci0JCXdhcm54KCJhcmd1bWVudCB0byAtaSBtdXN0 IGJlIGVpdGhlciBhZGFwdGVyIG9yIG1vZGUiKTsKLQkJcmV0dXJuOworLy8JCXdhcm54KCJhcmd1 bWVudCB0byAtaSBtdXN0IGJlIGVpdGhlciBhZGFwdGVyIG9yIG1vZGUiKTsKKy8vCQlyZXR1cm47 CisJCXJldmVydCgpOworCQllcnJ4KDEsICJhcmd1bWVudCB0byAtaSBtdXN0IGJlIGVpdGhlciBh ZGFwdGVyIG9yIG1vZGUiKTsKIAl9CiB9CiAKQEAgLTY4Miw3ICsxMDM2LDkgQEAKIAogCWluZm8u c2l6ZSA9IHNpemVvZihpbmZvKTsKIAlpZiAoaW9jdGwoMCwgQ09OU19HRVRJTkZPLCAmaW5mbykg PT0gLTEpIHsKLQkJd2FybigiZmFpbGVkIHRvIG9idGFpbiBjdXJyZW50IHZpZGVvIG1vZGUgcGFy YW1ldGVycyIpOworLy8JCXdhcm4oImZhaWxlZCB0byBvYnRhaW4gY3VycmVudCB2aWRlbyBtb2Rl IHBhcmFtZXRlcnMiKTsKKwkJcmV2ZXJ0KCk7CisJCWVycmMoMSwgZXJybm8sICJvYnRhaW5pbmcg Y3VycmVudCB2aWRlbyBtb2RlIHBhcmFtZXRlcnMiKTsKIAkJcmV0dXJuOwogCX0KIApAQCAtNjk0 LDEzICsxMDUwLDE3IEBACiAKIAlzaG90LmJ1ZiA9IGFsbG9jYShzaG90LnhzaXplICogc2hvdC55 c2l6ZSAqIHNpemVvZih1X2ludDE2X3QpKTsKIAlpZiAoc2hvdC5idWYgPT0gTlVMTCkgewotCQl3 YXJuKCJmYWlsZWQgdG8gYWxsb2NhdGUgbWVtb3J5IGZvciBkdW1wIik7Ci0JCXJldHVybjsKKy8v CQl3YXJuKCJmYWlsZWQgdG8gYWxsb2NhdGUgbWVtb3J5IGZvciBkdW1wIik7CisJCXJldmVydCgp OworCQllcnJ4KDEsICJmYWlsZWQgdG8gYWxsb2NhdGUgbWVtb3J5IGZvciBkdW1wIik7CisvLwkJ cmV0dXJuOwogCX0KIAogCWlmIChpb2N0bCgwLCBDT05TX1NDUlNIT1QsICZzaG90KSA9PSAtMSkg ewotCQl3YXJuKCJmYWlsZWQgdG8gZ2V0IGR1bXAgb2YgdGhlIHNjcmVlbiIpOwotCQlyZXR1cm47 CisvLwkJd2FybigiZmFpbGVkIHRvIGdldCBkdW1wIG9mIHRoZSBzY3JlZW4iKTsKKy8vCQlyZXR1 cm47CisJCXJldmVydCgpOworCQllcnJjKDEsIGVycm5vLCAiZHVtcGluZyBzY3JlZW4iKTsKIAl9 CiAKIAlpZiAobW9kZSA9PSBEVU1QX0ZNVF9SQVcpIHsKQEAgLTcwOCw4ICsxMDY4LDEwIEBACiAJ CSAgICAgICBzaG90LnhzaXplLCBzaG90LnlzaXplKTsKIAkJZmZsdXNoKHN0ZG91dCk7CiAKLQkJ KHZvaWQpd3JpdGUoU1RET1VUX0ZJTEVOTywgc2hvdC5idWYsCi0JCQkgICAgc2hvdC54c2l6ZSAq IHNob3QueXNpemUgKiBzaXplb2YodV9pbnQxNl90KSk7CisvLwkJKHZvaWQpd3JpdGUoU1RET1VU X0ZJTEVOTywgc2hvdC5idWYsCisvLwkJCSAgICBzaG90LnhzaXplICogc2hvdC55c2l6ZSAqIHNp emVvZih1X2ludDE2X3QpKTsKKwkJd3JpdGUoU1RET1VUX0ZJTEVOTywgc2hvdC5idWYsCisJCSAg ICAgIHNob3QueHNpemUgKiBzaG90LnlzaXplICogc2l6ZW9mKHVfaW50MTZfdCkpOwogCX0gZWxz ZSB7CiAJCWNoYXIgKmxpbmU7CiAJCWludCB4LCB5OwpAQCAtNzE3LDggKzEwNzksMTAgQEAKIAog CQlsaW5lID0gYWxsb2NhKHNob3QueHNpemUgKyAxKTsKIAkJaWYgKGxpbmUgPT0gTlVMTCkgewot CQkJd2FybigiZmFpbGVkIHRvIGFsbG9jYXRlIG1lbW9yeSBmb3IgbGluZSBidWZmZXIiKTsKLQkJ CXJldHVybjsKKy8vCQkJd2FybigiZmFpbGVkIHRvIGFsbG9jYXRlIG1lbW9yeSBmb3IgbGluZSBi dWZmZXIiKTsKKy8vCQkJcmV0dXJuOworCQkJcmV2ZXJ0KCk7CisJCQllcnJ4KDEsICJmYWlsZWQg dG8gYWxsb2NhdGUgbWVtb3J5IGZvciBsaW5lIGJ1ZmZlciIpOwogCQl9CiAKIAkJZm9yICh5ID0g MDsgeSA8IHNob3QueXNpemU7IHkrKykgewpAQCAtNzQyLDcgKzExMDYsOSBAQAogCiAJcmV0dXJu OwogfQotCisvKgorICogU2V0IHRoZSBjb25zb2xlIGhpc3RvcnkgYnVmZmVyIHNpemUuCisgKi8K IHZvaWQKIHNldF9oaXN0b3J5KGNoYXIgKm9wdCkKIHsKQEAgLTc1MCwxOSArMTExNiwzMiBAQAog CiAJc2l6ZSA9IGF0b2kob3B0KTsKIAlpZiAoKCpvcHQgPT0gJ1wwJykgfHwgc2l6ZSA8IDApIHsK LQkJd2FybngoImFyZ3VtZW50IG11c3QgYmUgYSBwb3NpdGl2ZSBudW1iZXIiKTsKLQkJcmV0dXJu OworLy8JCXdhcm54KCJhcmd1bWVudCBtdXN0IGJlIGEgcG9zaXRpdmUgbnVtYmVyIik7CisvLwkJ cmV0dXJuOworCQlyZXZlcnQoKTsKKwkJZXJyeCgxLCAiYXJndW1lbnQgbXVzdCBiZSBhIHBvc2l0 aXZlIG51bWJlciIpOworCX0KKworCWlmIChpb2N0bCgwLCBDT05TX0hJU1RPUlksICZzaXplKSA9 PSAtMSkgeworCQlyZXZlcnQoKTsKKwkJZXJyYygxLCBlcnJubywgInNldHRpbmcgaGlzdG9yeSBi dWZmZXIgc2l6ZSIpOwogCX0KLQlpZiAoaW9jdGwoMCwgQ09OU19ISVNUT1JZLCAmc2l6ZSkgPT0g LTEpCi0JCXdhcm4oInNldHRpbmcgaGlzdG9yeSBidWZmZXIgc2l6ZSIpOwogfQogCisvKgorICog Q2xlYXIgdGhlIGNvbnNvbGUgaGlzdG9yeSBidWZmZXIuCisgKi8KKwogdm9pZAogY2xlYXJfaGlz dG9yeSgpCiB7CiAKLQlpZiAoaW9jdGwoMCwgQ09OU19DTFJISVNUKSA9PSAtMSkKLQkJd2Fybigi Y2xlYXIgaGlzdG9yeSBidWZmZXIiKTsKKy8vCWlmIChpb2N0bCgwLCBDT05TX0NMUkhJU1QpID09 IC0xKQorLy8JCXdhcm4oImNsZWFyIGhpc3RvcnkgYnVmZmVyIik7CisJaWYgKGlvY3RsKDAsIENP TlNfQ0xSSElTVCkgPT0gLTEpIHsKKwkJcmV2ZXJ0KCk7CisJCWVycmMoMSwgZXJybm8sICJjbGVh cmluZyBoaXN0b3J5IGJ1ZmZlciIpOworCX0KIH0KIAogaW50CkBAIC03NzEsMTIgKzExNTAsMTAg QEAKIAljaGFyCSpmb250LCAqdHlwZTsKIAlpbnQJZHVtcG1vZCwgZHVtcG9wdCwgb3B0OwogCWlu dAlyZXRlcnI7Ci0KKwlpbml0KCk7CiAJaW5mby5zaXplID0gc2l6ZW9mKGluZm8pOwotCWlmIChh cmdjID09IDEpCi0JCXVzYWdlKCk7Ci0JCS8qIE5vdCByZWFjaGVkICovCi0JaWYgKGlvY3RsKDAs IENPTlNfR0VUSU5GTywgJmluZm8pIDwgMCkKKworCWlmIChpb2N0bCgwLCBDT05TX0dFVElORk8s ICZpbmZvKSA9PSAtMSkKIAkJZXJyKDEsICJtdXN0IGJlIG9uIGEgdmlydHVhbCBjb25zb2xlIik7 CiAJZHVtcG1vZCA9IDA7CiAJZHVtcG9wdCA9IERVTVBfRkJGOwpAQCAtODA0LDkgKzExODEsMTIg QEAKIAkJCWxvYWRfZm9udCh0eXBlLCBmb250KTsKIAkJCWJyZWFrOwogCQljYXNlICdnJzoKLQkJ CWlmIChzc2NhbmYob3B0YXJnLCAiJWR4JWQiLCAmdmVzYV9jb2xzLAotCQkJICAgICZ2ZXNhX3Jv d3MpICE9IDIpIHsKLQkJCQl3YXJueCgiaW5jb3JyZWN0IGdlb21ldHJ5OiAlcyIsIG9wdGFyZyk7 CisvLwkJCWlmIChzc2NhbmYob3B0YXJnLCAiJWR4JWQiLCAmdmVzYV9jb2xzLAorLy8JCQkgICAg JnZlc2Ffcm93cykgIT0gMikgeworCisJCQkJaWYgKHNzY2FuZihvcHRhcmcsICIlZHglZCIsCisJ CQkgICAgJnZlc2FfY29scywgJnZlc2Ffcm93cykgIT0gMikgeworCQkJCXJldmVydCgpOwkJd2Fy bngoImluY29ycmVjdCBnZW9tZXRyeTogJXMiLCBvcHRhcmcpOwogCQkJCXVzYWdlKCk7CiAJCQl9 CiAJCQlicmVhazsKQEAgLTgzOCw3ICsxMjE4LDcgQEAKIAkJCWR1bXBtb2QgPSBEVU1QX0ZNVF9U WFQ7CiAJCQlicmVhazsKIAkJY2FzZSAncic6Ci0JCQlzZXRfcmV2ZXJzZV9jb2xvcnMoYXJnYywg YXJndiwgJm9wdGluZCk7CisJCQlnZXRfcmV2ZXJzZV9jb2xvcnMoYXJnYywgYXJndiwgJm9wdGlu ZCk7CiAJCQlicmVhazsKIAkJY2FzZSAnUyc6CiAJCQlzZXRfbG9ja3N3aXRjaChvcHRhcmcpOwpA QCAtODU4LDEzICsxMjM4LDMyIEBACiAJaWYgKGR1bXBtb2QgIT0gMCkKIAkJZHVtcF9zY3JlZW4o ZHVtcG1vZCwgZHVtcG9wdCk7CiAJcmV0ZXJyID0gdmlkZW9fbW9kZShhcmdjLCBhcmd2LCAmb3B0 aW5kKTsKLQlzZXRfbm9ybWFsX2NvbG9ycyhhcmdjLCBhcmd2LCAmb3B0aW5kKTsKKwlnZXRfbm9y bWFsX2NvbG9ycyhhcmdjLCBhcmd2LCAmb3B0aW5kKTsKIAlpZiAob3B0aW5kIDwgYXJnYyAmJiAh c3RyY21wKGFyZ3Zbb3B0aW5kXSwgInNob3ciKSkgewogCQl0ZXN0X2ZyYW1lKCk7CiAJCW9wdGlu ZCsrOwogCX0KKworCXZpZGVvX21vZGUoYXJnYywgYXJndiwgJm9wdGluZCk7CisKKwlnZXRfbm9y bWFsX2NvbG9ycyhhcmdjLCBhcmd2LCAmb3B0aW5kKTsKKworCWlmIChjb2xvcnNfY2hhbmdlZCB8 fCB2aWRlb19tb2RlX2NoYW5nZWQpIHsKKwkJaWYgKCEobmV3X21vZGVfaW5mby52aV9mbGFncyAm IFZfSU5GT19HUkFQSElDUykpIHsKKwkJCWlmICgobm9ybWFsX2JhY2tfY29sb3IgPCA4KSAmJiAo cmV2ZXJzX2JhY2tfY29sb3IgPCA4KSkgeworCQkJCXNldF9jb2xvcnMoKTsKKwkJCX0gZWxzZSB7 CisJCQkJcmV2ZXJ0KCk7CisJCQkJZXJyeCgxLCAiYmcgY29sb3IgZm9yIHRleHQgbW9kZXMgbXVz dCBiZSA8IDgiKTsKKwkJCX0KKwkJfSBlbHNlIHsKKwkJCXNldF9jb2xvcnMoKTsKKwkJfQorCX0K KwogCWlmICgob3B0aW5kICE9IGFyZ2MpIHx8IChhcmdjID09IDEpKQogCQl1c2FnZSgpOwogCXJl dHVybiByZXRlcnI7CiB9CisKIAo= --------------Boundary-00=_BVNA40MWKGMMYJ0CCJD0-- From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 19:16: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 44ED516A41C for ; Sat, 18 Jun 2005 19:16:33 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from smtp4.server.rpi.edu (smtp4.server.rpi.edu [128.113.2.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0C6E043D49 for ; Sat, 18 Jun 2005 19:16:32 +0000 (GMT) (envelope-from gad@FreeBSD.org) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by smtp4.server.rpi.edu (8.13.0/8.13.0) with ESMTP id j5IJGSim011736; Sat, 18 Jun 2005 15:16:31 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <42B46171.2070606@oslonett.no> References: <42B46171.2070606@oslonett.no> Date: Sat, 18 Jun 2005 15:16:27 -0400 To: Morten Johansen , freebsd-current@FreeBSD.org From: Garance A Drosehn Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-CanItPRO-Stream: default X-RPI-SA-Score: undef - spam-scanning disabled X-Scanned-By: CanIt (www . canit . ca) on 128.113.2.4 Cc: Subject: Re: [patch] panic executing shell-script 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, 18 Jun 2005 19:16:33 -0000 At 8:01 PM +0200 6/18/05, Morten Johansen wrote: >Hi -current, > >When executing a shell-script where interpreter-name has 2 or more >trailing whitespace, kernel panics. >E.g. bin/jetty.sh from port www/jetty. > >Fix: > >--- imgact_shell.c Thu Jun 9 02:27:02 2005 >+++ imgact_shell.c.mj Sat Jun 18 19:33:00 2005 >@@ -161,7 +161,7 @@ exec_shell_imgact(imgp) > while (ihp < maxp && ((*ihp != '\n') && (*ihp != '\0'))) > ihp++; > opte = ihp; >- while (--ihp > interpe && ((*ihp == ' ') || (*ihp == '\t'))) >+ while (--ihp > optb && ((*ihp == ' ') || (*ihp == '\t'))) > opte = ihp; > > /* That looks like my fault. I'll look into it. Thanks for the report. -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@FreeBSD.org Rensselaer Polytechnic Institute; Troy, NY; USA From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 21:23: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 20E3B16A41C; Sat, 18 Jun 2005 21:23:19 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from efnet-math.org (efnet-math.org [69.60.109.125]) by mx1.FreeBSD.org (Postfix) with ESMTP id BB60E43D1D; Sat, 18 Jun 2005 21:23:18 +0000 (GMT) (envelope-from ssouhlal@FreeBSD.org) Received: from [192.168.1.12] (63-170-138-118.cst-sg.blacksburg.ntc-com.net [63.170.138.118]) (authenticated bits=0) by efnet-math.org (8.13.1/8.13.1) with ESMTP id j5ILNFVY003127 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Sat, 18 Jun 2005 17:23:16 -0400 In-Reply-To: <20050618171216.GA661@gothmog.gr> References: <20050618171216.GA661@gothmog.gr> Mime-Version: 1.0 (Apple Message framework v730) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <38B71BBE-6E71-43F5-AD70-1C0FE29F8A08@FreeBSD.org> Content-Transfer-Encoding: 7bit From: Suleiman Souhlal Date: Sat, 18 Jun 2005 17:23:08 -0400 To: Giorgos Keramidas X-Mailer: Apple Mail (2.730) Cc: Jun Kuriyama , Current Current , Xin LI Subject: Re: panics with today'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: Sat, 18 Jun 2005 21:23:19 -0000 Hi, On Jun 18, 2005, at 1:12 PM, Giorgos Keramidas wrote: > Today's current panics whenever I try to build mail/procmail a little > after the following appears on the screen: > > Jun 18 19:50:13 gothmog kernel: Acquiring lockmgr lock "ufs" with > the following non-sleepable locks held: > Jun 18 19:50:13 gothmog kernel: exclusive sleep mutex vnode > pollinfo r = 0 (0xc1ebc000) locked @ /usr/src/sys/kern/kern_event.c: > 881 Jun Kuriyama and Xin LI have reported this in the past week. The patch at http://people.freebsd.org/~ssouhlal/testing/ knlist_locking-20050618.diff should fix this. Can you please give it a try? -- Suleiman Souhlal | ssouhlal@vt.edu The FreeBSD Project | ssouhlal@FreeBSD.org From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 23:11: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 9C08016A41C for ; Sat, 18 Jun 2005 23:11:17 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id A57BA43D1F for ; Sat, 18 Jun 2005 23:11:16 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: (qmail 16028 invoked by uid 207); 18 Jun 2005 23:11:16 -0000 Received: from keramida@freebsd.org by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.19/3.81. Clear:RC:1(81.186.70.94):. Processed in 0.447179 secs); 18 Jun 2005 23:11:16 -0000 Received: from dialup94.ach.sch.gr (HELO gothmog.gr) ([81.186.70.94]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Jun 2005 23:11:15 -0000 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.4/8.13.4) with ESMTP id j5INB86u009887; Sun, 19 Jun 2005 02:11:08 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.4/8.13.4/Submit) id j5INB8K4009886; Sun, 19 Jun 2005 02:11:08 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sun, 19 Jun 2005 02:11:07 +0300 From: Giorgos Keramidas To: Suleiman Souhlal Message-ID: <20050618231107.GA9438@gothmog.gr> References: <20050618171216.GA661@gothmog.gr> <38B71BBE-6E71-43F5-AD70-1C0FE29F8A08@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <38B71BBE-6E71-43F5-AD70-1C0FE29F8A08@FreeBSD.org> Cc: Jun Kuriyama , Current Current , Xin LI Subject: Re: panics with today'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: Sat, 18 Jun 2005 23:11:17 -0000 On 2005-06-18 17:23, Suleiman Souhlal wrote: > On Jun 18, 2005, at 1:12 PM, Giorgos Keramidas wrote: > >Today's current panics whenever I try to build mail/procmail a little > >after the following appears on the screen: > > > >Jun 18 19:50:13 gothmog kernel: Acquiring lockmgr lock "ufs" with > >the following non-sleepable locks held: > >Jun 18 19:50:13 gothmog kernel: exclusive sleep mutex vnode > >pollinfo r = 0 (0xc1ebc000) locked @ /usr/src/sys/kern/kern_event.c:881 > > Jun Kuriyama and Xin LI have reported this in the past week. > The patch at http://people.freebsd.org/~ssouhlal/testing/ > knlist_locking-20050618.diff should fix this. Can you please give it > a try? I haven't been able to track freebsd-current very closely the past couple of weeks, so I missed the relevant posts. Thanks for the pointer to the diff. I'm building a kernel now... From owner-freebsd-current@FreeBSD.ORG Sat Jun 18 23:42: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 C866E16A420 for ; Sat, 18 Jun 2005 23:42:52 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: from nic.ach.sch.gr (nic.sch.gr [194.63.238.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id CF4D243D48 for ; Sat, 18 Jun 2005 23:42:51 +0000 (GMT) (envelope-from keramida@freebsd.org) Received: (qmail 20258 invoked by uid 207); 18 Jun 2005 23:42:51 -0000 Received: from keramida@freebsd.org by nic by uid 201 with qmail-scanner-1.21 (sophie: 3.04/2.19/3.81. Clear:RC:1(81.186.70.94):. Processed in 0.551317 secs); 18 Jun 2005 23:42:51 -0000 Received: from dialup94.ach.sch.gr (HELO gothmog.gr) ([81.186.70.94]) (envelope-sender ) by nic.sch.gr (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 18 Jun 2005 23:42:50 -0000 Received: from gothmog.gr (gothmog [127.0.0.1]) by gothmog.gr (8.13.4/8.13.4) with ESMTP id j5INgfoA001637; Sun, 19 Jun 2005 02:42:41 +0300 (EEST) (envelope-from keramida@freebsd.org) Received: (from giorgos@localhost) by gothmog.gr (8.13.4/8.13.4/Submit) id j5INgb98001636; Sun, 19 Jun 2005 02:42:37 +0300 (EEST) (envelope-from keramida@freebsd.org) Date: Sun, 19 Jun 2005 02:42:33 +0300 From: Giorgos Keramidas To: Suleiman Souhlal Message-ID: <20050618234233.GA1563@gothmog.gr> References: <20050618171216.GA661@gothmog.gr> <38B71BBE-6E71-43F5-AD70-1C0FE29F8A08@FreeBSD.org> <20050618231107.GA9438@gothmog.gr> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050618231107.GA9438@gothmog.gr> Cc: Jun Kuriyama , freebsd-current@freebsd.org, Xin LI Subject: Re: panics with today'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: Sat, 18 Jun 2005 23:42:52 -0000 On 2005-06-19 02:11, Giorgos Keramidas wrote: > On 2005-06-18 17:23, Suleiman Souhlal wrote: > > >Jun 18 19:50:13 gothmog kernel: Acquiring lockmgr lock "ufs" with > > >the following non-sleepable locks held: > > >Jun 18 19:50:13 gothmog kernel: exclusive sleep mutex vnode > > >pollinfo r = 0 (0xc1ebc000) locked @ /usr/src/sys/kern/kern_event.c:881 > > > > Jun Kuriyama and Xin LI have reported this in the past week. > > The patch at http://people.freebsd.org/~ssouhlal/testing/ > > knlist_locking-20050618.diff should fix this. Can you please give it > > a try? > > I haven't been able to track freebsd-current very closely the past > couple of weeks, so I missed the relevant posts. Thanks for the pointer > to the diff. I'm building a kernel now... Great! This works fine. I've just rebuilt procmail and run through its tests without any lock overrides in the system log and, more importantly, without any panics :)